directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [mina] 0.8 vs 0.9
Date Sun, 06 Nov 2005 12:05:12 GMT
Hi Dave,

Sorry for this late reply. I almost forgot to reply to your message.

2005/11/3, Irving, Dave <>:
> Im trying to performance test my NIO Http server at the moment, and
> naturally I've written some clients which sit on Mina.
> With persistent connection testing out of the way, its time to see how
> fast we can go when connections are short-lived.
> I've noticed in Mina 0.8 that there doesn't seem to be a non-blocking way
> to make a connection to a server: something my client applications will
> definately need to do. Have I missed something?

You're right. MINA 0.9 supports the non-blocking way.

However, I got hold of the latest code from svn, and it seems this solves my
> problem: SocketConnector#connect no longer blocks the caller.
> Unfortunately, Im now faced with another problem: It seems we can no
> longer provide a marker object when writing to an IoSession (instead we now
> get returned a WriteFuture).
>  I was using this to mark a response as the "last for a connection". E.g,
> if I received a connection-close HTTP header, then when I get round to
> writing the response for that request I send a token object which signals
> the last response. When Im called back to be told that the data has been
> written, I can close the connection.
> I can see two ways of preserving this behaviour with the latest version,
> but both appear to be slightly problematic:
>  1) I use the ByteBuffer as the token. However, Im not sure if this is
> strictly safe (multiple threads scheduling the writes, buffer pooling etc)

You can use the ByteBuffer as a key until it is returned back to the pool.
It will be returned when your messageSent() (or messageReceived()) method
returns. So we can say it is safe. If you want to prevent it from being
returned, you can call setPooled(false) on it.

2) Block on the WriteFuture to wait for the op to complete. However, I dont
> want to block the thread which provides the response (an application
> thread), so Id need to add complexity (such as having another thread who's
> only job is to block on the WriteFuture and close the connection when the
> last write is complete).

You can simply choose the first one. :)

what we call human nature is actually human habit

View raw message