[jira] Created: (ZOOKEEPER-795) eventThread isn't shutdown after a connection session expired event coming
eventThread isn't shutdown after a connection session expired event coming Key: ZOOKEEPER-795 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-795 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.3.1 Environment: ubuntu 10.04 Reporter: mathieu barcikowski Priority: Critical Hi, I notice a problem with the eventThread located in ClientCnxn.java file. The eventThread isn't shutdown after a connection session expired event coming (i.e. never receive EventOfDeath). When a session timeout occurs and the session is marked as expired, the connexion is fully closed (socket, SendThread...) expect for the eventThread. As a result, if i create a new zookeeper object and connect through it, I got a zombi thread which will never be kill (as for the previous zookeeper object, the state is already close, calling close again don't do anything). So everytime I will create a new zookeeper connection after a expired session, I will have a one more zombi EventThread. How to reproduce : - Start a zookeeper client connection in debug mode - Pause the jvm enough time to the expired event occur - Watch for example with jvisualvm the list of threads, the sendThread is succesfully killed, but the EventThread go to wait state for a infinity of time - if you reopen a new zookeeper connection, and do again the previous steps, another EventThread will be present in infinite wait state -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-789) Improve FLE log messages
[ https://issues.apache.org/jira/browse/ZOOKEEPER-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-789: - Status: Patch Available (was: Open) Improve FLE log messages Key: ZOOKEEPER-789 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-789 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.3.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.2, 3.4.0 Attachments: ZOOKEEPER-789.patch, ZOOKEEPER-789.patch Notification messages are quite important to determine what is going with leader election. The main idea of this improvement is name the fields we output in notification log messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-789) Improve FLE log messages
[ https://issues.apache.org/jira/browse/ZOOKEEPER-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-789: - Attachment: ZOOKEEPER-789.patch Thanks for pointing it out, Pat. I forgot to edit the preferences (new desktop). Here is a new patch. Improve FLE log messages Key: ZOOKEEPER-789 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-789 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.3.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.2, 3.4.0 Attachments: ZOOKEEPER-789.patch, ZOOKEEPER-789.patch Notification messages are quite important to determine what is going with leader election. The main idea of this improvement is name the fields we output in notification log messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-793) Large-scale Pub/Sub System (C++ Client)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883184#action_12883184 ] Ivan Kelly commented on ZOOKEEPER-793: -- This is great feedback. A lot of the things were simply things I overlooked, or bad habits carried over from java :) I'm a bit confused by your first point. The interface and implementation are already separate. If you want to stub out the hedwig client, just implement the Client, Subscriber and Publisher class and don't link against the actual hedwig library. Perhaps I misread. Large-scale Pub/Sub System (C++ Client) --- Key: ZOOKEEPER-793 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-793 Project: Zookeeper Issue Type: Sub-task Reporter: Ivan Kelly Assignee: Ivan Kelly Attachments: hedwig-cpp-0.1.tar.gz Write a c++ client for hedwig -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-795) eventThread isn't shutdown after a connection session expired event coming
[ https://issues.apache.org/jira/browse/ZOOKEEPER-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883316#action_12883316 ] Patrick Hunt commented on ZOOKEEPER-795: A second user reported this issue to me. When we fix this we should also address the event thread naming. Where the user creates a new session from within the event thread context we end up with a very long thread name (we keep appending the thread name to the parent thread... so main-event-event-event-event, etc...) eventThread isn't shutdown after a connection session expired event coming Key: ZOOKEEPER-795 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-795 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.3.1 Environment: ubuntu 10.04 Reporter: mathieu barcikowski Priority: Blocker Fix For: 3.3.2, 3.4.0 Hi, I notice a problem with the eventThread located in ClientCnxn.java file. The eventThread isn't shutdown after a connection session expired event coming (i.e. never receive EventOfDeath). When a session timeout occurs and the session is marked as expired, the connexion is fully closed (socket, SendThread...) expect for the eventThread. As a result, if i create a new zookeeper object and connect through it, I got a zombi thread which will never be kill (as for the previous zookeeper object, the state is already close, calling close again don't do anything). So everytime I will create a new zookeeper connection after a expired session, I will have a one more zombi EventThread. How to reproduce : - Start a zookeeper client connection in debug mode - Pause the jvm enough time to the expired event occur - Watch for example with jvisualvm the list of threads, the sendThread is succesfully killed, but the EventThread go to wait state for a infinity of time - if you reopen a new zookeeper connection, and do again the previous steps, another EventThread will be present in infinite wait state -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-795) eventThread isn't shutdown after a connection session expired event coming
[ https://issues.apache.org/jira/browse/ZOOKEEPER-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-795: --- Fix Version/s: 3.3.2 3.4.0 Priority: Blocker (was: Critical) eventThread isn't shutdown after a connection session expired event coming Key: ZOOKEEPER-795 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-795 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.3.1 Environment: ubuntu 10.04 Reporter: mathieu barcikowski Priority: Blocker Fix For: 3.3.2, 3.4.0 Hi, I notice a problem with the eventThread located in ClientCnxn.java file. The eventThread isn't shutdown after a connection session expired event coming (i.e. never receive EventOfDeath). When a session timeout occurs and the session is marked as expired, the connexion is fully closed (socket, SendThread...) expect for the eventThread. As a result, if i create a new zookeeper object and connect through it, I got a zombi thread which will never be kill (as for the previous zookeeper object, the state is already close, calling close again don't do anything). So everytime I will create a new zookeeper connection after a expired session, I will have a one more zombi EventThread. How to reproduce : - Start a zookeeper client connection in debug mode - Pause the jvm enough time to the expired event occur - Watch for example with jvisualvm the list of threads, the sendThread is succesfully killed, but the EventThread go to wait state for a infinity of time - if you reopen a new zookeeper connection, and do again the previous steps, another EventThread will be present in infinite wait state -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-796) zkServer.sh should support an external PIDFILE variable
zkServer.sh should support an external PIDFILE variable --- Key: ZOOKEEPER-796 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-796 Project: Zookeeper Issue Type: Bug Reporter: Alex Newman So currently the pid file has to be tied to the datadirectory when starting zkServer.sh. It would be good to be able to break them up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-796) zkServer.sh should support an external PIDFILE variable
[ https://issues.apache.org/jira/browse/ZOOKEEPER-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Newman updated ZOOKEEPER-796: -- Attachment: foo.patch zkServer.sh should support an external PIDFILE variable --- Key: ZOOKEEPER-796 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-796 Project: Zookeeper Issue Type: Bug Reporter: Alex Newman Attachments: foo.patch So currently the pid file has to be tied to the datadirectory when starting zkServer.sh. It would be good to be able to break them up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-796) zkServer.sh should support an external PIDFILE variable
[ https://issues.apache.org/jira/browse/ZOOKEEPER-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Newman updated ZOOKEEPER-796: -- Status: Patch Available (was: Open) zkServer.sh should support an external PIDFILE variable --- Key: ZOOKEEPER-796 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-796 Project: Zookeeper Issue Type: Bug Reporter: Alex Newman Attachments: foo.patch So currently the pid file has to be tied to the datadirectory when starting zkServer.sh. It would be good to be able to break them up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model
[ https://issues.apache.org/jira/browse/ZOOKEEPER-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883334#action_12883334 ] Abmar Barros commented on ZOOKEEPER-702: As discussed with Flavio, I am thinking of adding a new parameter called -fd to the client, which will determine the name of the failure detector to be used. In this sense, the parameters of the failure detector will have its name as prefix, for instance: -fd chen -fd.chen.alpha 1 In the server side, these parameters are intended to be defined in the ZooKeeper configuration file. What do you think? GSoC 2010: Failure Detector Model - Key: ZOOKEEPER-702 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702 Project: Zookeeper Issue Type: Wish Reporter: Henry Robinson Assignee: Abmar Barros Attachments: bertier-pseudo.txt, chen-pseudo.txt, phiaccrual-pseudo.txt, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch Failure Detector Module Possible Mentor Henry Robinson (henry at apache dot org) Requirements Java, some distributed systems knowledge, comfort implementing distributed systems protocols Description ZooKeeper servers detects the failure of other servers and clients by counting the number of 'ticks' for which it doesn't get a heartbeat from other machines. This is the 'timeout' method of failure detection and works very well; however it is possible that it is too aggressive and not easily tuned for some more unusual ZooKeeper installations (such as in a wide-area network, or even in a mobile ad-hoc network). This project would abstract the notion of failure detection to a dedicated Java module, and implement several failure detectors to compare and contrast their appropriateness for ZooKeeper. For example, Apache Cassandra uses a phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which is much more tunable and has some very interesting properties. This is a great project if you are interested in distributed algorithms, or want to help re-factor some of ZooKeeper's internal code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-796) zkServer.sh should support an external PIDFILE variable
[ https://issues.apache.org/jira/browse/ZOOKEEPER-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883403#action_12883403 ] Hadoop QA commented on ZOOKEEPER-796: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12448246/foo.patch against trunk revision 958096. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. -1 patch. The patch command could not apply the patch. Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/87/console This message is automatically generated. zkServer.sh should support an external PIDFILE variable --- Key: ZOOKEEPER-796 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-796 Project: Zookeeper Issue Type: Bug Reporter: Alex Newman Attachments: foo.patch So currently the pid file has to be tied to the datadirectory when starting zkServer.sh. It would be good to be able to break them up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-797) c client source with AI_ADDRCONFIG cannot be compiled with early glibc
[ https://issues.apache.org/jira/browse/ZOOKEEPER-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qian Ye updated ZOOKEEPER-797: -- Status: Patch Available (was: Open) c client source with AI_ADDRCONFIG cannot be compiled with early glibc -- Key: ZOOKEEPER-797 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-797 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.3.1 Environment: linux 2.6.9 Reporter: Qian Ye Attachments: ZOOKEEPER-797.patch c client source with AI_ADDRCONFIG cannot be compiled with early glibc (before 2.3.3) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-797) c client source with AI_ADDRCONFIG cannot be compiled with early glibc
c client source with AI_ADDRCONFIG cannot be compiled with early glibc -- Key: ZOOKEEPER-797 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-797 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.3.1 Environment: linux 2.6.9 Reporter: Qian Ye Attachments: ZOOKEEPER-797.patch c client source with AI_ADDRCONFIG cannot be compiled with early glibc (before 2.3.3) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-797) c client source with AI_ADDRCONFIG cannot be compiled with early glibc
[ https://issues.apache.org/jira/browse/ZOOKEEPER-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qian Ye updated ZOOKEEPER-797: -- Attachment: ZOOKEEPER-797.patch c client source with AI_ADDRCONFIG cannot be compiled with early glibc -- Key: ZOOKEEPER-797 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-797 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.3.1 Environment: linux 2.6.9 Reporter: Qian Ye Attachments: ZOOKEEPER-797.patch c client source with AI_ADDRCONFIG cannot be compiled with early glibc (before 2.3.3) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
