[jira] Created: (ZOOKEEPER-219) events.poll timeout in watcher test too short
events.poll timeout in watcher test too short - Key: ZOOKEEPER-219 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-219 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Priority: Minor Fix For: 3.0.1, 3.1.0 in watchertest there are some event.poll calls that have 1milli timeouts e = localWatcher.events.poll(1, TimeUnit.MILLISECONDS); this is showing falure in some cases under hudson (I assume when it's under load from other tests running for other proj) We should review the poll calls and verify adequate timeouts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-217) Errors in config file
[ https://issues.apache.org/jira/browse/ZOOKEEPER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646693#action_12646693 ] Flavio Paiva Junqueira commented on ZOOKEEPER-217: -- Instead of a boolean, we should throw an exception that propagates all the way back to main and exit there. Errors in config file - Key: ZOOKEEPER-217 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-217 Project: Zookeeper Issue Type: Improvement Components: server Affects Versions: 3.0.0 Reporter: Flavio Paiva Junqueira Priority: Minor Fix For: 3.0.1, 3.1.0 Discussing 209 with Ben today, we thought that it would be better to have the parse method of QuorumPeerConfig returning a boolean that indicates whether the configuration is good or not, and let the caller decide whether to exit or not. Currently we execute a System.exit() on QuorumPeerConfig.parse when we have a critical configuration error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-219) events.poll timeout in watcher test too short
[ https://issues.apache.org/jira/browse/ZOOKEEPER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-219: --- Status: Patch Available (was: Open) events.poll timeout in watcher test too short - Key: ZOOKEEPER-219 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-219 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Priority: Minor Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-219.patch in watchertest there are some event.poll calls that have 1milli timeouts e = localWatcher.events.poll(1, TimeUnit.MILLISECONDS); this is showing falure in some cases under hudson (I assume when it's under load from other tests running for other proj) We should review the poll calls and verify adequate timeouts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-219) events.poll timeout in watcher test too short
[ https://issues.apache.org/jira/browse/ZOOKEEPER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-219: -- Assignee: Patrick Hunt events.poll timeout in watcher test too short - Key: ZOOKEEPER-219 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-219 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-219.patch in watchertest there are some event.poll calls that have 1milli timeouts e = localWatcher.events.poll(1, TimeUnit.MILLISECONDS); this is showing falure in some cases under hudson (I assume when it's under load from other tests running for other proj) We should review the poll calls and verify adequate timeouts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-218) error in barrier recipe example code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-218: --- Attachment: ZOOKEEPER-218.patch it seemed to me that the arg to the method should be root, not name, I've updated the code as such. Also made the node creation as eph/seq so that multiple processes per host can participate in a specific barrier error in barrier recipe example code Key: ZOOKEEPER-218 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-218 Project: Zookeeper Issue Type: Bug Components: documentation Affects Versions: 3.0.0 Reporter: Patrick Hunt Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-218.patch Report from user Murali Vemulapati. The wiki recipe page also should be updated to handle multiple clients using the barrier on the same system (multiple processes, etc...). Currently the docs/example support only a single user of the barrier per host. -- I believe there is a typo in the barrier example given at: http://hadoop.apache.org/zookeeper/docs/current/zookeeperTutorial.html With the following fix, the program runs as expected: == 83c83 this.name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); --- name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); 100c100 CreateMode.EPHEMERAL_SEQUENTIAL); --- CreateMode.EPHEMERAL); == The first change assigns the name to the instance variable 'name' of Barrier class (otherwise the 'name' instance variable will have a value of 'null' when calling zk.create to create the child node under the root barrier node). The second change lets us run multiple processes on the same machine. thanks murali -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-218) error in barrier recipe example code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-218: -- Assignee: Patrick Hunt error in barrier recipe example code Key: ZOOKEEPER-218 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-218 Project: Zookeeper Issue Type: Bug Components: documentation Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-218.patch Report from user Murali Vemulapati. The wiki recipe page also should be updated to handle multiple clients using the barrier on the same system (multiple processes, etc...). Currently the docs/example support only a single user of the barrier per host. -- I believe there is a typo in the barrier example given at: http://hadoop.apache.org/zookeeper/docs/current/zookeeperTutorial.html With the following fix, the program runs as expected: == 83c83 this.name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); --- name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); 100c100 CreateMode.EPHEMERAL_SEQUENTIAL); --- CreateMode.EPHEMERAL); == The first change assigns the name to the instance variable 'name' of Barrier class (otherwise the 'name' instance variable will have a value of 'null' when calling zk.create to create the child node under the root barrier node). The second change lets us run multiple processes on the same machine. thanks murali -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-218) error in barrier recipe example code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-218: --- Status: Patch Available (was: Open) error in barrier recipe example code Key: ZOOKEEPER-218 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-218 Project: Zookeeper Issue Type: Bug Components: documentation Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-218.patch Report from user Murali Vemulapati. The wiki recipe page also should be updated to handle multiple clients using the barrier on the same system (multiple processes, etc...). Currently the docs/example support only a single user of the barrier per host. -- I believe there is a typo in the barrier example given at: http://hadoop.apache.org/zookeeper/docs/current/zookeeperTutorial.html With the following fix, the program runs as expected: == 83c83 this.name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); --- name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); 100c100 CreateMode.EPHEMERAL_SEQUENTIAL); --- CreateMode.EPHEMERAL); == The first change assigns the name to the instance variable 'name' of Barrier class (otherwise the 'name' instance variable will have a value of 'null' when calling zk.create to create the child node under the root barrier node). The second change lets us run multiple processes on the same machine. thanks murali -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-217) Errors in config file
[ https://issues.apache.org/jira/browse/ZOOKEEPER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-217: --- Fix Version/s: (was: 3.0.1) Errors in config file - Key: ZOOKEEPER-217 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-217 Project: Zookeeper Issue Type: Improvement Components: server Affects Versions: 3.0.0 Reporter: Flavio Paiva Junqueira Priority: Minor Fix For: 3.1.0 Discussing 209 with Ben today, we thought that it would be better to have the parse method of QuorumPeerConfig returning a boolean that indicates whether the configuration is good or not, and let the caller decide whether to exit or not. Currently we execute a System.exit() on QuorumPeerConfig.parse when we have a critical configuration error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-64) We should log system env information when intializing client/server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646741#action_12646741 ] Patrick Hunt commented on ZOOKEEPER-64: --- On client or server regardless of runtime/architecture: zookeeper.version version number host.name name of host os.name Operating system name os.arch Operating system architecture os.version Operating system version user.name User's account name user.home User's home directory user.dirUser's current working directory In addition I'm planning to log the following from java client/server code: java.versionJava Runtime Environment version java.vendor Java Runtime Environment vendor java.home Java installation directory java.class.path Java class path java.library.path List of paths to search when loading libraries java.io.tmpdir Default temp file path java.compiler Name of JIT compiler to use We should log system env information when intializing client/server --- Key: ZOOKEEPER-64 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-64 Project: Zookeeper Issue Type: Improvement Components: c client, java client, server Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 We should log system environment information (as much as possible) during both client server initialization. This will help with debugging of customer issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
