[
https://issues.apache.org/jira/browse/BOOKKEEPER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288505#comment-13288505
]
Flavio Junqueira commented on BOOKKEEPER-281:
---------------------------------------------
bq. Regarding state notifications, I think this is a bad idea. A user of the
api shouldn't need to know if the client is ready to use or not. They should be
able to just submit an async request to the client, and either the client does
it and completes with success or failure due to an unrecoverable error state.
These are independent paths. If the application wants, it can wait until it is
connected. If it doesn't check and it submits operations, then its operations
might fail as you say.
bq. The user isn't going to check the state and, on seeing that the client
isn't connected, decide that it doesn't want to add an entry.
Adding an entry is probably not a good example because it doesn't depend on
zookeeper in a regular run. Creating/Closing a ledger are perhaps more
relevant, no? In any case, I see that as being useful, since an application
might not want to submit a whole bunch of asynchronous operations to later find
that none of them went through. It's true that it can happen independent of the
case we are discussing here, but under the conditions we are discussing here,
the application could know that it is better ti wait if we notify.
bq. My biggest problem with the ZooKeeper api is that it doesn't allow a user
to submit an async request without having to ensure that its in connected
state. The api is supposed to hide these kind of details.
If the client session is expired, then we can't guarantee ordering. If we don't
fail the operations, then we might end up violating our ordering guarantees.
bq. In fact, the HBase guys wrapped the whole zookeeper api to get around this
problem[1]. I think, in 4.2 we should perhaps take a similar approach.
I haven't looked at the particular repository you pointed us to, but in general
I find embedding zookeeper, trying to make its use completely transparent, a
bad idea. If it is a separate component, it is best for debugging that the
developer is aware.
> BKClient is failing when zkclient connection delays
> ---------------------------------------------------
>
> Key: BOOKKEEPER-281
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-281
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Fix For: 4.1.0, 4.2.0
>
> Attachments: BOOKKEEPER-281.diff, BOOKKEEPER-281.diff,
> BOOKKEEPER-281.diff
>
>
> I have started the ZK cluster and when tries to create a BookKeeper client
> from my application, it is throwing following ZooKeeper
> ConnectionLossException and is exitting.
> 12/06/01 11:44:31 WARN client.ZooKeeperSaslClient: SecurityException:
> java.lang.SecurityException: Unable to locate a login configuration occurred
> when trying to find JAAS configuration.
> 12/06/01 11:44:31 INFO client.ZooKeeperSaslClient: Client will not
> SASL-authenticate because the default JAAS configuration section 'Client'
> could not be found. If you are not using SASL, you may ignore this. On the
> other hand, if you expected SASL to work, please fix your JAAS configuration.
> 12/06/01 11:44:31 INFO zookeeper.ClientCnxn: Client session timed out, have
> not heard from server in 4540ms for sessionid 0x0, closing socket connection
> and attempting reconnect
> 12/06/01 11:44:32 INFO zookeeper.ClientCnxn: Opening socket connection to
> server /10.18.40.91:2182
> Exception in thread "main"
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
> at
> org.apache.bookkeeper.client.BookieWatcher.readBookiesBlocking(BookieWatcher.java:151)
> at org.apache.bookkeeper.client.BookKeeper.<init>(BookKeeper.java:139)
> at BKClient1.main(BKClient1.java:40)
> 12/06/01 11:44:36 WARN client.ZooKeeperSaslClient: SecurityException:
> java.lang.SecurityException: Unable to locate a login configuration occurred
> when trying to find JAAS configuration.
> When analyzed more, the root cause is:
> BookKeeper.java:
> --------------------
> In the constructor of BookKeeper, immediately after creating the ZK client ,
> it is going to bookieWatcher.readBookiesBlocking() for available bookies from
> ZK server before reaching SyncConnected event.
> I think, we would properly use the existing countdown latch and wait till
> ZooKeeper client connection establishment before continue reading Bookies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
