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.

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

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

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

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

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

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..

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

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

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

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

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

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

Hi Shlomi

Thanks for your response.  On my LG, I have my agent configured as 'Enable Firewall Agent'.

MI Listener Name is set
Local Machine Name is set
Connection Timeout (seconds) is 30

Connection Type is TCP

User Secure Connection (SSL) is checked.

I have a ticket now open with the support team.  Unfortunately, adjusting the timeout doesn't appear to have a consistent impact, and I'm unable to determine any further information from the LR agent logs.  

I should mention that reported back in Saas when this situation arises, I get the following type error:

-27778 [GENERAL_MSG_CAT_SSL_ERROR] read to host <my host name> failed [10053].  Software caused connection abort.

Hi Claire,

In the past when I practiced it myself I used to reduce the timeout to 5 seconds in order to ensure the agent always connects to the MI Listener. Not sure if will be good in this case, worth a try.

Now that you have a ticket opened, please share with the support team a link to this post. I believe it will be easier to handle this case by actually looking at your system.

Regards,

Shlomi