[
https://issues.apache.org/jira/browse/ZOOKEEPER-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235271#comment-13235271
]
Camille Fournier commented on ZOOKEEPER-1375:
---------------------------------------------
A server ran out of memory? This ticket is for the client code, not the server
code. More likely NIOServerCnxn than ClientCnxn as you mention.
OOM stuff can cause VMs to behave very strangely, which is why I generally
think it's best to fail big and fail fast when it happens. There's not really
any sense in trying to "recover" because beyond that point the behavior is
pretty non-deterministic. Strange that the other VMs wouldn't form a quorum
though... might be interesting to dig into. Feel free to open another ticket
with some more info and we can dig into it more.
> SendThread is exiting after OOMError
> ------------------------------------
>
> Key: ZOOKEEPER-1375
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1375
> Project: ZooKeeper
> Issue Type: Bug
> Affects Versions: 3.4.0
> Reporter: Rakesh R
>
> After reviewing the ClientCnxn code, there is still chances of exiting the
> SendThread without intimating the users. Say if client throws OOMError and
> entered into the throwable block. Here again while sending the Disconnected
> event, its creating "new WatchedEvent()" object.This will throw OOMError and
> leads to exit the SendThread without any Disconnected event notification.
> {noformat}
> try{
> //...
> } catch (Throwable e)
> {
> //..
> cleanup();
> if(state.isAlive()){
> eventThread.queueEvent(
> new WatchedEvent(Event.EventType.None,
> Event.KeeperState.Disconnected, null) )
> }
> //....
> }
> {noformat}
--
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
