[
https://issues.apache.org/jira/browse/THRIFT-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated THRIFT-836:
---------------------------------
Priority: Blocker (was: Major)
> Race condition causes CancelledKeyException in TAsyncClientManager
> ------------------------------------------------------------------
>
> Key: THRIFT-836
> URL: https://issues.apache.org/jira/browse/THRIFT-836
> Project: Thrift
> Issue Type: Bug
> Components: Library (Java)
> Reporter: Ning Liang
> Assignee: Bryan Duxbury
> Priority: Blocker
> Fix For: 0.4
>
> Attachments: async_client_catch_all.diff, async_thrift.diff,
> async_thrift_catch_except.diff
>
>
> Currently, TAsyncClientMethod cancels its selection key on a successful
> method call. The current model assumes the key goes away and the client gets
> a new key on the next Selector registration, which is incorrect - the
> cancelled key can hang around, with the implication that the developer needs
> to check key.isValid() on the next selector action, which TAsyncClientMethod
> currently does. However, if the developer re-uses the client for another
> call, you can get a CancelledKeyException from the Selector#register call,
> which crashes the SelectorThread. This occurs once you have sufficient
> concurrency on the Selector - cancelled key cleanup takes longer, so we hit
> this condition.
> Attached is a patch with fix and regression test. Summary of fix:
> 1) Don't cancel() the key after a successful method call.
> 2) Catch CancelledKeyException in the SelectorThread, so the manager can't
> die.
> 3) Add an onError method to TAsyncMethodCall, so that the SelectorThread can
> notify the client of an error on selector registration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
