You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Cameron McKenzie <ca...@apache.org> on 2014/07/22 00:58:02 UTC
CURATOR-122 and CURATOR-123
I've had a bit of a look into these, and there's definitely an issue. If I
setup a simple test that creates a read only TestingServer and a
CuratorFramework that allows 'read only', then I only get a CONNECTED
message on initial connection.
I've run the debugger and this seems to be because we only get a
SyncConnected event from ZooKeeper, not a ConnectedReadOnly event. I
haven't tested this against a proper ZooKeeper cluster yet (will try to do
that today), but is this expected behaviour?
The current TestReadOnly test is a bit bogus, because it only tests that a
particular set of events occur, it doesn't test the order of them. If you
actually look at the logs for the test, it's as discussed in CURATOR-123:
CONNECTED (initial connection)
SUSPENDED (server is killed)
LOST
READ_ONLY (server is restarted)
SUSPENDED
RECONNECTED
In the addStateChange() method in the ConnectionStateManager, I can see
that on initial connection it will only ever generate a CONNECTED event,
due to the following:
boolean isNegativeMessage = ((newConnectionState == ConnectionState.LOST)
|| (newConnectionState == ConnectionState.SUSPENDED));
if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(
false, true) )
{
localState = ConnectionState.CONNECTED;
}
but as discussed above, ZooKeeper doesn't seem to be sending the READ_ONLY
event at initial connection anyway.
Any ideas?
cheers
Cam
Re: CURATOR-122 and CURATOR-123
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
It’s hard to configure it to do so. I have a test case, though, that reproduces.
On July 22, 2014 at 4:25:25 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
Yep, that's definitely the cause for the initial connection state being
reported incorrectly, but when I attached a debugger, the ZooKeeper server
never seemed to actually send the ConnnectedReadOnly state.
cheers
On Wed, Jul 23, 2014 at 3:14 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I think the problem is in ConnectionStateManager.addStateChange() :
>
> if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(false,
> true) )
> {
> localState = ConnectionState.CONNECTED;
> }
>
> -Jordan
>
>
> On July 21, 2014 at 5:58:31 PM, Cameron McKenzie (cammckenzie@apache.org)
> wrote:
>
> I've had a bit of a look into these, and there's definitely an issue. If I
> setup a simple test that creates a read only TestingServer and a
> CuratorFramework that allows 'read only', then I only get a CONNECTED
> message on initial connection.
>
> I've run the debugger and this seems to be because we only get a
> SyncConnected event from ZooKeeper, not a ConnectedReadOnly event. I
> haven't tested this against a proper ZooKeeper cluster yet (will try to do
> that today), but is this expected behaviour?
>
> The current TestReadOnly test is a bit bogus, because it only tests that a
> particular set of events occur, it doesn't test the order of them. If you
> actually look at the logs for the test, it's as discussed in CURATOR-123:
>
> CONNECTED (initial connection)
> SUSPENDED (server is killed)
> LOST
> READ_ONLY (server is restarted)
> SUSPENDED
> RECONNECTED
>
> In the addStateChange() method in the ConnectionStateManager, I can see
> that on initial connection it will only ever generate a CONNECTED event,
> due to the following:
>
> boolean isNegativeMessage = ((newConnectionState == ConnectionState.LOST)
> || (newConnectionState == ConnectionState.SUSPENDED));
>
> if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(
> false, true) )
>
> {
>
> localState = ConnectionState.CONNECTED;
>
> }
>
> but as discussed above, ZooKeeper doesn't seem to be sending the READ_ONLY
> event at initial connection anyway.
>
> Any ideas?
>
> cheers
>
> Cam
>
Re: CURATOR-122 and CURATOR-123
Posted by Cameron McKenzie <mc...@gmail.com>.
Yep, that's definitely the cause for the initial connection state being
reported incorrectly, but when I attached a debugger, the ZooKeeper server
never seemed to actually send the ConnnectedReadOnly state.
cheers
On Wed, Jul 23, 2014 at 3:14 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I think the problem is in ConnectionStateManager.addStateChange() :
>
> if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(false,
> true) )
> {
> localState = ConnectionState.CONNECTED;
> }
>
> -Jordan
>
>
> On July 21, 2014 at 5:58:31 PM, Cameron McKenzie (cammckenzie@apache.org)
> wrote:
>
> I've had a bit of a look into these, and there's definitely an issue. If I
> setup a simple test that creates a read only TestingServer and a
> CuratorFramework that allows 'read only', then I only get a CONNECTED
> message on initial connection.
>
> I've run the debugger and this seems to be because we only get a
> SyncConnected event from ZooKeeper, not a ConnectedReadOnly event. I
> haven't tested this against a proper ZooKeeper cluster yet (will try to do
> that today), but is this expected behaviour?
>
> The current TestReadOnly test is a bit bogus, because it only tests that a
> particular set of events occur, it doesn't test the order of them. If you
> actually look at the logs for the test, it's as discussed in CURATOR-123:
>
> CONNECTED (initial connection)
> SUSPENDED (server is killed)
> LOST
> READ_ONLY (server is restarted)
> SUSPENDED
> RECONNECTED
>
> In the addStateChange() method in the ConnectionStateManager, I can see
> that on initial connection it will only ever generate a CONNECTED event,
> due to the following:
>
> boolean isNegativeMessage = ((newConnectionState == ConnectionState.LOST)
> || (newConnectionState == ConnectionState.SUSPENDED));
>
> if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(
> false, true) )
>
> {
>
> localState = ConnectionState.CONNECTED;
>
> }
>
> but as discussed above, ZooKeeper doesn't seem to be sending the READ_ONLY
> event at initial connection anyway.
>
> Any ideas?
>
> cheers
>
> Cam
>
Re: CURATOR-122 and CURATOR-123
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I think the problem is in ConnectionStateManager.addStateChange() :
if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(false, true) )
{
localState = ConnectionState.CONNECTED;
}
-Jordan
On July 21, 2014 at 5:58:31 PM, Cameron McKenzie (cammckenzie@apache.org) wrote:
I've had a bit of a look into these, and there's definitely an issue. If I
setup a simple test that creates a read only TestingServer and a
CuratorFramework that allows 'read only', then I only get a CONNECTED
message on initial connection.
I've run the debugger and this seems to be because we only get a
SyncConnected event from ZooKeeper, not a ConnectedReadOnly event. I
haven't tested this against a proper ZooKeeper cluster yet (will try to do
that today), but is this expected behaviour?
The current TestReadOnly test is a bit bogus, because it only tests that a
particular set of events occur, it doesn't test the order of them. If you
actually look at the logs for the test, it's as discussed in CURATOR-123:
CONNECTED (initial connection)
SUSPENDED (server is killed)
LOST
READ_ONLY (server is restarted)
SUSPENDED
RECONNECTED
In the addStateChange() method in the ConnectionStateManager, I can see
that on initial connection it will only ever generate a CONNECTED event,
due to the following:
boolean isNegativeMessage = ((newConnectionState == ConnectionState.LOST)
|| (newConnectionState == ConnectionState.SUSPENDED));
if ( !isNegativeMessage && initialConnectMessageSent.compareAndSet(
false, true) )
{
localState = ConnectionState.CONNECTED;
}
but as discussed above, ZooKeeper doesn't seem to be sending the READ_ONLY
event at initial connection anyway.
Any ideas?
cheers
Cam