These are chat archives for atomix/atomix

9th
Jul 2016
Roman Pearah
@neverfox
Jul 09 2016 06:20
Why do I sometimes get a java.util.ConcurrentModificationException when trying to close a client?
Jordan Halterman
@kuujo
Jul 09 2016 06:20
must be a bug… where does it come from?
Roman Pearah
@neverfox
Jul 09 2016 06:21
I'm just calling close on my client that was connected to a single standalone replica
Jordan Halterman
@kuujo
Jul 09 2016 06:21
I mean, you can’t see where it’s thrown in the client from the stacktrace?
Roman Pearah
@neverfox
Jul 09 2016 06:21
ah
Jordan Halterman
@kuujo
Jul 09 2016 06:22
must be a data structure that needs to be changed
Roman Pearah
@neverfox
Jul 09 2016 06:22
io.atomix.AtomixClient.close        AtomixClient.java:  170
io.atomix.manager.ResourceClient.close      ResourceClient.java:  306
 java.util.HashMap$ValueIterator.next             HashMap.java: 1466
java.util.HashMap$HashIterator.nextNode             HashMap.java: 1437
Jordan Halterman
@kuujo
Jul 09 2016 06:23
ahh yes
easy fix thanks!
Roman Pearah
@neverfox
Jul 09 2016 06:24
cool!
would love an explanation if you get a chance
what's weird is that it only recently started happening I assumed it was something I did in my code
not that that's mutually exclusive from this being a bug
Jordan Halterman
@kuujo
Jul 09 2016 06:27
atomix/atomix#197
Roman Pearah
@neverfox
Jul 09 2016 06:28
Nice
When will that land in a snapshot?
Jordan Halterman
@kuujo
Jul 09 2016 06:28
in a few minutes
Roman Pearah
@neverfox
Jul 09 2016 06:28
perfect
thanks so much
Jordan Halterman
@kuujo
Jul 09 2016 06:29
So, it’s because instances is a HashMap which is not thread safe. Because the close() method was not synchronized, if the close() method is called while another thread is writing to the instances map then you get that exception
Roman Pearah
@neverfox
Jul 09 2016 06:29
got it
Jordan Halterman
@kuujo
Jul 09 2016 06:30
what probably happened internally is the client was closing resources while simultaneously closing the ResourceClient which caused that, but the lock will prevent that from happening now
Roman Pearah
@neverfox
Jul 09 2016 06:31
yeah it seems to happen the smaller and faster my process is
Jordan Halterman
@kuujo
Jul 09 2016 06:31
makes sense
just gotta wait for the tests then I’ll push the snapshot
Roman Pearah
@neverfox
Jul 09 2016 06:33
no worries
cwolfinger
@cwolfinger
Jul 09 2016 22:21
Hi - I have been trying out Atomix for a few days and I am pretty impressed by the ease of use and feature set. One issue I continue to see is that if I start a single node cluster and the node shutsdown (for example laptop goes into sleep mode) when I try and restart the Atomix cluster the application hangs on bootstrap.join(); - any thoughts?
The last logs:
INFO [2016-07-09 22:06:21,888] io.atomix.copycat.server.state.ServerContext: /0.0.0.0:8700 - Transitioning to LEADER
INFO [2016-07-09 22:06:21,892] io.atomix.copycat.server.state.ServerContext: /0.0.0.0:8700 - Found leader /0.0.0.0:8700
INFO [2016-07-09 22:06:21,898] io.atomix.copycat.server.state.ServerStateMachine: /0.0.0.0:8700 - Installing snapshot 1
INFO [2016-07-09 22:06:22,125] io.atomix.copycat.server.CopycatServer: Server started successfully!
But i do not see:
INFO [2016-07-09 22:06:22,166] io.atomix.copycat.client.session.ClientSession: Registered session 1879
which is normally what occurs when the system starts successfully ...
Running with latest RC version from Maven
Jordan Halterman
@kuujo
Jul 09 2016 22:53
hmm that’s interesting
will try to reproduce it...
Does it behave correctly if you just kill the process and restart? I’m doing that repeatedly on a single node and it’s behaving as expected, but I’ll try some other failures
Jordan Halterman
@kuujo
Jul 09 2016 23:33
But you're right you should be seeing the client register a new session...
It seems to me if the client can't register a new session that would usually imply a loss of quorum, meaning perhaps the cluster thinks there are two nodes? I have never personally seen that happen.