Repository navigation
Fixed: JmsListenerFactory.getInstance starts a second loader thread when two dispatchers are created concurrently (OFBIZ-13777) - #2511
Open
mridulpathak wants to merge 1 commit into
Conversation
JmsListenerFactory.getInstance created a factory whose constructor already started the listener loader thread, and only then tried to publish it with compareAndSet. When two dispatchers were created at the same time, the instance that lost the race was discarded but its thread kept loading listeners into the same static maps, under a different lock, so the same JMS listener could be created and connected twice and the extra one was never closed. getInstance now builds the factory without starting the thread and starts it only when its compareAndSet succeeds. The public constructor still starts the thread as before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JmsListenerFactory.getInstance created a factory whose constructor already started the listener loader thread, and only then tried to publish it with compareAndSet. When two dispatchers were created at the same time, the instance that lost the race was discarded but its thread kept loading listeners into the same static maps under a different lock, so the same JMS listener could be created and connected twice, and the extra one was never closed (on a topic, every message ran the service twice). getInstance now builds the factory without starting the thread and starts it only when its compareAndSet succeeds. The public constructor keeps its current behaviour.