Highlighted
Super Contributor.
Super Contributor.
1524 views

Intermitted LG failure connecting to Saas Performance Center

Jump to solution

Hello
I'm hoping you can help me resolve the following errors. I'm getting these intermittently, and they cause any test running to fall over, and I need to reboot the load generator host from Performance Center, before I can resume.

I have executed the same test at different times, so I believe my scenario is OK. I just cannot seem to find any relevant reason or solution as to why these errors occur, and I therfore don't know how to resolve.

We have other load generators, that are connection OK to the Saas environment, and they run the same versions, and we do not encounter these issues.

Any guidance you could provide would be appreciated.

Errors in LoadRunner_agent_service.log
30/01/2017 16:44:01 Error: Communication error: SSL write error : [param not passed in call]. (sys error message - WSAECONNABORTED) [MsgId: MERR-10343]
30/01/2017 16:44:01 Error: Client almrwcpcmt125-mil5.saas.hpe.com is not responding. [MsgId: MERR-29992]
30/01/2017 16:44:01 Error: Communication error: The Client failed to send packet. The socket has been shut down. [MsgId: MERR-10343]
30/01/2017 16:44:01 Error: Communication error: The Client failed to send packet. The socket has been shut down. [MsgId: MERR-10343]
30/01/2017 16:44:01 Error: Two Way Communication Error: Function two_way_comm_post_message / two_way_comm_post_message_ex failed. [MsgId: MERR-60990]
30/01/2017 16:44:01 Error: Communication error: The Client failed to send packet. The socket has been shut down. [MsgId: MERR-10343]


Errors in RemoteManagement_agent_service.log
30/01/2017 09:46:31 Error: Communication error: The client SSL certificate is not trusted by the server. [MsgId: MERR-10343]
30/01/2017 09:46:31 Error: Two Way Communication Error: Function two_way_comm_resolve_userdata failed. Reason: invalid handle. [MsgId: MERR-60985]
30/01/2017 09:46:31 Error: Communication error: SSL write error : [param not passed in call]. (sys error message - WSAECONNRESET) [MsgId: MERR-10343]
30/01/2017 09:46:31 Error: Communication error: SSL write error : [param not passed in call]. (sys error message - WSAECONNRESET) [MsgId: MERR-10343]
30/01/2017 09:46:31 Error: Communication error: SSL write error : [param not passed in call]. (sys error message - WSAECONNRESET) [MsgId: MERR-10343]
30/01/2017 10:15:44 Error: Two Way Communication Error: Function two_way_comm_resolve_userdata failed. Reason: invalid handle. [MsgId: MERR-60985]
30/01/2017 14:05:40 Error: Communication error: Failed to connect to remote host [server full name: almrwcpcmt125-mil5.saas.hpe.com]. [MsgId: MERR-10343]
30/01/2017 14:05:40 Error: Two Way Communication Error: Function two_way_comm_resolve_userdata failed. Reason: invalid handle. [MsgId: MERR-60985]
30/01/2017 14:05:40 Error: Communication error: Failed to send message - socket is not connected yet. [MsgId: MERR-10343]

0 Likes
1 Solution

Accepted Solutions
Highlighted
Super Contributor.
Super Contributor.

Just an update, that we have resolved this issue locally.

Basically, having run a wireshark trace, filtering between out LG and the MI listener, it was observed that we had a lot of packet retransmissions and such like accumulating in the run up to failure.

Running a test on another LG did not generate any issues.

It was then observed that the original LG only had a link speed of 100 Mbps, whereas the second LG had a link speed of 1 Gbps.  After speaking with our network team, it was established that we may have had an issue with the switch relating to our lab in recent weeks, that I wasn't previously aware of.  We hooked the LG into a 1 Gbps link, and the test completes again successfully without any issue.

The 'network performance' view on the LG didn't really highlight any capacity issues.  It wasn't until we studied the wireshark trace and investigated further, that we noticed the link speed issue.

View solution in original post

0 Likes
15 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hello ClaireMcG

Thank you for your post.

ClaireMcG, I appreciate if you let me know which version of PC do you have?

Does the script was record on the same version of you currently PC version?

Please send me a screenshot of the system health check

Is the script exucted with no errors on vugen?

 

Please try to reinstall the problematic LG, and let me know if this solves the issue.

Regards,

Daniela Gómez Alvarado
Customer Support Engineer

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Daniela, thanks for your response.

I'm running the following

Saas based PC = 12.50

VuGen Version 12.53 Build 1203

LG - Load Runner Agent Service 12.50.0

I have executed the same test scenario successfully from PC, and also encountered the errors when running the scenario.  As, it has been successful once, I'm hoping it isn't script and scenario related.

Any ideas appreciated.

Thanks

Claire

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hello Claire,

It seems like there are two different issues here

1. The original Load Generator connection issue. It is very hard to understand what the issue is. I suggest opening a ticket to get help

