directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <>
Subject [mina] 0.8 vs 0.9
Date Thu, 03 Nov 2005 10:21:12 GMT
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?
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
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).
Am I being stupid? Is there an easier way to do this?
Any advice would be appreciated...

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

View raw message