SEVERE: selectorThread.stopException

[Jeanfrancois Arcand-2]

Hi Alan,

Looking at another issue, I've waked up and found a problem with our
current implementation could have caused a file descriptor leak:

https://grizzly.dev.java.net/issues/show_bug.cgi?id=177

Mainly, if the requests queue gets full (by default, it means 4096
requests are waiting for a threads to be free to serve the request),
internally we throw a PipelineFullException, but in Grizzly 1.5 and up,
we forgot to close the connection properly, leading to a possible file
descriptor leaks.

It is probably not the problem you were suffering because the
PipelineFullException would have been written to the log...but we never
know :-)

A+

-- Jeanfrancois


Alan Williamson wrote:

>>> [root@munich]# netstat -an | grep 80 | wc -l
>>> 199
>>>
>>
>> In what state are they? CLOSE_WAIT ? Hopefully not as this is the leak
>> cause.
>
> vast majority in TIME_WAIT
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...