#2 more performance thoughts

[Jimmy P]

1. improve how we are currently doing I/O servicing for
multiple processor machines. right now we are creating
independent selectors and round-robin'ing connections.
this is suboptimal because there is no dynamic load
balancing possible with this method.

2. why use a write buffer on the server side? right
now messages are read into a datagram, output to a
write buffer, then output to a channel. we should be
able to blast from the read buffer onto destination
channels once we have determined what the routing
should be. i think this is another thing that points to
the need to create less garbage on a message server.
client-side garbage is inherent in the jms design and
the lack of restrictions placed on what clients can do
with messages (keep them around forever, modify them, etc.)

3. adding a pipe connection type would be really cool
to make in-process JMS'ing nicely lightweight. this
could be very significant for application designers, etc.

4. use non-blocking connect() and finishConnect()
instead of the blocking connect for better client side
I/O when making lots of connections. This is a low
priority.