[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12430: ------------------------------ Description: The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/r... We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. was: The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)