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

[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:
>