You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by GitBox <gi...@apache.org> on 2019/07/08 17:26:22 UTC

[GitHub] [storm] JanecekPetr commented on issue #3034: STORM-3422: TupleCaptureBolt is not thread-safe

JanecekPetr commented on issue #3034: STORM-3422: TupleCaptureBolt is not thread-safe
URL: https://github.com/apache/storm/pull/3034#issuecomment-509317998
 
 
   > I would also expect there to be some contention on the map field, as it will be updated by every tuple in the local topology.
   
   D'oh! Of course. That was bad.
   
   I updated the PR with another take - this time taking advantage of the *happens-before* guarantees provided by [`ConcurrentHashMap#compute()`](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html#compute-K-java.util.function.BiFunction-). This now allows parallelism among different bolts, and will correctly work even if two instances of the same bolt are executed at the same time. The change is simpler, and there's no need to synchronize on the list anymore. The cost is that the inner lambda is a capturing one and has therefore be instantiated with every iteration...
   
   Do you guy have any benchmarks impacted by this? I could not find one. Or do we not really care in tests?
   
   (and I rebased the branch)

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services