ConcurrentModificationException

[ghost]

Hi again :)

I got an exception on updating object in repository:

Caused by: java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextEntry(HashMap.java:851)
    at java.util.HashMap$KeyIterator.next(HashMap.java:885)
    at org.dizitart.no2.internals.ChangeEventBus.post(ChangeEventBus.java:40)
    at org.dizitart.no2.internals.ChangeEventBus.post(ChangeEventBus.java:30)
    at org.dizitart.no2.internals.DataService.notify(DataService.java:262)
    at org.dizitart.no2.internals.DataService.update(DataService.java:197)
    at org.dizitart.no2.internals.NitriteService.update(NitriteService.java:361)
    at org.dizitart.no2.internals.DefaultNitriteCollection.update(DefaultNitriteCollection.java:322)
    at org.dizitart.no2.objects.DefaultObjectRepository.update(DefaultObjectRepository.java:144)
    at org.dizitart.no2.objects.DefaultObjectRepository.update(DefaultObjectRepository.java:128)

As mentioned in documentation

ObjectRepository is thread-safe for concurrent use.

What can be the reason of such exception?

[anidotnet]

I have never came across this issue before. The only reason I can think of is in one thread you are registering a listener and in another thread you are posting the notification simultaneously. Can you post a small reproducible code?

I have a quick-fix in mind, but need to see what kind of code causes it.

[anidotnet]

Fix is there in 2.2.0-SNAPSHOT, but I still love to see the code that causes it 😄

[ghost]

I will send it in a few hours :)

[ghost]

I wrap ChangeListener in RxJava 2 Observable which means that every subscriber register it's own version of ChangeListener.

All subscribers of this observable were subscribed on RxJava's IO-thread.

---

Last night I changed the code to this and do not face with described issue anymore:

[anidotnet]

Yes your last change is the idiomatic one. You should register listener at the beginning and listening through out the app life-cycle.

I have changed the event bus code which will handle the first scenario also, but remember you may loose some events due to the inherent property of ConcurrentHashMap if the listener collection is modified while dispatching events. But this is the short-fall of the first scenario only, your second scenario is fool-proof.