While we were testing our app's binary connection to another , we configured it with the wrong cert for the service. This results in the following message being logged about 30 times a second or something crazy on our app:
2013-09-20 15:34:52.292: com.betfair.cougar.client.socket.IoSessionFactory INFO - Connected to ***:9003
2013-09-20 15:34:52.293: com.betfair.cougar.netutil.nio.RequestResponseManagerImpl INFO - Notified 0 outstanding requests for session 0023870
2013-09-20 15:34:52.335: com.betfair.cougar.client.socket.ExecutionVenueNioClient WARN - Unexpected exception from session 0023871
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:416)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
Because the SSL stuff is started after the connection is initiated because the original protocol didn’t support SSL, then it’s an exception handler in the client which triggers a reconnect. So there is no delay like the backoff and retry that occurs with the ReconnectTask in IoSessionFactory.
It would be hard to add one because there’s no context of the original connect request when the exception comes through. We could potentially keep a map of last attempted connect time by address (perhaps with a ttl on entries so we don’t end up with loads) and then implement the backoff logic based on that, but like I said, it’s not going to be an easy fix..
While we were testing our app's binary connection to another , we configured it with the wrong cert for the service. This results in the following message being logged about 30 times a second or something crazy on our app:
Because the SSL stuff is started after the connection is initiated because the original protocol didn’t support SSL, then it’s an exception handler in the client which triggers a reconnect. So there is no delay like the backoff and retry that occurs with the ReconnectTask in IoSessionFactory.
It would be hard to add one because there’s no context of the original connect request when the exception comes through. We could potentially keep a map of last attempted connect time by address (perhaps with a ttl on entries so we don’t end up with loads) and then implement the backoff logic based on that, but like I said, it’s not going to be an easy fix..