Hi Marc,
On 11/13/2012 05:39 PM, Arens, Marc wrote:
> Hello,
>
> we are currently dealing with incoming ServletRequests getting stuck
> in calls to thirdparty libs and filling the FixedThreadPool Grizzly
> uses. I have already implement a RequestWatcher that keeps track of
> requests/threads that are currently being handled. This Requestwatcher
> reports the stuck requests and tries to interrupt them via
> Thread.interrupt() and sends an error to the client to ensure
> operation of the server. "Of course" those threads don't react to
> interrupts and remain in TIMED_WAITING state.
That is strange. There is no way to may thread immune wrt
Thread.interrupt(), probably something is wrong in 3rd party lib... May
be they fall into never-ending loop, or swallow IO)InterruptedException...
> Does Grizzly offer a more general approach to remove those threads
> from the threadpool? Is it possible to use our own existing
> implementation of ThreadPool/ExecutorService to achieve this?
Even though we suggest to use Grizzly thread pool implementation, it's
possible to set custom executor service to Grizzly
Transport#setWorkerThreadPool(ExecutorService).
But as I said I doubt it's a problem in Grizzly thread pool implementation.
Thanks.
WBR,
Alexey.
> Best regards,
> Marc