[
https://issues.apache.org/jira/browse/BOOKKEEPER-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415077#comment-13415077
]
Sijie Guo edited comment on BOOKKEEPER-326 at 7/16/12 12:59 PM:
----------------------------------------------------------------
thanks for Rakesh providing the patch.
{code}
- synchronized private void connect() {
- if (state == ConnectionState.CONNECTING) {
- return;
- }
- // Start the connection attempt to the input server host.
- state = ConnectionState.CONNECTING;
-
+ private void connect() {
{code}
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.
was (Author: hustlmsp):
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
