Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the event processors #374

Merged
merged 11 commits into from
Mar 10, 2021
Merged

Improve the event processors #374

merged 11 commits into from
Mar 10, 2021

Conversation

sbegaudeau
Copy link
Member

No description provided.

@sbegaudeau sbegaudeau requested a review from pcdavid March 4, 2021 12:37
@sbegaudeau sbegaudeau force-pushed the sbe/enh/reactor branch 3 times, most recently from 7eed6ad to c73f675 Compare March 8, 2021 09:22
@pcdavid pcdavid self-assigned this Mar 8, 2021
Copy link
Member

@pcdavid pcdavid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments.

Comment on lines 50 to 53
var subscriptionCount = this.username2subscriptionCount.getOrDefault(username, new AtomicInteger());
subscriptionCount.getAndIncrement();

this.username2subscriptionCount.put(username, subscriptionCount);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually re-reading this I think this is not thread-safe either. From the initial state, two threads can enter add, both calling getOrDefaultwill return 2 AtomicInteger, increment them both to 1, and both but 1 into the map. The last one to call put will "win" but we still end with 1 for this username.

I think we should use ConcurrentMap.computeIfAbsent() instead of getOrDefault and then put to atomically get/initialize the AtomicInteger and then atomically mutate it.

Same logic for remove.

@sbegaudeau sbegaudeau requested a review from pcdavid March 9, 2021 15:30
Bug: #367
Signed-off-by: Stéphane Bégaudeau <[email protected]>
Bug: #368
Signed-off-by: Stéphane Bégaudeau <[email protected]>
This first commit will make sure that the disposal of the representation event
processors do not rely on SubscriptionDescription anymore. Thanks to this commit
it will be possible to remove the SubscriptionDescription during the retrieval of
the payload flux and then to update the lifecycle of the APIs used to disposed
the representations event processors.

Bug: #357
Signed-off-by: Stéphane Bégaudeau <[email protected]>
…tion event processors

Bug: #357
Signed-off-by: Stéphane Bégaudeau <[email protected]>
- Remove useless code in the dipose since no one is present anymore to receive complete events
- Use SLF4J native formatting capabilities instead of MessageFormat
- Improve the thread safety of the subscription manager

Signed-off-by: Stéphane Bégaudeau <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants