You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David kerber <dc...@verizon.net> on 2011/09/14 17:28:23 UTC
Strange networking trace
I don't really think this issue is related to Tomcat, but I'm not sure,
so I'm starting here.
Running:
TC 7.0.20 64-bit on
64-bit Windows server 2008 Standard SP2, with
64-bit JRE 6.0_27 in server mode.
The server is a single physical machine, not virtual and not clustered,
and has no VMs inside it either. The NIC is a 1Gbps server NIC, with
TOE enabled.
The issue we're having is that we're getting duplicate responses from
the server to a request from our automated data collection systems in
the field. There is no human interaction with this data flow. The data
is transmitted as an HTTP POST request, with a short (~75 byte) string
as the actual data payload, and an even shorter response string sent
back after the data is processed.
What got us looking at this is that it doesn't quite keep up with the
data flow. A much older machine running Windows 2000 Server keeps up
with no trouble at all, running the exact same application (just copy
the .war over), but on TC 6.0.something and an older 32-bit JRE in
server mode.
In this table, right arrows are data coming in from the field, and left
arrows are data sent out from the server in response. This data was
collected with WireShark monitoring the NIC on the machine, and the
entire exchange takes much less than a second. The duplicate responses
follow extremely quickly behind the original, within a few microseconds.
Dir Sz Action
-> 62 Start session
<- 58 Response and ACK
<- 58 Duplicate response and ACK
-> 60 ACK
-> 292 HTTP Headers
<- 54 ACK
<- 54 Duplicate ACK
-> 126 Content (72 bytes)
<- 191 HTTP response
<- 191 Duplicate HTTP response
<- 54 ACK and FIN
<- 54 Duplicate ACK and FIN
-> 60 ACK
-> 60 FIN, ACK
<- 54 ACK
<- 54 Duplicate ACK
1482 (660->/820<-) bytes for delivery of a 72 byte payload
411 bytes from duplicate transmissions.
Googling indicates that this kind of thing can sometimes be a congestion
control technique at the NIC layer, but this is happening even when the
links don't appear to be congested. Anybody seen anything like this, or
have any suggestions where to look for causes and/or fixes?
TIA!
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Strange networking trace
Posted by David kerber <dc...@verizon.net>.
On 9/14/2011 11:48 AM, Caldarale, Charles R wrote:
>> From: David kerber [mailto:dckerber@verizon.net]
>> Subject: Strange networking trace
>
>> <- 58 Response and ACK
>> <- 58 Duplicate response and ACK
>
>> <- 54 ACK
>> <- 54 Duplicate ACK
>
>> <- 191 HTTP response
>> <- 191 Duplicate HTTP response
>
>> <- 54 ACK and FIN
>> <- 54 Duplicate ACK and FIN
>
>> <- 54 ACK
>> <- 54 Duplicate ACK
>
> Do the duplicates have the same TCP sequence numbers as the originals? If so, Tomcat is not involved.
Yes, the sequence numbers are the same. So I'll look elsewhere for the
answer.
>
> Have you tried replacing the NIC? Or turning off TOE?
Both of the machines are showing duplicate ACKs, but one can keep up any
way, and the other does not. But they both have TOE enabled. That
gives me something to try, any way.
Thanks, Chuck.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Strange networking trace
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David kerber [mailto:dckerber@verizon.net]
> Subject: Strange networking trace
> <- 58 Response and ACK
> <- 58 Duplicate response and ACK
> <- 54 ACK
> <- 54 Duplicate ACK
> <- 191 HTTP response
> <- 191 Duplicate HTTP response
> <- 54 ACK and FIN
> <- 54 Duplicate ACK and FIN
> <- 54 ACK
> <- 54 Duplicate ACK
Do the duplicates have the same TCP sequence numbers as the originals? If so, Tomcat is not involved.
Have you tried replacing the NIC? Or turning off TOE?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org