[jira] [Commented] (ZOOKEEPER-1942) ZooKeeper OSGi package imports: org.ietf.jgss dependency missing from manifest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002784#comment-15002784 ] Amichai Rothman commented on ZOOKEEPER-1942: So when can we expect any of the releases? > ZooKeeper OSGi package imports: org.ietf.jgss dependency missing from manifest > -- > > Key: ZOOKEEPER-1942 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1942 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: Kalvin Misquith > > For OSGI applications, the zookeeper manifest file should have org.ietf.jgss > in its Import-Package statement. > org.apache.zookeeper.client.ZooKeeperSaslClient imports org.ietf.jgss.*. > The following ClassDefNotFoundError occurs without it. > java.lang.NoClassDefFoundError: org.ietf.jgss.GSSException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:94) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:171) > at > org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:945) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1003) > Caused by: java.lang.ClassNotFoundException: org.ietf.jgss.GSSException > at > org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) > at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) > at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) > at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) > at java.lang.ClassLoader.loadClass(ClassLoader.java:707) > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1942) ZooKeeper OSGi package imports: org.ietf.jgss dependency missing from manifest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002826#comment-15002826 ] Raul Gutierrez Segales commented on ZOOKEEPER-1942: --- [~amichai]: as soon as we get enough votes for 3.4.7-rc0: http://www.mail-archive.com/dev@zookeeper.apache.org/msg32159.html > ZooKeeper OSGi package imports: org.ietf.jgss dependency missing from manifest > -- > > Key: ZOOKEEPER-1942 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1942 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: Kalvin Misquith > > For OSGI applications, the zookeeper manifest file should have org.ietf.jgss > in its Import-Package statement. > org.apache.zookeeper.client.ZooKeeperSaslClient imports org.ietf.jgss.*. > The following ClassDefNotFoundError occurs without it. > java.lang.NoClassDefFoundError: org.ietf.jgss.GSSException > at java.lang.J9VMInternals.verifyImpl(Native Method) > at java.lang.J9VMInternals.verify(J9VMInternals.java:94) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:171) > at > org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:945) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1003) > Caused by: java.lang.ClassNotFoundException: org.ietf.jgss.GSSException > at > org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) > at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) > at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) > at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) > at java.lang.ClassLoader.loadClass(ClassLoader.java:707) > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1556) Memory leak reported by valgrind mt version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003080#comment-15003080 ] Hadriel Kaplan commented on ZOOKEEPER-1556: --- We've found the same thing at my company. In our case, the leak was caused because the completion thread can end before the IO thread, just before the IO thread created a completion entry for the completion thread to process. We added a mutex guard to prevent the completion thread (do_completion()) from exiting its while-loop until the IO thread (do_io()) had exited its while loop; and also added an extra call to process_completions(zh) just after the while-loop in case it had one more to do. We cleared the new mutex guard inside of adaptor_finish(), after the IO thread is ended. The reason is that the IO thread (and the completion thread) can finish their while-loops as soon as zh->close_requested is set to 1 in zookeeper_close(), including before free_completions() does its stuff... and since free_completions() can create one or more fake responses for the completion thread to process (for unanswered requests), it's possible for free_completions() to also add things to the completion queue and cause the memory leak. So keeping the completion thread inside its while-loop until adaptor_finish() is called seems to make sense. > Memory leak reported by valgrind mt version > --- > > Key: ZOOKEEPER-1556 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1556 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.4 >Reporter: André Martin >Priority: Minor > > Valgrind reports the following memory leak when using the c-client (mt): > ==11674== 18 bytes in 9 blocks are indirectly lost in loss record 14 of 173 > ==11674==at 0x4C2B6CD: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11674==by 0xC8064A: ia_deserialize_string (recordio.c:271) > ==11674==by 0xC81F2E: deserialize_String_vector (zookeeper.jute.c:247) > ==11674==by 0xC842F9: deserialize_GetChildrenResponse > (zookeeper.jute.c:874) > ==11674==by 0xC7E9F0: zookeeper_process (zookeeper.c:1904) > ==11674==by 0xC7FE5B: do_io (mt_adaptor.c:439) > ==11674==by 0x4E39E99: start_thread (pthread_create.c:308) > ==11674==by 0x5FA6DBC: clone (clone.S:112) > ==11674== > ==11674== 90 (72 direct, 18 indirect) bytes in 49 blocks are definitely lost > in loss record 139 of 173 > ==11674==at 0x4C29DB4: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11674==by 0xC81EEE: deserialize_String_vector (zookeeper.jute.c:245) > ==11674==by 0xC842F9: deserialize_GetChildrenResponse > (zookeeper.jute.c:874) > ==11674==by 0xC7E9F0: zookeeper_process (zookeeper.c:1904) > ==11674==by 0xC7FE5B: do_io (mt_adaptor.c:439) > ==11674==by 0x4E39E99: start_thread (pthread_create.c:308) > ==11674==by 0x5FA6DBC: clone (clone.S:112) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2307) ZooKeeper not starting because acceptedEpoch is less than the currentEpoch
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2307:
---
Attachment: ZOOKEEPER-2307-03.patch
Previous patch failed two tested cases {{testTxnTimeout}} and {{testNormalRun}}
in {{org.apache.zookeeper.server.quorum.Zab1_0Test}} This happened because
after this issue fix currentEpoch and acceptedEpoch update takes more time as
it is first written to file and then run time value is changed.
To fix the these failing test case, now we should wait at least for a time
taken to write small data to a file.
> ZooKeeper not starting because acceptedEpoch is less than the currentEpoch
> --
>
> Key: ZOOKEEPER-2307
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2307
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.5.2
>
> Attachments: ZOOKEEPER-2307-01.patch, ZOOKEEPER-2307-02.patch,
> ZOOKEEPER-2307-03.patch
>
>
> This issue occurred in one of our test environment where disk was being
> changed to read only very frequently.
> The the scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C
> # Start A and B. Both A and B start successfully, quorum is running.
> # Start C, because of IO error C fails to update acceptedEpoch file. But C
> also starts successfully, joins the quorum as follower
> # Stop C
> # Start C, bellow exception with message "The accepted epoch, 0 is less than
> the current epoch, 1" is thrown
> {code}
> 2015-10-29 16:52:32,942 [myid:3] - ERROR [main:QuorumPeer@784] - Unable to
> load database on disk
> java.io.IOException: The accepted epoch, 0 is less than the current epoch, 1
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:781)
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:720)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:202)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:139)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:88)
> 2015-10-29 16:52:32,946 [myid:3] - ERROR [main:QuorumPeerMain@111] -
> Unexpected exception, exiting abnormally
> java.lang.RuntimeException: Unable to run quorum server
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:785)
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:720)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:202)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:139)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:88)
> Caused by: java.io.IOException: The accepted epoch, 0 is less than the
> current epoch, 1
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:781)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2139) Zookeeper client configuration should not be java system property
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003497#comment-15003497
]
Walllee li commented on ZOOKEEPER-2139:
---
In my stage, the client needs to connect two secure kerberos. The patch does
not solve this stage.How can i deal with the stage?
> Zookeeper client configuration should not be java system property
> -
>
> Key: ZOOKEEPER-2139
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2139
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.5.0
>Reporter: Surendra Singh Lilhore
>Assignee: Arshad Mohammad
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2139-05.patch, ZOOKEEPER-2139.patch,
> ZOOKEEPER-2139.patch, ZOOKEEPER-2139_1.patch, ZOOKEEPER-2139_2.patch
>
>
> I have two ZK client in one JVM, one is secure client and second is normal
> client (For non secure cluster).
> "zookeeper.sasl.client" system property is "true" by default, because of this
> my second client connection is failing.
> We should pass all client configurations in client constructor like HDFS
> client.
> For example :
> {code}
> public ZooKeeper(String connectString, int sessionTimeout, Watcher watcher,
> Configuration conf) throws IOException
> {
> ..
> ..
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2141) ACL cache in DataTree never removes entries
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Junqueira updated ZOOKEEPER-2141: Assignee: Karol Dudzinski > ACL cache in DataTree never removes entries > --- > > Key: ZOOKEEPER-2141 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2141 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: Karol Dudzinski >Assignee: Karol Dudzinski > Attachments: ZOOKEEPER-2141.patch > > > The problem and potential solutions are discussed in > http://mail-archives.apache.org/mod_mbox/zookeeper-user/201502.mbox/browser > I will attach a proposed patch in due course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2141) ACL cache in DataTree never removes entries
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karol Dudzinski updated ZOOKEEPER-2141: --- Attachment: ZOOKEEPER-2141.patch > ACL cache in DataTree never removes entries > --- > > Key: ZOOKEEPER-2141 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2141 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: Karol Dudzinski > Attachments: ZOOKEEPER-2141.patch > > > The problem and potential solutions are discussed in > http://mail-archives.apache.org/mod_mbox/zookeeper-user/201502.mbox/browser > I will attach a proposed patch in due course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2141) ACL cache in DataTree never removes entries
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002206#comment-15002206 ] Hadoop QA commented on ZOOKEEPER-2141: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12771977/ZOOKEEPER-2141.patch against trunk revision 1713774. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2955//console This message is automatically generated. > ACL cache in DataTree never removes entries > --- > > Key: ZOOKEEPER-2141 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2141 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: Karol Dudzinski > Attachments: ZOOKEEPER-2141.patch > > > The problem and potential solutions are discussed in > http://mail-archives.apache.org/mod_mbox/zookeeper-user/201502.mbox/browser > I will attach a proposed patch in due course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
would like to contribute to the zookeeper
Dear, I'm Java Developer from China, and want to contribute some code to ZooKeeper. What do I need to do to get that? Justin Liu 2015/11/12
Failed: ZOOKEEPER-2141 PreCommit Build #2955
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2141 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2955/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 168 lines...] [exec] Skipping patch. [exec] 2 out of 2 hunks ignored [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12771977/ZOOKEEPER-2141.patch [exec] against trunk revision 1713774. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2955//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] f4c898681b5a11ae7e0a266c09ad9d1c2f659102 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1787: exec returned: 1 Total time: 1 minute 9 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 Recording test results Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 ERROR: Publisher 'Publish JUnit test result report' failed: No test report files were found. Configuration error? Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 [description-setter] Description set: ZOOKEEPER-2141 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 Setting LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7 ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Created] (ZOOKEEPER-2320) C-client crashes when removing watcher asynchronously in "local" mode
Hadriel Kaplan created ZOOKEEPER-2320:
-
Summary: C-client crashes when removing watcher asynchronously in
"local" mode
Key: ZOOKEEPER-2320
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2320
Project: ZooKeeper
Issue Type: Bug
Components: c client
Affects Versions: 3.5.1
Reporter: Hadriel Kaplan
The C-client library will crash when invoking the asynchronous
{{zoo_aremove_watchers()}} API function with the '{{local}}' argument set to 1.
The reason is: if the local argument is 1/true, then the code does
'{{notify_sync_completion((struct sync_completion *)data);}}' But casting the
'{{data}}' variable to a {{sync_completion}} struct pointer is bogus/invalid,
and when it's later handles as that struct pointer it's accessing invalid
memory.
As a side note: it will work ok when called _synchronously_ through
{{zoo_remove_watchers()}}, because that function creates a {{sync_completion}}
struct and passes it to the asynch {{zoo_aremove_watchers()}}, but it will not
work ok when the asynch function is used directly for the reason stated
perviously.
Another side note: the docs state that setting the 'local' flag makes the
C-client remove the watcher "even if there is no server connection" - but
really it makes the C-client remove the watcher without notifying the server at
*all*, even if the connection to a server is up. (well... that's what it would
do if it didn't just crash instead ;)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
