[jira] [Commented] (ZOOKEEPER-2211) PurgeTxnLog does not correctly purge when snapshots and logs are at different locations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996646#comment-14996646 ] Arshad Mohammad commented on ZOOKEEPER-2211: Thanks [~rgs] for committing the patch. Submitted ZOOKEEPER-2211-04_br_3_4.patch for branch-3.4. > PurgeTxnLog does not correctly purge when snapshots and logs are at different > locations > --- > > Key: ZOOKEEPER-2211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2211 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.6, 3.5.0 > Environment: Ubuntu 12.04, Java 1.7. >Reporter: Wesley Chow >Assignee: Arshad Mohammad > Fix For: 3.4.7, 3.5.2, 3.6.0 > > Attachments: ZOOKEEPER-2211-02.patch, ZOOKEEPER-2211-03.patch, > ZOOKEEPER-2211-04.patch, ZOOKEEPER-2211-04_br_3_4.patch, ZOOKEEPER-2211.patch > > > PurgeTxnLog does not work when snapshots and transaction logs are at > different file paths. The argument handling is buggy and only works when both > snap and datalog dirs are given, and datalog dir contains both logs and snaps > (snap is ignored). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2211) PurgeTxnLog does not correctly purge when snapshots and logs are at different locations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad updated ZOOKEEPER-2211: --- Attachment: ZOOKEEPER-2211-04_br_3_4.patch > PurgeTxnLog does not correctly purge when snapshots and logs are at different > locations > --- > > Key: ZOOKEEPER-2211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2211 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.6, 3.5.0 > Environment: Ubuntu 12.04, Java 1.7. >Reporter: Wesley Chow >Assignee: Arshad Mohammad > Fix For: 3.4.7, 3.5.2, 3.6.0 > > Attachments: ZOOKEEPER-2211-02.patch, ZOOKEEPER-2211-03.patch, > ZOOKEEPER-2211-04.patch, ZOOKEEPER-2211-04_br_3_4.patch, ZOOKEEPER-2211.patch > > > PurgeTxnLog does not work when snapshots and transaction logs are at > different file paths. The argument handling is buggy and only works when both > snap and datalog dirs are given, and datalog dir contains both logs and snaps > (snap is ignored). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: ZOOKEEPER-2211 PreCommit Build #2952
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2211 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2952/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 98 lines...] [exec] Skipping patch. [exec] 2 out of 2 hunks ignored -- saving rejects to file src/java/test/org/apache/zookeeper/server/PurgeTxnTest.java.rej [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/12771356/ZOOKEEPER-2211-04_br_3_4.patch [exec] against trunk revision 1713320. [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/2952//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] 6e04af28779e870f5f07b801e3641e882c00c0c1 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: 49 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-2211 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] [Commented] (ZOOKEEPER-2211) PurgeTxnLog does not correctly purge when snapshots and logs are at different locations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996655#comment-14996655 ] Hadoop QA commented on ZOOKEEPER-2211: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12771356/ZOOKEEPER-2211-04_br_3_4.patch against trunk revision 1713320. +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/2952//console This message is automatically generated. > PurgeTxnLog does not correctly purge when snapshots and logs are at different > locations > --- > > Key: ZOOKEEPER-2211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2211 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.6, 3.5.0 > Environment: Ubuntu 12.04, Java 1.7. >Reporter: Wesley Chow >Assignee: Arshad Mohammad > Fix For: 3.4.7, 3.5.2, 3.6.0 > > Attachments: ZOOKEEPER-2211-02.patch, ZOOKEEPER-2211-03.patch, > ZOOKEEPER-2211-04.patch, ZOOKEEPER-2211-04_br_3_4.patch, ZOOKEEPER-2211.patch > > > PurgeTxnLog does not work when snapshots and transaction logs are at > different file paths. The argument handling is buggy and only works when both > snap and datalog dirs are given, and datalog dir contains both logs and snaps > (snap is ignored). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996674#comment-14996674
]
Arshad Mohammad commented on ZOOKEEPER-1971:
JMX port is already configurable through JMXPORT environment variable. If user
adds {{export JMXPORT="9090"}} in {{zkEnv.sh}} or {{zookeeper-env.sh}} then
jmx will start on port 9090.
So there is nothing to be done as part of this JIRA. I will soon close this
JIRA.
> Make JMX remote monitoring port configurable
>
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
>
> This is a follow-up item from ZOOKEEPER-1948.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2319) UnresolvedAddressException cause the QuorumCnxManager.Listener exit
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhaohui Yu updated ZOOKEEPER-2319:
--
Description:
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I think we should catch UnresolvedAddressException to avoid the Listener exit.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
was:
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I don't think place the receiveConnection call in this try catch block is a
good idea. And I think we should catch UnresolvedAddressException to avoid the
Listener exit.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
> UnresolvedAddressException cause the QuorumCnxManager.Listener exit
> ---
>
> Key: ZOOKEEPER-2319
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2319
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Zhaohui Yu
>Priority: Critical
>
> Given three nodes, the leader on 2, but some issue with this machine, so I
> shutdown this machine, and change the host name to another machine.
> Then I start the node in the new machine, but the new node can not join.
> I found the the 1 and 3's Listener thread exit.
> With the code of Listener's run method:
> I think we should catch UnresolvedAddressException to avoid the Listener exit.
> @Override
> public void run() {
>
> while((!shutdown) && (numRetries < 3)){
> try {
>// bind and accept
> receiveConnection(client);
>
> } catch (IOException e) {
>
> }
> }
> //
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2319) UnresolvedAddressException cause the QuorumCnxManager.Listener exit
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhaohui Yu updated ZOOKEEPER-2319:
--
Description:
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I don't think place the receiveConnection call in this try catch block is a
good idea. And I think we should catch UnresolvedAddressException to avoid the
Listener exit.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
was:
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I don't think place the receiveConnection call in the try is a good idea. And I
think we should catch UnresolvedAddressException to avoid the Listener exit.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
> UnresolvedAddressException cause the QuorumCnxManager.Listener exit
> ---
>
> Key: ZOOKEEPER-2319
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2319
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Zhaohui Yu
>Priority: Critical
>
> Given three nodes, the leader on 2, but some issue with this machine, so I
> shutdown this machine, and change the host name to another machine.
> Then I start the node in the new machine, but the new node can not join.
> I found the the 1 and 3's Listener thread exit.
> With the code of Listener's run method:
> I don't think place the receiveConnection call in this try catch block is a
> good idea. And I think we should catch UnresolvedAddressException to avoid
> the Listener exit.
> @Override
> public void run() {
>
> while((!shutdown) && (numRetries < 3)){
> try {
>// bind and accept
> receiveConnection(client);
>
> } catch (IOException e) {
>
> }
> }
> //
> }
--
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=14997068#comment-14997068
]
Gary Helmling commented on ZOOKEEPER-2139:
--
[~surendrasingh] Can you please re-attach the latest version of the patch? The
June 30 version, which I am assuming to be the latest, is missing the
ClientConfiguration class and won't compile.
> 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: Surendra Singh Lilhore
> Fix For: 3.5.2, 3.6.0
>
> Attachments: 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] [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=14996989#comment-14996989
]
Surendra Singh Lilhore commented on ZOOKEEPER-2139:
---
[~arshad.mohammad] offline discussed with me few days back. I will confirm with
him and assign accordingly.
> 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: Surendra Singh Lilhore
> Fix For: 3.5.2, 3.6.0
>
> Attachments: 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] [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=14997047#comment-14997047
]
Surendra Singh Lilhore commented on ZOOKEEPER-2139:
---
Thanks [~ghelmling]. Appreciate your interests. It would be good if we can test
this and will try to push this in. I tested in my env and please let me know
your feedback as well.
> 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: Surendra Singh Lilhore
> Fix For: 3.5.2, 3.6.0
>
> Attachments: 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] [Created] (ZOOKEEPER-2318) segfault in auth_completion_func
Marshall McMullen created ZOOKEEPER-2318:
Summary: segfault in auth_completion_func
Key: ZOOKEEPER-2318
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2318
Project: ZooKeeper
Issue Type: Bug
Components: c client
Affects Versions: 3.5.0
Reporter: Marshall McMullen
We have seen some sporadic issues with unexplained segfaults inside
auth_completion_func. The interesting thing is we are not using any auth
mechanism at all. This happened against this version of the code:
svn.apache.org/repos/asf/zookeeper/trunk@1547702
Here's the stacktrace we are seeing:
{code}
Thread 1 (Thread 0x7f21d13ff700 ? (LWP 5230)):
#0 0x7f21efff42f0 in auth_completion_func (rc=0, zh=0x7f21e7470800) at
src/zookeeper.c:1696
#1 0x7f21efff7898 in zookeeper_process (zh=0x7f21e7470800, events=2) at
src/zookeeper.c:2708
#2 0x7f21f0006583 in do_io (v=0x7f21e7470800) at src/mt_adaptor.c:440
#3 0x7f21eeab7e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x7f21ed1803fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#5 0x in ?? ()
{code}
The offending line in our case is:
1696LOG_INFO(LOGCALLBACK(zh), "Authentication scheme %s succeeded",
zh->auth_h.auth->scheme);
It must be the case that zh->auth_h.auth is NULL for this to happen since the
code path returns if zh is NULL.
Interesting log messages around this time:
{code}
Socket [10.170.243.7:2181] zk retcode=-2, errno=115(Operation now in progress):
unexpected server response: expected 0xfff9, but received 0xfff8
Priming connection to [10.170.243.4:2181]: last_zxid=0x370eb4d
initiated connection to server [10.170.243.4:2181]
Oct 13 12:03:21.273384 zookeeper - INFO
[NIOServerCxnFactory.AcceptThread:/10.170.243.4:2181:NIOServerCnxnFactory$AcceptThread@296]
- Accepted socket connection from /10.170.243.4:48523
Oct 13 12:03:21.274321 zookeeper - WARN
[NIOWorkerThread-24:ZooKeeperServer@822] - Connection request from old client
/10.170.243.4:48523; will be dropped if server is in r-o mode
Oct 13 12:03:21.274452 zookeeper - INFO
[NIOWorkerThread-24:ZooKeeperServer@869] - Client attempting to renew session
0x311596d004a at /10.170.243.4:48523; client last zxid is 0x30370eb4d;
server last zxid is 0x30370eb4d
Oct 13 12:03:21.274584 zookeeper - INFO [NIOWorkerThread-24:Learner@115] -
Revalidating client: 0x311596d004a
session establishment complete on server [10.170.243.4:2181],
sessionId=0x311596d004a, negotiated timeout=2
Oct 13 12:03:21.275693 zookeeper - INFO
[QuorumPeer[myid=1]/10.170.243.4:2181:ZooKeeperServer@611] - Established
session 0x311596d004a with negotiated timeout 2 for client
/10.170.243.4:48523
Oct 13 12:03:24.229590 zookeeper - WARN [NIOWorkerThread-8:NIOServerCnxn@361]
- Unable to read additional data from client sessionid 0x311596d004a,
likely client has closed socket
Oct 13 12:03:24.230018 zookeeper - INFO [NIOWorkerThread-8:NIOServerCnxn@999]
- Closed socket connection for client /10.170.243.4:48523 which had sessionid
0x311596d004a
Oct 13 12:03:24.230257 zookeeper - WARN [NIOWorkerThread-19:NIOServerCnxn@361]
- Unable to read additional data from client sessionid 0x12743aa0001,
likely client has closed socket
{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=14996888#comment-14996888
]
Gary Helmling commented on ZOOKEEPER-2139:
--
[~surendrasingh] are you still interested in working on this? If not, I would
be happy to pick up the latest patch and try to get it in. Or if you are still
working on this, maybe I can help test the latest patch?
> 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: Surendra Singh Lilhore
> Fix For: 3.5.2, 3.6.0
>
> Attachments: 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] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14996714#comment-14996714 ] nijel commented on ZOOKEEPER-1971: -- Hi [~arshad.mohammad] thanks for the analysis As per my initial analysis, only one jmx port can be configurable, where as when JMX is enabled it is listening to 2 ports will be open for listening Normally in production clusters, listening to a non-configured port is not recommandable. > Make JMX remote monitoring port configurable > > > Key: ZOOKEEPER-1971 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971 > Project: ZooKeeper > Issue Type: Improvement > Components: server > Environment: All >Reporter: Biju Nair >Assignee: Arshad Mohammad > > This is a follow-up item from ZOOKEEPER-1948. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2317) Non-OSGi compatible version
Markus Tippmann created ZOOKEEPER-2317: -- Summary: Non-OSGi compatible version Key: ZOOKEEPER-2317 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2317 Project: ZooKeeper Issue Type: Bug Components: build Affects Versions: 3.5.1 Environment: Karaf OSGi container Reporter: Markus Tippmann Bundle cannot be deployed to OSGi container. Manifest version is not OSGi compatible. Instead of using 3.5.1-alpha, manifest needs to contain 3.5.1.alpha -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2319) UnresolvedAddressException cause the QuorumCnxManager.Listener exit
Zhaohui Yu created ZOOKEEPER-2319:
-
Summary: UnresolvedAddressException cause the
QuorumCnxManager.Listener exit
Key: ZOOKEEPER-2319
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2319
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.4.6
Reporter: Zhaohui Yu
Priority: Critical
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I don't think place the receiveConnection call in the try is a good idea.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2319) UnresolvedAddressException cause the QuorumCnxManager.Listener exit
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhaohui Yu updated ZOOKEEPER-2319:
--
Description:
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I don't think place the receiveConnection call in the try is a good idea. And I
think we should catch UnresolvedAddressException to avoid the Listener exit.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
was:
Given three nodes, the leader on 2, but some issue with this machine, so I
shutdown this machine, and change the host name to another machine.
Then I start the node in the new machine, but the new node can not join.
I found the the 1 and 3's Listener thread exit.
With the code of Listener's run method:
I don't think place the receiveConnection call in the try is a good idea.
@Override
public void run() {
while((!shutdown) && (numRetries < 3)){
try {
// bind and accept
receiveConnection(client);
} catch (IOException e) {
}
}
//
}
> UnresolvedAddressException cause the QuorumCnxManager.Listener exit
> ---
>
> Key: ZOOKEEPER-2319
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2319
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Zhaohui Yu
>Priority: Critical
>
> Given three nodes, the leader on 2, but some issue with this machine, so I
> shutdown this machine, and change the host name to another machine.
> Then I start the node in the new machine, but the new node can not join.
> I found the the 1 and 3's Listener thread exit.
> With the code of Listener's run method:
> I don't think place the receiveConnection call in the try is a good idea. And
> I think we should catch UnresolvedAddressException to avoid the Listener exit.
> @Override
> public void run() {
>
> while((!shutdown) && (numRetries < 3)){
> try {
>// bind and accept
> receiveConnection(client);
>
> } catch (IOException e) {
>
> }
> }
> //
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
