You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Flavio Paiva Junqueira (JIRA)" <ji...@apache.org> on 2009/05/12 23:28:02 UTC
[jira] Created: (ZOOKEEPER-400) Issues with procedure to close
ledger
Issues with procedure to close ledger
-------------------------------------
Key: ZOOKEEPER-400
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
Project: Zookeeper
Issue Type: Bug
Components: contrib-bookkeeper
Reporter: Flavio Paiva Junqueira
Priority: Critical
When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
* On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
* LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708666#action_12708666 ]
Hadoop QA commented on ZOOKEEPER-400:
-------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12407927/ZOOKEEPER-400.patch
against trunk revision 774081.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 6 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/72/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/72/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/72/console
This message is automatically generated.
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Flavio Paiva Junqueira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Flavio Paiva Junqueira updated ZOOKEEPER-400:
---------------------------------------------
Attachment: ZOOKEEPER-400.patch
This patch implements the modifications as suggested and changes unit tests accordingly.
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Flavio Paiva Junqueira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Flavio Paiva Junqueira updated ZOOKEEPER-400:
---------------------------------------------
Status: Patch Available (was: Open)
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Flavio Paiva Junqueira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Flavio Paiva Junqueira reassigned ZOOKEEPER-400:
------------------------------------------------
Assignee: Flavio Paiva Junqueira
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Flavio Paiva Junqueira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Flavio Paiva Junqueira updated ZOOKEEPER-400:
---------------------------------------------
Resolution: Fixed
Fix Version/s: 3.2.0
Status: Resolved (was: Patch Available)
Committed.
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Flavio Paiva Junqueira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708820#action_12708820 ]
Flavio Paiva Junqueira commented on ZOOKEEPER-400:
--------------------------------------------------
Core tests failed again because of problems with the C tests. This issue is unrelated to this patch. In fact, this patch doesn't even modify ZooKeeper core.
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-400) Issues with procedure to close
ledger
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708965#action_12708965 ]
Benjamin Reed commented on ZOOKEEPER-400:
-----------------------------------------
+1 good catch!
> Issues with procedure to close ledger
> -------------------------------------
>
> Key: ZOOKEEPER-400
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-400
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Flavio Paiva Junqueira
> Assignee: Flavio Paiva Junqueira
> Priority: Critical
> Attachments: ZOOKEEPER-400.patch
>
>
> When running a few experiments with BookKeeper, I found a couple of issues with closing a ledger:
> * On ClientCBWorker::run(), we should call setAddConfirmed before invoking the callback method. Otherwise, it is possible that an application closes a ledger before ClientCBWorker modifies the last confirmed operation, and the value written to ZooKeeper won't be the last one written;
> * LedgerHandle should write the last add confirmed instead of the last counter. The last attribute counts the operations issued, and we use it to determine the id of the next entry. If an application calls close upon receiving all callbacks, then with the previous modification, the last confirmed add must be equal to (last-1). However, if an application invokes close before receiving all callbacks, the ledger may be left in an inconsistent state because the last entry written to ZooKeeper may be an operation that hasn't completed yet.
> Although the modifications required are simple, they are important.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.