users@grizzly.java.net

Re: culling non-performing connections?

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Wed, 03 Feb 2010 11:50:10 +0100

Hi Greg,

> I'm not sure if this is in Grizzly proper or left to user code but
> here's what I want to express:
> If a useful message cannot be assembled in n-seconds, kill the
> connection.
>
> Say there is a connection established by a client. There is a fixed
> header (which contains the size of the message body to follow)
> followed by a variable length message body.
> How would one express the notion that the client is just too damned
> slow? Accidentally (fine, network congestion) or deliberately
> (dribble in one byte just enough to keep the connection alive and
> consume server resources for long periods).
I guess you can take a look at the IdleConnectionFilter [1], it kills
idle connections, which is a little bit different, but I guess you'll
not need to change much to get what you need.

> I'm also curious how to deal with suppressing SSL renegotiations
> just endlessly cycling through ciphers. Perhaps the "too damned
> slow" rule would handle this as well.
I guess that rule is universal :)

Thanks.

WBR,
Alexey.

[1]
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/grizzly/src/main/java/com/sun/grizzly/utils/IdleTimeoutFilter.java?rev=4141&view=markup
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/code/modules/grizzly/src/test/java/com/sun/grizzly/IdleConnectionFilterTest.java?rev=4133&view=markup

>
> Any pointers to sample code?
>
> thanks,
> greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>