These are chat archives for atomix/atomix
We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY
io.atomix.copycat.session.ClosedSessionException: session closed. We have long-running parallel processes that read/write data to atomix (lots of clients essentially) and we get deep into a job and hit that issue, which can wipe out hours of work since we don't have recovery code figured out. So a few questions: Should this be happening, i.e. is it the kind of exception you should expect on the regular? What's the recommended way to recover from such a problem? Do you need to reestablish the whole client connection or just retry getting the resource or the write?
ClosedSessionExceptionis one of those things that should be rare but is certainly recoverable. From my experience even when running under high load, I rarely encounter session churn. When I did run into it was usually a symptom. (For example the issue underlying atomix/copycat#235 caused these exceptions)
CopycatClient::onStateChangeYou should assume when the client is not in
CONNECTEDstate it will have trouble submitting operations to the cluster. When the recovery logic completes the client should transition back to