Custom exception not transported to the hazelcast client (disributed executor service) -> instead UndefinedErrorCodeException

[Petikoch]

If I use the hazelcast client to call the distributed executor service and the callable throws an exception with a custom type, the exception is not transported to the client. The cause of the ExecutionException is then not "my exception", instead it is UndefinedErrorCodeException. The class of "my exception" is both in the classpath of the "server" and of the "client".

If I do the same using a regular hazelcast node (not the client), everything works.

How can I let transport "my exception" as cause to the hazelcast client?

See the below example to show the issue (using hazelcast and hazelcast-client 3.7.5):

import com.hazelcast.client.HazelcastClient;
import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;

import java.io.Serializable;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;

public class CustomExceptionIssueWithHazelcastClient {

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

		// does not work
		HazelcastInstance hzClient = HazelcastClient.newHazelcastClient();
		// works, in constrast:
		// HazelcastInstance hzClient = Hazelcast.newHazelcastInstance();

		try {
			hzClient.getExecutorService("Default").submit(
					new ThrowingCallable(),
					member -> {
						final String memberAttr = member.getStringAttribute("type");
						return memberAttr != null && memberAttr.equals("server");
					}
			).get();
		}  catch (ExecutionException e) {
			if(!(e.getCause() instanceof CustomRuntimeException)){
				System.out.println("Wrong exception type here! " );
				e.printStackTrace();
				TimeUnit.SECONDS.sleep(5);
			}
		} finally {
			hzClient.shutdown();
			hzServer.shutdown();
		}
	}

	public static class CustomRuntimeException extends RuntimeException {
	}

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

		@Override
		public String call() throws Exception {
			throw new CustomRuntimeException();
		}
	}
}

[Petikoch]

#9713 seems to go in the right direction, am I right?

[sancar]

When we switched to protocol to support all languages, exceptions support get weakened. Before we were using Java Serialization directly. Right now, we are using our own description for exceptions. For the exceptions are not defined in protocol, we are delivering them via UndefinedErrorCodeException which has the original class name as field.

More extensive work on this will be done on 4.0.

#9713 is a workaround to be used internally. One idea is to make this public in 4.0 to be used by our users.

[dbrimley]

@sancar Would this enhancement mean breaking the client protocol? Should it be just in 4.0 or can at least some research be carried out in 3.11 phase?

[sancar]

It feels like we can find a way to not to break the protocol when introducing the change.
So 3.11 could be an option.

[Petikoch]

I just fell into this problem again, when trying to migrate code which was working using a hazelcast-lite-member into code which uses a hazelcast client instead.

Exception handling was broken... and I had to extend the catch block to fix it.

It would be really nice if the same API (HazelcastInstance#getExecutorService ... submit ...) would behave the same way, also regarding exceptions, in hazelcast AND in hazelcast-client.

I'm looking forward to 3.11! :-)

[sancar]

@Petikoch Sorry to inform you that we could not prioritize this one and it is postponed.
And whether this will be on 3.12 or later is not decided yet.

[dbrimley]

@sancar although this didn't make it into 3.11 due to time constraints, is this a client side only fix? Therefore it might be possible to release in a 3.11.1 of the Java Client? Trying to think of ways to get this to @Petikoch as soon as possible.

[sancar]

@dbrimley
This seems to require new configuration on both server and client for users to register their classes.

[javanotes]

Hi Team, has this been put into formal solution? I am experiencing this in 4.0.2