Vugen script reply Error - Failed to connect to server "xxxxx.com:443": [10060] Connection timed out

1,210 views
Skip to first unread message

performanc...@gmail.com

unread,
Jun 12, 2016, 5:51:03 PM6/12/16
to LoadRunner

I am able to access the application manually and able to record a Web(HTTP/HTML) script using Vugen11.52 but while replying a script, getting “Connection timed out” error.
Environment: Vugen 11.52, IE11, RTS: Proxy-Obtain the proxy settings from the default browser

Tried below options but no luck.

  • Increased HTTP Request and Keep Alive Timeouts
  • Added web_set_sockets_option("SSL_VERSION", "TLS");
  • Replied script with “Winnet reply instead of Sockets”, error: "HttpSendRequest" failed, Windows error code=12029 (cannot connect) and retry limit (0) exceeded for URL=”

 Any suggestion would be highly appreciated.

Krishna Koduru

unread,
Jun 12, 2016, 6:56:20 PM6/12/16
to LR-Loa...@googlegroups.com
Uncheck the option "Winnet reply instead of Sockets" and give a try.

Best regards,
Krishna Koduru.

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.
To post to this group, send email to LR-Loa...@googlegroups.com.
Visit this group at https://groups.google.com/group/LR-LoadRunner.
To view this discussion on the web visit https://groups.google.com/d/msgid/LR-LoadRunner/eba138f4-149d-4439-b4fa-93a2305c5f17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
--- 
Krishna Koduru,
Associate - Projects,
Cognizant Technology Solutions Pvt Ltd,
Contact: 
+44 7440225806 (Scotland)
.

James Pulley

unread,
Jun 13, 2016, 9:55:35 AM6/13/16
to LoadRunner
Architecturally, think very carefully about what is happening. What tier is the cause of the connection failure?  Do you have maximal logging enabled to gain insight?   Have you deployed Wiresharkl alongside your replay to see where the connection fails?   Levarage your foundation skills in architecture, networks and troubleshooting to ID where and why the failure occurs.  This should lead naturally to a resolution to address the issue.

Changing your timeouts is not an appropriate response.   The standard browser timeout is 120 seconds for HTTP from the send of the request.  Your end users cannot adjust this issue and you should not either.   Also, the connection timeout is fixed from a TCP perspective for retry, which your users cannot change.   You appear to want to remove errors rather than understand why and fix the error.

You might also want to try to search for information on Winsock 12029 for greater insight as to possible causes.  This might allow you to form a hypothesis that you can test against with information coming out of Wireshark and the extended logs.

James Pulley
Reply all
Reply to author
Forward
0 new messages