[ http://issues.apache.org/jira/browse/DIRMINA-68?page=comments#action_12422678 ] Trustin Lee commented on DIRMINA-68: ------------------------------------
We can apply the same mechanism to connectionless transport types like datagram once DIRMINA-162 is resolved. Then reconnect(...) method could reside in IoConnector rather than SocketConnector. But would this be convenient for users? For now, IoSession.getService() returns IoService rather than IoConnector, so you need to downcast the returned value. There are also other possible options that might be more convenient and therefore we should review: * IoSession.reconnect() might be a viable option though it should throw a UnsupportedOperation or IllegalStateException when it is called inadequately. * IoSession.get/setReconnectPolicy() - we can cover most reconnection scenarios using pre-defined policy classes. These getter and setter shouldn't do anything when they are called for the sessions managed by an IoAcceptor. I think each approach has both its strength and weakness. What would you choose? > Automatic reconnect configuration for client channels. > ------------------------------------------------------ > > Key: DIRMINA-68 > URL: http://issues.apache.org/jira/browse/DIRMINA-68 > Project: Directory MINA > Issue Type: Improvement > Reporter: Trustin Lee > Attachments: MinaFailoverSession.java, ReconnectionFilter.java, > ReconnectionFilter.java, ReconnectionFilter.java > > > We need to provide: > * automatic reconnect property for client sessions > * reconnect delay > * max retry count > Current retry count and client session flag will be stored as session > attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
