Not necessarily a problem from the TCP layer point f view. But once
you can find a request that's truncated in the TCP log, you can look out
- whether it was a normal connection shutdown or a reset
- whether there were unusual pauses between packets triggering timeouts
etc. That's why you would benefit from your test client being able to
log the client port when a failure arises so you can filter easily in
Wireshark. I'm thinking about adding client port as a loggable item to
the Tomcat AccessLog but that won't help you right now.
I vaguely remember problems with TCP checksum offloading, but they
should be fixed long ago. See e.g.
http://compgroups.net/comp.unix.solaris/disable-e1000-tcp-checksum-offloading-t5220/472801
I can't see any RST packets so I can only conclude its a normal(ish)
shutdown.
I have found that if I run my test client on a Linux server that's close
to the Solaris servers, I don't have an issue with truncation. Perhaps
there's a switch issue between our Solaris servers at the outside world.
I also once at a customer saw a problem not of truncation, but the
last packet of a response as delayed quite noticable. That was fixed
by applying the current Solaris patch cluster at that time.
I'm not sure there's a delay but I'm sure the patch level is way out of
date.
Thanks for your help though, my workaround at the moment is to just run
Tomcat 7. We're planning to migrate of Solaris onto Linux anyway, we'll
just have to wait until then before upgrading to Tomcat 8.
--
Andrew Seales
EDINA tel: +44 (0) 131 650 3022
Edinburgh University fax: +44 (0) 131 650 3308
Causewayside House url: http://edina.ac.uk
160 Causewayside email: andrew.sea...@ed.ac.uk
Edinburgh EH9 1PR
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
