Can one of the admins verify this patch?

Internal PR hazelcast/hazelcast-mono#1780
Internal message only. Nothing to see here, move along

I think there is no other way; we can't add them to supressed exceptions, because those will be also serialized (and we already know, that we can't serialize it). Logging makes most sense.

run-lab-run

The job Hazelcast-pr-builder of your PR failed. (Hazelcast internal details: build log, artifacts).
Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

--------------------------
---------SUMMARY----------
--------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.4.1:enforce (enforce-tools) on project hazelcast-root: 
--------------------------
---------ERRORS-----------
--------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.4.1:enforce (enforce-tools) on project hazelcast-root: 
--------------------------
[ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireJavaVersion failed with message:
--------------------------
[ERROR] Detected JDK version 11.0.18 (JAVA_HOME=/usr/share/jdks/oracle-11) is not in the allowed range [17,).
--------------------------
[ERROR] -> [Help 1]
--------------------------
[ERROR] 
--------------------------
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
--------------------------
[ERROR] 
--------------------------
[ERROR] For more information about the errors and possible solutions, please read the following articles:
--------------------------
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
--------------------------
[ERROR] 
--------------------------
[ERROR] After correcting the problems, you can resume the build with the command
--------------------------
[ERROR]   mvn  -rf :hazelcast-root
--------------------------

If the real issue is that the cause of the original exception is lost, perhaps it'd be better to add the exceptions' message to the new HazelcastSerializationException?

Currently, something else may catch the HazelcastSerializationException because it's actually expected (obvious case is a test, but there are others that may apply) but with this there'd be extra logging in place that can't be easily disabled.

Currently, something else may catch the HazelcastSerializationException

Can you give an example? The new log will only run when there is a Throwable that could not be serialized.

Also I think only message of the exception is not enough, because the author wants to track the exception. So I think stacktrace is important for that.

but with this there'd be extra logging in place that can't be easily disabled.

As much as I don't like a lot of new configuration, we can put this behind a property that would be disabled by default.

Currently, something else may catch the HazelcastSerializationException

Can you give an example? The new log will only run when there is a Throwable that could not be serialized.

Two (obscure) cases come to mind:

• You have a unit test that tests serializing the unserializable. The output of the test will be full of [ERROR]s that are actually expected for that test
• You are testing an unknown datastream against possible serialization formats, you try a couple, expecting all-but-one to fail

Also I think only message of the exception is not enough, because the author wants to track the exception. So I think stacktrace is important for that.

I'm sure there's a textual representation we could agree on that would have that information - effectively here were saying - if you can't serialize the exception over-the-wire, serialize to a file instead (in the form of a log message).

but with this there'd be extra logging in place that can't be easily disabled.

As much as I don't like a lot of new configuration, we can put this behind a property that would be disabled by default.

What if we log this to a dedicated logger (e.g. com.hazelcast.internal.serialization.impl.SerializationUtil.NonSerializableThrowable)? Then the logging of this specific message can be easily disabled (it kind of already can, since this is the only message logged on the com.hazelcast.internal.serialization.impl.SerializationUtil logger, but that may change in the future).

Two (obscure) cases come to mind:

You have a unit test that tests serializing the unserializable. The output of the test will be full of [ERROR]s that are actually > expected for that test
You are testing an unknown datastream against possible serialization formats, you try a couple, expecting all-but-one to fail

Note that these will log only if the object is a Throwable, which is not very likely imo.

What if we log this to a dedicated logger (e.g. com.hazelcast.internal.serialization.impl.SerializationUtil.NonSerializableThrowable)? Then the logging of this specific message can be easily disabled (it kind of already can, since this is the only message logged on the com.hazelcast.internal.serialization.impl.SerializationUtil logger, but that may change in the future).

Can be possible but I think Jack does not like the default behaviour of logging those throwables that can't be serialized. Adding dedicated logger will still log them by default.

Question: The problem is about at the client side not seeing exception details, right? We actually put the stack trace information into the error codec, and it was deserialized and set at the client exception factory while exception is created. Was this not enough?

nope not enough. We don't put any other info than the class name about the object to be serialized's (if it's Throwable) in to HazelcastSerializationException's message.

If you also want to communicate the details of the object that can not be serialized and if it is of type Throwable, the we can set this object as the cause for the constructed HazelcastSerializationException and if there is any other exception we throw during the serialization. At the end, user will see top level HazelcastSerializationException`, a cause and the cause of the cause which is the throwable object. Then, you do not need to do logging, does this make sense?

this seems ok to me, however what if it already has a cause? Also it's not the cause of serialization exception actually, but the object tried to be serialized. We need to make this clear

Question: The problem is about at the client side not seeing exception details, right? We actually put the stack trace information into the error codec, and it was deserialized and set at the client exception factory while exception is created. Was this not enough?

nope not enough. We don't put any other info than the class name about the object to be serialized's (if it's Throwable) in to HazelcastSerializationException's message.

If you also want to communicate the details of the object that can not be serialized and if it is of type Throwable, the we can set this object as the cause for the constructed HazelcastSerializationException and if there is any other exception we throw during the serialization. At the end, user will see top level HazelcastSerializationException`, a cause and the cause of the cause which is the throwable object. Then, you do not need to do logging, does this make sense?

this seems ok to me, however what if it already has a cause? Also it's not the cause of serialization exception actually, but the object tried to be serialized. We need to make this clear

The exception is created during serialization by us, hence we control the cause part of the exception and we can check the places we throw during serialization and arrange the cause properly to include this object.

Discussed with @srknzl and we concluded that why we need to try serialize a throwable in the first place? Normally, in a callable, you either return a real non-throwable object or you throw an exception. Hence, why is the throwable used as the return value of a callable?