Do you give permission to place the code in to the baseline? I have used it in my tutorial example that I will be checking in to subversion in the next day or so.
On 5/23/07, Brigham Stevens <[EMAIL PROTECTED]> wrote:
(sorry for the blank message I put To: field to early and somehow bashed my keyboard badly) We were having problems with our mina client & server's UDP sessions. They were being terminated by the ExpiringMap which is part of the ExpiringSessionRecycler that is used for UDP sessions. We didn't want that behavior, and also it seemed like it was even terminating busy sessions that were streaming UDP packets basically at least 30 times a second. But looking into it, I realized we needed to create our own SessioRecycler to avoid this. I found this related issue in DIRMINA: http://issues.apache.org/jira/browse/DIRMINA-319?page=com.atlassian.jira.plu gin.system.issuetabpanels:all-tabpanel My question is prompted from Trustin's comment: "DatagramConnector doesn't use of IoSessionRecycler at all because [EMAIL PROTECTED] DatagramConnector} doesn't create a session with the same remote and local addresses. This is an API design flaw. We don't need DatagramService either because of the same reason." So I have implemented the Simple Session Recycler shown below. My question is, to ensure my session is maintained, should I be using the DatagramConnector.connect method that includes the local and remote address(+port) in the client when it connects? I like not having to specify on the client. In practice, I have not found specifying the local address/port necessary, but reading the DIRMINA comments, I just want to make sure that I am on the right track. If Mina uses the same DatagramChannel the whole time, I don't think the clients local address(port) would ever change and that is what I'm seeing, (My recycler seems to work well) but I guess I don't fully understand the comment in DIRMINA-319. I noticed that UDP IoSessionHandler's never receive Idle callbacks. This would be nice to have, but I guess from the other comments in that Issue you are aware of this, and maybe we will see Idle handlers being called in 2.0 ! Here is my SimpleSessionRecycler that avoids getting disconnected: (Would something like this make a good default recycler for 2.0? So people would not have to implement a session recycler just to get things running.) public class SimpleSessionRecycler implements IoSessionRecycler { Map<Long, IoSession> map = Collections.synchronizedMap(new HashMap<Long, IoSession>()); public void put(IoSession session) { SocketAddress local = session.getLocalAddress(); SocketAddress remote = session.getRemoteAddress(); map.put(getKey(local, remote), session); } long getKey(SocketAddress local, SocketAddress remote) { long key = ((long) local.hashCode() << 32) | remote.hashCode(); return key; } /** * Attempts to retrieve a recycled [EMAIL PROTECTED] IoSession}. * * @param localAddress * the local socket address of the [EMAIL PROTECTED] IoSession} the * transport wants to recycle. * @param remoteAddress * the remote socket address of the [EMAIL PROTECTED] IoSession} the * transport wants to recycle. * @return a recycled [EMAIL PROTECTED] IoSession}, or null if one cannot be found. */ public IoSession recycle(SocketAddress localAddress, SocketAddress remoteAddress) { IoSession session = map.get(getKey(localAddress, remoteAddress)); return session; } public void remove(IoSession session) { map.remove(getKey(session.getLocalAddress(), session.getRemoteAddress())); } }
-- ..Cheers Mark
