mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brigham Stevens" <...@vikingmind.com>
Subject UDP Session Recyler Question
Date Wed, 23 May 2007 16:32:41 GMT
(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 {@link
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 {@link IoSession}.
     *
     * @param localAddress
     *            the local socket address of the {@link IoSession} the
     *            transport wants to recycle.
     * @param remoteAddress
     *            the remote socket address of the {@link IoSession} the
     *            transport wants to recycle.
     * @return a recycled {@link 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()));
    }
}


Mime
View raw message