[JAVA-5114] ResizingByteBufferFlux - shouldn't need locks Created: 22/Aug/23  Updated: 28/Aug/23

Status: Backlog
Project: Java Driver
Component/s: Reactive Streams
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Unknown
Reporter: Ross Lawley Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Changes Summary:

1. What would you like to communicate to the user about this feature?
2. Would you like the user to see examples of the syntax and/or executable code and its output?
3. Which versions of the driver/connector does this apply to?


 Description   

As per valentin.kovalenko@mongodb.com observations in #1178

I am not sure synchronization is needed here at all, because of the following rules:

  • Subscription #1: Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context.
  • Subscriber #7: A Subscriber MUST ensure that all calls on its Subscription's request and cancel methods are performed serially.

But, because I am not sure it is not needed (I may be missing or misunderstanding something), I preserved the synchronization.

Since upgrading the reactor to 2022.0.0 - the compliance with the reactive streams spec should enable the removal of the lock / synchronization.



 Comments   
Comment by Valentin Kavalenka [ 22/Aug/23 ]

If the changes in the PR are approved, volatile and Atomic s are the only synchronization that will be left in ResizingByteBufferFlux. Some of such fields are accessed only from hookOnSubscribe, while others are also accessed from hookOnNext, hookOnComplete. Whether or not synchronization is needed for those is to be determined.

Generated at Thu Feb 08 09:03:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.