[jira] [Created] (ZOOKEEPER-3536) On Windows maven build generates corrupted tarball
Mohammad Arshad created ZOOKEEPER-3536:
--
Summary: On Windows maven build generates corrupted tarball
Key: ZOOKEEPER-3536
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3536
Project: ZooKeeper
Issue Type: Bug
Components: build
Affects Versions: 3.5.5
Reporter: Mohammad Arshad
On windows maven command {code}mvn clean install -DskipTests{code} creates
corrupted tarballs.
In zookeeper-assembly/pom.xml posix causing
the problem. Many use Windows as development environment. it would be better
if we can make tarLongFileMode property configurable or select based on OS.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (ZOOKEEPER-2354) ZOOKEEPER-1653 not merged in master and 3.5 branch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927528#comment-16927528 ] Mohammad Arshad commented on ZOOKEEPER-2354: [~tuk], can you raise PR, I will merge it. > ZOOKEEPER-1653 not merged in master and 3.5 branch > -- > > Key: ZOOKEEPER-2354 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2354 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.6.0, 3.5.7 > > Attachments: ZOOKEEPER-2354-01.patch > > > ZOOKEEPER-1653 is merged only to 3.4 branch. > It should be merged to 3.5 and master branch as well. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ZOOKEEPER-3496) Transaction larger than jute.maxbuffer makes ZooKeeper unavailable
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923151#comment-16923151
]
Mohammad Arshad commented on ZOOKEEPER-3496:
PR Created
> Transaction larger than jute.maxbuffer makes ZooKeeper unavailable
> --
>
> Key: ZOOKEEPER-3496
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3496
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.5, 3.4.14
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.6.0, 3.4.15, 3.5.6
>
> Attachments: ZOOKEEPER-3496-001.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Problem:*
> ZooKeeper server fails to start, logs following error
> {code:java}
> Exception in thread "main" java.io.IOException: Unreasonable length = 1001025
> at
> org.apache.jute.BinaryInputArchive.checkLength(BinaryInputArchive.java:127)
> at
> org.apache.jute.BinaryInputArchive.readBuffer(BinaryInputArchive.java:92)
> {code}
> This indicates that one of the transactions size is more than the configured
> jute.maxbuffer values. But how transaction more than jute.maxbuffer size is
> allowed to write?
> *Analysis:*
> At ZooKeeper server jute.maxbuffer specifies the maximum size of a
> transaction. By default it is 1 MB at the server
> jute.maxbuffer is used for following:
> # Size sanity check of incoming request. Incoming requests size must not be
> more than jute.maxbuffer
> # Size sanity check of the transaction while reading from transaction or
> snapshot file. Transaction size must not be more than jute.maxbuffer+1024
> # Size sanity check of transaction while reading data from the leader.
> Transaction size must not be more than jute.maxbuffer+1024
> Request size sanity check is done in the beginning of a request processing
> but later request processing adds additional information into request then
> writes to transaction file. This additional information size is not
> considered in sanity check. This is how transaction larger than
> jute.maxbuffer are accepted into ZooKeeper.
> If this additional information size is less than 1024 Bytes then it is OK as
> ZooKeeper already takes care of it.
> But if this additional information size is more than 1024 bytes it allows the
> request, But while reading from transaction/snapshot file and while reading
> from leader it fails and make the ZooKeeper service unavailable
> +Example:+
> Suppose incoming request size is 100 Bytes
> Configured jute.maxbuffer is 100
> After processing the request ZooKeeper server adds 1025 more bytes
> In this case, request will be processed successfully, and 100+1025 bytes
> will be written to transaction file
> But while reading from the transaction log 100+1025 bytes cannot be read
> as max allowed length is 100(effectively 100+1024).
> *Solutions:*
> If incoming request size sanity check is done after populating all additional
> information then this problem is solved. But doing sanity check in the later
> stage of request processing will defeat the purpose of sanity check itself.
> So this we can not do
> Currently additional information size is constant 1024 Bytes [Code
> Reference|https://github.com/apache/zookeeper/blob/branch-3.5/zookeeper-jute/src/main/java/org/apache/jute/BinaryInputArchive.java#L126].
> We should increase this value and make it more reasonable. I propose to make
> this additional information size to same as the jute.maxbuffer. Also make
> additional information size configurable.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (ZOOKEEPER-2985) Expired session may unexpired after leader failover
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893770#comment-16893770
]
Mohammad Arshad commented on ZOOKEEPER-2985:
{quote}
If it's helpful I have code to reproduce this on an in-process cluster running
3.4.11 or 3.5.3-beta.
{quote}
[~cthunes], Test code surely be helpful in understanding this issue. Please
share the test code, if you already have, which can reproduce this issue.
> Expired session may unexpired after leader failover
> ---
>
> Key: ZOOKEEPER-2985
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2985
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.3, 3.4.11
>Reporter: Chris Thunes
>Priority: Major
>
> We recently observed an inconsistency in our Kafka cluster which we tracked
> down to ZooKeeper sessions expiring and then re-appearing after a ZooKeeper
> leadership failover. The Kafka nodes received session "Expired" events,
> leading to them starting new sessions and attempting to re-create some
> ephemeral nodes (broker ID nodes in kafka/brokers/ids specifically). However,
> between receiving the session Expired event and establishing a new session a
> leadership failover occurred within the ZooKeeper cluster which resulted in
> the expired session re-appearing. When Kafka attempted to re-create the
> ephemeral nodes mentioned above it (unexpectedly) received NODEEXISTS errors.
> This behavior is a result of how session expiration is handled by the leader.
> Specifically, the expired session is marked as "closing" immediately upon
> expiration (in SessionTrackerImpl) and _before_ the corresponding
> "closeSession" entry is committed. A client can therefore receive a session
> Expired event before its session is fully closed. A leadership failover which
> results in the loss of the (uncommitted) closeSession entry thus leads to the
> sessions' ephemeral nodes "re-appearing" until another expiration of the old
> session on the new leader takes place.
> I'm not certain if this should be considered a bug or an edge case that
> client are expected to handle. If it is the latter then I think it would be
> good to include this in the Programmer's Guide in the documentation.
> If it's helpful I have code to reproduce this on an in-process cluster
> running 3.4.11 or 3.5.3-beta.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (ZOOKEEPER-3536) On Windows maven build generates corrupted tarball
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-3536.
Resolution: Invalid
It is not an issue
> On Windows maven build generates corrupted tarball
> --
>
> Key: ZOOKEEPER-3536
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3536
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.5
>Reporter: Mohammad Arshad
>Priority: Minor
>
> On windows maven command {code}mvn clean install -DskipTests{code} creates
> corrupted tarballs.
> In zookeeper-assembly/pom.xml posix
> causing the problem. Many use Windows as development environment. it would
> be better if we can make tarLongFileMode property configurable or select
> based on OS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3496) Transaction larger than jute.maxbuffer makes ZooKeeper unavailable
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938371#comment-16938371
]
Mohammad Arshad commented on ZOOKEEPER-3496:
[~hanm] had committed to branch-3.5. This issue is committed to branch-3.5 and
master
> Transaction larger than jute.maxbuffer makes ZooKeeper unavailable
> --
>
> Key: ZOOKEEPER-3496
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3496
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.5, 3.4.14
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-3496-001.patch
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> *Problem:*
> ZooKeeper server fails to start, logs following error
> {code:java}
> Exception in thread "main" java.io.IOException: Unreasonable length = 1001025
> at
> org.apache.jute.BinaryInputArchive.checkLength(BinaryInputArchive.java:127)
> at
> org.apache.jute.BinaryInputArchive.readBuffer(BinaryInputArchive.java:92)
> {code}
> This indicates that one of the transactions size is more than the configured
> jute.maxbuffer values. But how transaction more than jute.maxbuffer size is
> allowed to write?
> *Analysis:*
> At ZooKeeper server jute.maxbuffer specifies the maximum size of a
> transaction. By default it is 1 MB at the server
> jute.maxbuffer is used for following:
> # Size sanity check of incoming request. Incoming requests size must not be
> more than jute.maxbuffer
> # Size sanity check of the transaction while reading from transaction or
> snapshot file. Transaction size must not be more than jute.maxbuffer+1024
> # Size sanity check of transaction while reading data from the leader.
> Transaction size must not be more than jute.maxbuffer+1024
> Request size sanity check is done in the beginning of a request processing
> but later request processing adds additional information into request then
> writes to transaction file. This additional information size is not
> considered in sanity check. This is how transaction larger than
> jute.maxbuffer are accepted into ZooKeeper.
> If this additional information size is less than 1024 Bytes then it is OK as
> ZooKeeper already takes care of it.
> But if this additional information size is more than 1024 bytes it allows the
> request, But while reading from transaction/snapshot file and while reading
> from leader it fails and make the ZooKeeper service unavailable
> +Example:+
> Suppose incoming request size is 100 Bytes
> Configured jute.maxbuffer is 100
> After processing the request ZooKeeper server adds 1025 more bytes
> In this case, request will be processed successfully, and 100+1025 bytes
> will be written to transaction file
> But while reading from the transaction log 100+1025 bytes cannot be read
> as max allowed length is 100(effectively 100+1024).
> *Solutions:*
> If incoming request size sanity check is done after populating all additional
> information then this problem is solved. But doing sanity check in the later
> stage of request processing will defeat the purpose of sanity check itself.
> So this we can not do
> Currently additional information size is constant 1024 Bytes [Code
> Reference|https://github.com/apache/zookeeper/blob/branch-3.5/zookeeper-jute/src/main/java/org/apache/jute/BinaryInputArchive.java#L126].
> We should increase this value and make it more reasonable. I propose to make
> this additional information size to same as the jute.maxbuffer. Also make
> additional information size configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3496) Transaction larger than jute.maxbuffer makes ZooKeeper unavailable
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938373#comment-16938373
]
Mohammad Arshad commented on ZOOKEEPER-3496:
Thanks [~eolivelli], [~hanm], [~lvfangmin] for the reviews.
> Transaction larger than jute.maxbuffer makes ZooKeeper unavailable
> --
>
> Key: ZOOKEEPER-3496
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3496
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.5, 3.4.14
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-3496-001.patch
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> *Problem:*
> ZooKeeper server fails to start, logs following error
> {code:java}
> Exception in thread "main" java.io.IOException: Unreasonable length = 1001025
> at
> org.apache.jute.BinaryInputArchive.checkLength(BinaryInputArchive.java:127)
> at
> org.apache.jute.BinaryInputArchive.readBuffer(BinaryInputArchive.java:92)
> {code}
> This indicates that one of the transactions size is more than the configured
> jute.maxbuffer values. But how transaction more than jute.maxbuffer size is
> allowed to write?
> *Analysis:*
> At ZooKeeper server jute.maxbuffer specifies the maximum size of a
> transaction. By default it is 1 MB at the server
> jute.maxbuffer is used for following:
> # Size sanity check of incoming request. Incoming requests size must not be
> more than jute.maxbuffer
> # Size sanity check of the transaction while reading from transaction or
> snapshot file. Transaction size must not be more than jute.maxbuffer+1024
> # Size sanity check of transaction while reading data from the leader.
> Transaction size must not be more than jute.maxbuffer+1024
> Request size sanity check is done in the beginning of a request processing
> but later request processing adds additional information into request then
> writes to transaction file. This additional information size is not
> considered in sanity check. This is how transaction larger than
> jute.maxbuffer are accepted into ZooKeeper.
> If this additional information size is less than 1024 Bytes then it is OK as
> ZooKeeper already takes care of it.
> But if this additional information size is more than 1024 bytes it allows the
> request, But while reading from transaction/snapshot file and while reading
> from leader it fails and make the ZooKeeper service unavailable
> +Example:+
> Suppose incoming request size is 100 Bytes
> Configured jute.maxbuffer is 100
> After processing the request ZooKeeper server adds 1025 more bytes
> In this case, request will be processed successfully, and 100+1025 bytes
> will be written to transaction file
> But while reading from the transaction log 100+1025 bytes cannot be read
> as max allowed length is 100(effectively 100+1024).
> *Solutions:*
> If incoming request size sanity check is done after populating all additional
> information then this problem is solved. But doing sanity check in the later
> stage of request processing will defeat the purpose of sanity check itself.
> So this we can not do
> Currently additional information size is constant 1024 Bytes [Code
> Reference|https://github.com/apache/zookeeper/blob/branch-3.5/zookeeper-jute/src/main/java/org/apache/jute/BinaryInputArchive.java#L126].
> We should increase this value and make it more reasonable. I propose to make
> this additional information size to same as the jute.maxbuffer. Also make
> additional information size configurable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-2238) Support limiting the maximum number of connections/clients to a zookeeper server.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-2238: -- Assignee: (was: Mohammad Arshad) > Support limiting the maximum number of connections/clients to a zookeeper > server. > - > > Key: ZOOKEEPER-2238 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2238 > Project: ZooKeeper > Issue Type: Improvement >Reporter: nijel >Priority: Major > Labels: pull-request-available > Attachments: ZOOKEEPER-2238-05.patch, ZOOKEEPER-2238-06.patch, > ZOOKEEPER-2238-07.patch, ZOOKEEPER-2238.2.patch, ZOOKEEPER-2238.3.patch, > ZOOKEEPER-2238.4.patch, ZOOKEEPER-2238.diff > > Time Spent: 10m > Remaining Estimate: 0h > > Currently zookeeper have the feature of limiting the maximum number of > connection/client per IP or Host (maxClientCnxns). > But to safe guard zookeeper server from DoS attack due to many clients from > different IPs, it is better to have a limit of total number of > connections/clients to a a single member of the ZooKeeper ensemble as well. > So the idea is to introduce a new configuration to limit the maximum number > of total connections/clients. > Please share your thoughts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Make server principal configurable at client side.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941606#comment-16941606
]
Mohammad Arshad commented on ZOOKEEPER-1467:
[~beeflyme] if you disagree with [~sujithsimon22], please create new jira we
can discuss there whether we can fetch server principal from server itself.
> Make server principal configurable at client side.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-1467) Make server principal configurable at client side.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-1467.
Tags: (was: Huawei)
Resolution: Fixed
> Make server principal configurable at client side.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Make server principal configurable at client side.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941611#comment-16941611
]
Mohammad Arshad commented on ZOOKEEPER-1467:
Thank [~sujithsimon22] for the contribution.
Thanks [~eolivelli], [~enixon] for the reviews.
> Make server principal configurable at client side.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938686#comment-16938686 ] Mohammad Arshad commented on ZOOKEEPER-3558: Thanks for the information [~hanm] Two concerns with ZOOKEEPER-1634. 1. It is merged only in master. 2. It is limited to only sasl authentication scheme. It can not support any other scheme Shall we back port ZOOKEEPER-1634 to branch-3.5 also do changed to make it work for any authentication scheme. > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.7 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938707#comment-16938707
]
Mohammad Arshad commented on ZOOKEEPER-1467:
[~rajeshhadoop] how to configure principal
zookeeper/hadoop.hadoop@hadoop.com without adding new configuration
provided hadoo.hadoo.com can not be configured as host ?
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939576#comment-16939576 ] Mohammad Arshad commented on ZOOKEEPER-3561: 1. In ZOOKEEPER-1634 all properties names are in context of SASL. Now the context is broad and 3.6.0 is not released yet so i think we can change the property names. Giving new name to properties. enforce.auth.enabled and enforce.auth.scheme 2. There is no need to do special handling for allowSaslFailedClients scenario. When enforce authentication is enabled allowSaslFailedClients is implied to be false. So we can take this as false in case enforce.auth.enabled=true Moreover allowSaslFailedClients seems to be a testing property. It makes no sense to enable enforce authentication and allow failed SASL authentication. If someone wants to allow failed authentication he will not enable enforce authentication and vice versa. 3. I think it may not be required to introduce new response code SESSIONCLOSEDREQUIRESASLAUTH. Exploring bit more if we can use AUTHFAILED > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939123#comment-16939123
]
Mohammad Arshad commented on ZOOKEEPER-1467:
All other bigdata components like hdfs. yarn. hbase etc have exposed server
principals through configuration which clients configure to connect to servers.
I think we should add zookeeper.server.principal configuration.
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939124#comment-16939124
]
Mohammad Arshad commented on ZOOKEEPER-1467:
is anybody interested in raising PR?
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-1467) Make server principal configurable at client side.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-1467:
---
Summary: Make server principal configurable at client side. (was: Server
principal on client side is derived using hostname.)
> Make server principal configurable at client side.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-1467) Make server principal configurable at client side.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-1467:
---
Fix Version/s: 3.5.7
> Make server principal configurable at client side.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939326#comment-16939326 ] Mohammad Arshad commented on ZOOKEEPER-3558: I will work on ZOOKEEPER-3561 . After ZOOKEEPER-3561 is committed will raise PR to backport to branch-3.5 > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.7 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-3561: -- Assignee: Mohammad Arshad > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=16975089#comment-16975089
]
Mohammad Arshad commented on ZOOKEEPER-2307:
Raised PR.
> 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: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-2307-01.patch, ZOOKEEPER-2307-02.patch,
> ZOOKEEPER-2307-03.patch, ZOOKEEPER-2307-04.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3584) "NoAuth" error message is ambiguous
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953587#comment-16953587 ] Mohammad Arshad commented on ZOOKEEPER-3584: org.apache.zookeeper.KeeperException.Code#NOAUTH/org.apache.zookeeper.KeeperException.NoAuthException means no authorization. This code/exception is returned when ACL check fails. > "NoAuth" error message is ambiguous > --- > > Key: ZOOKEEPER-3584 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3584 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.5.6 >Reporter: Lars Francke >Assignee: Lars Francke >Priority: Trivial > Attachments: ZOOKEEPER-3584.1.patch > > > Currently we get a NoAuthException printed as "NoAuth" > > Unfortunately "Auth" could mean "Authentication" or "Authorization" so I > propose to change the error message to "Not authenticated" > I won't change the NoAuthException class name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3584) "NoAuth" error message is ambiguous
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953608#comment-16953608 ] Mohammad Arshad commented on ZOOKEEPER-3584: Authorization > "NoAuth" error message is ambiguous > --- > > Key: ZOOKEEPER-3584 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3584 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.5.6 >Reporter: Lars Francke >Assignee: Lars Francke >Priority: Trivial > Attachments: ZOOKEEPER-3584.1.patch > > > Currently we get a NoAuthException printed as "NoAuth" > > Unfortunately "Auth" could mean "Authentication" or "Authorization" so I > propose to change the error message to "Not authenticated" > I won't change the NoAuthException class name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3584) "NoAuth" error message is ambiguous
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953612#comment-16953612 ] Mohammad Arshad commented on ZOOKEEPER-3584: https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/KeeperException.java#L373-L374 This code comment also should be corrected. > "NoAuth" error message is ambiguous > --- > > Key: ZOOKEEPER-3584 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3584 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.5.6 >Reporter: Lars Francke >Assignee: Lars Francke >Priority: Trivial > Attachments: ZOOKEEPER-3584.1.patch > > > Currently we get a NoAuthException printed as "NoAuth" > > Unfortunately "Auth" could mean "Authentication" or "Authorization" so I > propose to change the error message to "Not authenticated" > I won't change the NoAuthException class name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937881#comment-16937881 ] Mohammad Arshad commented on ZOOKEEPER-3558: Attached fix ZOOKEEPER-3558-01.patch for reference, will create PR later. > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.7 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3558: --- Attachment: ZOOKEEPER-3558-01.patch > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.7 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Make server principal configurable at client side.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950775#comment-16950775
]
Mohammad Arshad commented on ZOOKEEPER-1467:
Thanks [~sujithsimon22] for the interest, added you as contributor, welcome to
ZooKeeper
> Make server principal configurable at client side.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0, 3.5.7
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3653) Audit Log feature fails in a stand alone zookeeper setup
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-3653. Fix Version/s: 3.7.0 3.6.0 Resolution: Fixed Issue resolved by pull request 1185 [https://github.com/apache/zookeeper/pull/1185] > Audit Log feature fails in a stand alone zookeeper setup > > > Key: ZOOKEEPER-3653 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3653 > Project: ZooKeeper > Issue Type: Bug > Components: audit >Reporter: Sujith Simon >Assignee: Sujith Simon >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When the Audit Log feature is enabled in a standalone zookeeper setup, an > error pops up which states "Failed to audit log request" with an EndOfFile > exception due to an issue with the deserialization in the AuditHelper.java > when the request.request.slice() returns an empty pointer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3667) set jute.maxbuffer hexadecimal number throw parseInt error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-3667. Fix Version/s: 3.7.0 3.5.7 3.6.0 Resolution: Fixed Issue resolved by pull request 1222 [https://github.com/apache/zookeeper/pull/1222] > set jute.maxbuffer hexadecimal number throw parseInt error > -- > > Key: ZOOKEEPER-3667 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3667 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.5.6 >Reporter: bright.zhou >Assignee: Sujith Simon >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.7, 3.7.0 > > Attachments: 20191227-204631(eSpace).png > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3613) ZKConfig fails to return proper value on getBoolean() when user accidentally includes spaces at the end of the value
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-3613.
Fix Version/s: 3.7.0
3.5.7
3.6.0
Resolution: Fixed
Issue resolved by pull request 1190
[https://github.com/apache/zookeeper/pull/1190]
> ZKConfig fails to return proper value on getBoolean() when user accidentally
> includes spaces at the end of the value
>
>
> Key: ZOOKEEPER-3613
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3613
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.5
>Reporter: Scott Guminy
>Assignee: Sujith Simon
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.7, 3.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I was using ZooKeeper client in WebSphere Liberty and attempting to configure
> SSL/TLS for client connections.
> To do so, I must add the system property {{zookeeper.client.secure=true}}.
> In WebSphere Liberty, java system properties are placed in a file called
> bootstrap.properties - each property on a separate line. I accidentally
> added a space at the end of the line. When {{ZKConfig.getBoolean()}}
> attempted to convert this string to a {{boolean}}, it returned {{false}} due
> to the space at the end.
> {{ZKConfig.getBoolean()}} should trim the string before attempting to convert
> to a boolean.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3815) Support a new comprehensive parent znode watcher
Mohammad Arshad created ZOOKEEPER-3815: -- Summary: Support a new comprehensive parent znode watcher Key: ZOOKEEPER-3815 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3815 Project: ZooKeeper Issue Type: New Feature Reporter: Mohammad Arshad Assignee: Mohammad Arshad When a client registers this new watcher(for time being lets call it comprehensive parent znode watcher, we can give better name later.) on a parent znode then # Client should be notified on following events ## When a child is added ## When a child is deleted ## When a child is updated ## When parent is deleted # Client should be notified with znode data, This should be optional. There are many scenarios where znode data is always required. This can avoid unnecessary RPC calls. # If Client keeps all child znode data in memory, there should be way to check whether client data is consistent with Zookeeper server data. This is to ensure that no notification is lost. # This watcher should be persistent watcher, not one time watcher -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3969) Add whoami API and Cli command
Mohammad Arshad created ZOOKEEPER-3969:
--
Summary: Add whoami API and Cli command
Key: ZOOKEEPER-3969
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3969
Project: ZooKeeper
Issue Type: New Feature
Reporter: Mohammad Arshad
Assignee: Mohammad Arshad
Fix For: 3.7.0, 3.6.3
When connected to Zookeeper through CLI, many times there is need to know who
is the current user. This is helpful when finding ACL related problems. Finding
who is current user is not easy, have to check many configuration both at
client and at server.
Personally I run below three commands to know the current user
{code:java}
create /a
setAcl /a auth::cdrwa
getAcl /a
{code}
Given all the above facts, I think adding whoami command will be good add-on
into the zookeeper command list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3848) Zookeeper upgrade fails due to missing snapshots on branch-3.6
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116368#comment-17116368
]
Mohammad Arshad commented on ZOOKEEPER-3848:
zookeeper.snapshot.trust.empty is not the correct configuration if you are
adding in zoocfg.
try adding snapshot.trust.empty=true in zoo.cfg it will work.
> Zookeeper upgrade fails due to missing snapshots on branch-3.6
> --
>
> Key: ZOOKEEPER-3848
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3848
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.6.2
>Reporter: Zhuqi Jin
>Priority: Major
>
> We tested upgrading a single-node zookeeper from branch-3.4/branch-3.5 to
> branch-3.6, but the upgraded node failed to start.
> The error message is shown as following:
> {code:java}
> 2020-05-24 00:24:24,996 [myid:1] - ERROR [main:ZooKeeperServerMain@90] -
> Unexpected exception, exiting abnormally
> java.io.IOException: No snapshot found, but there are log entries. Something
> is broken!
> at
> org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:281)
> at
> org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:285)
> at
> org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:484)
> at
> org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:655)
> at
> org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:758)
> at
> org.apache.zookeeper.server.ServerCnxnFactory.startup(ServerCnxnFactory.java:130)
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:159)
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:112)
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:67)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:140)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:90)
> 2020-05-24 00:24:24,999 [myid:1] - INFO [main:ZKAuditProvider@42] -
> ZooKeeper audit is disabled.
> 2020-05-24 00:24:25,001 [myid:1] - ERROR [main:ServiceUtils@42] - Exiting JVM
> with code 1 {code}
> The error can be reproduced through the following steps:
> # Step1: Start a single-node zookeeper (compiled from either branch-3.4 or
> branch-3.5) with the following configuration(zoo.cfg):
> {code:java}
> tickTime=2000
> initLimit=10
> syncLimit=5
> dataDir=/tmp/zookeeper
> clientPort=2181
> server.1=localhost:2888:3888{code}
> # Step2: Use a zookeeper stress testing tool - zk-smoketool
> ([https://github.com/phunt/zk-smoketest.git]) - to test this node. We invoked
> create, set, and get operations in zk-smoketool but not delete operation, so
> that generated data are left on disk.
> # Step3: Upgrade the node to branch-3.6 with the same configuration. After
> upgraded, as the log suggested, zookeeper failed to start.
> We learned about ZOOKEEPER-3056 and ZOOKEEPER-3513, and added
> {code:java}
> zookeeper.snapshot.trust.empty=true {code}
> to branch-3.6's configuration(zoo.cfg), but it ran into the same failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3985) pokerzoo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-3985: -- Assignee: (was: Mohammad Arshad) > pokerzoo > > > Key: ZOOKEEPER-3985 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3985 > Project: ZooKeeper > Issue Type: Bug > Components: audit > Environment: [link title|http://example.com][link > title|http://example.com] >Reporter: nadiao >Priority: Major > > kartu poker > Popularitas poker dengan cepat menjadi permainan yang paling banyak dinikmati > di dunia. Permainan populer ini dikatakan telah sepenuhnya direvolusi oleh > Chris Moneymaker, ketika ia menang di World Series of Poker pada tahun 2003 > setelah menggunakan situs poker online untuk memenuhi syarat. Media telah > menciptakan sensasi ini dan akibatnya yang langgeng “efek Penghasil Uang”. > Seorang akuntan rendahan, kartu poker memainkan turnamen satelit tiga puluh > sembilan dolar di situs poker online PokerStars, memenangkan kursi di acara > utama World Series of Poker. Itu adalah turnamen langsung pertama Moneymaker, > dan dia membawa pulang hadiah dua setengah juta dolar. Karena acara yang > disiarkan secara luas dan dihebohkan ini, poker online meledak ke layar > dengan ribuan orang lain yang bercita-cita menjadi besar. > > Dengan ribuan pemain poker yang berharap bermimpi menjadi besar setelah > menyaksikan kemenangan Chris Moneymaker, popularitas bermain poker online > melonjak ke ketinggian baru. Di [pokerace 99|https://199.192.27.121] , yang > dikatakan berasal dari Robstown, Texas, setiap pemain diberikan dua kartu > tertutup sementara lima kartu komunitas diserahkan oleh dealer. Setiap pemain > memiliki kesempatan untuk bertaruh, memeriksa, atau melipat setelah setiap > kesepakatan. Popularitasnya telah meledak selama awal 2000-an, bahkan > menggantikan stud tujuh kartu sebagai permainan kasino Amerika Serikat yang > paling banyak dimainkan. > > Dengan ribuan pemain poker yang berharap bermimpi menjadi besar setelah > menyaksikan kemenangan Chris Moneymaker, popularitas bermain poker online > melonjak ke ketinggian baru. Kemudahan permainan dapat dimainkan secara > online sangat menarik bagi pemain pemula. Kasino mungkin menakutkan bagi > pemula. Mereka mungkin juga berlokasi di daerah yang secara geografis tidak > nyaman, hanya menarik penduduk lokal atau mereka yang mampu membayar liburan > mahal. Situs poker online juga memiliki taruhan yang lebih rendah daripada > https://199.192.27.121 , karena tidak sebanding dengan waktu operasi > kehidupan nyata untuk menjalankan permainan dengan pot kecil yang tidak akan > membayar biaya overhead mereka. Menambahkan tabel untuk permainan dengan > berbagai biaya dan jenis permainan juga tidak akan menghabiskan ruang online > seperti di kasino kehidupan nyata. > > Ada beberapa situs berbeda yang tersedia untuk bermain poker online, termasuk > PokerStars, Party Poker, William Hill, Everest Poker, dan Bodog. Mungkin yang > paling terkenal di antara situs untuk bermain poker online adalah PokerStars > – ruang kartu online terbesar di dunia. Situs penting lainnya untuk bermain > poker 88 online adalah Bodog Poker. Dibuat oleh Calvin Ayre, Bodog adalah > ruang poker online AS yang diperdagangkan terbesar dan salah satu situs judi > online paling tepercaya -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3985) pokerzoo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221134#comment-17221134 ] Mohammad Arshad commented on ZOOKEEPER-3985: Please write the description in English so everybody can understand the issue. > pokerzoo > > > Key: ZOOKEEPER-3985 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3985 > Project: ZooKeeper > Issue Type: Bug > Components: audit > Environment: [link title|http://example.com][link > title|http://example.com] >Reporter: nadiao >Priority: Major > > kartu poker > Popularitas poker dengan cepat menjadi permainan yang paling banyak dinikmati > di dunia. Permainan populer ini dikatakan telah sepenuhnya direvolusi oleh > Chris Moneymaker, ketika ia menang di World Series of Poker pada tahun 2003 > setelah menggunakan situs poker online untuk memenuhi syarat. Media telah > menciptakan sensasi ini dan akibatnya yang langgeng “efek Penghasil Uang”. > Seorang akuntan rendahan, kartu poker memainkan turnamen satelit tiga puluh > sembilan dolar di situs poker online PokerStars, memenangkan kursi di acara > utama World Series of Poker. Itu adalah turnamen langsung pertama Moneymaker, > dan dia membawa pulang hadiah dua setengah juta dolar. Karena acara yang > disiarkan secara luas dan dihebohkan ini, poker online meledak ke layar > dengan ribuan orang lain yang bercita-cita menjadi besar. > > Dengan ribuan pemain poker yang berharap bermimpi menjadi besar setelah > menyaksikan kemenangan Chris Moneymaker, popularitas bermain poker online > melonjak ke ketinggian baru. Di [pokerace 99|https://199.192.27.121] , yang > dikatakan berasal dari Robstown, Texas, setiap pemain diberikan dua kartu > tertutup sementara lima kartu komunitas diserahkan oleh dealer. Setiap pemain > memiliki kesempatan untuk bertaruh, memeriksa, atau melipat setelah setiap > kesepakatan. Popularitasnya telah meledak selama awal 2000-an, bahkan > menggantikan stud tujuh kartu sebagai permainan kasino Amerika Serikat yang > paling banyak dimainkan. > > Dengan ribuan pemain poker yang berharap bermimpi menjadi besar setelah > menyaksikan kemenangan Chris Moneymaker, popularitas bermain poker online > melonjak ke ketinggian baru. Kemudahan permainan dapat dimainkan secara > online sangat menarik bagi pemain pemula. Kasino mungkin menakutkan bagi > pemula. Mereka mungkin juga berlokasi di daerah yang secara geografis tidak > nyaman, hanya menarik penduduk lokal atau mereka yang mampu membayar liburan > mahal. Situs poker online juga memiliki taruhan yang lebih rendah daripada > https://199.192.27.121 , karena tidak sebanding dengan waktu operasi > kehidupan nyata untuk menjalankan permainan dengan pot kecil yang tidak akan > membayar biaya overhead mereka. Menambahkan tabel untuk permainan dengan > berbagai biaya dan jenis permainan juga tidak akan menghabiskan ruang online > seperti di kasino kehidupan nyata. > > Ada beberapa situs berbeda yang tersedia untuk bermain poker online, termasuk > PokerStars, Party Poker, William Hill, Everest Poker, dan Bodog. Mungkin yang > paling terkenal di antara situs untuk bermain poker online adalah PokerStars > – ruang kartu online terbesar di dunia. Situs penting lainnya untuk bermain > poker 88 online adalah Bodog Poker. Dibuat oleh Calvin Ayre, Bodog adalah > ruang poker online AS yang diperdagangkan terbesar dan salah satu situs judi > online paling tepercaya -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3969) Add whoami API and Cli command
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221135#comment-17221135
]
Mohammad Arshad commented on ZOOKEEPER-3969:
Thanks [~symat] for reviewing and merging the PR.
Thanks [~eolivelli], [~ztzg] for reviewing the PR
> Add whoami API and Cli command
> ---
>
> Key: ZOOKEEPER-3969
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3969
> Project: ZooKeeper
> Issue Type: New Feature
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.7.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> When connected to Zookeeper through CLI, many times there is need to know who
> is the current user. This is helpful when finding ACL related problems.
> Finding who is current user is not easy, have to check many configuration
> both at client and at server.
> Personally I run below three commands to know the current user
> {code:java}
> create /a
> setAcl /a auth::cdrwa
> getAcl /a
> {code}
> Given all the above facts, I think adding whoami command will be good add-on
> into the zookeeper command list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3891) ZKCli commands give wrong error message "Authentication is not valid" for insufficient permissions
Mohammad Arshad created ZOOKEEPER-3891:
--
Summary: ZKCli commands give wrong error message "Authentication
is not valid" for insufficient permissions
Key: ZOOKEEPER-3891
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3891
Project: ZooKeeper
Issue Type: Bug
Reporter: Mohammad Arshad
Assignee: Mohammad Arshad
ZKCli commands give error message "Authentication is not valid" for
insufficient permissions .(when KeeperException.NoAuthException is thrown).
This is misleading message.
Steps: to get the error
{code:java}
[zk: vm1:2181(CONNECTED) 0] create /b
Created /b
[zk: vm1:2181(CONNECTED) 1] getAcl /b
'world,'anyone
: cdrwa
[zk: vm1:2181(CONNECTED) 2] setAcl /b world:anyone:ra
[zk: vm1:2181(CONNECTED) 3] getAcl /b
'world,'anyone
: ra
[zk: vm1:2181(CONNECTED) 4] create /b/b1
Authentication is not valid : /b/b1
[zk: vm1:2181(CONNECTED) 5]
{code}
I think we should change message "Authentication is not valid" to
"Insufficient permission"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3873) ClientCnxnSocketNIO#enableWrite throws NullPointerException
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151878#comment-17151878
]
Mohammad Arshad commented on ZOOKEEPER-3873:
Any idea how to reproduce this issue?
> ClientCnxnSocketNIO#enableWrite throws NullPointerException
> ---
>
> Key: ZOOKEEPER-3873
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3873
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Reporter: maoling
>Priority: Minor
> Fix For: 3.7.0
>
>
> I also attach the client side logs here
> {code:java}
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss for
> /bench-watch/12318org.apache.zookeeper.KeeperException$ConnectionLossException:
> KeeperErrorCode = ConnectionLoss for /bench-watch/123182020-06-27
> 13:42:31,898 [myid:127.0.0.1:2181] - WARN
> [pool-1-thread-11-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1278] -
> Session 0x1001a2fab59004c for sever localhost/127.0.0.1:2181, Closing socket
> connection. Attempting reconnect except it is a
> SessionExpiredException.java.lang.NullPointerException at
> org.apache.zookeeper.ClientCnxnSocketNIO.enableWrite(ClientCnxnSocketNIO.java:377)
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:353)
> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1268) at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:102) at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:54) at
> org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1856)
> {code}
>
> {code:java}
> 2020-06-27 13:51:04,334 [myid:] - ERROR [pool-1-thread-12:ClientCnxn@1590] -
> Timeout error occurred for the packet 'clientPath:null serverPath:null
> finished:false header:: 13886,3 replyHeader:: 0,0,0 request::
> '/bench-watch/12815,T response:: '.2020-06-27 13:51:04,334 [myid:] - ERROR
> [pool-1-thread-12:ClientCnxn@1590] - Timeout error occurred for the packet
> 'clientPath:null serverPath:null finished:false header:: 13886,3
> replyHeader:: 0,0,0 request:: '/bench-watch/12815,T response::
> '.2020-06-27 13:51:04,334 [myid:] - ERROR [pool-1-thread-29:ClientCnxn@1590]
> - Timeout error occurred for the packet 'clientPath:null serverPath:null
> finished:false header:: 13395,3 replyHeader:: 0,0,0 request::
> '/bench-watch/12331,T response:: '.2020-06-27 13:51:04,335
> [myid:127.0.0.1:2181] - WARN
> [pool-1-thread-12-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1278] -
> Session 0x1001a2fab59003d for sever localhost/127.0.0.1:2181, Closing socket
> connection. Attempting reconnect except it is a
> SessionExpiredException.java.nio.channels.CancelledKeyException at
> sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) at
> sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:77) at
> org.apache.zookeeper.ClientCnxnSocketNIO.enableWrite(ClientCnxnSocketNIO.java:377)
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:353)
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1268)2020-06-27
> 13:51:04,336 [myid:127.0.0.1:2181] - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1159] -
> Opening socket connection to server localhost/127.0.0.1:2181.2020-06-27
> 13:51:04,336 [myid:127.0.0.1:2181] - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1161] -
> SASL config status: Will not attempt to authenticate using SASL (unknown
> error)2020-06-27 13:51:04,337 [myid:127.0.0.1:2181] - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@993] -
> Socket connection established, initiating session, client: /127.0.0.1:62205,
> server: localhost/127.0.0.1:21812020-06-27 13:51:04,339 [myid:127.0.0.1:2181]
> - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1426] -
> Session establishment complete on server localhost/127.0.0.1:2181, session id
> = 0x1001a2fab59005a, negotiated timeout = 4
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (ZOOKEEPER-3873) ClientCnxnSocketNIO#enableWrite throws NullPointerException
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-3873:
---
Comment: was deleted
(was: Any idea how to reproduce this issue?)
> ClientCnxnSocketNIO#enableWrite throws NullPointerException
> ---
>
> Key: ZOOKEEPER-3873
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3873
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Reporter: maoling
>Priority: Minor
> Fix For: 3.7.0
>
>
> I also attach the client side logs here
> {code:java}
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss for
> /bench-watch/12318org.apache.zookeeper.KeeperException$ConnectionLossException:
> KeeperErrorCode = ConnectionLoss for /bench-watch/123182020-06-27
> 13:42:31,898 [myid:127.0.0.1:2181] - WARN
> [pool-1-thread-11-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1278] -
> Session 0x1001a2fab59004c for sever localhost/127.0.0.1:2181, Closing socket
> connection. Attempting reconnect except it is a
> SessionExpiredException.java.lang.NullPointerException at
> org.apache.zookeeper.ClientCnxnSocketNIO.enableWrite(ClientCnxnSocketNIO.java:377)
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:353)
> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1268) at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:102) at
> org.apache.zookeeper.KeeperException.create(KeeperException.java:54) at
> org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1856)
> {code}
>
> {code:java}
> 2020-06-27 13:51:04,334 [myid:] - ERROR [pool-1-thread-12:ClientCnxn@1590] -
> Timeout error occurred for the packet 'clientPath:null serverPath:null
> finished:false header:: 13886,3 replyHeader:: 0,0,0 request::
> '/bench-watch/12815,T response:: '.2020-06-27 13:51:04,334 [myid:] - ERROR
> [pool-1-thread-12:ClientCnxn@1590] - Timeout error occurred for the packet
> 'clientPath:null serverPath:null finished:false header:: 13886,3
> replyHeader:: 0,0,0 request:: '/bench-watch/12815,T response::
> '.2020-06-27 13:51:04,334 [myid:] - ERROR [pool-1-thread-29:ClientCnxn@1590]
> - Timeout error occurred for the packet 'clientPath:null serverPath:null
> finished:false header:: 13395,3 replyHeader:: 0,0,0 request::
> '/bench-watch/12331,T response:: '.2020-06-27 13:51:04,335
> [myid:127.0.0.1:2181] - WARN
> [pool-1-thread-12-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1278] -
> Session 0x1001a2fab59003d for sever localhost/127.0.0.1:2181, Closing socket
> connection. Attempting reconnect except it is a
> SessionExpiredException.java.nio.channels.CancelledKeyException at
> sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) at
> sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:77) at
> org.apache.zookeeper.ClientCnxnSocketNIO.enableWrite(ClientCnxnSocketNIO.java:377)
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:353)
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1268)2020-06-27
> 13:51:04,336 [myid:127.0.0.1:2181] - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1159] -
> Opening socket connection to server localhost/127.0.0.1:2181.2020-06-27
> 13:51:04,336 [myid:127.0.0.1:2181] - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1161] -
> SASL config status: Will not attempt to authenticate using SASL (unknown
> error)2020-06-27 13:51:04,337 [myid:127.0.0.1:2181] - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@993] -
> Socket connection established, initiating session, client: /127.0.0.1:62205,
> server: localhost/127.0.0.1:21812020-06-27 13:51:04,339 [myid:127.0.0.1:2181]
> - INFO
> [pool-1-thread-39-SendThread(127.0.0.1:2181):ClientCnxn$SendThread@1426] -
> Session establishment complete on server localhost/127.0.0.1:2181, session id
> = 0x1001a2fab59005a, negotiated timeout = 4
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3876) zkServer.sh status command fails when IPV6 is configured
Mohammad Arshad created ZOOKEEPER-3876:
--
Summary: zkServer.sh status command fails when IPV6 is configured
Key: ZOOKEEPER-3876
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3876
Project: ZooKeeper
Issue Type: Bug
Reporter: Mohammad Arshad
Assignee: Mohammad Arshad
Fix For: 3.7.0
When server configuration has client IP and port in it as below
{code:java}
server.1=127:0:0:0:0:0:0:1:2890:3890:participant;127:0:0:0:0:0:0:1:2181
{code}
Then zkServer.sh status command fails. It is not able to parse the host and ip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3877) JMX Bean RemotePeerBean should enclose IPV6 host in square bracket same as LocalPeerBean
Mohammad Arshad created ZOOKEEPER-3877: -- Summary: JMX Bean RemotePeerBean should enclose IPV6 host in square bracket same as LocalPeerBean Key: ZOOKEEPER-3877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3877 Project: ZooKeeper Issue Type: Bug Components: jmx Reporter: Mohammad Arshad Assignee: Mohammad Arshad Fix For: 4.0.0 JMX metrics Bean RemotePeerBean should enclose ipv6 host in square bracket same as LocalPeerBean Changes done in ZOOKEEPER-3057 for LocalPeerBean should also be done for RemotePeerBean -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3878) Client connection fails if IPV6 is not enclosed in square brackets
Mohammad Arshad created ZOOKEEPER-3878: -- Summary: Client connection fails if IPV6 is not enclosed in square brackets Key: ZOOKEEPER-3878 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3878 Project: ZooKeeper Issue Type: Bug Reporter: Mohammad Arshad Assignee: Mohammad Arshad Fix For: 4.0.0, 3.6.2 Clients should be able to connect to ZooKeeper with or without square bracket around IPV6 in connection string. 127:0:0:0:0:0:0:1:2181 and [127:0:0:0:0:0:0:1]:2181 both should work. After ZOOKEEPER-3106 fix connection with 127:0:0:0:0:0:0:1:2181 fails I think we should support both with or without square bracket around IPV6. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3886) Client connection string should support IPV6 with or without enclosed in square bracket.
Mohammad Arshad created ZOOKEEPER-3886: -- Summary: Client connection string should support IPV6 with or without enclosed in square bracket. Key: ZOOKEEPER-3886 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3886 Project: ZooKeeper Issue Type: Improvement Reporter: Mohammad Arshad Assignee: Mohammad Arshad Fix For: 3.5.9 Clients should be able to connect to ZooKeeper with or without square bracket around IPV6 in connection string. 127:0:0:0:0:0:0:1:2181 and [127:0:0:0:0:0:0:1]:2181 both should work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3878) Client connection fails if IPV6 is not enclosed in square brackets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156946#comment-17156946 ] Mohammad Arshad commented on ZOOKEEPER-3878: Thanks @eolivelli for reviewing and committing this Issue. > Client connection fails if IPV6 is not enclosed in square brackets > -- > > Key: ZOOKEEPER-3878 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3878 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.7.0, 3.6.2 > > Time Spent: 1h > Remaining Estimate: 0h > > Clients should be able to connect to ZooKeeper with or without square > bracket around IPV6 in connection string. > 127:0:0:0:0:0:0:1:2181 and [127:0:0:0:0:0:0:1]:2181 both should work. > After ZOOKEEPER-3106 fix connection with 127:0:0:0:0:0:0:1:2181 fails > I think we should support both with or without square bracket around IPV6. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3887) In SSL-only server zkServer.sh status command should use secureClientPortAddress instead of clientPortAddress
Mohammad Arshad created ZOOKEEPER-3887: -- Summary: In SSL-only server zkServer.sh status command should use secureClientPortAddress instead of clientPortAddress Key: ZOOKEEPER-3887 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3887 Project: ZooKeeper Issue Type: Bug Components: scripts Reporter: Mohammad Arshad Assignee: Mohammad Arshad Fix For: 3.7.0, 3.6.2, 3.5.9 When only SSL client port is enabled, zkServer.sh status command should use secureClientPortAddress value instead of clientPortAddress. As clientPortAddress is not configured, zkServer.sh status command tries to connect to localhost and fails. ZOOKEEPER-3818 has addressed the port issue, same way we should address the host issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3877) JMX Bean RemotePeerBean should enclose IPV6 host in square bracket same as LocalPeerBean
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3877: --- Fix Version/s: (was: 4.0.0) 3.7.0 > JMX Bean RemotePeerBean should enclose IPV6 host in square bracket same as > LocalPeerBean > - > > Key: ZOOKEEPER-3877 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3877 > Project: ZooKeeper > Issue Type: Bug > Components: jmx >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Minor > Fix For: 3.7.0 > > > JMX metrics Bean RemotePeerBean should enclose ipv6 host in square bracket > same as LocalPeerBean > Changes done in ZOOKEEPER-3057 for LocalPeerBean should also be done for > RemotePeerBean -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3878) Client connection fails if IPV6 is not enclosed in square brackets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3878: --- Fix Version/s: (was: 3.6.2) (was: 4.0.0) 3.7.0 > Client connection fails if IPV6 is not enclosed in square brackets > -- > > Key: ZOOKEEPER-3878 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3878 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.7.0 > > > Clients should be able to connect to ZooKeeper with or without square > bracket around IPV6 in connection string. > 127:0:0:0:0:0:0:1:2181 and [127:0:0:0:0:0:0:1]:2181 both should work. > After ZOOKEEPER-3106 fix connection with 127:0:0:0:0:0:0:1:2181 fails > I think we should support both with or without square bracket around IPV6. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-2262) Admin commands do not include secure client information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-2262. Fix Version/s: (was: 3.5.10) (was: 3.7.0) Resolution: Won't Fix Secure client information included as part of ZOOKEEPER-3633 fix > Admin commands do not include secure client information > --- > > Key: ZOOKEEPER-2262 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2262 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: JettyAdminServer > > Admin commands do not include secure client information > connections, configuration, connection_stat_reset and stats admin should > include secure client informations > 1) configuration should include the secure client port also > 2) connections should include secure connections also > 3) connection_stat_reset should also reset secure connection > 4) stats command should accumulate both secure and non secure information -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260382#comment-17260382 ] Mohammad Arshad commented on ZOOKEEPER-832: --- [~george_zhu] there is no plan this commit this patch. If you are still facing the issue, please raise another jira with details and scenario. As this issue scenario is not valid for fix. > Invalid session id causes infinite loop during automatic reconnect > -- > > Key: ZOOKEEPER-832 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.5, 3.5.0, 3.4.11 > Environment: All >Reporter: Ryan Holmes >Assignee: Mohammad Arshad >Priority: Critical > Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch > > > Steps to reproduce: > 1.) Connect to a standalone server using the Java client. > 2.) Stop the server. > 3.) Delete the contents of the data directory (i.e. the persisted session > data). > 4.) Start the server. > The client now automatically tries to reconnect but the server refuses the > connection because the session id is invalid. The client and server are now > in an infinite loop of attempted and rejected connections. While this > situation represents a catastrophic failure and the current behavior is not > incorrect, it appears that there is no way to detect this situation on the > client and therefore no way to recover. > The suggested improvement is to send an event to the default watcher > indicating that the current state is "session invalid", similar to how the > "session expired" state is handled. > Server log output (repeats indefinitely): > 2010-08-05 11:48:08,283 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - > Accepted socket connection from /127.0.0.1:63292 > 2010-08-05 11:48:08,284 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing > session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last > zxid is 0x0 client must try another server > 2010-08-05 11:48:08,284 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed > socket connection for client /127.0.0.1:63292 (no session established for > client) > Client log output (repeats indefinitely): > 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - > Opening socket connection to server localhost/127.0.0.1:2181 > 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session > 0x12a3ae4e893000a for server null, unexpected error, closing socket > connection and attempting reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078) > 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring > exception during shutdown input > java.nio.channels.ClosedChannelException > at > sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638) > at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360) > at > org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129) > 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring > exception during shutdown output > java.nio.channels.ClosedChannelException > at > sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649) > at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368) > at > org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260355#comment-17260355 ] Mohammad Arshad commented on ZOOKEEPER-3561: It is ok, let it be only in master branch > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.7.0 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-2265) zookeeper build fails while doing configuration for cppunit test
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-2265.
Fix Version/s: (was: 3.5.10)
(was: 3.7.0)
Resolution: Invalid
After moving to maven this issue is no more valid
> zookeeper build fails while doing configuration for cppunit test
>
>
> Key: ZOOKEEPER-2265
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2265
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.1
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Attachments: ZOOKEEPER-2265-01.patch
>
>
> running {color:red}ant tar{color} gives following error
> {code}
> D:\gitHome\zookeeper-trunk\build.xml:1432: Execute failed:
> java.io.IOException: Cannot run program "autoreconf" (in directory
> "D:\gitHome\zookeeper-trunk\src\c"):
> {code}
> This error is purely environment error and it can be fixed by installing
> appropriate software package.
> But does it really required to configure the cpp unit as {color:red}ant
> tar{color} target flow does not run cppunit test cases. Then why to configure?
> There should be no cppunit configurations for {color:red}ant tar{color}
> target flow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-3558. Release Note: ZOOKEEPER-3561 implemented this jira functionality in master branch. Won't Fix in branch-3.5 Resolution: Won't Fix > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.10 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-2456) Provide API to get user from different authentication providers
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-2456.
Fix Version/s: (was: 3.5.10)
(was: 3.7.0)
Resolution: Won't Fix
The API got added as part of ZOOKEEPER-1260.
{code:java}
org.apache.zookeeper.server.auth.AuthenticationProvider#getUserName
{code}
> Provide API to get user from different authentication providers
> ---
>
> Key: ZOOKEEPER-2456
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2456
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
>
> Currently zookeeper server same field is used to store both user name and
> password
> Provide a mechanism to separate the user and password either by adding new
> field or by adding new API
> DETAILS:
> org.apache.zookeeper.data.Id class is used to store scheme and id.
> {code}
> public Id( String scheme, String id)
> {code}
> id field holds only user in most cases but in some cases it holds user as
> well as password
> By default there are only four authentication provider
> DigestAuthenticationProvider
> IPAuthenticationProvider
> SASLAuthenticationProvider
> X509AuthenticationProvider
> In code we can check if scheme is digest then {{id.split(":")\[0\]}} is user
> otherwise id is user. This will work only if we are limited to above four
> authentication provider
> But Custom authentication provider are very important and are very commonly
> used. How the zookeeper code will know what is the user, is it id or
> {{id.split(":")\[0\]}} or anything else ?
> So there is need to add new API which AuthenticationProvider providers
> implement to define what is user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218075#comment-17218075 ] Mohammad Arshad commented on ZOOKEEPER-3561: Thanks [~hanm] for reviewing and merging the PR. Thanks [~nkalmar], [~eolivelli], [~ztzg] for reviewing the PR > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.7.0 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218079#comment-17218079 ] Mohammad Arshad commented on ZOOKEEPER-3561: I think this issue should be merged to branch-3.6 also. What is your thought [~hanm] > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.7.0 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218075#comment-17218075 ] Mohammad Arshad edited comment on ZOOKEEPER-3561 at 10/21/20, 3:21 AM: --- Thanks [~hanm] for reviewing and merging the PR. Thanks [~anmolnar], [~eolivelli], [~ztzg] for reviewing the PR was (Author: arshad.mohammad): Thanks [~hanm] for reviewing and merging the PR. Thanks [~nkalmar], [~eolivelli], [~ztzg] for reviewing the PR > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.7.0 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ZOOKEEPER-4031) Why we would “add the last logfile that is less than the zxid” in FileTxnLog:653
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reopened ZOOKEEPER-4031: > Why we would “add the last logfile that is less than the zxid” in > FileTxnLog:653 > -- > > Key: ZOOKEEPER-4031 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4031 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-4028) zookeeper client timeout
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-4028.
Resolution: Invalid
> zookeeper client timeout
>
>
> Key: ZOOKEEPER-4028
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4028
> Project: ZooKeeper
> Issue Type: Bug
> Environment: 2020-12-14 20:09:43,488 [myid:] - WARN
> [NIOWorkerThread-2:NIOServerCnxn@366] - Unable to read additional data from
> client sessionid 0x1989ff10001, likely client has closed socket
> 4.I expected after 2000ms(2s) zookeeper should set the session timetout, but
> zookeeper set the session timeout state after 17s has pased! I don't know
> why. anyone has suggestion?
> 2020-12-14 20:08:07,309 [myid:] - INFO [main:ZooKeeperServer@947] -
> maxSessionTimeout set to 2
> 2020-12-14 20:08:07,309 [myid:] - INFO [main:ZooKeeperServer@166] - Created
> server with tickTime 1000 minSessionTimeout 2000 maxSessionTimeout 2
> datadir /tmp/zookeeper/version-2 snapdir /tmp/zookeeper/version-2
> 2020-12-14 20:08:07,321 [myid:] - INFO [main:Log@169] - Logging initialized
> @296ms to org.eclipse.jetty.util.log.Slf4jLog
> 2020-12-14 20:08:07,384 [myid:] - WARN [main:ContextHandler@1520] -
> o.e.j.s.ServletContextHandler@57536d79{/,null,UNAVAILABLE} contextPath ends
> with /*
> 2020-12-14 20:08:07,385 [myid:] - WARN [main:ContextHandler@1531] - Empty
> contextPath
> 2020-12-14 20:08:07,394 [myid:] - INFO [main:Server@359] -
> jetty-9.4.24.v20191120; built: 2019-11-20T21:37:49.771Z; git:
> 363d5f2df3a8a28de40604320230664b9c793c16; jvm 1.8.0_261-b12
> 2020-12-14 20:08:07,427 [myid:] - INFO [main:DefaultSessionIdManager@333] -
> DefaultSessionIdManager workerName=node0
> 2020-12-14 20:08:07,427 [myid:] - INFO [main:DefaultSessionIdManager@338] -
> No SessionScavenger set, using defaults
> 2020-12-14 20:08:07,429 [myid:] - INFO [main:HouseKeeper@140] - node0
> Scavenging every 66ms
> 2020-12-14 20:08:07,436 [myid:] - INFO [main:ContextHandler@825] - Started
> o.e.j.s.ServletContextHandler@57536d79{/,null,AVAILABLE}
> 2020-12-14 20:08:07,444 [myid:] - INFO [main:AbstractConnector@330] -
> Started ServerConnector@1e88b3c{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
> 2020-12-14 20:08:07,444 [myid:] - INFO [main:Server@399] - Started @419ms
> 2020-12-14 20:08:07,444 [myid:] - INFO [main:JettyAdminServer@112] - Started
> AdminServer on address 0.0.0.0, port 8080 and command URL /commands
> 2020-12-14 20:08:07,447 [myid:] - INFO [main:ServerCnxnFactory@135] - Using
> org.apache.zookeeper.server.NIOServerCnxnFactory as server connection factory
> 2020-12-14 20:08:07,448 [myid:] - INFO [main:NIOServerCnxnFactory@673] -
> Configuring NIO connection handler with 10s sessionless connection timeout, 1
> selector thread(s), 4 worker threads, and 64 kB direct buffers.
> 2020-12-14 20:08:07,449 [myid:] - INFO [main:NIOServerCnxnFactory@686] -
> binding to port 0.0.0.0/0.0.0.0:2181
> 2020-12-14 20:08:07,457 [myid:] - INFO [main:ZKDatabase@117] -
> zookeeper.snapshotSizeFactor = 0.33
> 2020-12-14 20:08:07,459 [myid:] - INFO [main:FileSnap@83] - Reading snapshot
> /tmp/zookeeper/version-2/snapshot.aa
> 2020-12-14 20:08:07,470 [myid:] - INFO [main:FileTxnSnapLog@404] -
> Snapshotting: 0xbb to /tmp/zookeeper/version-2/snapshot.bb
> 2020-12-14 20:08:07,480 [myid:] - INFO [main:ContainerManager@64] - Using
> checkIntervalMs=6 maxPerMinute=1
> 2020-12-14 20:08:22,412 [myid:] - INFO [SyncThread:0:FileTxnLog@218] -
> Creating new log file: log.bc
> 2020-12-14 20:08:28,055 [myid:] - INFO [SessionTracker:ZooKeeperServer@398]
> - Expiring session 0x191408c, timeout of 2ms exceeded
> 2020-12-14 20:08:43,210 [myid:] - WARN [NIOWorkerThread-1:NIOServerCnxn@366]
> - Unable to read additional data from client sessionid 0x1989ff1,
> likely client has closed socket
> 2020-12-14 20:09:03,057 [myid:] - INFO [SessionTracker:ZooKeeperServer@398]
> - Expiring session 0x1989ff1, timeout of 2ms exceeded
> 2020-12-14 20:09:07,482 [myid:] - INFO
> [ContainerManagerTask:ContainerManager@119] - Attempting to delete candidate
> container: /msg/root/msg3
> 2020-12-14 20:09:07,488 [myid:] - INFO
> [ContainerManagerTask:ContainerManager@119] - Attempting to delete candidate
> container: /msg/root/msg1
> 2020-12-14 20:09:07,495 [myid:] - INFO
> [ContainerManagerTask:ContainerManager@119] - Attempting to delete candidate
> container: /msg/root/msg2
> 2020-12-14 20:09:43,488 [myid:] - WARN [NIOWorkerThread-2:NIOServerCnxn@366]
> - Unable to read additional data from client sessionid 0x1989ff10001,
> likely client has closed socket
> 2020-12-14 20:10:00,056 [myid:] - INFO [SessionTracker:ZooKeeperServer@398]
> - Expiring session 0x1989ff10001, timeout of 2ms exceeded
>
[jira] [Resolved] (ZOOKEEPER-4031) Why we would “add the last logfile that is less than the zxid” in FileTxnLog:653
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-4031. Resolution: Invalid > Why we would “add the last logfile that is less than the zxid” in > FileTxnLog:653 > -- > > Key: ZOOKEEPER-4031 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4031 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ZOOKEEPER-4028) zookeeper client timeout
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad reopened ZOOKEEPER-4028:
> zookeeper client timeout
>
>
> Key: ZOOKEEPER-4028
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4028
> Project: ZooKeeper
> Issue Type: Bug
> Environment: 2020-12-14 20:09:43,488 [myid:] - WARN
> [NIOWorkerThread-2:NIOServerCnxn@366] - Unable to read additional data from
> client sessionid 0x1989ff10001, likely client has closed socket
> 4.I expected after 2000ms(2s) zookeeper should set the session timetout, but
> zookeeper set the session timeout state after 17s has pased! I don't know
> why. anyone has suggestion?
> 2020-12-14 20:08:07,309 [myid:] - INFO [main:ZooKeeperServer@947] -
> maxSessionTimeout set to 2
> 2020-12-14 20:08:07,309 [myid:] - INFO [main:ZooKeeperServer@166] - Created
> server with tickTime 1000 minSessionTimeout 2000 maxSessionTimeout 2
> datadir /tmp/zookeeper/version-2 snapdir /tmp/zookeeper/version-2
> 2020-12-14 20:08:07,321 [myid:] - INFO [main:Log@169] - Logging initialized
> @296ms to org.eclipse.jetty.util.log.Slf4jLog
> 2020-12-14 20:08:07,384 [myid:] - WARN [main:ContextHandler@1520] -
> o.e.j.s.ServletContextHandler@57536d79{/,null,UNAVAILABLE} contextPath ends
> with /*
> 2020-12-14 20:08:07,385 [myid:] - WARN [main:ContextHandler@1531] - Empty
> contextPath
> 2020-12-14 20:08:07,394 [myid:] - INFO [main:Server@359] -
> jetty-9.4.24.v20191120; built: 2019-11-20T21:37:49.771Z; git:
> 363d5f2df3a8a28de40604320230664b9c793c16; jvm 1.8.0_261-b12
> 2020-12-14 20:08:07,427 [myid:] - INFO [main:DefaultSessionIdManager@333] -
> DefaultSessionIdManager workerName=node0
> 2020-12-14 20:08:07,427 [myid:] - INFO [main:DefaultSessionIdManager@338] -
> No SessionScavenger set, using defaults
> 2020-12-14 20:08:07,429 [myid:] - INFO [main:HouseKeeper@140] - node0
> Scavenging every 66ms
> 2020-12-14 20:08:07,436 [myid:] - INFO [main:ContextHandler@825] - Started
> o.e.j.s.ServletContextHandler@57536d79{/,null,AVAILABLE}
> 2020-12-14 20:08:07,444 [myid:] - INFO [main:AbstractConnector@330] -
> Started ServerConnector@1e88b3c{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
> 2020-12-14 20:08:07,444 [myid:] - INFO [main:Server@399] - Started @419ms
> 2020-12-14 20:08:07,444 [myid:] - INFO [main:JettyAdminServer@112] - Started
> AdminServer on address 0.0.0.0, port 8080 and command URL /commands
> 2020-12-14 20:08:07,447 [myid:] - INFO [main:ServerCnxnFactory@135] - Using
> org.apache.zookeeper.server.NIOServerCnxnFactory as server connection factory
> 2020-12-14 20:08:07,448 [myid:] - INFO [main:NIOServerCnxnFactory@673] -
> Configuring NIO connection handler with 10s sessionless connection timeout, 1
> selector thread(s), 4 worker threads, and 64 kB direct buffers.
> 2020-12-14 20:08:07,449 [myid:] - INFO [main:NIOServerCnxnFactory@686] -
> binding to port 0.0.0.0/0.0.0.0:2181
> 2020-12-14 20:08:07,457 [myid:] - INFO [main:ZKDatabase@117] -
> zookeeper.snapshotSizeFactor = 0.33
> 2020-12-14 20:08:07,459 [myid:] - INFO [main:FileSnap@83] - Reading snapshot
> /tmp/zookeeper/version-2/snapshot.aa
> 2020-12-14 20:08:07,470 [myid:] - INFO [main:FileTxnSnapLog@404] -
> Snapshotting: 0xbb to /tmp/zookeeper/version-2/snapshot.bb
> 2020-12-14 20:08:07,480 [myid:] - INFO [main:ContainerManager@64] - Using
> checkIntervalMs=6 maxPerMinute=1
> 2020-12-14 20:08:22,412 [myid:] - INFO [SyncThread:0:FileTxnLog@218] -
> Creating new log file: log.bc
> 2020-12-14 20:08:28,055 [myid:] - INFO [SessionTracker:ZooKeeperServer@398]
> - Expiring session 0x191408c, timeout of 2ms exceeded
> 2020-12-14 20:08:43,210 [myid:] - WARN [NIOWorkerThread-1:NIOServerCnxn@366]
> - Unable to read additional data from client sessionid 0x1989ff1,
> likely client has closed socket
> 2020-12-14 20:09:03,057 [myid:] - INFO [SessionTracker:ZooKeeperServer@398]
> - Expiring session 0x1989ff1, timeout of 2ms exceeded
> 2020-12-14 20:09:07,482 [myid:] - INFO
> [ContainerManagerTask:ContainerManager@119] - Attempting to delete candidate
> container: /msg/root/msg3
> 2020-12-14 20:09:07,488 [myid:] - INFO
> [ContainerManagerTask:ContainerManager@119] - Attempting to delete candidate
> container: /msg/root/msg1
> 2020-12-14 20:09:07,495 [myid:] - INFO
> [ContainerManagerTask:ContainerManager@119] - Attempting to delete candidate
> container: /msg/root/msg2
> 2020-12-14 20:09:43,488 [myid:] - WARN [NIOWorkerThread-2:NIOServerCnxn@366]
> - Unable to read additional data from client sessionid 0x1989ff10001,
> likely client has closed socket
> 2020-12-14 20:10:00,056 [myid:] - INFO [SessionTracker:ZooKeeperServer@398]
> - Expiring session 0x1989ff10001, timeout of 2ms exceeded
> 2020-12-14 20:10:07,481
[jira] [Comment Edited] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260382#comment-17260382 ] Mohammad Arshad edited comment on ZOOKEEPER-832 at 1/13/21, 2:45 PM: - [~george_zhu] there is no plan to commit this patch. If you are still facing the issue, please raise another jira with details and scenario. As this issue scenario is not valid for fix. was (Author: arshad.mohammad): [~george_zhu] there is no plan this commit this patch. If you are still facing the issue, please raise another jira with details and scenario. As this issue scenario is not valid for fix. > Invalid session id causes infinite loop during automatic reconnect > -- > > Key: ZOOKEEPER-832 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.5, 3.5.0, 3.4.11 > Environment: All >Reporter: Ryan Holmes >Assignee: Mohammad Arshad >Priority: Critical > Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch > > > Steps to reproduce: > 1.) Connect to a standalone server using the Java client. > 2.) Stop the server. > 3.) Delete the contents of the data directory (i.e. the persisted session > data). > 4.) Start the server. > The client now automatically tries to reconnect but the server refuses the > connection because the session id is invalid. The client and server are now > in an infinite loop of attempted and rejected connections. While this > situation represents a catastrophic failure and the current behavior is not > incorrect, it appears that there is no way to detect this situation on the > client and therefore no way to recover. > The suggested improvement is to send an event to the default watcher > indicating that the current state is "session invalid", similar to how the > "session expired" state is handled. > Server log output (repeats indefinitely): > 2010-08-05 11:48:08,283 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - > Accepted socket connection from /127.0.0.1:63292 > 2010-08-05 11:48:08,284 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing > session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last > zxid is 0x0 client must try another server > 2010-08-05 11:48:08,284 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed > socket connection for client /127.0.0.1:63292 (no session established for > client) > Client log output (repeats indefinitely): > 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - > Opening socket connection to server localhost/127.0.0.1:2181 > 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session > 0x12a3ae4e893000a for server null, unexpected error, closing socket > connection and attempting reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078) > 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring > exception during shutdown input > java.nio.channels.ClosedChannelException > at > sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638) > at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360) > at > org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129) > 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring > exception during shutdown output > java.nio.channels.ClosedChannelException > at > sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649) > at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368) > at > org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-4275) Slowness in sasl login or subject.doAs() causes zk client to falsely assume that the server did not respond, closes connection and goes to unnecessary retries
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-4275: -- Assignee: Ravi Kishore Valeti > Slowness in sasl login or subject.doAs() causes zk client to falsely assume > that the server did not respond, closes connection and goes to unnecessary > retries > -- > > Key: ZOOKEEPER-4275 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4275 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.5.9 >Reporter: Ravi Kishore Valeti >Assignee: Ravi Kishore Valeti >Priority: Minor > Labels: pull-request-available > Fix For: 3.5.10, 3.8.0, 3.7.1, 3.6.4 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Zookeeper client does sasl auth (login and subject.doAs())as a preset before > attempting a connection to server. > If there is a delay in sasl auth (possibly due to slow Kerberos > communication), ZK client falsely assumes that the zk server did not respond > and runs in to unnecessary multiple retries. > Client configuration: > "zookeeper.session.timeout" = "3000" > "zookeeper.recovery.retry" = "1" > "zookeeper.recovery.retry.intervalmill" = "500" > This configuration translates to > connect timeout as 1000ms > Read Timeout as 2000ms > Example: There was a 3 second delay in logging in the user as seen from the > logs below. The connection attempt was made later. However, zk client did not > wait for server response but logged a timeout (3 seconds > 1 sec connect > timeout), closed the connection and went to retries. Since there was a > consistent delay at Kerberos master, we had seen this retries go as long as > 10 mins causing requests to timeout/fail. > Logs: > 3/23/21 4:15:*32.389* AM jute.maxbuffer value is x Bytes > 3/23/21 4:15:*35.395* AM Client successfully logged in. > 3/23/21 4:15:35.396 AM TGT refresh sleeping until: Wed Mar 24 00:34:31 GMT > 2021 > 3/23/21 4:15:35.396 AM TGT refresh thread started. > 3/23/21 4:15:35.396 AM Client will use GSSAPI as SASL mechanism. > 3/23/21 4:15:35.396 AM TGT expires: xxx Mar xx 04:15:35 GMT > 2021 > 3/23/21 4:15:35.396 AM TGT valid starting at: xxx Mar xx 04:15:35 GMT > 2021 > 3/23/21 4:15:*35.397* AM *Opening socket connection* to server x:2181. > Will attempt to SASL-authenticate using Login Context section 'Client' > 3/23/21 4:15:*35.397* AM *Client session timed out, have not heard from > server in* *3008ms* for sessionid 0x0 > 3/23/21 4:15:35.397 AM Client session timed out, have not heard from server > in 3008ms for sessionid 0x0, closing socket connection and attempting > reconnect > 3/23/21 4:15:35.498 AM TGT renewal thread has been interrupted and will exit. > 3/23/21 4:15:38.503 AM Client successfully logged in. > 3/23/21 4:15:38.503 AM TGT expires: xxx Mar xx 04:15:38 GMT > 2021 > 3/23/21 4:15:38.503 AM Client will use GSSAPI as SASL mechanism. > 3/23/21 4:15:38.503 AM TGT valid starting at: xxx Mar xx 04:15:38 GMT > 2021 > 3/23/21 4:15:38.503 AM TGT refresh thread started. > 3/23/21 4:15:38.503 AM TGT refresh sleeping until: Wed Mar 24 00:10:10 GMT > 2021 > 3/23/21 4:15:38.506 AM Opening socket connection to server x:2181. Will > attempt to SASL-authenticate using Login Context section 'Client' > 3/23/21 4:15:38.506 AM Client session timed out, have not heard from server > in 3009ms for sessionid 0x0, closing socket connection and attempting > reconnect > 3/23/21 4:15:38.506 AM Client session timed out, have not heard from server > in 3009ms for sessionid 0x0 > 3/23/21 4:15:38.606 AM TGT renewal thread has been interrupted and will exit. > 3/23/21 4:15:41.610 AM Client successfully logged in. > 3/23/21 4:15:41.611 AM TGT refresh sleeping until: xxx Mar xx 23:42:03 GMT > 2021 > 3/23/21 4:15:41.611 AM Client will use GSSAPI as SASL mechanism. > 3/23/21 4:15:41.611 AM TGT valid starting at: xxx Mar xx 04:15:41 GMT > 2021 > 3/23/21 4:15:41.611 AM TGT expires: xxx Mar xx 04:15:41 GMT > 2021 > 3/23/21 4:15:41.611 AM TGT refresh thread started. > 3/23/21 4:15:41.612 AM Opening socket connection to server x:2181. Will > attempt to SASL-authenticate using Login Context section 'Client' > 3/23/21 4:15:41.613 AM Client session timed out, have not heard from server > in 3006ms for sessionid 0x0 > 3/23/21 4:15:41.613 AM Client session timed out, have not heard from server > in 3006ms for sessionid 0x0, closing socket connection and attempting > reconnect -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3887) In SSL-only server zkServer.sh status command should use secureClientPortAddress instead of clientPortAddress
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308607#comment-17308607 ] Mohammad Arshad commented on ZOOKEEPER-3887: I created SSL certificate for test with CN=host1, ZK server was not starting as server by default binds on localhost. It was failing with certificate_unknown error. Configured secureClientPortAddress=host1 now ZK server started successfully but zkServer.sh status command started failing because this command was using localhost as clientPortAddress was not configured Summited changes in the PR so status command uses configured secureClientPortAddress value instead of clientPortAddress value. > In SSL-only server zkServer.sh status command should use > secureClientPortAddress instead of clientPortAddress > - > > Key: ZOOKEEPER-3887 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3887 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When only SSL client port is enabled, zkServer.sh status command should use > secureClientPortAddress value instead of clientPortAddress. > As clientPortAddress is not configured, zkServer.sh status command tries to > connect to localhost and fails. > ZOOKEEPER-3818 has addressed the port issue, same way we should address the > host issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3887) In SSL-only server zkServer.sh status command should use secureClientPortAddress instead of clientPortAddress
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3887: --- Fix Version/s: 3.7.1 3.6.3 > In SSL-only server zkServer.sh status command should use > secureClientPortAddress instead of clientPortAddress > - > > Key: ZOOKEEPER-3887 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3887 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0, 3.7.1 > > Time Spent: 10m > Remaining Estimate: 0h > > When only SSL client port is enabled, zkServer.sh status command should use > secureClientPortAddress value instead of clientPortAddress. > As clientPortAddress is not configured, zkServer.sh status command tries to > connect to localhost and fails. > ZOOKEEPER-3818 has addressed the port issue, same way we should address the > host issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3887) In SSL-only server zkServer.sh status command should use secureClientPortAddress instead of clientPortAddress
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3887: --- Affects Version/s: 3.6.2 > In SSL-only server zkServer.sh status command should use > secureClientPortAddress instead of clientPortAddress > - > > Key: ZOOKEEPER-3887 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3887 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.6.2 >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0, 3.7.1 > > Time Spent: 10m > Remaining Estimate: 0h > > When only SSL client port is enabled, zkServer.sh status command should use > secureClientPortAddress value instead of clientPortAddress. > As clientPortAddress is not configured, zkServer.sh status command tries to > connect to localhost and fails. > ZOOKEEPER-3818 has addressed the port issue, same way we should address the > host issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4251) Flaky test: org.apache.zookeeper.test.WatcherTest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-4251: --- Fix Version/s: 3.7.1 > Flaky test: org.apache.zookeeper.test.WatcherTest > - > > Key: ZOOKEEPER-4251 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4251 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0, 3.7.1 > > Attachments: image-2021-03-16-12-24-27-480.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Flakyness=73.3% (11 / 15) > !image-2021-03-16-12-24-27-480.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-4251) Flaky test: org.apache.zookeeper.test.WatcherTest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-4251: -- Assignee: Mohammad Arshad > Flaky test: org.apache.zookeeper.test.WatcherTest > - > > Key: ZOOKEEPER-4251 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4251 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0, 3.7.1 > > Attachments: image-2021-03-16-12-24-27-480.png > > Time Spent: 2h > Remaining Estimate: 0h > > Flakyness=73.3% (11 / 15) > !image-2021-03-16-12-24-27-480.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4266) Correct ZooKeeper version in documentation header
Mohammad Arshad created ZOOKEEPER-4266: -- Summary: Correct ZooKeeper version in documentation header Key: ZOOKEEPER-4266 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4266 Project: ZooKeeper Issue Type: Bug Components: documentation Reporter: Mohammad Arshad Assignee: Mohammad Arshad Fix For: 3.8.0, 3.7.1 Attachments: image-2021-03-28-22-25-39-949.png Both Master and branch-3.7 documentation header have ZooKeeper version as 3.6. These should be changed to 3.8 and 3.7 for master and branch-3.7 respectively Master documentation currently: !image-2021-03-28-22-25-39-949.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-4270) Flaky test: QuorumPeerMainTest#testLeaderOutOfView
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-4270.
Resolution: Fixed
Issue resolved by pull request 1665
[https://github.com/apache/zookeeper/pull/1665]
> Flaky test: QuorumPeerMainTest#testLeaderOutOfView
> --
>
> Key: ZOOKEEPER-4270
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4270
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: tests
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.8.0, 3.7.1, 3.6.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest#testLeaderOutOfView is
> flaky and often fails when I run it in local CI.
> Failure message:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest.testLeaderOutOfView(QuorumPeerMainTest.java:937)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4267) Fix check-style issues
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-4267:
---
Attachment: screenshot-1.png
> Fix check-style issues
> --
>
> Key: ZOOKEEPER-4267
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4267
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.3, 3.8.0, 3.7.1
>
> Attachments: screenshot-1.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently there check-style issues reported in following files which need to
> be fixed
> {noformat}
> org.apache.zookeeper.common.CertificatesToPlayWith
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest
> {noformat}
> Because of these issues checkstyle:check check is failing in all the branches
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4267) Fix check-style issues
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311348#comment-17311348
]
Mohammad Arshad commented on ZOOKEEPER-4267:
!screenshot-1.png!
> Fix check-style issues
> --
>
> Key: ZOOKEEPER-4267
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4267
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.3, 3.8.0, 3.7.1
>
> Attachments: screenshot-1.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently there check-style issues reported in following files which need to
> be fixed
> {noformat}
> org.apache.zookeeper.common.CertificatesToPlayWith
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest
> {noformat}
> Because of these issues checkstyle:check check is failing in all the branches
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4270) Flaky test: QuorumPeerMainTest#testLeaderOutOfView
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311441#comment-17311441
]
Mohammad Arshad commented on ZOOKEEPER-4270:
Thanks [~eolivelli] for the review.
> Flaky test: QuorumPeerMainTest#testLeaderOutOfView
> --
>
> Key: ZOOKEEPER-4270
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4270
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: tests
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.3, 3.8.0, 3.7.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest#testLeaderOutOfView is
> flaky and often fails when I run it in local CI.
> Failure message:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest.testLeaderOutOfView(QuorumPeerMainTest.java:937)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4267) Fix check-style issues
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311350#comment-17311350
]
Mohammad Arshad commented on ZOOKEEPER-4267:
Even though issues in CertificatesToPlayWith.java are suppressed
{noformat}
{noformat}
Somehow not honored in my environment.
As these issues are fixable, better to fix it
> Fix check-style issues
> --
>
> Key: ZOOKEEPER-4267
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4267
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.3, 3.8.0, 3.7.1
>
> Attachments: screenshot-1.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently there check-style issues reported in following files which need to
> be fixed
> {noformat}
> org.apache.zookeeper.common.CertificatesToPlayWith
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest
> {noformat}
> Because of these issues checkstyle:check check is failing in all the branches
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4267) Fix check-style issues
Mohammad Arshad created ZOOKEEPER-4267:
--
Summary: Fix check-style issues
Key: ZOOKEEPER-4267
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4267
Project: ZooKeeper
Issue Type: Bug
Reporter: Mohammad Arshad
Assignee: Mohammad Arshad
Fix For: 3.6.3, 3.8.0, 3.7.1
Currently there check-style issues reported in following files which need to be
fixed
{noformat}
org.apache.zookeeper.common.CertificatesToPlayWith
org.apache.zookeeper.server.quorum.QuorumPeerMainTest
{noformat}
Because of these issues checkstyle:check check is failing in all the branches
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4267) Fix check-style issues
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-4267:
---
Description:
Currently there check-style issues reported in following files which need to be
fixed
{noformat}
org.apache.zookeeper.common.CertificatesToPlayWith
org.apache.zookeeper.server.quorum.QuorumPeerMainTest
{noformat}
Because of these issues checkstyle:check check is failing in all the branches
was:
Currently there check-style issues reported in following files which need to be
fixed
{noformat}
org.apache.zookeeper.common.CertificatesToPlayWith
org.apache.zookeeper.server.quorum.QuorumPeerMainTest
{noformat}
Because of these issues checkstyle:check check is failing in all the branches
!image-2021-03-29-13-20-51-447.png!
> Fix check-style issues
> --
>
> Key: ZOOKEEPER-4267
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4267
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Fix For: 3.6.3, 3.8.0, 3.7.1
>
>
> Currently there check-style issues reported in following files which need to
> be fixed
> {noformat}
> org.apache.zookeeper.common.CertificatesToPlayWith
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest
> {noformat}
> Because of these issues checkstyle:check check is failing in all the branches
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4267) Fix check-style issues
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-4267:
---
Description:
Currently there check-style issues reported in following files which need to be
fixed
{noformat}
org.apache.zookeeper.common.CertificatesToPlayWith
org.apache.zookeeper.server.quorum.QuorumPeerMainTest
{noformat}
Because of these issues checkstyle:check check is failing in all the branches
!image-2021-03-29-13-20-51-447.png!
was:
Currently there check-style issues reported in following files which need to be
fixed
{noformat}
org.apache.zookeeper.common.CertificatesToPlayWith
org.apache.zookeeper.server.quorum.QuorumPeerMainTest
{noformat}
Because of these issues checkstyle:check check is failing in all the branches
> Fix check-style issues
> --
>
> Key: ZOOKEEPER-4267
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4267
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Fix For: 3.6.3, 3.8.0, 3.7.1
>
>
> Currently there check-style issues reported in following files which need to
> be fixed
> {noformat}
> org.apache.zookeeper.common.CertificatesToPlayWith
> org.apache.zookeeper.server.quorum.QuorumPeerMainTest
> {noformat}
> Because of these issues checkstyle:check check is failing in all the branches
> !image-2021-03-29-13-20-51-447.png!
>
--
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 ] Mohammad Arshad updated ZOOKEEPER-4241: --- Fix Version/s: (was: 3.6.3) > 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.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] [Created] (ZOOKEEPER-4269) acceptedEpoch.tmp rename failure will cause server startup error
Mohammad Arshad created ZOOKEEPER-4269: -- Summary: acceptedEpoch.tmp rename failure will cause server startup error Key: ZOOKEEPER-4269 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4269 Project: ZooKeeper Issue Type: Bug Reporter: Mohammad Arshad Assignee: Mohammad Arshad accepted epoch is first written to temporary file acceptedEpoch.tmp then this file is renamed to acceptedEpoch. Failure, either because of exception or power-off, in renaming the acceptedEpoch.tmp file will cause server startup error with message "The current epoch, x, is older than the last zxid y" To handle this scenario we should read accepted epoch from this temp file as well. For more context, refer https://github.com/apache/zookeeper/pull/1109 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4269) acceptedEpoch.tmp rename failure will cause server startup error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-4269: --- Fix Version/s: 3.7.1 3.8.0 3.6.3 > acceptedEpoch.tmp rename failure will cause server startup error > > > Key: ZOOKEEPER-4269 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4269 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0, 3.7.1 > > Time Spent: 10m > Remaining Estimate: 0h > > accepted epoch is first written to temporary file acceptedEpoch.tmp then this > file is renamed to acceptedEpoch. > Failure, either because of exception or power-off, in renaming the > acceptedEpoch.tmp file will cause server startup error with message "The > current epoch, x, is older than the last zxid y" > To handle this scenario we should read accepted epoch from this temp file as > well. > For more context, refer https://github.com/apache/zookeeper/pull/1109 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-4269) acceptedEpoch.tmp rename failure will cause server startup error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-4269. Resolution: Fixed Issue resolved by pull request 1668 [https://github.com/apache/zookeeper/pull/1668] > acceptedEpoch.tmp rename failure will cause server startup error > > > Key: ZOOKEEPER-4269 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4269 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.8.0, 3.7.1, 3.6.3 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > accepted epoch is first written to temporary file acceptedEpoch.tmp then this > file is renamed to acceptedEpoch. > Failure, either because of exception or power-off, in renaming the > acceptedEpoch.tmp file will cause server startup error with message "The > current epoch, x, is older than the last zxid y" > To handle this scenario we should read accepted epoch from this temp file as > well. > For more context, refer https://github.com/apache/zookeeper/pull/1109 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4269) acceptedEpoch.tmp rename failure will cause server startup error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312713#comment-17312713 ] Mohammad Arshad commented on ZOOKEEPER-4269: Thanks [~eolivelli], [~ztzg] for the reviews. > acceptedEpoch.tmp rename failure will cause server startup error > > > Key: ZOOKEEPER-4269 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4269 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.8.0, 3.7.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > accepted epoch is first written to temporary file acceptedEpoch.tmp then this > file is renamed to acceptedEpoch. > Failure, either because of exception or power-off, in renaming the > acceptedEpoch.tmp file will cause server startup error with message "The > current epoch, x, is older than the last zxid y" > To handle this scenario we should read accepted epoch from this temp file as > well. > For more context, refer https://github.com/apache/zookeeper/pull/1109 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4272) Upgrade Netty library to > 4.1.60 due to security vulnerability CVE-2021-21295
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312488#comment-17312488 ] Mohammad Arshad commented on ZOOKEEPER-4272: Thanks [~ayushmantri] for the PRs Thanks [~eolivelli] for the reviews. > Upgrade Netty library to > 4.1.60 due to security vulnerability CVE-2021-21295 > -- > > Key: ZOOKEEPER-4272 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4272 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.6.2 >Reporter: Dominique Mongelli >Assignee: Ayush Mantri >Priority: Major > Labels: pull-request-available > Fix For: 3.5.10, 3.6.3, 3.8.0, 3.7.1 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Our security tool raised the following security flaw on zookeeper 3.6.2: > [https://nvd.nist.gov/vuln/detail/CVE-2021-21295] > It is a vulnerability related to jar *netty-codec-4.1.50.Final.jar*. > Based on netty issue tracker, the vulnerability is fixed in 4.1.60.Final: > [https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (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 reassigned ZOOKEEPER-4205: -- Assignee: Amichai Rothman > 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 >Assignee: Amichai Rothman >Priority: Major > Labels: pull-request-available > Fix For: 3.6.3, 3.7.0, 3.8.0 > > 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] [Commented] (ZOOKEEPER-3798) remove the useless code in the ProposalRequestProcessor#processRequest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314402#comment-17314402
]
Mohammad Arshad commented on ZOOKEEPER-3798:
Update fix version from 3.6.3 to 3.8.0,3.7.1 as changes are not present in
branch 3.6
> remove the useless code in the ProposalRequestProcessor#processRequest
> --
>
> Key: ZOOKEEPER-3798
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3798
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Ling Mao
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.8.0,3.7.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> remove the following useless codes in the
> ProposalRequestProcessor#processRequest
> {code:java}
> public void processRequest(Request request) throws RequestProcessorException {
> // LOG.warn("Ack>>> cxid = " + request.cxid + " type = " +
> // request.type + " id = " + request.sessionId);
> // request.addRQRec(">prop");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3798) remove the useless code in the ProposalRequestProcessor#processRequest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-3798:
---
Fix Version/s: (was: 3.6.3)
3.8.0,3.7.1
> remove the useless code in the ProposalRequestProcessor#processRequest
> --
>
> Key: ZOOKEEPER-3798
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3798
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Ling Mao
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.8.0,3.7.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> remove the following useless codes in the
> ProposalRequestProcessor#processRequest
> {code:java}
> public void processRequest(Request request) throws RequestProcessorException {
> // LOG.warn("Ack>>> cxid = " + request.cxid + " type = " +
> // request.type + " id = " + request.sessionId);
> // request.addRQRec(">prop");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3841) remove useless codes in the Leader.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-3841:
---
Fix Version/s: (was: 3.6.3)
3.7.1,3.8.0
> remove useless codes in the Leader.java
> ---
>
> Key: ZOOKEEPER-3841
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3841
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Ling Mao
>Priority: Minor
> Fix For: 3.7.1,3.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> - There are some useless code in the Leader.java which were comment out.
> - Pls recheck all the things in this class to clear up
> e.g:
> {code:java}
> // Everything is a go, simply start counting the ticks
> // WARNING: I couldn't find any wait statement on a synchronized
> // block that would be notified by this notifyAll() call, so
> // I commented it out
> //synchronized (this) {
> //notifyAll();
> //}
> {code}
> {code:java}
> //turnOffFollowers();
> {code}
> {code:java}
> //LOG.warn("designated leader is: " + designatedLeader);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3841) remove useless codes in the Leader.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314403#comment-17314403
]
Mohammad Arshad commented on ZOOKEEPER-3841:
Update fix version from 3.6.3 to 3.8.0,3.7.1 as changes are not present in
branch 3.6
> remove useless codes in the Leader.java
> ---
>
> Key: ZOOKEEPER-3841
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3841
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Ling Mao
>Priority: Minor
> Fix For: 3.7.1,3.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> - There are some useless code in the Leader.java which were comment out.
> - Pls recheck all the things in this class to clear up
> e.g:
> {code:java}
> // Everything is a go, simply start counting the ticks
> // WARNING: I couldn't find any wait statement on a synchronized
> // block that would be notified by this notifyAll() call, so
> // I commented it out
> //synchronized (this) {
> //notifyAll();
> //}
> {code}
> {code:java}
> //turnOffFollowers();
> {code}
> {code:java}
> //LOG.warn("designated leader is: " + designatedLeader);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3934) upgrade dependency-check to version 6.0.0
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3934: --- Fix Version/s: (was: 3.6.3) (was: 3.7.0) > upgrade dependency-check to version 6.0.0 > - > > Key: ZOOKEEPER-3934 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3934 > Project: ZooKeeper > Issue Type: Improvement > Components: build, security >Affects Versions: 3.7.0, 3.5.8, 3.6.2 >Reporter: Patrick D. Hunt >Assignee: Patrick D. Hunt >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > 6.0.0 is now available. I verified it with 3.5, 3.6,3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3931) "zkServer.sh version" returns a trailing dash
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314410#comment-17314410
]
Mohammad Arshad commented on ZOOKEEPER-3931:
Created https://issues.apache.org/jira/browse/ZOOKEEPER-4273 to forward port in
master branch-3.7
> "zkServer.sh version" returns a trailing dash
> -
>
> Key: ZOOKEEPER-3931
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3931
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Enrico Olivelli
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When you run zkServer.sh version the result includes a few spam lines and the
> version reports a trailing dash
> {noformat}
> bin/zkServer.sh version
> ZooKeeper JMX enabled by default
> Using config: /xxx/bin/../conf/zoo.cfg
> Apache ZooKeeper, version 3.6.2- 09/04/2020 12:44 GMT
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3931) "zkServer.sh version" returns a trailing dash
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-3931.
Fix Version/s: 3.6.3
Resolution: Fixed
> "zkServer.sh version" returns a trailing dash
> -
>
> Key: ZOOKEEPER-3931
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3931
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Enrico Olivelli
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When you run zkServer.sh version the result includes a few spam lines and the
> version reports a trailing dash
> {noformat}
> bin/zkServer.sh version
> ZooKeeper JMX enabled by default
> Using config: /xxx/bin/../conf/zoo.cfg
> Apache ZooKeeper, version 3.6.2- 09/04/2020 12:44 GMT
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3980) Fix Jenkinsfiles with new tool names
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3980: --- Fix Version/s: 3.8.0 3.6.3 > Fix Jenkinsfiles with new tool names > > > Key: ZOOKEEPER-3980 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3980 > Project: ZooKeeper > Issue Type: Task > Components: build-infrastructure >Affects Versions: 3.7.0 >Reporter: Enrico Olivelli >Assignee: Enrico Olivelli >Priority: Blocker > Labels: pull-request-available > Fix For: 3.6.3, 3.7.0, 3.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3992) addWatch api should check the null watch
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad updated ZOOKEEPER-3992:
---
Fix Version/s: 3.8.0
3.6.3
> addWatch api should check the null watch
>
>
> Key: ZOOKEEPER-3992
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3992
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Reporter: Ling Mao
>Assignee: Damien Diederen
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.3, 3.7.0, 3.8.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> {code:java}
> public void addWatch(String basePath, Watcher watcher, AddWatchMode mode)
> throws KeeperException, InterruptedException {
> PathUtils.validatePath(basePath);
> String serverPath = prependChroot(basePath);
> RequestHeader h = new RequestHeader();
> h.setType(ZooDefs.OpCode.addWatch);
> AddWatchRequest request = new AddWatchRequest(serverPath, mode.getMode());
> ReplyHeader r = cnxn.submitRequest(h, request, new ErrorResponse(),
>
> {code}
> we need to _*validateWatcher(watcher)*_ to ** avoid the case:
> {code:java}
> zk.addWatch("/a/b", null, PERSISTENT_RECURSIVE);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3933) owasp failing with json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-3933: -- Assignee: (was: Mohammad Arshad) > owasp failing with json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712 > --- > > Key: ZOOKEEPER-3933 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3933 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.7.0, 3.5.8, 3.6.2 >Reporter: Patrick D. Hunt >Priority: Blocker > Fix For: 3.6.3, 3.7.0 > > > dependency-check is failing with: > json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3933) owasp failing with json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-3933: -- Assignee: Mohammad Arshad > owasp failing with json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712 > --- > > Key: ZOOKEEPER-3933 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3933 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.7.0, 3.5.8, 3.6.2 >Reporter: Patrick D. Hunt >Assignee: Mohammad Arshad >Priority: Blocker > Fix For: 3.6.3, 3.7.0 > > > dependency-check is failing with: > json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4273) Forward port ZOOKEEPER-3931: "zkServer.sh version" returns a trailing dash
Mohammad Arshad created ZOOKEEPER-4273:
--
Summary: Forward port ZOOKEEPER-3931: "zkServer.sh version"
returns a trailing dash
Key: ZOOKEEPER-4273
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4273
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.7.1
Reporter: Mohammad Arshad
When you run zkServer.sh version the result includes a few spam lines and the
version reports a trailing dash
{noformat}
bin/zkServer.sh version
ZooKeeper JMX enabled by default
Using config: /xxx/bin/../conf/zoo.cfg
Apache ZooKeeper, version 3.6.2- 09/04/2020 12:44 GMT
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3957) Create Owasp check build on new Jenkins instance
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3957: --- Fix Version/s: 3.8.0 3.6.3 > Create Owasp check build on new Jenkins instance > > > Key: ZOOKEEPER-3957 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3957 > Project: ZooKeeper > Issue Type: Task > Components: build >Reporter: Andor Molnar >Assignee: Andor Molnar >Priority: Major > Fix For: 3.6.3, 3.7.0, 3.8.0 > > Time Spent: 50m > Remaining Estimate: 0h > > We haven't migrated the owasp build to the new instance yet. > Need to create a new multi-branch Pipeline job here: > https://ci-hadoop.apache.org/view/ZooKeeper/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3931) "zkServer.sh version" returns a trailing dash
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314411#comment-17314411
]
Mohammad Arshad commented on ZOOKEEPER-3931:
Thanks [~Suraj Naik] for your contribution, Added you as a contributor
> "zkServer.sh version" returns a trailing dash
> -
>
> Key: ZOOKEEPER-3931
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3931
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Enrico Olivelli
>Assignee: Suraj Naik
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When you run zkServer.sh version the result includes a few spam lines and the
> version reports a trailing dash
> {noformat}
> bin/zkServer.sh version
> ZooKeeper JMX enabled by default
> Using config: /xxx/bin/../conf/zoo.cfg
> Apache ZooKeeper, version 3.6.2- 09/04/2020 12:44 GMT
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3931) "zkServer.sh version" returns a trailing dash
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad reassigned ZOOKEEPER-3931:
--
Assignee: Suraj Naik
> "zkServer.sh version" returns a trailing dash
> -
>
> Key: ZOOKEEPER-3931
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3931
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Enrico Olivelli
>Assignee: Suraj Naik
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When you run zkServer.sh version the result includes a few spam lines and the
> version reports a trailing dash
> {noformat}
> bin/zkServer.sh version
> ZooKeeper JMX enabled by default
> Using config: /xxx/bin/../conf/zoo.cfg
> Apache ZooKeeper, version 3.6.2- 09/04/2020 12:44 GMT
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3774) Close quorum socket asynchronously on the leader to avoid ping being blocked by long socket closing time
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad updated ZOOKEEPER-3774: --- Fix Version/s: (was: 3.6.3) 3.7.1 3.8.0 > Close quorum socket asynchronously on the leader to avoid ping being blocked > by long socket closing time > > > Key: ZOOKEEPER-3774 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3774 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Jie Huang >Assignee: Jie Huang >Priority: Minor > Labels: pull-request-available > Fix For: 3.8.0, 3.7.1 > > Time Spent: 3h > Remaining Estimate: 0h > > In ZOOKEEPER-3574 we close the quorum sockets on followers asynchronously > when a leader is partitioned away so the shutdown process will not be stalled > by long socket closing time and the followers can quickly establish a new > quorum to serve client requests. > We've found that the long socket closing time can cause trouble on the leader > too when a follower is partitioned away if the partition is detected by > PingLaggingDetector. When the ping thread detects partition, it tries to > disconnect the follower. If the socket closing time is long, the ping thread > will be blocked and no ping is sent to any follower--even the ones still > connected to the leader--since the ping thread is responsible for sending > pings to all followers. When followers don't receive pings, they don't send > ping response. When the leader don't receive ping response, the sessions > expire. > To prevent good sessions from expiring, we need to close the socket > asynchronously on the leader too. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3774) Close quorum socket asynchronously on the leader to avoid ping being blocked by long socket closing time
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314401#comment-17314401 ] Mohammad Arshad commented on ZOOKEEPER-3774: Update fix version from 3.6.3 to 3.8.0,3.7.1 as changes are not present in branch 3.6 > Close quorum socket asynchronously on the leader to avoid ping being blocked > by long socket closing time > > > Key: ZOOKEEPER-3774 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3774 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Reporter: Jie Huang >Assignee: Jie Huang >Priority: Minor > Labels: pull-request-available > Fix For: 3.8.0, 3.7.1 > > Time Spent: 3h > Remaining Estimate: 0h > > In ZOOKEEPER-3574 we close the quorum sockets on followers asynchronously > when a leader is partitioned away so the shutdown process will not be stalled > by long socket closing time and the followers can quickly establish a new > quorum to serve client requests. > We've found that the long socket closing time can cause trouble on the leader > too when a follower is partitioned away if the partition is detected by > PingLaggingDetector. When the ping thread detects partition, it tries to > disconnect the follower. If the socket closing time is long, the ping thread > will be blocked and no ping is sent to any follower--even the ones still > connected to the leader--since the ping thread is responsible for sending > pings to all followers. When followers don't receive pings, they don't send > ping response. When the leader don't receive ping response, the sessions > expire. > To prevent good sessions from expiring, we need to close the socket > asynchronously on the leader too. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
