[jira] [Commented] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14908912#comment-14908912 ] Chris Chen commented on ZOOKEEPER-2253: --- [~rgs] lemme know if you have any questions > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch, ZOOKEEPER-2253.patch, > ZOOKEEPER-2253.patch, zookeeper-2253-3.4.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14744562#comment-14744562 ] Chris Chen commented on ZOOKEEPER-2253: --- Yes, sorry, I meant to say The conditional check here is for a reply packet to update the last seen zxid. Because we match for a ping packet in another block that check is now superfluous. > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch, ZOOKEEPER-2253.patch, > ZOOKEEPER-2253.patch, zookeeper-2253-3.4.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-2253: -- Attachment: zookeeper-2253-3.4.patch Added patch for 3.4 branch. > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch, ZOOKEEPER-2253.patch, > ZOOKEEPER-2253.patch, zookeeper-2253-3.4.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-2253: -- Attachment: ZOOKEEPER-2253.patch Updated patch against HEAD. > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch, ZOOKEEPER-2253.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-2253: -- Attachment: ZOOKEEPER-2253.patch Arrgh patchy. > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch, ZOOKEEPER-2253.patch, > ZOOKEEPER-2253.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734019#comment-14734019 ] Chris Chen commented on ZOOKEEPER-2253: --- There is no last_zxid check since the zxid is -1 for pings right? This here is a test because in the C client the ping replies are "in order" but if this check wasn't there the C client would set the last zxid to -1. With this patch (hdr.xid != PING_XID) is guaranteed to be false, so. > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch, ZOOKEEPER-2253.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-2253: -- Attachment: ZOOKEEPER-2253.patch > C asserts ordering of ping requests, while Java client does not > --- > > Key: ZOOKEEPER-2253 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Chris Chen > Attachments: ZOOKEEPER-2253.patch > > > Affects C clients from 3.3 to trunk. > The Java client does not enforce ordering on ping requests. It merely updates > fields when a ping reply is received and schedules a new ping request when > necessary. > The C client actually enqueues the void response in the completion data > structure and pulls it off when it gets a response. > This sounds like an implementation detail (and it is, sort of), but if a > future server were to, say, send unsolicited ping replies to a client to > assert liveness, it would work fine against a Java client but would cause a C > client to fail the assertion in zookeeper_process, "assert(cptr)", line 2912, > zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1742) make check doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14720280#comment-14720280 ] Chris Chen commented on ZOOKEEPER-1742: --- I take that back, it looks like the solaris toolchain is using the GNU linker? make check doesn't work on macos -- Key: ZOOKEEPER-1742 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.5, 3.5.0 Reporter: Flavio Junqueira Assignee: Germán Blanco Fix For: 3.5.2, 3.6.0 Attachments: ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch There are two problems I have spotted when running make check with the C client. First, it complains that the sleep call is not defined in two test files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. Including unistd.h works. The second problem is with linker options. It complains that --wrap is not a valid. I'm not sure how to deal with this one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1742) make check doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14720274#comment-14720274 ] Chris Chen commented on ZOOKEEPER-1742: --- Any word? It looks like some work was done similar to this for ZOOKEEPER-1077 make check doesn't work on macos -- Key: ZOOKEEPER-1742 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.5, 3.5.0 Reporter: Flavio Junqueira Assignee: Germán Blanco Fix For: 3.5.2, 3.6.0 Attachments: ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742-3.4.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch, ZOOKEEPER-1742.patch There are two problems I have spotted when running make check with the C client. First, it complains that the sleep call is not defined in two test files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. Including unistd.h works. The second problem is with linker options. It complains that --wrap is not a valid. I'm not sure how to deal with this one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2253) C asserts ordering of ping requests, while Java client does not
Chris Chen created ZOOKEEPER-2253: - Summary: C asserts ordering of ping requests, while Java client does not Key: ZOOKEEPER-2253 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2253 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.5.0 Reporter: Chris Chen Affects C clients from 3.3 to trunk. The Java client does not enforce ordering on ping requests. It merely updates fields when a ping reply is received and schedules a new ping request when necessary. The C client actually enqueues the void response in the completion data structure and pulls it off when it gets a response. This sounds like an implementation detail (and it is, sort of), but if a future server were to, say, send unsolicited ping replies to a client to assert liveness, it would work fine against a Java client but would cause a C client to fail the assertion in zookeeper_process, assert(cptr), line 2912, zookeeper.c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1851) Follower and Observer Request Processors Do Not Forward create2 Requests
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14052010#comment-14052010 ] Chris Chen commented on ZOOKEEPER-1851: --- [~rakeshr] anything else you need? Follower and Observer Request Processors Do Not Forward create2 Requests Key: ZOOKEEPER-1851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1851 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.5.0 Reporter: Chris Chen Assignee: Thawan Kooburat Labels: patch Fix For: 3.5.0 Attachments: ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch Recent changes to the Observer and Follower Request Processors switch on the request opcode, but create2 is left out. This leads to a condition where the create2 request is passed to the CommitProcessor, but the leader never gets the request, the CommitProcessor can't find a matching request, so the client gets disconnected. Added tests as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1851) Follower and Observer Request Processors Do Not Forward create2 Requests
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1851: -- Attachment: ZOOKEEPER-1851.patch Change HashSet creation. Follower and Observer Request Processors Do Not Forward create2 Requests Key: ZOOKEEPER-1851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1851 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.5.0 Reporter: Chris Chen Assignee: Thawan Kooburat Labels: patch Fix For: 3.5.0 Attachments: ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch Recent changes to the Observer and Follower Request Processors switch on the request opcode, but create2 is left out. This leads to a condition where the create2 request is passed to the CommitProcessor, but the leader never gets the request, the CommitProcessor can't find a matching request, so the client gets disconnected. Added tests as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1851) Follower and Observer Request Processors Do Not Forward create2 Requests
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1851: -- Attachment: ZOOKEEPER-1851.patch Updated tests, fixed formatting. Follower and Observer Request Processors Do Not Forward create2 Requests Key: ZOOKEEPER-1851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1851 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.5.0 Reporter: Chris Chen Assignee: Thawan Kooburat Labels: patch Fix For: 3.5.0 Attachments: ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch Recent changes to the Observer and Follower Request Processors switch on the request opcode, but create2 is left out. This leads to a condition where the create2 request is passed to the CommitProcessor, but the leader never gets the request, the CommitProcessor can't find a matching request, so the client gets disconnected. Added tests as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: (was: ZOOKEEPER-1877.patch) Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Assignee: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: ZOOKEEPER-1877.patch Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Assignee: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043867#comment-14043867 ] Chris Chen commented on ZOOKEEPER-1877: --- Updated patch that handles corner cases. Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Assignee: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: (was: ZOOKEEPER-1877.patch) Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: ZOOKEEPER-1877.patch Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
Chris Chen created ZOOKEEPER-1877: - Summary: Malformed ACL Id can crash server with skipACL=yes Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: 411.patch Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Attachments: 411.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: ZOOKEEPER-1877.patch Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1877) Malformed ACL Id can crash server with skipACL=yes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1877: -- Attachment: (was: 411.patch) Malformed ACL Id can crash server with skipACL=yes -- Key: ZOOKEEPER-1877 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1877 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Chris Chen Attachments: ZOOKEEPER-1877.patch Because of the way fixupACL is written in PrepRequestProcessor, a request that feeds in an ACL with null members in the Id will cause a server with skipACL=yes to crash. A patch will be provided that re-introduces checks for well-formed ACLs even if skipACL is enabled. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1851) Follower and Observer Request Processors Do Not Forward create2 Requests
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1851: -- Attachment: ZOOKEEPER-1851.patch Re-formatted. Apparently git diffs don't fly here. Follower and Observer Request Processors Do Not Forward create2 Requests Key: ZOOKEEPER-1851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1851 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.5.0 Reporter: Chris Chen Labels: patch Attachments: ZOOKEEPER-1851.patch, ZOOKEEPER-1851.patch Recent changes to the Observer and Follower Request Processors switch on the request opcode, but create2 is left out. This leads to a condition where the create2 request is passed to the CommitProcessor, but the leader never gets the request, the CommitProcessor can't find a matching request, so the client gets disconnected. Added tests as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (ZOOKEEPER-1851) Follower and Observer Request Processors Do Not Forward create2 Requests
Chris Chen created ZOOKEEPER-1851: - Summary: Follower and Observer Request Processors Do Not Forward create2 Requests Key: ZOOKEEPER-1851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1851 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.5.0 Reporter: Chris Chen Recent changes to the Observer and Follower Request Processors switch on the request opcode, but create2 is left out. This leads to a condition where the create2 request is passed to the CommitProcessor, but the leader never gets the request, the CommitProcessor can't find a matching request, so the client gets disconnected. Added tests as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1851) Follower and Observer Request Processors Do Not Forward create2 Requests
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Chen updated ZOOKEEPER-1851: -- Attachment: ZOOKEEPER-1851.patch Follower and Observer Request Processors Do Not Forward create2 Requests Key: ZOOKEEPER-1851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1851 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.5.0 Reporter: Chris Chen Labels: patch Attachments: ZOOKEEPER-1851.patch Recent changes to the Observer and Follower Request Processors switch on the request opcode, but create2 is left out. This leads to a condition where the create2 request is passed to the CommitProcessor, but the leader never gets the request, the CommitProcessor can't find a matching request, so the client gets disconnected. Added tests as well. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
