[jira] [Created] (ZOOKEEPER-3584) "NoAuth" error message is ambiguous
Lars Francke created ZOOKEEPER-3584: --- Summary: "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 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] [Updated] (ZOOKEEPER-3407) Update POM file with new information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated ZOOKEEPER-3407: Summary: Update POM file with new information (was: Update POM with new mailing lists) > Update POM file with new information > > > Key: ZOOKEEPER-3407 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3407 > Project: ZooKeeper > Issue Type: Task >Reporter: Lars Francke >Priority: Trivial > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3407) Update POM file with new information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated ZOOKEEPER-3407: Description: New mailing lists & Jenkins update > Update POM file with new information > > > Key: ZOOKEEPER-3407 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3407 > Project: ZooKeeper > Issue Type: Task >Reporter: Lars Francke >Priority: Trivial > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > New mailing lists & Jenkins update -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3407) Update POM with new mailing lists
Lars Francke created ZOOKEEPER-3407: --- Summary: Update POM with new mailing lists Key: ZOOKEEPER-3407 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3407 Project: ZooKeeper Issue Type: Task Reporter: Lars Francke -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3406) Update website for new mailing lists
Lars Francke created ZOOKEEPER-3406: --- Summary: Update website for new mailing lists Key: ZOOKEEPER-3406 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3406 Project: ZooKeeper Issue Type: Task Reporter: Lars Francke This updates the website to include information about issues@ and notifications@ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844602#comment-16844602 ] Lars Francke commented on ZOOKEEPER-1147: - Thanks for checking. Did you already create a follow-up ticket? If not I can do so. > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat >Priority: Major > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 observers. Majority of these clients are > read only - ie they do not do any updates or create ephemeral nodes. > In ZooKeeper today, the client creates a session and the session creation is > handled like any other update. In the above use case, the session create/drop > workload can easily overwhelm an ensemble. The following is a proposal for a > "local session", to support a larger number of connections. > 1. The idea is to introduce a new type of session - "local" session. A > "local" session doesn't have a full functionality of a normal session. > 2. Local sessions cannot create ephemeral nodes. > 3. Once a local session is lost, you cannot re-establish it using the > session-id/password. The session and its watches are gone for good. > 4. When a local session connects, the session info is only maintained > on the zookeeper server (in this case, an observer) that it is connected to. > The leader is not aware of the creation of such a session and there is no > state written to disk. > 5. The pings and expiration is handled by the server that the session > is connected to. > With the above changes, we can make ZooKeeper scale to a much larger number > of clients without making the core ensemble a bottleneck. > In terms of API, there are two options that are being considered > 1. Let the client specify at the connect time which kind of session do they > want. > 2. All sessions connect as local sessions and automatically get promoted to > global sessions when they do an operation that requires a global session > (e.g. creating an ephemeral node) > Chubby took the approach of lazily promoting all sessions to global, but I > don't think that would work in our case, where we want to keep sessions which > never create ephemeral nodes as always local. Option 2 would make it more > broadly usable but option 1 would be easier to implement. > We are thinking of implementing option 1 as the first cut. There would be a > client flag, IsLocalSession (much like the current readOnly flag) that would > be used to determine whether to create a local session or a global session. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844139#comment-16844139 ] Lars Francke commented on ZOOKEEPER-1147: - I just saw this in the release announcement for 3.5: Is there any documentation on this available? > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat >Priority: Major > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 observers. Majority of these clients are > read only - ie they do not do any updates or create ephemeral nodes. > In ZooKeeper today, the client creates a session and the session creation is > handled like any other update. In the above use case, the session create/drop > workload can easily overwhelm an ensemble. The following is a proposal for a > "local session", to support a larger number of connections. > 1. The idea is to introduce a new type of session - "local" session. A > "local" session doesn't have a full functionality of a normal session. > 2. Local sessions cannot create ephemeral nodes. > 3. Once a local session is lost, you cannot re-establish it using the > session-id/password. The session and its watches are gone for good. > 4. When a local session connects, the session info is only maintained > on the zookeeper server (in this case, an observer) that it is connected to. > The leader is not aware of the creation of such a session and there is no > state written to disk. > 5. The pings and expiration is handled by the server that the session > is connected to. > With the above changes, we can make ZooKeeper scale to a much larger number > of clients without making the core ensemble a bottleneck. > In terms of API, there are two options that are being considered > 1. Let the client specify at the connect time which kind of session do they > want. > 2. All sessions connect as local sessions and automatically get promoted to > global sessions when they do an operation that requires a global session > (e.g. creating an ephemeral node) > Chubby took the approach of lazily promoting all sessions to global, but I > don't think that would work in our case, where we want to keep sessions which > never create ephemeral nodes as always local. Option 2 would make it more > broadly usable but option 1 would be easier to implement. > We are thinking of implementing option 1 as the first cut. There would be a > client flag, IsLocalSession (much like the current readOnly flag) that would > be used to determine whether to create a local session or a global session. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
