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

Sijie Guo commented on BOOKKEEPER-326:
--------------------------------------

thanks for Rakesh providing the patch.

{quote}
-    synchronized private void connect() {
-        if (state == ConnectionState.CONNECTING) {
-            return;
-        } 
-        // Start the connection attempt to the input server host.
-        state = ConnectionState.CONNECTING;
-
+    private void connect() {
{quote}

I am not sure I understood the above changes. but if you removed the above 
codes. how you could prevent concurrently call to #connect method? as Ivan 
suggested, synchronized on state variable would be enough.


{quote}
2. We should ensure that call to the client don't reenter. I've attached a 
patch which insures it doesn't happen on the public methods of LedgerHandle.
{quote}

-1 on the changes Ivan made to LedgerHandle. it breaks the throttle mechanism 
we deployed in BookKeeper now. for now, we use semaphore to do rate limit on 
both read/write operations, if permits are exhausted, the client which called 
addEntry/readEntries would be blocked until the permits are releases. the 
changes would not block client when permits are exhausted.

so before we had a new throttling mechanism (may be using RateLimit as Ivan 
mentioned), we don't need to include these changes in this jira. And I think it 
would be in BOOKKEEPER-239 discussing new throttling mechanism.
                
> DeadLock during ledger recovery 
> --------------------------------
>
>                 Key: BOOKKEEPER-326
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-326
>             Project: Bookkeeper
>          Issue Type: Bug
>    Affects Versions: 4.1.0
>            Reporter: Vinay
>            Priority: Blocker
>         Attachments: BK_DeadLock.log, BOOKKEEPER-326.1.patch, 
> BOOKKEEPER-326.part2.diff, BOOKKEEPER-326.patch
>
>
> Deadlock found during ledger recovery. please find the attached thread dump.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to