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

Conversation

Projects
None yet
2 participants
@kroepke
Member

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

MessageProcessors must be instantiated per processing thread
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

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

@joschi joschi self-assigned this May 13, 2016

@joschi

This comment has been minimized.

Contributor

joschi commented May 17, 2016

LGTM. 👍

@joschi joschi merged commit 507814a into 2.0 May 17, 2016

0 of 4 checks passed

ci-server-integration Jenkins build is being scheduled
Details
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

MessageProcessors must be instantiated per processing thread (#2231)
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