On 03/28/2011 02:45 PM, wild wrote:
> ok I will try to increase the timeout.... This change should fix the 2 errors
> ("Broken Pipe" or "client is busy or timeout") or only one ? Can you explain
> why it should help ?
Primarily "broken pipe", not sure where the 2nd exception comes from yet.
> if channel.write send the data, why do we have to call selector.select() ?
> After som check on client side, it seams that the connection is still alive
> but selector.select() is returning 0.
It depends which selector.select() you mean, the one in
OutputWriter.flushChannel()?
It's getting called when we can not flush the entire buffer, because the
underlying socket buffer is overloaded. (most probably client is not
able to read data as fast as server sends it). So we just wait until
client releases some space in the TCP buffer and let server write more data.
You can increase the write timeout as well by setting jvm-option
-Dcom.sun.enterprise.web.connector.grizzly.writeTimeout=XXX
in the domain.xml, the value is in milliseconds, by default it's equal
to 30000 (30 seconds).
> it is difficult to provide a test case because it happened sometimes, mainly
> when the load increase. Our use of comet is simple, we have implemented a
> comet handler inspired from ConcurrentCometHandler and we write in the
> httpResponse each time we have to write an event.
>
> We implement our own thread pool in order to handler priority and use
> several comet context in the same comet engine.
I see. Let's check what timeouts increasing will give us.
Thanks.
WBR,
Alexey.
> thanks
>
> william
>
> --
> View this message in context: http://grizzly.1045725.n5.nabble.com/Broken-Pipe-and-client-is-busy-or-timeout-errors-tp4268012p4268394.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.