[ 
https://issues.apache.org/jira/browse/CASSANDRA-5926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne resolved CASSANDRA-5926.
-----------------------------------------

    Resolution: Fixed

Let me re-close this since the committed did fix the original deadlock. It's 
obviously now unfortunate that we're running into a netty bug, but since 1.2.9 
has shipped, I've opened a separate issue (CASSANDRA-5955) to upgrade our 
dependency.
                
> The native protocol server can deadlock
> ---------------------------------------
>
>                 Key: CASSANDRA-5926
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5926
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 1.2.9
>
>         Attachments: 5926.txt, stack
>
>
> Until CASSANDRA-5239 (i.e. since StorageProxy is blocking), the native 
> protocol server needs to use a thread per request being processed. For that, 
> it currently use a DebuggableThreadPoolExecutor, but with a limited queue. 
> The rational being that we don't want to OOM if a client overwhelm the 
> server. Rather, we prefer blocking (which DTPE gives us) on the submission of 
> new request by the netty worker threads when all threads are busy.
> However, as it happens, when netty sends back a response to a query, there is 
> cases where some events (technically, InterestChanged and WriteComplete 
> events) are send up the pipeline. And those event are submitted on the 
> request executor as other requests. Long story short, a request thread can 
> end blocking on the submission to its own executor, hence deadlocking.
> The simplest solution is probably to reuse MemoryAwareThreadPoolExecutor from 
> netty rather that our own DTPE as it also allow to block task submission when 
> all threads are busy but knows not to block it's own internal events.

--
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

Reply via email to