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

MessageProcessors must be instantiated per processing thread #2231

Merged
merged 2 commits into from May 17, 2016
Merged

Conversation

@kroepke
Copy link
Member

@kroepke kroepke commented May 13, 2016

When introducing the MessageProcessor interface, the processing threads accidentally shared the instances (and by induction the MessageFilter instances as well).
That posed no problem for most of the filters, because they do not rely on shared state, but the Drools filter does and could skip messages (because of Drools itself returning early)

This change uses a Provider to get the OrderedMessageProcessor instances explicitly and those do not get shared across threads.

fixes #2119
fixes #2188

When introducing the MessageProcessor interface, the processing threads accidentally shared the instances (and by induction the MessageFilter instances as well).
That posed no problem for most of the filters, because they do not rely on shared state, but the Drools filter does and could skip messages (because of Drools itself returning early)

This change uses a Provider to get the OrderedMessageProcessor instances explicitly and those do not get shared across threads.

fixes #2119
fixes #2188
@kroepke kroepke added this to the 2.0.2 milestone May 13, 2016
OutputBuffer outputBuffer) {
super(metricRegistry);
this.orderedMessageProcessors = orderedMessageProcessors;
this.orderedMessageProcessors = orderedMessageProcessorsProvider.get();

This comment has been minimized.

@joschi

joschi May 13, 2016
Contributor

Why use a Provider here? If OrderedMessageProcessors.class isn't bound as a singleton, Guice will create a new instance anyway.

This comment has been minimized.

@kroepke

kroepke May 17, 2016
Author Member

I was being extra-super-duper careful and explicit, but you are correct, it is not strictly necessary.

This comment has been minimized.

@joschi

joschi May 17, 2016
Contributor

The thing is that a (singleton) provider could also return always the same instance of the injectee and it doesn't help clarifying the contract (that we need a new instance every time).


bind(OrderedMessageProcessors.class).asEagerSingleton();
// must not be a singleton, because each thread should get an isolated copy of the processors
bind(OrderedMessageProcessors.class);

This comment has been minimized.

@joschi

joschi May 13, 2016
Contributor

Maybe make it very explicit here with bind(OrderedMessageProcessors.class).in(Scopes.NO_SCOPE)?

This comment has been minimized.

@kroepke

kroepke May 17, 2016
Author Member

aye!

@joschi joschi self-assigned this May 13, 2016
@joschi
Copy link
Contributor

@joschi joschi commented May 17, 2016

LGTM. 👍

@joschi joschi merged commit 507814a into 2.0 May 17, 2016
0 of 4 checks passed
0 of 4 checks passed
@garybot2
ci-server-integration Jenkins build is being scheduled
Details
@garybot2
ci-web-linter Jenkins build is being scheduled
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
bernd added a commit that referenced this pull request May 17, 2016
When introducing the MessageProcessor interface, the processing threads accidentally shared the instances (and by induction the MessageFilter instances as well).
That posed no problem for most of the filters, because they do not rely on shared state, but the Drools filter does and could skip messages (because of Drools itself returning early)

This change uses a Provider to get the OrderedMessageProcessor instances explicitly and those do not get shared across threads.

Fixes #2119, fixes #2188

(cherry picked from commit 507814a)
@joschi joschi deleted the issue-2119 branch May 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants