Server becomes unresponsive for unknown reason

["이희승 (Trustin Lee)"]

If you are seeing the following or similar message in your syslog:

TCP: Treason uncloaked! Peer 172.16.8.10:5455/49038 shrinks window
3981572292:3981572352. Repaired.

You might want to upgrade your kernel:


http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5ea3a7480606cef06321cd85bc5113c72d2c7c68

Special thanks to Tim Fox, who discovered this issue while debugging
HornetQ and Netty.

HTH,
Trustin

On 08/10/2010 07:51 PM, professor.bokdrol wrote:
> 
> Thanks for you reply, I appreciate your time. I will focus my search more on
> OS problems.
> 
> Juan
> 
> On Mon, Aug 9, 2010 at 11:21 PM, tsuna-2 [via Netty Forums and Mailing
> Lists] <ml-node+5391548-1778539135-282487 at n2.nabble.com<ml-node%2B5391548-1778539135-282487 at n2.nabble.com>
>> wrote:
> 
>> On Mon, Aug 9, 2010 at 1:17 PM, professor.bokdrol
>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=5391548&i=0>>
>> wrote:
>>> My application just fails to respond to SYN packets from remote hosts.
>>> Locally connections are established quite fine.
>>
>> Your application doesn't directly control responses to SYN packets,
>> the Linux kernel does.  If you don't see an ACK to the initial SYN
>> packet, it could indicate that your application isn't accept()ing
>> connections fast enough.  Modern Linux kernels tend to have SYN
>> cookies enabled, which allows them to ACK the initial SYN even though
>> your application isn't ready to accept() the socket.  When they do,
>> you'll typically see a message in syslog (or kern.log, depending on
>> your distro).  If you don't have SYN cookies enabled, the kernel will
>> just discard the SYN packet and the kernel of the client will retry
>> after its timeout has expired.
>>
>> I'm not familiar enough with the low level details of Netty to know
>> how Netty is accept()ing new sockets but if you somehow prevent the
>> code that runs accept() from running, or don't run it fast enough
>> while a tons of connections are being established to your application,
>> this can happen.  Also, you can configure how many sockets the kernel
>> will "buffer" for you until you accept() them, this is normally done
>> via the listen() system call, but I have no idea how this is done in
>> Java (if it's even possible) and whether Netty exposes this somehow/
>>
>> It's not an accept() problem, then the problem is not related to your
>> application and comes from somewhere else in the networking stack.
>>
>> --
>> Benoit "tsuna" Sigoure
>> Software Engineer @ www.StumbleUpon.com
>> _______________________________________________
>> netty-users mailing list
>> [hidden email] <http://user/SendEmail.jtp?type=node&node=5391548&i=1>
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>>
>> ------------------------------
>>  View message @
>> http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Server-becomes-unresponsive-for-unknown-reason-tp5132023p5391548.html
>> To unsubscribe from Re: Server becomes unresponsive for unknown reason, click
>> here<http://netty-forums-and-mailing-lists.685743.n2.nabble.com/template/NodeServlet.jtp?tpl=unsubscribe_by_code&node=5390483&code=cHJvZmVzc29yLmJva2Ryb2xAZ21haWwuY29tfDUzOTA0ODN8MTQxNjMwNzg0MQ==>.
>>
>>
>>
> 

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100826/d5f38fe7/attachment.bin