[jira] [Assigned] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko reassigned ZOOKEEPER-3792:
---
Assignee: Mate Szalay-Beko
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Assignee: Mate Szalay-Beko
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105138#comment-17105138
]
Mate Szalay-Beko commented on ZOOKEEPER-3792:
-
Thanks [~tison], I will try to fix the website generation script, and also
trying to fix the issue for the older releases (by hardcoding the new link in
the old released documentation both on the {{website}} and {{asf-side}}
branches to avoid these changes to be overwritten)
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zili Chen reassigned ZOOKEEPER-3792:
Assignee: (was: Zili Chen)
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105100#comment-17105100
]
Zili Chen edited comment on ZOOKEEPER-3792 at 5/12/20, 5:46 AM:
Hi [~symat]! You're the release manager so I think it would be better you take
over the ticket for verifying it in the release process.
You can make use of the linked PR whose idea is mainly "generate aggregate java
apidoc". FYI, previously we only delivered zookeeper-server java apidoc, and
the manner seems changed with
ZOOKEEPER-3369(a2aecb9acc420c95f60b6649ffcbd4e0184cc0cd).
was (Author: tison):
Hi [~symat]! You're the release manager so I think it would be better you take
over the ticker for verifying it in the release process.
You can make use of the linked PR whose idea is mainly "generate aggregate java
apidoc". FYI, previously we only delivered zookeeper-server java apidoc, and
the manner seems changed with
ZOOKEEPER-3369(a2aecb9acc420c95f60b6649ffcbd4e0184cc0cd).
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105100#comment-17105100
]
Zili Chen edited comment on ZOOKEEPER-3792 at 5/12/20, 5:46 AM:
Hi [~symat]! You're the release manager so I think it would be better you take
over the ticker for verifying it in the release process.
You can make use of the linked PR whose idea is mainly "generate aggregate java
apidoc". FYI, previously we only delivered zookeeper-server java apidoc, and
the manner seems changed with
ZOOKEEPER-3369(a2aecb9acc420c95f60b6649ffcbd4e0184cc0cd).
was (Author: tison):
Hi [~symat]! You're the release manager and I think it would be better you take
over the ticker for verifying it in the release process.
You can make use of the linked PR whose idea is mainly "generate aggregate java
apidoc". FYI, previously we only delivered zookeeper-server java apidoc, and
the manner seems changed with
ZOOKEEPER-3369(a2aecb9acc420c95f60b6649ffcbd4e0184cc0cd).
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105100#comment-17105100
]
Zili Chen commented on ZOOKEEPER-3792:
--
Hi [~symat]! You're the release manager and I think it would be better you take
over the ticker for verifying it in the release process.
You can make use of the linked PR whose idea is mainly "generate aggregate java
apidoc". FYI, previously we only delivered zookeeper-server java apidoc, and
the manner seems changed with
ZOOKEEPER-3369(a2aecb9acc420c95f60b6649ffcbd4e0184cc0cd).
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Assignee: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3825) StaticHostProvider.updateServerList address matching fails when connectString uses IP addresses
Rhys Yarranton created ZOOKEEPER-3825:
-
Summary: StaticHostProvider.updateServerList address matching
fails when connectString uses IP addresses
Key: ZOOKEEPER-3825
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3825
Project: ZooKeeper
Issue Type: Bug
Components: java client
Affects Versions: 3.5.5
Reporter: Rhys Yarranton
StaticHostProvider.updateServerList contains address matching like this:
{code:java}
for (InetSocketAddress addr : shuffledList) {
if (addr.getPort() == myServer.getPort()
&& ((addr.getAddress() != null
&& myServer.getAddress() != null && addr
.getAddress().equals(myServer.getAddress())) || addr
.getHostString().equals(myServer.getHostString(
{
myServerInNewConfig = true;
break;
}
}
{code}
The addresses in shuffledList are unresolved, while the current server address
in myServer is a resolved address (coming from a socket). If the connect
string is expressed in terms of IP addresses instead of host names, the two
won't match even when they represent the same server.
On the unresolved addresses, getAddress() is null, and getHostString() is
something like 1.2.3.4. On the resolved address, getAddress() is not null, and
getHostString() is (normally) the canonical host name corresponding to the IP
address.
As a result, this method tends to return true (reconfig) when it should not.
The calling method, ZooKeeper.updateServerList then closes the connection.
This might be written off as not too serious, except that Curator calls this
method when there is a connection state change. (Sometimes many times.) What
we observe is that when the client has to reconnect, _e.g._, if there is a
server failure, when it reconnects the socket gets closed right away. It goes
into a cycle of death until the session dies and a new one is created. (This
doesn't seem like very nice behaviour on Curator's behalf, but that's what's
out there.)
As a workaround, we implemented a custom HostProvider to filter out calls to
updateServerList which don't actually change the list.
As a permanent fix, instead of passing the current host based on the socket
remote address, may need to remember the unresolved address that was used to
connect. (Or use the original strings.)
Filed this against 3.5.5. Based on source control, it looks this still in
exists on master at time of writing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104633#comment-17104633
]
Zili Chen commented on ZOOKEEPER-3792:
--
Thanks for your attentions. It is mid-night in my timezone. Will take a look
tomorrow.
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Assignee: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104498#comment-17104498
]
Mate Szalay-Beko commented on ZOOKEEPER-3792:
-
> I noticed when doing the 3.5.7 release, and manually corrected the links
I think your manual correction has been updated since then, as it doesn't work
now: [https://zookeeper.apache.org/doc/r3.5.7/index.html]
> Anyway, we talked that probably jute api docs is not even necessary to link
yep, the Jute classes are auto-generated for our internal API, I don't see much
value to publish javadoc for them.
[~tison] do you plan to work on the fix? (this is our current procedure to
generate the website: [https://github.com/apache/zookeeper/tree/website] )
If you have no time for this right now, then do you mind if I take this over?
(although I don't think this is very high priority, nobody asked for the
javadocs, and we publish the source in maven central, so I think most of the
developers use their IDE to read it)
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Assignee: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104463#comment-17104463
]
Norbert Kalmár commented on ZOOKEEPER-3792:
---
The jute apidocs have been separated from "other" api docs. The directory
structure changed, and website template did not change with it. I noticed when
doing the 3.5.7 release, and manually corrected the links. We had a discussion
on dev list, which I can't find right now... maybe it was on slack?
Anyway, we talked that probably jute api docs is not even necessary to link.
Looks like we never got to the point to actually fix, sorry about that.
So the apidocs gets generated no problem, it's just the path that needs to be
updated.
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Assignee: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3824) ZooKeeper dynamic reconfig doesn't work with GSSAPI/SASL enabled Quorum authn/z
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajkiran Sura updated ZOOKEEPER-3824:
-
Description:
With 'DynamicReconfig' feature in v3.5.6, ideally the servers can be added and
removed without restarting ZooKeeper service on any of the nodes.
But, with Keberos (GSSAPI via SASL) enabled quorum
authentication/authorization, this is not possible. Because, when you try to
add a new server, it won't be able to connect to any of the members in the
ensemble and the data won't be synced. This is because all the members reject
it based on authorization. For this to make it work, we need to do 'reconfig',
then restart leader, the new member and rest of the members.
Is this the expected behavior with Quorum-auth + DynamicReconfig? Or am I
missing something here.
This is our basic quorum-auth config:
{quote}quorum.auth.serverRequireSasl=true
quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST
quorum.auth.enableSasl=true
quorum.auth.learner.saslLoginContext=QuorumLearner
quorum.auth.learnerRequireSasl=true
quorum.cnxn.threads.size=20
quorum.auth.server.saslLoginContext=QuorumServer
{quote}
FTR: I raised this question in [ZooKeeper-user
forum|http://zookeeper-user.578899.n2.nabble.com/ZooKeeper-dynamic-reconfig-issue-when-Quorum-authn-authz-is-enabled-td7584927.html]
and both Mate and Enrico suspect this to be a bug.
Also this is easily reproducible in a Kerbers (GSSAPI via SASL) enabled quorum
based ensemble.
Regards,
Rajkiran
was:
With 'DynamicReconfig' feature in v3.5.6, ideally the servers can be added and
removed without restarting ZooKeeper service on any of the nodes.
But, with Keberos (GSSAPI via SASL) enabled quorum
authentication/authorization, this is not possible. Because, when you try to
add a new server, it won't be able to connect to any of the members in the
ensemble and the data won't be synced. This is because all the members reject
it based on authorization. For this to make it work, we need to do 'reconfig',
then restart leader, the new member and rest of the members.
Is this the expected behavior with Quorum-auth + DynamicReconfig? Or am I
missing something here.
This is our basic quorum-auth config:
{quote}quorum.auth.serverRequireSasl=true
quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST
quorum.auth.enableSasl=true
quorum.auth.learner.saslLoginContext=QuorumLearner
quorum.auth.learnerRequireSasl=true
quorum.cnxn.threads.size=20
quorum.auth.server.saslLoginContext=QuorumServer
{quote}
FTR: I raised this question in [ZooKeeper-user
forum|[http://zookeeper-user.578899.n2.nabble.com/ZooKeeper-dynamic-reconfig-issue-when-Quorum-authn-authz-is-enabled-td7584927.html]]
and both Mate and Enrico suspect this to be a bug.
Also this is easily reproducible in a Kerbers (GSSAPI via SASL) enabled quorum
based ensemble.
Regards,
Rajkiran
> ZooKeeper dynamic reconfig doesn't work with GSSAPI/SASL enabled Quorum
> authn/z
> ---
>
> Key: ZOOKEEPER-3824
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3824
> Project: ZooKeeper
> Issue Type: Bug
> Components: kerberos, leaderElection, quorum, server
>Affects Versions: 3.5.6
> Environment: O.S. :- RHEL7
>Reporter: Rajkiran Sura
>Priority: Major
>
> With 'DynamicReconfig' feature in v3.5.6, ideally the servers can be added
> and removed without restarting ZooKeeper service on any of the nodes.
> But, with Keberos (GSSAPI via SASL) enabled quorum
> authentication/authorization, this is not possible. Because, when you try to
> add a new server, it won't be able to connect to any of the members in the
> ensemble and the data won't be synced. This is because all the members reject
> it based on authorization. For this to make it work, we need to do
> 'reconfig', then restart leader, the new member and rest of the members.
> Is this the expected behavior with Quorum-auth + DynamicReconfig? Or am I
> missing something here.
> This is our basic quorum-auth config:
> {quote}quorum.auth.serverRequireSasl=true
> quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST
> quorum.auth.enableSasl=true
> quorum.auth.learner.saslLoginContext=QuorumLearner
> quorum.auth.learnerRequireSasl=true
> quorum.cnxn.threads.size=20
> quorum.auth.server.saslLoginContext=QuorumServer
> {quote}
> FTR: I raised this question in [ZooKeeper-user
> forum|http://zookeeper-user.578899.n2.nabble.com/ZooKeeper-dynamic-reconfig-issue-when-Quorum-authn-authz-is-enabled-td7584927.html]
> and both Mate and Enrico suspect this to be a bug.
> Also this is easily reproducible in a Kerbers (GSSAPI via SASL) enabled
> quorum based ensemble.
>
> Regards,
> Rajkiran
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3824) ZooKeeper dynamic reconfig doesn't work with GSSAPI/SASL enabled Quorum authn/z
Rajkiran Sura created ZOOKEEPER-3824:
Summary: ZooKeeper dynamic reconfig doesn't work with GSSAPI/SASL
enabled Quorum authn/z
Key: ZOOKEEPER-3824
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3824
Project: ZooKeeper
Issue Type: Bug
Components: kerberos, leaderElection, quorum, server
Affects Versions: 3.5.6
Environment: O.S. :- RHEL7
Reporter: Rajkiran Sura
With 'DynamicReconfig' feature in v3.5.6, ideally the servers can be added and
removed without restarting ZooKeeper service on any of the nodes.
But, with Keberos (GSSAPI via SASL) enabled quorum
authentication/authorization, this is not possible. Because, when you try to
add a new server, it won't be able to connect to any of the members in the
ensemble and the data won't be synced. This is because all the members reject
it based on authorization. For this to make it work, we need to do 'reconfig',
then restart leader, the new member and rest of the members.
Is this the expected behavior with Quorum-auth + DynamicReconfig? Or am I
missing something here.
This is our basic quorum-auth config:
{quote}quorum.auth.serverRequireSasl=true
quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST
quorum.auth.enableSasl=true
quorum.auth.learner.saslLoginContext=QuorumLearner
quorum.auth.learnerRequireSasl=true
quorum.cnxn.threads.size=20
quorum.auth.server.saslLoginContext=QuorumServer
{quote}
FTR: I raised this question in [ZooKeeper-user
forum|[http://zookeeper-user.578899.n2.nabble.com/ZooKeeper-dynamic-reconfig-issue-when-Quorum-authn-authz-is-enabled-td7584927.html]]
and both Mate and Enrico suspect this to be a bug.
Also this is easily reproducible in a Kerbers (GSSAPI via SASL) enabled quorum
based ensemble.
Regards,
Rajkiran
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3792) Reconcile document site in 3.5.7 & 3.6.0
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104409#comment-17104409
]
Mate Szalay-Beko commented on ZOOKEEPER-3792:
-
I am not sure about the status of this ticket. But this is something we should
fix. Currently the link for the API docs is broken for both 3.6.1 and 3.5.7. I
am about to publish the website after 3.5.8, and we are still having this
issue. (CC: [~eolivelli] , [~nkalmar] )
> Reconcile document site in 3.5.7 & 3.6.0
>
>
> Key: ZOOKEEPER-3792
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3792
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.6.0, 3.5.7
>Reporter: Zili Chen
>Assignee: Zili Chen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After ZOOKEEPER-3369 we generate document in {{apidocs/}} instead of {{api/}}
> before. Moreover, the document site cannot proper linked to apidocs in
> 3.6.0(but in 3.5.7, thought it is wrong in {{website}} branch, it is manually
> corrected in {{asf-site}} branch}}.
> I propose we generate single aggregated document and place it under {{api/}}
> folder, as well as bumping website for the update.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3814) ZooKeeper caching of config
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104188#comment-17104188
]
Rajkiran Sura commented on ZOOKEEPER-3814:
--
{quote}The existence of the .next file indicates that a reconfiguration was
halted in the middle, before completing.
{quote}
Also, as I mentioned earlier, we had initially not enabled dynamicReconfig, so
not sure why the "dynamic.next" was coming into picture.
{quote}The standard way of changing the id would be removing the old id from
the cluster and adding the new one using one or more reconfig commands.
{quote}
FTR: We were trying to achieve this via legacy rolling restarts method. i.e.,
first remove old ID, do a rolling restart. Then, add new ID, do a rolling
restart. This worked for us perfectly fine(as in the newly added ID joined the
cluster and was serving upto-date data). But, then when a ZooKeeper failover
happened and this newly added ID became leader, we had problems (i.e., none of
the ZooKeeper members were serving the clients).
Thanks Mate and Alexander for looking into this.
> ZooKeeper caching of config
> ---
>
> Key: ZOOKEEPER-3814
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3814
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection, quorum, server
>Affects Versions: 3.5.6
>Reporter: Rajkiran Sura
>Assignee: Mate Szalay-Beko
>Priority: Major
>
> Hello,
> We recently upgraded our 5 node ZooKeeper ensemble from v3.4.8 to v3.5.6.
> Encountered no issues as such.
> This is how the ZooKeeper config looks like:
> {quote}tickTime=2000
> dataDir=/zookeeper-data/
> initLimit=5
> syncLimit=2
> maxClientCnxns=2048
> autopurge.snapRetainCount=3
> autopurge.purgeInterval=1
> 4lw.commands.whitelist=stat, ruok, conf, isro, mntr
> authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
> requireClientAuthScheme=sasl
> quorum.cnxn.threads.size=20
> quorum.auth.enableSasl=true
> quorum.auth.kerberos.servicePrincipal= zookeeper/_HOST
> quorum.auth.learnerRequireSasl=true
> quorum.auth.learner.saslLoginContext=QuorumLearner
> quorum.auth.serverRequireSasl=true
> quorum.auth.server.saslLoginContext=QuorumServer
> server.17=node1.foo.bar.com:2888:3888;2181
> server.19=node2.foo.bar.com:2888:3888;2181
> server.20=node3.foo.bar.com:2888:3888;2181
> server.21=node4.foo.bar.com:2888:3888;2181
> server.22=node5.bar.com:2888:3888;2181
> {quote}
> Post upgrade, we had to migrate server.22 on the same node, but with
> *FOO*.bar.com domain name due to kerberos referral issues. And, we used
> different server-identifier, i.e., *23* when we migrated. So, here is how the
> new config looked like:
> {quote}server.17=node1.foo.bar.com:2888:3888;2181
> server.19=node2.foo.bar.com:2888:3888;2181
> server.20=node3.foo.bar.com:2888:3888;2181
> server.21=node4.foo.bar.com:2888:3888;2181
> *server.23=node5.{color:#00875a}foo{color}.bar.com:2888:3888;2181*
> {quote}
> We restarted all the nodes in the ensemble with the above updated config. And
> the migrated node joined the quorum successfully and was serving all clients
> directly connected to it, without any issues.
> Recently, when a leader election happened,
> server.*23*=node5.foo.bar.com(migrated node) was chosen as Leader (as it has
> highest ID). But then, ZooKeeper was unable to serve any clients and *all*
> the servers were _somehow still_ trying to establish a channel to 22 (old DNS
> name: node5.bar.com) and were throwing below error in a loop:
> {quote}{{2020-05-02 01:43:03,026 [myid:23] - WARN
> [WorkerSender[myid=23]:QuorumPeer$QuorumServer@196] - Failed to resolve
> address: node4.bar.com}}
> {{java.net.UnknownHostException: node5.bar.com: Name or service not known}}
> {{ at java.base/java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)}}
> {{ at
> java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:929)}}
> {{ at
> java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1515)}}
> {{ at
> java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:848)}}
> {{ at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1505)}}
> {{ at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1364)}}
> {{ at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1298)}}
> {{ at java.base/java.net.InetAddress.getByName(InetAddress.java:1248)}}
> {{ at
> org.apache.zookeeper.server.quorum.QuorumPeer$QuorumServer.recreateSocketAddresses(QuorumPeer.java:194)}}
> {{ at
> org.apache.zookeeper.server.quorum.QuorumPeer.recreateSocketAddresses(QuorumPeer.java:774)}}
> {{ at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:701)}}
> {{ at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.to
[jira] [Created] (ZOOKEEPER-3823) Add a benchmark tool for testing watch feature performance
maoling created ZOOKEEPER-3823: -- Summary: Add a benchmark tool for testing watch feature performance Key: ZOOKEEPER-3823 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3823 Project: ZooKeeper Issue Type: New Feature Reporter: maoling Assignee: maoling -- This message was sent by Atlassian Jira (v8.3.4#803005)
