[jira] [Commented] (ZOOKEEPER-4253) I connected to ZooKeeper at different times, but I got the same session ID
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303140#comment-17303140
]
Damon Liu commented on ZOOKEEPER-4253:
--
[~ctubbsii] sorry,When I create problems several times, the browser prompts
that I failed, causing me to create problems repeatedly.
I will pay attention next time.
> I connected to ZooKeeper at different times, but I got the same session ID
> --
>
> Key: ZOOKEEPER-4253
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4253
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.13
>Reporter: Damon Liu
>Priority: Major
> Attachments: AA.log, BB.log, zookeeper.log
>
>
> App AA connects to ZooKeeper and creates a temporary path such as
> /brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA
> BB and ZooKeeper are restarted, and BB allocates AA's old session
> before restart:
> AA connect to zookeeper ,and log in zk:
> [2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 8000 for
> client /{color:#ff}22.20.0.45{color}:59966
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> after restart:
> BB connect to zookeeper ,and log in zk:
> [2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 3 for
> client /{color:#ff}22.20.0.47{color}:39360
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> I understand that after a restart, ZooKeeper loads old transaction logs and
> snapshot files, and old sessions and temporary paths are loaded. If BB
> obtains the old session 0x1053ef9 at this point, the session will not
> expire and the temporary path will not be deleted, causing AA to be unable to
> re-register the temporary path
> This is my question. I look forward to your help. Thank you very much!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4257) learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg
Mohammad Arshad created ZOOKEEPER-4257: -- Summary: learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg Key: ZOOKEEPER-4257 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4257 Project: ZooKeeper Issue Type: Sub-task Reporter: Mohammad Arshad Fix For: 3.7.0, 3.8.0 Configurations learner.asyncSending and learner.closeSocketAsync introduced in ZOOKEEPER-3575 and ZOOKEEPER-3574 are java system property only, which means can not be configured through ZooKeeper configuration file zoo.cfg As these JIRA changes are not released yet it is better to correct it and make it configurable through zoo.cfg. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4257) learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303128#comment-17303128 ] Mohammad Arshad commented on ZOOKEEPER-4257: is anybody interested in submitting the fix? > learner.asyncSending and learner.closeSocketAsync should be configurable in > zoo.cfg > --- > > Key: ZOOKEEPER-4257 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4257 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Mohammad Arshad >Priority: Minor > Fix For: 3.7.0, 3.8.0 > > > Configurations learner.asyncSending and learner.closeSocketAsync introduced > in ZOOKEEPER-3575 and ZOOKEEPER-3574 are java system property only, which > means can not be configured > through ZooKeeper configuration file zoo.cfg > As these JIRA changes are not released yet it is better to correct it and > make it configurable through zoo.cfg. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4253) I connected to ZooKeeper at different times, but I got the same session ID
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damon Liu updated ZOOKEEPER-4253:
-
Description:
App AA connects to ZooKeeper and creates a temporary path such as
/brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA BB
and ZooKeeper are restarted, and BB allocates AA's old session
before restart:
AA connect to zookeeper ,and log in zk:
[2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
{color:#ff}0x1053ef9{color} with negotiated timeout 8000 for client
/{color:#ff}22.20.0.45{color}:59966
(org.apache.zookeeper.server.ZooKeeperServer)
after restart:
BB connect to zookeeper ,and log in zk:
[2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
{color:#ff}0x1053ef9{color} with negotiated timeout 3 for
client /{color:#ff}22.20.0.47{color}:39360
(org.apache.zookeeper.server.ZooKeeperServer)
I understand that after a restart, ZooKeeper loads old transaction logs and
snapshot files, and old sessions and temporary paths are loaded. If BB obtains
the old session 0x1053ef9 at this point, the session will not expire
and the temporary path will not be deleted, causing AA to be unable to
re-register the temporary path
This is my question. I look forward to your help. Thank you very much!
was:
I have an app AA connect to zookeeper and register a temporary path such as
/brokers/ids/10，and I have another app BB also connect to zookeeper. At some
point, AA BB and ZooKeeper both restarted
before restart:
AA connect log in zk : [2021-03-07 08:47:43,468] INFO [SyncThread:0]
Established session {color:#FF}0x1053ef9{color} with negotiated
timeout 8000 for client /{color:#FF}22.20.0.45{color}:59966
(org.apache.zookeeper.server.ZooKeeperServer)
after restart:
BB connect log in zk:[2021-03-07 08:58:51,351] INFO [SyncThread:0] Established
session {color:#FF}0x1053ef9{color} with negotiated timeout 3
for client /{color:#FF}22.20.0.47{color}:39360
(org.apache.zookeeper.server.ZooKeeperServer)
I understand that when ZooKeeper restarts, the transaction log and snapshot
files will be loaded, and the old
session({color:#FF}0x1053EF9{color}) and the temporary path will be
loaded,If App BB gets the old session {color:#FF}0x1053EF9{color},
the session will not expire, the temporary path（/brokers/ids/10） will not be
deleted, and App AA will not be able to re-register the temporary
path(/brokers/ids/10)。
That's my question，looking forward to your help. Thank you.
> I connected to ZooKeeper at different times, but I got the same session ID
> --
>
> Key: ZOOKEEPER-4253
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4253
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.13
>Reporter: Damon Liu
>Priority: Major
> Attachments: AA.log, BB.log, zookeeper.log
>
>
> App AA connects to ZooKeeper and creates a temporary path such as
> /brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA
> BB and ZooKeeper are restarted, and BB allocates AA's old session
> before restart:
> AA connect to zookeeper ,and log in zk:
> [2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 8000 for
> client /{color:#ff}22.20.0.45{color}:59966
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> after restart:
> BB connect to zookeeper ,and log in zk:
> [2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 3 for
> client /{color:#ff}22.20.0.47{color}:39360
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> I understand that after a restart, ZooKeeper loads old transaction logs and
> snapshot files, and old sessions and temporary paths are loaded. If BB
> obtains the old session 0x1053ef9 at this point, the session will not
> expire and the temporary path will not be deleted, causing AA to be unable to
> re-register the temporary path
> This is my question. I look forward to your help. Thank you very much!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4253) I connected to ZooKeeper at different times, but I got the same session ID
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damon Liu updated ZOOKEEPER-4253:
-
Attachment: BB.log
AA.log
> I connected to ZooKeeper at different times, but I got the same session ID
> --
>
> Key: ZOOKEEPER-4253
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4253
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.13
>Reporter: Damon Liu
>Priority: Major
> Attachments: AA.log, BB.log, zookeeper.log
>
>
> App AA connects to ZooKeeper and creates a temporary path such as
> /brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA
> BB and ZooKeeper are restarted, and BB allocates AA's old session
> before restart:
> AA connect to zookeeper ,and log in zk:
> [2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 8000 for
> client /{color:#ff}22.20.0.45{color}:59966
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> after restart:
> BB connect to zookeeper ,and log in zk:
> [2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 3 for
> client /{color:#ff}22.20.0.47{color}:39360
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> I understand that after a restart, ZooKeeper loads old transaction logs and
> snapshot files, and old sessions and temporary paths are loaded. If BB
> obtains the old session 0x1053ef9 at this point, the session will not
> expire and the temporary path will not be deleted, causing AA to be unable to
> re-register the temporary path
> This is my question. I look forward to your help. Thank you very much!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4257) learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303131#comment-17303131 ] Ayush Mantri commented on ZOOKEEPER-4257: - i'll raise PR asap > learner.asyncSending and learner.closeSocketAsync should be configurable in > zoo.cfg > --- > > Key: ZOOKEEPER-4257 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4257 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Mohammad Arshad >Priority: Minor > Fix For: 3.7.0, 3.8.0 > > > Configurations learner.asyncSending and learner.closeSocketAsync introduced > in ZOOKEEPER-3575 and ZOOKEEPER-3574 are java system property only, which > means can not be configured > through ZooKeeper configuration file zoo.cfg > As these JIRA changes are not released yet it is better to correct it and > make it configurable through zoo.cfg. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-4205) Test fails when port 8080 is in use
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-4205. Fix Version/s: 3.6.3 3.7.0 3.8.0 Resolution: Fixed Issue resolved by pull request 1599 [https://github.com/apache/zookeeper/pull/1599] > Test fails when port 8080 is in use > --- > > Key: ZOOKEEPER-4205 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4205 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.8.0 >Reporter: Amichai Rothman >Priority: Major > Labels: pull-request-available > Fix For: 3.8.0, 3.7.0, 3.6.3 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Port 8080 is used by default on various web servers and applications. On any > system running such a server the ZooKeeper build fails because the port is in > use. It should use a dynamically assigned free port instead. > > java.lang.NullPointerException > at > org.apache.zookeeper.server.X509AuthFailureTest.testSecureStandaloneServerAuthNFailure(X509AuthFailureTest.java:81) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4253) I connected to ZooKeeper at different times, but I got the same session ID
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damon Liu updated ZOOKEEPER-4253:
-
Description:
App AA connects to ZooKeeper and creates a temporary path such as
/brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA BB
and ZooKeeper are restarted, and BB allocates AA's old session
before restart:
AA connect to zookeeper ,and log in zk:
[2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
{color:#ff}0x1053ef9{color} with negotiated timeout 8000 for client
/{color:#ff}22.20.0.45{color}:59966
(org.apache.zookeeper.server.ZooKeeperServer)
after restart:
BB connect to zookeeper ,and log in zk:
[2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
{color:#ff}0x1053ef9{color} with negotiated timeout 3 for
client /{color:#ff}22.20.0.47{color}:39360
(org.apache.zookeeper.server.ZooKeeperServer)
I understand that after a restart, ZooKeeper loads old transaction logs and
snapshot files, and old sessions and temporary paths are loaded. If BB obtains
the old session 0x1053ef9 at this point, the session will not expire
and the temporary path will not be deleted, causing AA to be unable to
re-register the temporary path
This is my question. I look forward to your help. Thank you very much!
2021/03/17 14:44
I have checked the source code of zookeeper, and the generation of session is
as follows:
{code:java}
public static long initializeNextSession(long id) {
long nextSid = 0;
nextSid = (Time.currentElapsedTime() << 24) >>> 8;
nextSid = nextSid | (id <<56);
return nextSid;
}{code}
Id is a fixed value, and the only variable that affects session id is the
current time. Obviously zookeeper it takes different time to create session
twice, but why get the same session id?
was:
App AA connects to ZooKeeper and creates a temporary path such as
/brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA BB
and ZooKeeper are restarted, and BB allocates AA's old session
before restart:
AA connect to zookeeper ,and log in zk:
[2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
{color:#ff}0x1053ef9{color} with negotiated timeout 8000 for client
/{color:#ff}22.20.0.45{color}:59966
(org.apache.zookeeper.server.ZooKeeperServer)
after restart:
BB connect to zookeeper ,and log in zk:
[2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
{color:#ff}0x1053ef9{color} with negotiated timeout 3 for
client /{color:#ff}22.20.0.47{color}:39360
(org.apache.zookeeper.server.ZooKeeperServer)
I understand that after a restart, ZooKeeper loads old transaction logs and
snapshot files, and old sessions and temporary paths are loaded. If BB obtains
the old session 0x1053ef9 at this point, the session will not expire
and the temporary path will not be deleted, causing AA to be unable to
re-register the temporary path
This is my question. I look forward to your help. Thank you very much!
> I connected to ZooKeeper at different times, but I got the same session ID
> --
>
> Key: ZOOKEEPER-4253
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4253
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.13
>Reporter: Damon Liu
>Priority: Major
> Attachments: AA.log, BB.log, zookeeper.log
>
>
> App AA connects to ZooKeeper and creates a temporary path such as
> /brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA
> BB and ZooKeeper are restarted, and BB allocates AA's old session
> before restart:
> AA connect to zookeeper ,and log in zk:
> [2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 8000 for
> client /{color:#ff}22.20.0.45{color}:59966
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> after restart:
> BB connect to zookeeper ,and log in zk:
> [2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 3 for
> client /{color:#ff}22.20.0.47{color}:39360
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> I understand that after a restart, ZooKeeper loads old transaction logs and
> snapshot files, and old sessions and temporary paths are loaded. If BB
> obtains the old session 0x1053ef9 at this point, the session will not
> expire and the temporary path will not be deleted, causing AA to be unable to
> re-register the temporary path
> This is my question. I look forward to your help. Thank you very much!
>
> 2021/03/17 14:44
> I have checked the source code of zookeeper,
[jira] [Resolved] (ZOOKEEPER-4231) Add document for snapshot compression config
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen resolved ZOOKEEPER-4231. Fix Version/s: 3.7.0 Resolution: Fixed Issue resolved by pull request 1642 [https://github.com/apache/zookeeper/pull/1642] > Add document for snapshot compression config > > > Key: ZOOKEEPER-4231 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4231 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Huizhi Lu >Assignee: Huizhi Lu >Priority: Minor > Labels: pull-request-available > Fix For: 3.7.0 > > Original Estimate: 24h > Time Spent: 40m > Remaining Estimate: 23h 20m > > Snapshot compression method was added in zookeeper, but there is no clear > documentation about the config. This ticket is created to add documentation > for the config: > *zookeeper.snapshot.compression.method* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4253) The client connects to zookeeper twice and get the same session id
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damon Liu updated ZOOKEEPER-4253:
-
Summary: The client connects to zookeeper twice and get the same session id
(was: I connected to ZooKeeper at different times, but I got the same session
ID)
> The client connects to zookeeper twice and get the same session id
> --
>
> Key: ZOOKEEPER-4253
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4253
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.13
>Reporter: Damon Liu
>Priority: Major
> Attachments: AA.log, BB.log, zookeeper.log
>
>
> App AA connects to ZooKeeper and creates a temporary path such as
> /brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA
> BB and ZooKeeper are restarted, and BB allocates AA's old session
> before restart:
> AA connect to zookeeper ,and log in zk:
> [2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 8000 for
> client /{color:#ff}22.20.0.45{color}:59966
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> after restart:
> BB connect to zookeeper ,and log in zk:
> [2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 3 for
> client /{color:#ff}22.20.0.47{color}:39360
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> I understand that after a restart, ZooKeeper loads old transaction logs and
> snapshot files, and old sessions and temporary paths are loaded. If BB
> obtains the old session 0x1053ef9 at this point, the session will not
> expire and the temporary path will not be deleted, causing AA to be unable to
> re-register the temporary path
> This is my question. I look forward to your help. Thank you very much!
>
> 2021/03/17 14:44
> I have checked the source code of zookeeper, and the generation of session is
> as follows:
> {code:java}
> public static long initializeNextSession(long id) {
> long nextSid = 0;
> nextSid = (Time.currentElapsedTime() << 24) >>> 8;
> nextSid = nextSid | (id <<56);
> return nextSid;
> }{code}
> Id is a fixed value, and the only variable that affects session id is the
> current time. Obviously zookeeper it takes different time to create session
> twice, but why get the same session id?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4257) learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-4257: -- Labels: pull-request-available (was: ) > learner.asyncSending and learner.closeSocketAsync should be configurable in > zoo.cfg > --- > > Key: ZOOKEEPER-4257 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4257 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Mohammad Arshad >Priority: Minor > Labels: pull-request-available > Fix For: 3.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Configurations learner.asyncSending and learner.closeSocketAsync introduced > in ZOOKEEPER-3575 and ZOOKEEPER-3574 are java system property only, which > means can not be configured > through ZooKeeper configuration file zoo.cfg > As these JIRA changes are not released yet it is better to correct it and > make it configurable through zoo.cfg. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3706) ZooKeeper.close() would leak SendThread when the network is broken
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3706: --- Fix Version/s: (was: 3.7.0) > ZooKeeper.close() would leak SendThread when the network is broken > -- > > Key: ZOOKEEPER-3706 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3706 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.6.0, 3.4.14, 3.5.6 >Reporter: Pierre Yin >Assignee: Pierre Yin >Priority: Major > Labels: pull-request-available > Fix For: 3.8.0 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > The close method of ZooKeeper may cause the leak of SendThread when the > network is broken. > When the network is broken, the SendThread of ZooKeeper client falls into the > continuous reconnecting scenario. But there is an unsafe point which is just > at the moment before startConnect() during the continuous reconnecting. If > SendThread.close() in another thread hit the unsafe point, startConnect() > would sleep some time and force to change state to States.CONNECTING although > SendThread.close() already set state to States.CLOSED. In this case, the > SendThread would be never be dead and nobody would change the state again. > In normal case, ZooKeeper.close() would be blocked forever to wait > closeSession packet is finished until the network broken is recovered. But if > user set the request timeout, ZooKeeper.close() would break the block waiting > within timeout and invoke SendThread.close() to change state to CLOSED. > That's why SendThread.close() can hit the unsafe point. > Set request timeout is a very common practice. > I propose a patch and send it out later. > Maybe someone can help to review it. > > Thanks > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4241) Change log level without restarting zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-4241: --- Fix Version/s: (was: 3.7.0) > Change log level without restarting zookeeper > - > > Key: ZOOKEEPER-4241 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4241 > Project: ZooKeeper > Issue Type: Wish > Components: server >Affects Versions: 3.6.2 > Environment: Kubernetes >Reporter: Pratik Thacker >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > In our usecase of zookeeper, we want to change log level of zookeeper without > restarting it. > This will help us to trace issues without restarting zookeeper as some of the > issues may not appear immediately after restart with debug log level enabled, > and it may take longer to reproduce the issue after restart. > Does such feature/API is already available in Apache Zookeeper? > If it is not available then could you please consider this request to > implement it? > Please let us know if you need any further details from us. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4257) learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-4257: --- Fix Version/s: (was: 3.7.0) > learner.asyncSending and learner.closeSocketAsync should be configurable in > zoo.cfg > --- > > Key: ZOOKEEPER-4257 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4257 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Mohammad Arshad >Priority: Minor > Fix For: 3.8.0 > > > Configurations learner.asyncSending and learner.closeSocketAsync introduced > in ZOOKEEPER-3575 and ZOOKEEPER-3574 are java system property only, which > means can not be configured > through ZooKeeper configuration file zoo.cfg > As these JIRA changes are not released yet it is better to correct it and > make it configurable through zoo.cfg. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4241) Change log level without restarting zookeeper
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303217#comment-17303217
]
Damien Diederen commented on ZOOKEEPER-4241:
[~arshad.mohammad]: Removed the 3.7.0 tag as it hasn't been merged into
{{branch-3.7.0}} as of now, and shouldn't appear in the release notes before it
is.
> Change log level without restarting zookeeper
> -
>
> Key: ZOOKEEPER-4241
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4241
> Project: ZooKeeper
> Issue Type: Wish
> Components: server
>Affects Versions: 3.6.2
> Environment: Kubernetes
>Reporter: Pratik Thacker
>Assignee: Mohammad Arshad
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.3, 3.8.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In our usecase of zookeeper, we want to change log level of zookeeper without
> restarting it.
> This will help us to trace issues without restarting zookeeper as some of the
> issues may not appear immediately after restart with debug log level enabled,
> and it may take longer to reproduce the issue after restart.
> Does such feature/API is already available in Apache Zookeeper?
> If it is not available then could you please consider this request to
> implement it?
> Please let us know if you need any further details from us.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4257) learner.asyncSending and learner.closeSocketAsync should be configurable in zoo.cfg
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303219#comment-17303219
]
Damien Diederen commented on ZOOKEEPER-4257:
Removed the 3.7.0 tag as no resolution has been merged into {{branch-3.7.0}} as
of now, and the ticket shouldn't appear in the release notes before then.
> learner.asyncSending and learner.closeSocketAsync should be configurable in
> zoo.cfg
> ---
>
> Key: ZOOKEEPER-4257
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4257
> Project: ZooKeeper
> Issue Type: Sub-task
>Reporter: Mohammad Arshad
>Priority: Minor
> Fix For: 3.8.0
>
>
> Configurations learner.asyncSending and learner.closeSocketAsync introduced
> in ZOOKEEPER-3575 and ZOOKEEPER-3574 are java system property only, which
> means can not be configured
> through ZooKeeper configuration file zoo.cfg
> As these JIRA changes are not released yet it is better to correct it and
> make it configurable through zoo.cfg.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4211) Expose Quota Metrics to Prometheus
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303530#comment-17303530 ] Li Wang commented on ZOOKEEPER-4211: PR submitted and all the checks passed. Can someone help reviewing it? We would like to get this into 3.7 release to leverage the quota enforcement feature. Thanks. > Expose Quota Metrics to Prometheus > -- > > Key: ZOOKEEPER-4211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4211 > Project: ZooKeeper > Issue Type: New Feature > Components: metric system >Affects Versions: 3.7.0, 3.7 >Reporter: Li Wang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > In 3.7, Quota limit can be enforced and the quota related stats are captured > in the StatsTrack. From the "listquota" CLI command, we can the quota limit > and usage info. > As an addition to that, we would like to collect the quota metrics and expose > them to the Prometheus for the following: > 1. Monitoring per namespace (Chroot) quota usage via the Grafana dashboard > 2. Creating alert based on the quota levels (e.g. 90% used) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4253) The client connects to zookeeper twice and get the same session id
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damon Liu updated ZOOKEEPER-4253:
-
Component/s: (was: java client)
> The client connects to zookeeper twice and get the same session id
> --
>
> Key: ZOOKEEPER-4253
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4253
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.13
>Reporter: Damon Liu
>Priority: Major
> Attachments: AA.log, BB.log, zookeeper.log
>
>
> App AA connects to ZooKeeper and creates a temporary path such as
> /brokers/ids/10. Another APP BB also connects to ZooKeeper. At some point AA
> BB and ZooKeeper are restarted, and BB allocates AA's old session
> before restart:
> AA connect to zookeeper ,and log in zk:
> [2021-03-07 08:47:43,468] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 8000 for
> client /{color:#ff}22.20.0.45{color}:59966
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> after restart:
> BB connect to zookeeper ,and log in zk:
> [2021-03-07 08:58:51,351] INFO [SyncThread:0] Established session
> {color:#ff}0x1053ef9{color} with negotiated timeout 3 for
> client /{color:#ff}22.20.0.47{color}:39360
> (org.apache.zookeeper.server.ZooKeeperServer)
>
> I understand that after a restart, ZooKeeper loads old transaction logs and
> snapshot files, and old sessions and temporary paths are loaded. If BB
> obtains the old session 0x1053ef9 at this point, the session will not
> expire and the temporary path will not be deleted, causing AA to be unable to
> re-register the temporary path
> This is my question. I look forward to your help. Thank you very much!
>
> 2021/03/17 14:44
> I have checked the source code of zookeeper, and the generation of session is
> as follows:
> {code:java}
> public static long initializeNextSession(long id) {
> long nextSid = 0;
> nextSid = (Time.currentElapsedTime() << 24) >>> 8;
> nextSid = nextSid | (id <<56);
> return nextSid;
> }{code}
> Id is a fixed value, and the only variable that affects session id is the
> current time. Obviously zookeeper it takes different time to create session
> twice, but why get the same session id?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
