[infinispan-issues] [JBoss JIRA] (ISPN-2955) Async marshalling executor retry when queue fills

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763536#comment-12763536 ] 

Dan Berindei commented on ISPN-2955:
------------------------------------

[~mircea.markus] Using CallerRunsPolicy would make the caller thread block for the entire duration of the RPC, not just while the command is serialized. So it could lead to much bigger delays in the caller thread than CallerBlocksPolicy (which would block only until the fastest RPC finished).
                
> Async marshalling executor retry when queue fills
> -------------------------------------------------
>
>                 Key: ISPN-2955
>                 URL: https://issues.jboss.org/browse/ISPN-2955
>             Project: Infinispan
>          Issue Type: Enhancement
>          Components: Marshalling
>    Affects Versions: 5.2.5.Final
>            Reporter: Manik Surtani
>            Assignee: Manik Surtani
>             Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> When using an async transport and async marshalling, an executor is used to process the marshalling task in a separate thread and the caller's thread is allowed to return immediately.
> When the executor's queue fills and the queue cannot accept any more tasks, it throws a {{RejectedExecutionException}}, causing a very bad user/developer experience.  A more correct approach to this is to catch the {{RejectedExecutionException}}, block and retry the task submission.
> The end result is that, in the degenerate case (when the executor queue is full) instead of throwing exceptions, those invocations will perform slightly slower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira