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

Exception causes get lost when using IExecutorService with the hazelcast client #10591

Petikoch opened this issue May 16, 2017 · 4 comments


Copy link

@Petikoch Petikoch commented May 16, 2017

In a distributed java application, I switched over in a node from a regular java hazelcast light member to a java hazelcast client. I noticed, that the hazelcast client behaves slightly different in terms of transportation of exceptions in the IExecutorService: exception causes get lost.

In the following example (using 3.7.7), we have three exceptions in a chain

  • RuntimeException "a"
  • with its cause IllegalStateException "b"
  • with its cause IllegalArgumentException "c"

Using the hazelcast client we see

  • RuntimeException "a" is transported
  • cause IllegalStateException is transported, but message "b" is missing
  • the actual root cause IllegalArgumentException "c" is missing completely
import com.hazelcast.client.HazelcastClient;
import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;
import org.hamcrest.Matchers;

import java.util.Objects;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertThat;

public class ExceptionCausesLost {

	public static void main(String[] args) throws InterruptedException {
		HazelcastInstance hzServer = Hazelcast.newHazelcastInstance();
		hzServer.getCluster().getLocalMember().setStringAttribute("type", "server");

		// exception causes get lost with client:
		HazelcastInstance hzClient = HazelcastClient.newHazelcastClient();
		// works, in contrast:
		//HazelcastInstance hzClient = Hazelcast.newHazelcastInstance();

		try {
					new ThrowingCallable(),
					member -> Objects.equals("server", member.getStringAttribute("type"))
			throw new IllegalStateException("Should not be here, should be in catch ExecutionException block");
		} catch (ExecutionException e) {
			assertThat(e.getCause(), Matchers.instanceOf(RuntimeException.class));
			assertEquals("a", e.getCause().getMessage());
			assertThat(e.getCause().getCause(), Matchers.instanceOf(IllegalStateException.class));
			assertEquals("b", e.getCause().getCause().getMessage());
			assertThat(e.getCause().getCause().getCause(), Matchers.instanceOf(IllegalArgumentException.class));
			assertEquals("c", e.getCause().getCause().getCause().getMessage());
			System.out.println("Everything is fine...");
		} finally {

	public static class ThrowingCallable implements Callable<String>, Serializable {

		public String call() throws Exception {
			throw new RuntimeException("a", new IllegalStateException("b", new IllegalArgumentException("c")));


The full exception chain is transported with the java hazelcast client, like with "regular" hazelcast nodes.

@sancar sancar added this to the 3.9 milestone Aug 1, 2017
@sancar sancar self-assigned this Aug 2, 2017
Copy link

@sancar sancar commented Aug 2, 2017

fixed via #9750 in 3.8

@sancar sancar closed this Aug 2, 2017
Copy link

@Petikoch Petikoch commented Nov 16, 2017

@sancar this is fixed in 3.9 not 3.8, isn't it?

Copy link

@sancar sancar commented Nov 16, 2017

I just checked the fix commit.
It is shipped with 3.8. Label of this issue was not properly updated. I've just changed it to 3.8

@sancar sancar removed this from the 3.9 milestone Nov 16, 2017
Copy link

@Petikoch Petikoch commented Nov 16, 2017

Ok, I saw it in the release notes of 3.9... This explains it.

Thanks a lot and have a nice day!

@sancar sancar added this to the 3.8 milestone Nov 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.