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

Lossing messages while moving them inside a transaction #259

pablolagreca opened this issue Aug 31, 2012 · 1 comment


None yet
2 participants
Copy link

commented Aug 31, 2012


I'm using Hazelcast 2.1.1 and I'm doing some test around moving messages between queues / map using transactions.

So what I do is I create two different java apps each one running in it's own JVM so each one is one instance of a hazelcast data grid. Each app moves messages from firstQueue to secondQueue and then to thirdQueue, everything inside a transaction. So before finishing moving all the created messages to the thirdQueue I kill one JVM so it only remains one hazelcast instance running.

I expect every message to be delivered to the thirdQueue since I'm using default conf (which implies backupCount = 1) and also using transactions.

Attached I've put two group of test. One for testing using queues and another one for test using maps. Both show the same issue.

To reproduce the issue run TestHighConcurrency2. Then run TestHighConcurrency. Before every message is moved to the thirdQueue kill vm of TestHighConcurrency and you will see that no every message is dispatch to thirdQueue. Do the same with TestHighConcurrencyMap for the map version.

It doesn't lose messages every time so you may have to run the test a couple of times before seing message lost. Also killing the VM near the end of message processing cause this issue to happen more often.

Thanks, Pablo.


This comment has been minimized.

Copy link

commented Aug 31, 2012

Test files for issue;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.