thanks for that clarification Jeanfrancois, as it turns out, that
explanation fits with the fact that lighttpd (our frontend load
balancer) had run out of socket handles and was doing a lot of back
queuing and flooding our backends with connections.
Jeanfrancois Arcand wrote:
> Hi Alan,
>
> The way Grizzly works is when a request arrive, it accept it and then
> put it inside a queue. Once thread is ready/free, it takes the request
> from the queue and execute it. Since we can't predict how long the
> request will takes to execute (some extension that uses JDBC might that
> a long time), we need to make sure the queue is not growing infinitely
> to avoid OOM, so we set the max to 4096. The exception you are getting
> is because the were 4096 requests queued...to change the default value,
> you can call:
>
> SelectorThread.setQueueSizeInBytes(...);
>
> An alternative is to create more Threads so the queue is cleared faster.
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>
>
> Alan Williamson wrote:
>> We are starting to get a lot of these errors ...
>>
>> ---------------------
>> com.sun.grizzly.Controller doSelect
>> SEVERE: doSelect exception
>> com.sun.grizzly.PipelineFullException: Queue is full
>> at com.sun.grizzly.DefaultPipeline.execute(DefaultPipeline.java:266)
>> at com.sun.grizzly.DefaultPipeline.execute(DefaultPipeline.java:37)
>> at com.sun.grizzly.Context.execute(Context.java:316)
>> ---------------------
>>