2. Running scripts created in VuGen version x on Load Generator/Controller of versio x-y is not supported. LoadRunner does not support forward compatibility. VuGen version should always be equal or lower than the Load Generator version. The best practice is to use the same version.

Regards,

Shlomi

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Shlomi

Thank you for your response.  I installed the 12.53 full load runner edition locally 3 weeks ago, following a fix that I needed for an element that had been previously missing from one of my analysis reports.  The scripts have run through PC successfully, even though they were generated on vugen that was a minor version ahead of PC and the LG.  Therefore, I had made the assumption, that the intermittent issue I'm seeing isn't related to the script?

I'm trying to get a ticket raised with the PC team.  My account does not currently recognise me as an admin for the PC solution, but I'm hoping to have this resolved today on HP side and get a formal ticket raised.

Many Thanks

Claire

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi Claire,

It is very likely that the issue is not related to the script. Still It is not supported to use scripts created in newer version on older Load Generators. It might work in some cases and it might create a complete mess in others 🙂

I thought that if you are able to post questions in this forum you are also able to open support tickets. Anyway, if you do not succeed opening a ticket let me know, i will try to help.

 

Regards,

Shlomi

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Thank you Shlomi

I've moved back to the 12.50 patch 3 version.

I'm going to re-record my script and see what happens.  I suspect also that my application under test is taking too long to respond to one of the transactions, so when user load is ramped up, and we have a lot of the running vusers waiting for a response, it could be impacting the CPU back in the LG.

Will report back..

Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

 

Thank you Claire. Waiting for your update.

Please note that it is recommended to use a new group in the scenario and not replace the current script in the same group.

The reason for that is mainly because of the run time settings. When you modify it in Performance Center it is kept in the database, if there were new Run Time Settings entries in the 12.53 which didn't exist in 12.50 patch 3 it might create issue when Performance Center tries to load the Run Time Settings dialog in UI or when running the script on the Load Generator. When ypou delete the group and add a new one you ensure you won't run into this issue.

Shlomi

Highlighted
Super Contributor.
Super Contributor.

Hi Shlomi

When I replayed a script recorded on the 12.50 verion of vugen, the CPU issues have certainly subsided.  Thanks for the pointer above about the groups. 

This has provided some clarity.  I'm still getting my errors in the LG logs, but we've now been able to trace applicable behaviour in the application we are testing.  I think we need to find out why that is happening here first...  I will report back when i have a better update.

Thank you

Claire

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Hi Shlomi

We have made some progress......  In our AUT, we've modified a parameter 'KeepAliveSecs' in the WebLogic plugin (for Apache server).  The 'KeepAliveSecs' was adjusted from 15 seconds to 30 seconds.  The oracle documentation incates that this parameter defines 'The length of time after which an inactive connection between the plug-in and WebLogic Server is closed.'

Since making this adjustment, our LG service has not errored.  So it appears that the MI listener appeared to breakdown when the AUT breaches the timeout setting above (when it was set to 15 seconds).

...from LoadRunner_agent_service.log

03/02/2017 16:31:53 Error: Communication error: SSL write error : [param not passed in call]. (sys error message - WSAECONNABORTED) [MsgId: MERR-10343]
03/02/2017 16:31:53 Error: Client almrwcpcmt125-mil5.saas.hpe.com is not responding.
03/02/2017 16:31:53 Error: Communication error: The Client failed to send packet. The socket has been shut down. [MsgId: MERR-10343]
03/02/2017 16:31:53 Error: Communication error: The Client failed to send packet. The socket has been shut down. [MsgId: MERR-10343]
03/02/2017 16:31:53 Error: Two Way Communication Error: Function two_way_comm_post_message / two_way_comm_post_message_ex failed. [MsgId: MERR-60990]
03/02/2017 16:31:53 Error: Communication error: The Client failed to send packet. The socket has been shut down. [MsgId: MERR-10343]

 

--------------------------------------------------------------------

I've also found some logging on the Apache / Weblogic side, where we can clearly see a URL::close in the BaseProxy.cpp followed by a WRITE_ERROR_TO_CLIENT weblogic error.  These seem to cause our MI listener to fail, and I don't know why.  While we can tune the timeouts on the application side, should a failure in our application have this impact on our LG?

Unfortunately, the service needs to be restarted on the load generator in order to resume any performance testing.  Are there valid reasons for shutting a socket connection?

Many Thanks

Claire

 

 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi Claire,

Thanks for the update and kodus for the impressive drill down.

It does seem strange and unrelated. Let me consult with subject matter experts internally. I will get back to you soon.

Regards,

Shlomi

 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi Claire,

I have asked experts in the team and an assumption was made why it might be related. I'd like to check with you whether the assumption is corect.

Does the Load Generator connects to the MI Listener using HTTP tunneling through the Apache proxy? If so, then the change in the configuration done in Apache/WebLogic might be related.

In any case please make sure the timeout you defined is higher than the one defined in the LG agent settings  

Regards,

Shlomi

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.