Adding this note, 

Option 1-4 are not applicable in this scenario. since this is only in VuGEN

 Wallace Hermogeno ,

Which LR version are you using? Dit you reply the script on a different computer as well?

Does the script always fails at the same call or when not, always with the same remote-server?

Did you had a look to the server logs?

The ultimate investigation is using wireshark and enable full logging in VuGen to check for any timing issues.

There are many 'blogs' on the internet about this error, you might explore those and see if there is any clue that helps you.

The blogs indicate that the server shutsdown the connection because the client is too slow. You might try to run VuGen as Administrator and via task manager change the priority to "Above Normal". That might help on timing issues. Try to disable anti-virus software (or exclude VuGen).

Which LR version are you using?

- I am using LR Version CE 24.1

Dit you reply the script on a different computer as well?

- I also tried it in my local and windows server and experience the same issue. Since it happened suddenly, I am having a hard time investigating this.

Does the script always fails at the same call or when not, always with the same remote-server?

- 100% fails at the same call/request both in local and remote-server. 

Did you had a look to the server logs?

-Unfortunately, I don't have any means to look at the server logs

The ultimate investigation is using wireshark and enable full logging in VuGen to check for any timing issues.

-I'll try to do this then :)

There are many 'blogs' on the internet about this error, you might explore those and see if there is any clue that helps you.

- Yeah, already looked on to those but their solution doesn't fix my issue. I will be posting the work-around I investigated.

The blogs indicate that the server shutsdown the connection because the client is too slow. You might try to run VuGen as Administrator and via task manager change the priority to "Above Normal". That might help on timing issues. Try to disable anti-virus software (or exclude VuGen).

-Okay okay ill also try this . Is it possible that this is application issue? I have read somewhere that this type of cases are application issue and not script itself.


Side Note: 

I tried tried to enable "Continue on Error" in Runtime settings. Basically, I still receive the error on that request and continues to run. Upon checking all of the transactions, they are even passing succesfully in End-to-End scenario(considering I still got the error on early transactions). So its working but I believe it is only a work-around. not the solution itself.

Thanks JHF Remmelzwaal 

Continue on error flags the transaction still as error, Did you saw in internet a remark about:

web_set_sockets_option("IGNORE_PREMATURE_SHUTDOWN", "1");

Sometimes LR tries to emulate multiple connections in case of "Mode=HTML"  and concurrent_start/end sections. Each VUser consumes only one thread, so multi concurrent connections are interleaved. .There is also an web_set_option call that limit the amounts of connections per Vuser to a single destination.

When the URL fails on a resource the above call might be OK, but else you might combine them with:

web_set_sockets_option(“MAX_CONNECTIONS_PER_HOST”,”1″);

I think that this is what I learned from my friend Google.

Succes, Erik

Thanks JHF Remmelzwaal , 

I forgot to add that into the notes. I also tried that but unfortunately, whenever I add that code to my script, it will not make any progress with the transactions and until we got Connection Timeout(configured in Runtime Settings).

Now one thing I discovered from what I mentioned days ago, "Continue on Error" works for me as I can proceed with End to end scenario successfully and verified them correctly. Which brings me to the question - why does my script work with correct details even if I got that error "Server XXX has shut down the connection prematurely" in early transaction?

The goal of the script is to generate load on the backend.. Sometimes you need the response of one call to make progress for the next call (correlation during login or taking an order number to process). In the case of you failing call, you might just trigger something on the backend, but are not dependent on it's response.
So you might decide: I'm fine with this and accept this.

That's true. but going by logic, I shouldn't be able to proceed with the next transactions or get a replay log/snapshot in the end of the scenario if I am failing or getting a "Server XXX has shut down the connection prematurely" in early stages right? 

Doesn't that mean  I am getting the error "Server XXX has shut down the connection prematurely" during login but still received a response from that call(with correct details), that's why I can progress for the next call?

So very happy that I am learning something new. Thank you JHF Remmelzwaal 

Hi Wallace, you wrote before " I also tried that but unfortunately, whenever I add that code to my script, it will not make any progress with the transactions and until we got Connection Timeout(configured in Runtime Settings)" So it looks like LR script is waiting a long time for a response when you set IGNORE_PREMATURE_SHUTDOWN. That looks a bit weird to me, but might make sense when you look to the name.

Can you just exclude this troubled call from your script? You do not have to have a transaction around it.

Is the troubled call the primary URL in a web_* call or is it implicit generated by LR due to "Mode=HTML" (look this up into documentation). You might change it to "Mode=HTTP". LR might now skip many calls that you need, so you need to correct for that.

BTW what do you see when you do the same process directly in e.g Chrome and enable net work tracing (press F12 to open dev tools of your browser and start recording on the NW tab)? You might also see the same error....

Hi JFH , 

Yes that seems to be the case. whenever I add IGNORE_PREMATURE_SHUTDOWN, since it will basically ignore the premature shutdown, I'll be stuck on that specific web request until we reached the HTTP Timeout(on my end it is setup to 1000 seconds). That's why the only work-around that actually works for me is "Continue on error' since all details are correct upon replay. Though, this should be only a temporary fix as we didn't encounter this before and have been using the same application for years. 

I also cannot exclude this since this happens during login and also a primary url.

With regards to F12, there's no error doing it manually. So it only happens when we replay the recorded script. So is it possible it is with VuGen settings? really weird for me.