-
Bug
-
Resolution: Done
-
Major
-
None
-
None
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/rxjava3/processors/SerializedProcessor.java#L60
We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications.
[ISPN-12430] AsyncNonBlockingStore can have many more modifications than modification queue size
Will Burns
created issue -
Will Burns
made changes -
| Status | Original: New [ 10016 ] | New: Open [ 1 ] |
Will Burns
made changes -
| Git Pull Request | New: https://github.com/infinispan/infinispan/pull/8783 | |
| Status | Original: Open [ 1 ] | New: Pull Request Sent [ 10011 ] |
Will Burns
made changes -
| Assignee | New: Will Burns [ wburns@redhat.com ] |
Will Burns
made changes -
| Description |
Original:
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. |
New:
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/rxjava3/processors/SerializedProcessor.java#L60 We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. |
Will Burns
made changes -
| Fix Version/s | New: 12.0.0.Dev05 [ 12350773 ] |
Tristan Tarrant
made changes -
| Fix Version/s | New: 12.0.0.Dev06 [ 12351466 ] | |
| Fix Version/s | Original: 12.0.0.Dev05 [ 12350773 ] |
Tristan Tarrant
made changes -
| Fix Version/s | New: 12.0.0.Dev07 [ 12352208 ] | |
| Fix Version/s | Original: 12.0.0.Dev06 [ 12351466 ] |
Tristan Tarrant
made changes -
| Fix Version/s | New: 12.0.0.CR1 [ 12352522 ] | |
| Fix Version/s | Original: 12.0.0.Dev07 [ 12352208 ] |
Tristan Tarrant
made changes -
| Fix Version/s | New: 12.0.0.Final [ 12345018 ] | |
| Fix Version/s | Original: 12.0.0.CR1 [ 12352522 ] |
| Resolution | New: Done [ 1 ] | |
| Status | Original: Pull Request Sent [ 10011 ] | New: Resolved [ 5 ] |
Tristan Tarrant
made changes -
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
Pedro Zapata Fernandez
made changes -
| Workflow | Original: GIT Pull Request with Triage workflow [ 13464729 ] | New: OJA-WF-BG [ 24697813 ] |