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

Throw ClientNotActiveException instead of generic HazelcastException #13525

Merged
merged 1 commit into from Sep 25, 2018

Conversation

@sancar
Copy link
Member

@sancar sancar commented Aug 2, 2018

alive check in ClientConnectionManager is moved to a more centralized
method and type of the exception is fixed.

(cherry picked from commit e244fe7)

@sancar sancar added this to the 3.10.5 milestone Aug 2, 2018
@sancar sancar self-assigned this Aug 2, 2018
@@ -377,6 +378,9 @@ private Connection getConnection(Address target, boolean asOwner, boolean acquir
}

private void checkAllowed(Address target, boolean asOwner, boolean acquiresResources) throws IOException {
if (!alive) {

This comment has been minimized.

@mmedenjak

mmedenjak Aug 2, 2018
Contributor

HazelcastClientNotActiveException does not extend HazelcastException. This is a behaviour change then. Is it possible some user was catching a HazelcastException?

This comment has been minimized.

@sancar

sancar Aug 3, 2018
Author Member

HazelcastException is retryable in client invocation system. When hazelcast exception is thrown from here, invocation system catches that throws as ClientNotActiveException to user.
https://github.com/hazelcast/hazelcast/blob/master/hazelcast-client/src/main/java/com/hazelcast/client/spi/impl/ClientInvocation.java#L209
But there is an unncessary wrapping there. It results as a ClientNotActiveException which has HazelcastException("client is shutting down") as cause.

There are a couple, usages of connection manager directly like txns which should handle HazelcastException themselves. In that case, we also convert it to ClientNotActiveException

So in almost all of the cases, user get ClientNotActiveException. Even if there were edge cases that user gets HazelcastException before, I would like to consider them as bug and fix it, rather then thinking this as behaviour change.
How does that sound ?

This comment has been minimized.

@mmedenjak

mmedenjak Aug 3, 2018
Contributor

I can admit I'm a bit lost here. It's your call. I'm just thinking if this could affect some user code like:

try {
  // use hazelcast
} catch (HazelcastException expected) {
  // all is good, I expected this!
}

This comment has been minimized.

@pveentjer

pveentjer Aug 8, 2018
Member

This is also my worry.

This comment has been minimized.

@sancar

sancar Aug 8, 2018
Author Member

Well as mentioned above, if we are not throwing ClientNotActiveException where we supposed to throw it is a bug.
And depending on when the clients shutdown we could be throwing ClientNotActiveException or HazelcastException. That means, user should already prepared for ClientNotActiveException. This fix is to correct one more place that we are throwing HazelcastException instead of ClientNotActiveException.

That is why, I see no problem with backward compatibility.

This comment has been minimized.

@ihsandemir

ihsandemir Aug 17, 2018
Contributor

Would it be possible (or cause any side affects) if IllegalStateException (base class of HazelcastClientNotActiveException) derive from HazelcastException instead of RuntimeException?

This comment has been minimized.

@sancar

sancar Aug 28, 2018
Author Member

IllegalStateException can't derive from HazelcastException, because it is from java.lang library. It is not our class.

@sancar sancar modified the milestones: 3.10.5, 3.10.6 Sep 3, 2018
alive check in ClientConnectionManager is moved to a more centralized
method and type of the exception is fixed.

(cherry picked from commit e244fe7)
@sancar sancar force-pushed the sancar:fix/exceptionType/maint3.x branch from 791ef2a to f67b9a2 Sep 24, 2018
@sancar sancar merged commit 9c02039 into hazelcast:maintenance-3.x Sep 25, 2018
1 check passed
1 check passed
default Test PASSed.
Details
@sancar sancar deleted the sancar:fix/exceptionType/maint3.x branch Sep 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

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