I was profiling my MINA-based application (which runs on CPU- and
memory-constrained machines) and determined that MINA uses a
surprisingly large number of threads (dozens of
DatagramAcceptor/AnonymousIoService threads). I had not configured MINA,
so I looked at the "Configuring Thread Model" documentation, but it
wasn't very helpful, in part since it is written for TCP applications.
As I understand things, most of MINA's defaults and its documentation
assume that the application is a stream-socket-based server where
connections can be handled roughly independently. The problem is that
I'm writing a UDP-based routing overlay network, meaning that I maintain
a single piece of state.
A single-threaded reactor would serve best for my application. While
there *are* fine-grained opportunities for concurrent handling of
packets, MINA has no awareness of the circumstances under which they may
be exploited, so concurrency should be left up to the application. As a
simplified example, based on a received message type, I may hand off a
long-running computation to a separate worker thread, but the norm is to
reply immediately. The dual, which is how things work currently, is that
usually multiple IO reactor threads contend for a global lock on the
state (introducing unnecessary synchronization overhead, memory
consumption, etc.), and occasionally a reactor thread does not require
the global lock and proceeds with the long-running computation.
It would be further beneficial if I could use the same reactor thread to
schedule tasks, rather than using a separate ScheduleExecutorService,
since these tasks end up executing in serial order anyway with packet
handling. I had posted previously about this:
http://www.nabble.com/Asynchronous-timeout-sleep-delay-etc.-tt12893472.html
Does anyone have advice on how to configure MINA to best suit my needs?
And if I can in fact configure everything to run in a single thread,
does MINA special-case this to introduce zero synchronization overhead?
I'd like to not remove MINA since time is short, but alas, time is short. :)
Thanks in advance.
--
Yang Zhang
http://www.mit.edu/~y_z/
