You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Mike Spreitzer <ms...@us.ibm.com> on 2001/01/14 08:01:37 UTC
SOAP call fails iff call message length is 3568 or greater, using IBM SOAP
1.2, Tomcat 3.2.1 standalone, IBM JDK 1.3.0, and RedHat Linux 6.2
I've done some further experimental computer science on my mysterious
connection reset problem, and found that when client and server are both
on the same machine, short calls succeed while long calls fail. Does this
ring any bells or prompt any revelations?
This is the mysterious failure I reported earlier, where the server makes
no complaint but the client complains because the server does a TCP
connection reset immediately after sending the reply message.
Using a modified version of the stockquote demo, I found the critical call
message length. I modified the StockQuoteService, because I was having
trouble reaching the I3 stock quote server, to simply return the
hashCode() of the symbol. I modified the GetQuote client to take as its
second parameter not the symbol but rather the length of the symbol and
then create a symbol of the given length. I found the calls always
succeeded when the symbol length was less than 3568 (that's 16*223, wonder
why that would be critical), and always failed when the symbol length was
3568 or greater. To my surprise, this critical length does *not*
correspond to the point where the call message spills over into a second
packet; it is the point where the second packet's payload length reaches
225 bytes.
FYI, here are two packet dumps, one of a successful call with a symbol
length of 3567, and one of a failing call with a symbol length of 3568.
First, the successful one:
01:55:08.177390 lo > wat-eu-2.1474 > wat-eu-2.8080: S
2302515426:2302515426(0) win 31072 <mss 3884,sackOK,timestamp 47996603
0,nop,wscale 0> (DF)
01:55:08.177390 lo < wat-eu-2.1474 > wat-eu-2.8080: S
2302515426:2302515426(0) win 31072 <mss 3884,sackOK,timestamp 47996603
0,nop,wscale 0> (DF)
01:55:08.177440 lo > wat-eu-2.8080 > wat-eu-2.1474: S
2298316346:2298316346(0) ack 2302515427 win 31072 <mss
3884,sackOK,timestamp 47996603 47996603,nop,wscale 0> (DF)
01:55:08.177440 lo < wat-eu-2.8080 > wat-eu-2.1474: S
2298316346:2298316346(0) ack 2302515427 win 31072 <mss
3884,sackOK,timestamp 47996603 47996603,nop,wscale 0> (DF)
01:55:08.177461 lo > wat-eu-2.1474 > wat-eu-2.8080: . 1:1(0) ack 1 win
31072 <nop,nop,timestamp 47996603 47996603> (DF)
01:55:08.177461 lo < wat-eu-2.1474 > wat-eu-2.8080: . 1:1(0) ack 1 win
31072 <nop,nop,timestamp 47996603 47996603> (DF)
01:55:08.185337 lo > wat-eu-2.1474 > wat-eu-2.8080: P 1:3873(3872) ack 1
win 31072 <nop,nop,timestamp 47996604 47996603> (DF)
01:55:08.185337 lo < wat-eu-2.1474 > wat-eu-2.8080: P 1:3873(3872) ack 1
win 31072 <nop,nop,timestamp 47996604 47996603> (DF)
01:55:08.185394 lo > wat-eu-2.8080 > wat-eu-2.1474: . 1:1(0) ack 3873
win 27200 <nop,nop,timestamp 47996604 47996604> (DF)
01:55:08.185394 lo < wat-eu-2.8080 > wat-eu-2.1474: . 1:1(0) ack 3873
win 27200 <nop,nop,timestamp 47996604 47996604> (DF)
01:55:08.185408 lo > wat-eu-2.1474 > wat-eu-2.8080: P 3873:4097(224) ack
1 win 31072 <nop,nop,timestamp 47996604 47996604> (DF)
01:55:08.185408 lo < wat-eu-2.1474 > wat-eu-2.8080: P 3873:4097(224) ack
1 win 31072 <nop,nop,timestamp 47996604 47996604> (DF)
01:55:08.192258 lo > wat-eu-2.8080 > wat-eu-2.1474: . 1:1(0) ack 4097
win 31072 <nop,nop,timestamp 47996605 47996604> (DF)
01:55:08.192258 lo < wat-eu-2.8080 > wat-eu-2.1474: . 1:1(0) ack 4097
win 31072 <nop,nop,timestamp 47996605 47996604> (DF)
01:55:08.196795 lo > wat-eu-2.8080 > wat-eu-2.1474: P 1:287(286) ack
4097 win 31072 <nop,nop,timestamp 47996605 47996604> (DF)
01:55:08.196795 lo < wat-eu-2.8080 > wat-eu-2.1474: P 1:287(286) ack
4097 win 31072 <nop,nop,timestamp 47996605 47996604> (DF)
01:55:08.196847 lo > wat-eu-2.1474 > wat-eu-2.8080: . 4097:4097(0) ack
287 win 30786 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.196847 lo < wat-eu-2.1474 > wat-eu-2.8080: . 4097:4097(0) ack
287 win 30786 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.196893 lo > wat-eu-2.8080 > wat-eu-2.1474: P 287:764(477) ack
4097 win 31072 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.196893 lo < wat-eu-2.8080 > wat-eu-2.1474: P 287:764(477) ack
4097 win 31072 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.197106 lo > wat-eu-2.8080 > wat-eu-2.1474: F 764:764(0) ack
4097 win 31072 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.197106 lo < wat-eu-2.8080 > wat-eu-2.1474: F 764:764(0) ack
4097 win 31072 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.197128 lo > wat-eu-2.1474 > wat-eu-2.8080: . 4097:4097(0) ack
765 win 30308 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.197128 lo < wat-eu-2.1474 > wat-eu-2.8080: . 4097:4097(0) ack
765 win 30308 <nop,nop,timestamp 47996605 47996605> (DF)
01:55:08.578437 lo > wat-eu-2.1474 > wat-eu-2.8080: F 4097:4097(0) ack
765 win 31072 <nop,nop,timestamp 47996643 47996605> (DF)
01:55:08.578437 lo < wat-eu-2.1474 > wat-eu-2.8080: F 4097:4097(0) ack
765 win 31072 <nop,nop,timestamp 47996643 47996605> (DF)
01:55:08.578597 lo > wat-eu-2.8080 > wat-eu-2.1474: . 765:765(0) ack
4098 win 31072 <nop,nop,timestamp 47996643 47996643> (DF)
01:55:08.578597 lo < wat-eu-2.8080 > wat-eu-2.1474: . 765:765(0) ack
4098 win 31072 <nop,nop,timestamp 47996643 47996643> (DF)
And now the failing one:
01:55:36.550917 lo > wat-eu-2.1475 > wat-eu-2.8080: S
2326083298:2326083298(0) win 31072 <mss 3884,sackOK,timestamp 47999440
0,nop,wscale 0> (DF)
01:55:36.550917 lo < wat-eu-2.1475 > wat-eu-2.8080: S
2326083298:2326083298(0) win 31072 <mss 3884,sackOK,timestamp 47999440
0,nop,wscale 0> (DF)
01:55:36.550969 lo > wat-eu-2.8080 > wat-eu-2.1475: S
2326077554:2326077554(0) ack 2326083299 win 31072 <mss
3884,sackOK,timestamp 47999440 47999440,nop,wscale 0> (DF)
01:55:36.550969 lo < wat-eu-2.8080 > wat-eu-2.1475: S
2326077554:2326077554(0) ack 2326083299 win 31072 <mss
3884,sackOK,timestamp 47999440 47999440,nop,wscale 0> (DF)
01:55:36.550989 lo > wat-eu-2.1475 > wat-eu-2.8080: . 1:1(0) ack 1 win
31072 <nop,nop,timestamp 47999440 47999440> (DF)
01:55:36.550989 lo < wat-eu-2.1475 > wat-eu-2.8080: . 1:1(0) ack 1 win
31072 <nop,nop,timestamp 47999440 47999440> (DF)
01:55:36.558703 lo > wat-eu-2.1475 > wat-eu-2.8080: P 1:3873(3872) ack 1
win 31072 <nop,nop,timestamp 47999441 47999440> (DF)
01:55:36.558703 lo < wat-eu-2.1475 > wat-eu-2.8080: P 1:3873(3872) ack 1
win 31072 <nop,nop,timestamp 47999441 47999440> (DF)
01:55:36.558762 lo > wat-eu-2.8080 > wat-eu-2.1475: . 1:1(0) ack 3873
win 27200 <nop,nop,timestamp 47999441 47999441> (DF)
01:55:36.558762 lo < wat-eu-2.8080 > wat-eu-2.1475: . 1:1(0) ack 3873
win 27200 <nop,nop,timestamp 47999441 47999441> (DF)
01:55:36.558776 lo > wat-eu-2.1475 > wat-eu-2.8080: P 3873:4098(225) ack
1 win 31072 <nop,nop,timestamp 47999441 47999441> (DF)
01:55:36.558776 lo < wat-eu-2.1475 > wat-eu-2.8080: P 3873:4098(225) ack
1 win 31072 <nop,nop,timestamp 47999441 47999441> (DF)
01:55:36.562248 lo > wat-eu-2.8080 > wat-eu-2.1475: . 1:1(0) ack 4098
win 27104 <nop,nop,timestamp 47999442 47999441> (DF)
01:55:36.562248 lo < wat-eu-2.8080 > wat-eu-2.1475: . 1:1(0) ack 4098
win 27104 <nop,nop,timestamp 47999442 47999441> (DF)
01:55:36.574396 lo > wat-eu-2.8080 > wat-eu-2.1475: P 1:287(286) ack
4098 win 27104 <nop,nop,timestamp 47999443 47999441> (DF)
01:55:36.574396 lo < wat-eu-2.8080 > wat-eu-2.1475: P 1:287(286) ack
4098 win 27104 <nop,nop,timestamp 47999443 47999441> (DF)
01:55:36.574438 lo > wat-eu-2.1475 > wat-eu-2.8080: . 4098:4098(0) ack
287 win 30786 <nop,nop,timestamp 47999443 47999443> (DF)
01:55:36.574438 lo < wat-eu-2.1475 > wat-eu-2.8080: . 4098:4098(0) ack
287 win 30786 <nop,nop,timestamp 47999443 47999443> (DF)
01:55:36.574757 lo > wat-eu-2.8080 > wat-eu-2.1475: P 287:765(478) ack
4098 win 27104 <nop,nop,timestamp 47999443 47999443> (DF)
01:55:36.574757 lo < wat-eu-2.8080 > wat-eu-2.1475: P 287:765(478) ack
4098 win 27104 <nop,nop,timestamp 47999443 47999443> (DF)
01:55:36.575119 lo > wat-eu-2.8080 > wat-eu-2.1475: R 765:765(0) ack
4098 win 30976 <nop,nop,timestamp 47999443 47999443> (DF)
01:55:36.575119 lo < wat-eu-2.8080 > wat-eu-2.1475: R 765:765(0) ack
4098 win 30976 <nop,nop,timestamp 47999443 47999443> (DF)
01:55:36.584354 lo > wat-eu-2.1475 > wat-eu-2.8080: R 4098:4098(0) ack
765 win 31072 <nop,nop,timestamp 47999444 47999443> (DF)
01:55:36.584354 lo < wat-eu-2.1475 > wat-eu-2.8080: R 4098:4098(0) ack
765 win 31072 <nop,nop,timestamp 47999444 47999443> (DF)
Any help appreciated,
Mike
Re: SOAP call fails iff call message length is 3568 or greater, using
IBM SOAP1.2, Tomcat 3.2.1 standalone, IBM JDK 1.3.0, and RedHat Linux
6.2
Posted by chuck clark <cc...@ziclix.com>.
wow..i had three items on my list of things to do today and finding out why i
was occasionally seeing these complaints in our logs was number one on the
list
i'm running RH 6.2 with the Sun JDK, IBM/Apache SOAP 2.0 and resin 1.2
i know that i was getting similar behavior to occur sometimes when users were
making large requests but it would fail only sporadically...5 or 6 times in a
row and then suddenly be successful once or twice
do you have a copy of your modified stock quote classes you used to test that
you could mail to me? i'll see if i can reproduce it and get back to you
cheers
chuck
Mike Spreitzer wrote:
> I've done some further experimental computer science on my mysterious
> connection reset problem, and found that when client and server are both
> on the same machine, short calls succeed while long calls fail. Does this
> ring any bells or prompt any revelations?
>
> This is the mysterious failure I reported earlier, where the server makes
> no complaint but the client complains because the server does a TCP
> connection reset immediately after sending the reply message.
>
> Using a modified version of the stockquote demo, I found the critical call
> message length. I modified the StockQuoteService, because I was having
> trouble reaching the I3 stock quote server, to simply return the
> hashCode() of the symbol. I modified the GetQuote client to take as its
> second parameter not the symbol but rather the length of the symbol and
> then create a symbol of the given length. I found the calls always
> succeeded when the symbol length was less than 3568 (that's 16*223, wonder
> why that would be critical), and always failed when the symbol length was
> 3568 or greater. To my surprise, this critical length does *not*
> correspond to the point where the call message spills over into a second
> packet; it is the point where the second packet's payload length reaches
> 225 bytes.
>
> FYI, here are two packet dumps, one of a successful call with a symbol
> length of 3567, and one of a failing call with a symbol length of 3568.
> First, the successful one:
>
Re: SOAP call fails iff call message length is 3568 or greater, using
IBM SOAP1.2, Tomcat 3.2.1 standalone, IBM JDK 1.3.0, and RedHat Linux
6.2
Posted by chuck clark <cc...@ziclix.com>.
wow..i had three items on my list of things to do today and finding out why i
was occasionally seeing these complaints in our logs was number one on the
list
i'm running RH 6.2 with the Sun JDK, IBM/Apache SOAP 2.0 and resin 1.2
i know that i was getting similar behavior to occur sometimes when users were
making large requests but it would fail only sporadically...5 or 6 times in a
row and then suddenly be successful once or twice
do you have a copy of your modified stock quote classes you used to test that
you could mail to me? i'll see if i can reproduce it and get back to you
cheers
chuck
Mike Spreitzer wrote:
> I've done some further experimental computer science on my mysterious
> connection reset problem, and found that when client and server are both
> on the same machine, short calls succeed while long calls fail. Does this
> ring any bells or prompt any revelations?
>
> This is the mysterious failure I reported earlier, where the server makes
> no complaint but the client complains because the server does a TCP
> connection reset immediately after sending the reply message.
>
> Using a modified version of the stockquote demo, I found the critical call
> message length. I modified the StockQuoteService, because I was having
> trouble reaching the I3 stock quote server, to simply return the
> hashCode() of the symbol. I modified the GetQuote client to take as its
> second parameter not the symbol but rather the length of the symbol and
> then create a symbol of the given length. I found the calls always
> succeeded when the symbol length was less than 3568 (that's 16*223, wonder
> why that would be critical), and always failed when the symbol length was
> 3568 or greater. To my surprise, this critical length does *not*
> correspond to the point where the call message spills over into a second
> packet; it is the point where the second packet's payload length reaches
> 225 bytes.
>
> FYI, here are two packet dumps, one of a successful call with a symbol
> length of 3567, and one of a failing call with a symbol length of 3568.
> First, the successful one:
>