[jira] [Commented] (THRIFT-2235) TThreadPoolServer should have a NOP reject policy

["Alejandro Abdelnur (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816852#comment-13816852 ] 

Alejandro Abdelnur commented on THRIFT-2235:
--------------------------------------------

My comment of not using a {{SynchronousQueue}} is wrong because  the TThreadPoolServer keeps a dedicated thread per client (as opposed to using a thread only when there is a service call).

The suggestion of using a {{RejectedExecutionHandler}} is still correct to avoid the Thrift server from hanging.

Also, the rejected client is not notified of the rejection, this means that the client will be hang until the timeout kicks in. To avoid this, the {{RejectedExecutionHandler}} should cast the {{Runnable}} to {{WorkerProcess}}, get the {{TTransport client_}}  field and close it.

> TThreadPoolServer should have a NOP reject policy
> -------------------------------------------------
>
>                 Key: THRIFT-2235
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2235
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.9.1
>            Reporter: Alejandro Abdelnur
>
> We are running into the issue described in THRIFT-692.
> It is possible to reproduce this easily by having concurrent requests exceeding the number of maximum threads.
> In this scenario, the threadpoolexecutor fails with an exception and the thrift server endpoint becomes unresponsive.
> The ThreadPoolExecutor should set a discard rejection policy to avoid this issue.  
> {code}
>     executor.setRejectedExecutionHandler(new RejectedExecutionHandler() {
>       @Override
>       public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
>       //LOG ERROR indicating that client request is being discarded.
>       }
>     });
> {code}
> Also, as suggested in THRIFT-692, using a bounded LinkedBlockingQueue instead the a SynchronousQueue would help to cope with spikes of requests beyond the max number of threads without failing users.



--
This message was sent by Atlassian JIRA
(v6.1#6144)