[jira] [Created] (ZOOKEEPER-4815) custom the data format of /zookeeper/config
yangoofy created ZOOKEEPER-4815: --- Summary: custom the data format of /zookeeper/config Key: ZOOKEEPER-4815 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4815 Project: ZooKeeper Issue Type: Improvement Reporter: yangoofy When using QuorumMaj, I hope to support custom /zookeeper/config node data formats, such as server. x=xx. xx. xx. xx: 2888:3888: observer; 0.0.0.0:2181; Group1 server. y=xx. xx. xx. xx: 2888:3888: observer; 0.0.0.0:2181; Group2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ZOOKEEPER-4811) When configuring the IP address of the zk server on the client side to connect to zk, the connection establishment time is high
yangoofy created ZOOKEEPER-4811: --- Summary: When configuring the IP address of the zk server on the client side to connect to zk, the connection establishment time is high Key: ZOOKEEPER-4811 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4811 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.7.1, 3.7.0 Reporter: yangoofy When configuring the IP address of the zk server on the client side to connect to zk, the connection establishment time is high。Mainly because Obtaining the hostname of the address takes approximately 5 seconds. 3.4.6 has mechanism to safely avoid reverse DNS lookup，but 3.7 don't do that。 1.What's the reasone？ 2.Can we modify the method StaticHostProvider/resolve() to avoid reverse DNS lookup? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ZOOKEEPER-4788) high maxlatency
yangoofy created ZOOKEEPER-4788: --- Summary: high maxlatency Key: ZOOKEEPER-4788 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4788 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.7.1 Reporter: yangoofy We use Zookeeper as the registration center for microservices. Zookeeper uses the default configuration. Snapshot600m, with 70w ephemeral nodes. A single Zookeeper server is 56c128g and xmx16g. The number of client connections is 8k, and the number of watches is 400w. During the centralized start and stop time of the client, the maxlatency of the server is as high as 10 seconds. How can me optimize it？ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ZOOKEEPER-4765) high maxlatency & xid out of order
yangoofy created ZOOKEEPER-4765: --- Summary: high maxlatency & xid out of order Key: ZOOKEEPER-4765 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4765 Project: ZooKeeper Issue Type: Wish Reporter: yangoofy 1. We use Zookeeper as the registration center for microservices. Zookeeper uses the default configuration. Snapshot600m, with 70w ephemeral nodes. A single Zookeeper server is 56c128g and xmx16g. The number of client connections is 8k, and the number of watches is 400w. During the centralized start and stop time of the client, the maxlatency of the server is as high as 10 seconds. How can I optimize it? 2. Is it necessary for the Zookeeper client to receive a response before verifying the request sent first, otherwise an error will be reported as' xid out of order '? Can we modify it to send requests and responses based on xid matching instead of strong verification order? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ZOOKEEPER-3218) zk server reopened，the interval for observer connect to the new leader is too long，then session expired
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] yangoofy updated ZOOKEEPER-3218: Summary: zk server reopened，the interval for observer connect to the new leader is too long，then session expired (was: zk集群挂掉重启后，observer重新连上leader的时间间隔可能过长，导致客户端session失效) > zk server reopened，the interval for observer connect to the new leader is too > long，then session expired > --- > > Key: ZOOKEEPER-3218 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3218 > Project: ZooKeeper > Issue Type: Bug > Environment: win7 32bits > zookeeper 3.4.6、3.4.13 >Reporter: yangoofy >Priority: Major > > two participants、one observer，zkclient connect to observer。 > Then，close the two participants，the zookeeper server cloesed > Ten seconds later，reopen the two participants，and leader selected > > But the observer can't connect to the new leader immediately。Because in > lookForLeader, the observer use blockingQueue(recvqueue) to offer/poll > notifications，when the recvqueue is empty，poll from recvqueue will be > blocked，and timeout is 200ms，400ms，800ms60s。 > For example，09:59:59 observer poll notification，recvqueue was empty and > timeout was 60s；10:00:00 two participants reopened and reselected；10:00:59 > observer polled notification，connected to the new leader > But the maxSessionTimeout default to 40s。The session expired > - > Please improve it：observer should connect to the new leader as soon as > possible -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3218) zk集群挂掉重启后，observer重新连上leader的时间间隔可能过长，导致客户端session失效
yangoofy created ZOOKEEPER-3218: --- Summary: zk集群挂掉重启后，observer重新连上leader的时间间隔可能过长，导致客户端session失效 Key: ZOOKEEPER-3218 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3218 Project: ZooKeeper Issue Type: Bug Environment: win7 32bits zookeeper 3.4.6、3.4.13 Reporter: yangoofy two participants、one observer，zkclient connect to observer。 Then，close the two participants，the zookeeper server cloesed Ten seconds later，reopen the two participants，and leader selected But the observer can't connect to the new leader immediately。Because in lookForLeader, the observer use blockingQueue(recvqueue) to offer/poll notifications，when the recvqueue is empty，poll from recvqueue will be blocked，and timeout is 200ms，400ms，800ms60s。 For example，09:59:59 observer poll notification，recvqueue was empty and timeout was 60s；10:00:00 two participants reopened and reselected；10:00:59 observer polled notification，connected to the new leader But the maxSessionTimeout default to 40s。The session expired - Please improve it：observer should connect to the new leader as soon as possible -- This message was sent by Atlassian JIRA (v7.6.3#76005)
