-
Notifications
You must be signed in to change notification settings - Fork 19
Propagate socketProvider.get() exception to a connection state #30
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
Comments
Now we stick with this behaviour as part of the
Don't sure whether this behaviour was intentional when it was created, but it has sense for me: only logic inside I don't think we should change this contract. A user can wrap a @Joyfolk Can you share your opinion on that? |
@Totktonada It is a good point about the contract. But any uncatched exception wouldn't lead to explicit fail of the application. It leads only to termination of the reconnection thread without any notification to the rest of the application and to hard-to-debug errors in the client code. I think it would be better to set connection state as dead with correct error information. |
Agreed. I rephrased the issue header. |
Related: PR #170. |
When a client is unable to connect during its creation, we have no object to call diff --git a/src/test/java/org/tarantool/ClientReconnectIT.java b/src/test/java/org/tarantool/ClientReconnectIT.java
index f644fc8..5cb7e53 100644
--- a/src/test/java/org/tarantool/ClientReconnectIT.java
+++ b/src/test/java/org/tarantool/ClientReconnectIT.java
@@ -16,6 +16,7 @@ import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.function.Executable;
+import java.net.ConnectException;
import java.nio.channels.SocketChannel;
import java.time.Duration;
import java.util.Collections;
@@ -422,4 +423,23 @@ public class ClientReconnectIT {
return new TarantoolClientImpl(provider, makeDefaultClientConfig());
}
+ @Test
+ public void testConnectionRefusedException() {
+ testHelper.stopInstance();
+
+ TarantoolClientConfig config = makeDefaultClientConfig();
+ config.initTimeoutMillis = 100;
+ CommunicationException e = assertThrows(CommunicationException.class,
+ () -> new TarantoolClientImpl(socketChannelProvider, config));
+
+ assertEquals(e.getMessage(), "100ms is exceeded when waiting " +
+ "for client initialization. You could configure init timeout " +
+ "in TarantoolConfig");
+ Throwable cause = e.getCause();
+ assertTrue(ConnectException.class.isAssignableFrom(cause.getClass()));
+ assertEquals(cause.getMessage(), "Connection refused");
+
+ testHelper.startInstance();
+ }
+
} (Maybe it is better to mock SingleSocketChannelProviderImpl or implement a socket provider that gives an error instead of starting / stopping an instance.) Our customer recently met a connection problem and it is hard to debug it without a real cause. The only workaround now is to implement own socket channel provider and log a problem from it. We also need to ensure (write a test) that a real cause is in thombstone when a reconnection fails after successful connect. |
I think that the issue can be closed when those things will work as described above. |
tarantool-java/src/main/java/org/tarantool/TarantoolClientImpl.java
Line 107 in 9eb519d
It's better to move this line inside try/catch block.
The text was updated successfully, but these errors were encountered: