Error code 10053,software caused connection abort. Summary

Application scenarios for discovering problems
c/S Structure program, request response using asynchronous mechanism. That is, the client sends a request not to wait for this result, the client holds the request in the request queue and obtains a Jobid, the server runs the result to store in the response queue, the client periodically views the response queue, obtains the result from the response queue according to the Jobid timing. The resulting test problem is affected by the server state, and the number of times the client gets the result is not fixed.
Test Script Sample
Lrs_create_socket ("Socket0", "TCP", "localhost=0", "remotehost=localhost:8080", Lrslastarg);
Lrs_send ("Socket0", "buf56", Lrslastarg);
Lrs_receive ("Socket0", "buf57", Lrslastarg);
Getjobid ();
do{
Lr_think_time (0.3);
Lrs_send ("Socket0", "buf58", Lrslastarg);
Lrs_receive ("Socket0", "buf59", Lrslastarg);
}while (! CheckStatus ());
Where buf56, 57 is to send the request, buf58, 59 is the loop to obtain results and check the return of the flag, if there is still no results returned after a certain period of time to obtain results, so the number of requests are not fixed.
LR Hints Socket exception
When I use Lrs_create_socket to create a connection, when this socket connection has reached 100 requests, this connection is not available, you must close and then recreate the create. LoadRunner prompt Error: Error:socket0-software caused connection abort. Error code:10053.


Problem validation
The first thought is LoadRunner support for sockets because the same test method can be passed in rational robot. So the simplest experiment was done:
1, with a socket to record access to a Web page and save (such as Baidu, or Tomcat's default page)
2, to add a circular way to access
As a result, the number of socket requests reached 100 can not be accessed again (a few times 100).

The script is as follows:
#include "Lrs.h"
int i;
Action ()
{
Lr_think_time (1);

Lrs_create_socket ("Socket0", "TCP", "localhost=0", "remotehost=appsvr01:8080", Lrslastarg);
I=1;
do{
Lrs_send ("Socket0", "buf0", Lrslastarg);
Lrs_receive ("Socket0", "Buf1", Lrslastarg);
Lr_output_message ("-------------LRS request times:%d", i);
i++;
Lrs_send ("Socket0", "Buf2", Lrslastarg);
Lrs_receive ("Socket0", "buf3", Lrslastarg);
Lr_output_message ("-------------LRS request times:%d", i);
i++;
Lrs_send ("Socket0", "Buf4", Lrslastarg);
Lrs_receive ("Socket0", "Buf5", Lrslastarg);
Lr_output_message ("-------------LRS request times:%d", i);
i++;
Lrs_send ("Socket0", "Buf6", Lrslastarg);
Lrs_receive ("Socket0", "Buf7", Lrslastarg);
Lr_output_message ("-------------LRS request times:%d", i);
i++;
}while (i<200);
return 0;
}

The LoadRunner Vugen log is as follows:
...
Lrs_send (Socket0, BUF2)
ACTION.C (): Lrs_receive (Socket0, BUF3)
ACTION.C:-------------LRS Request times:98
ACTION.C (): Lrs_send (Socket0, BUF4)
ACTION.C (+): lrs_receive (Socket0, Buf5)
ACTION.C ():-------------LRS Request times:99
ACTION.C (a): Lrs_send (Socket0, BUF6)
ACTION.C (): Lrs_receive (Socket0, BUF7)
ACTION.C (a): mismatch (expected 1249 bytes, 1268 bytes, actually received)
ACTION.C (a):-------------LRS Request times:100
ACTION.C (): Lrs_send (Socket0, buf0)
ACTION.C (a): Lrs_receive (Socket0, BUF1)
ACTION.C (a): Error:socket0-software caused connection abort. Error code:10053.
Abort is called from action.
Ending VUser ...
Starting action Vuser_end.
VUSER_END.C (): Lrs_cleanup ()
Ending action vuser_end.


A new discovery
After the discovery of the above questions after baffled, and some test friends to discuss the exchange, but also no clue. In an exchange accidentally found a friend of the test script is connected to the 80 port, and then inferred that he was using IIS as a test server, suddenly realized that this is related to the application server, immediately using IIS as a server to test, incredibly test passed, and did not appear socket connection problem. Subsequent tests with WebLogic were also passed.
Preliminary conclusions
All of the above verification methods found that the problem is not caused by loadrunner alone, but also with the test application server has a great relationship. This problem only occurs when you test JBoss, tomcat servers with LoadRunner, and there are no problems with IIS, WebLogic, and so on. But another strange problem is that using the same test method with rational robot, all server types are fine.


Continue to explore
Later, further research was made on why the same use of Tomcat server, the different differences in the request resulted in two test tools decidedly different test results. But the Charles tool only found subtle differences in requests that did not cause the problem to occur. So the mystery hangs in the open, hoping that people with lofty ideals will join together to explore the mysteries.