Winscok Error socket2 - Software caused connection abort. Error code : 10053
nsthetester
only log_in part.
My script is failing at one step while replaying.
I know my scripts need correlation. I have recorded same scripts
twice. So total all the three scripts are failing at this step. Please
see the extened log at the end.
These are my questions.
1) Which recieve buffer need correlation? Once I correlate rec buffer
which send buffer need to be parameterize?
2)I compare my first script rec. buffer(1073) data to identical
scripts buffer(1073) they have same 7 bytes of data.
3)Is correlation needed in rec buffer 1073? or Any other buffer how
can I figure out which buffer? Which buffer need to be parameterize.
4)Why script is failing at this point. I have similar mismatch problem
in Buf 215 also. But this does not stop replay of the script.
5)If I need to parametrize my input(username), I need to change my
send buffer data. But there are 700 buffers after I enter usrename on
my client. Which buffer is going to have username information. Is
there any quick way to find out rather look in to 700 buffers?
Please provide some solution for this problem.
Extended log.
vuser_init.c(2171): callRecv:756 bytes were received
vuser_init.c(2173): lrs_send(socket2, buf1072)
vuser_init.c(2175): lrs_receive(socket2, buf1073)
vuser_init.c(2175): Mismatch in buffer's length (expected 43 bytes, 7
bytes actually received, difference in 36 bytes)
================================EXPECTED
BUFFER================================
"\x14\x03\x01\x00\x01\x01\x16\x03\x01\x00"
" "
"\xb6"
"W"
"\x1b\xa1\xde"
"|L7"
"\xb7\xd0\x8c"
"A"
"\xfe\xf1"
"0o"
"\xf1\x9b\xba\xae"
"v"
"\xbd"
"\n"
"\xd3\x10\x85"
"a-"
"\x96"
"X"
"\xe3"
"r"
===============================================================================
================================RECEIVED
BUFFER================================
"\x15\x03\x01\x00\x02\x02"
"("
===============================================================================
vuser_init.c(2175): callRecv:7 bytes were received
vuser_init.c(2178): lrs_get_last_received_buffer(socket2, buf_p,
size_p)
vuser_init.c(2180): lrs_set_send_buffer(socket2, buf, 36)
vuser_init.c(2182): lrs_send(socket2, buf1074)
vuser_init.c(2184): lrs_receive(socket2, buf1075)
vuser_init.c(2184): Error : socket2 - Software caused connection
abort. Error code : 10053.
vuser_init.c(2184): Notify: Transaction "Log_in" ended with "Fail"
status (Duration: 4.7840).
Abort was called from an action.
James Pulley
been the beneficiary of a training and mentoring program?
Oh, on the correlation and parameterization front. It's real easy. For
any send buffer whose buffer number resolves to an even number when the
following formaul is applied int(buffnum^(1/3)), then you correlate that
buffer. On the even send buffers you parameterize.
I know what you're thinking, and you're right. The above is absolute total
nonsense: We have no idea what to correlate and parameterize in your script
because developers are inherently cagey creatures and do all sorts of
different and unique things in their code from release to release, not to
mention jumping to an entirely new application. If this is an application
involving PII or financial services then you will also likely have
encryption to deal with: Not fun and in some cases outright impossible using
a sockets model.
The absolute oldest tried and true methods for manual correlation hold the
true path for identifying correlation candidates. In the 9.x training you
can find the manual method in question in the appendix of the web virtual
user training guide. Record twice. Diff. The differences highlight
items related to multiple correlation types: Session, State, Time & Business
Process Related. The parameterization items are a bit clearer. If you
typed it in or picked it off the screen, well, you can see where this is
headed....
If this is your first adventure into Sockets then you are in for a wild
ride. A peer of mine has described this as work as being as tedious as
picking fly scat out of ground pepper...and just as rewarding if successful.
But if you have never worked in a sockets universe before coming to
LoadRunner then this is not the place to cut your teeth. The odds of
success will be very close to nil, particular since you are also still on
the tool learning curve (your vuser init items and your odd framing|phrasing
of parameterization and correlation in your original message). This is
time to hire the best person you can find with the best track record you can
find. When sockets are involved you should concentrate totally on skills
and once you find the right person or organization, pay whatever tribute
they demand. You're in world of hurt and have very little negotiating
leverage on this one.
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
Extended log.
--
You received this message because you are subscribed to the Google
"LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en
John Crunk
inexperienced that you don't understand session?
John
-----Original Message-----
From: lr-loa...@googlegroups.com [mailto:lr-loa...@googlegroups.com]
On Behalf Of nsthetester
Sent: Thursday, December 30, 2010 5:59 PM
To: LoadRunner
Extended log.
--