I have only just begun to examine the Mina code base and was hoping
someone could validate the following assumptions for me. What
follows is a mini design followed by my assumptions.
Mini Design :
=============
* What I want to acheive is a "MINA process" that accepts incoming
client connections, and then "buffers" them ready for a completely
separate process (eg outside the VM) which will ask for "any incoming
requests". The processing of requests and replies would be done
in a asynch manner.
* For the record this "separate process" is a commercial message broker
that talks other protocols but doesnt do native TCPIP sockets.
Hence the separation of TCPIP handling and the cross process
communication.
* The "MINA process" would accept client requests without reading them
or replying to them (timeout handling is assumed
here of course) . Rather the "MINA process" would "put the
"ProtocolSession" aside in a
memory table ready for later "reading and processing". (This might be
tweaked to read the request first but certainly not write a reply then
and there)
* The "outside process" would ask for "work" from ther MINA process at
its leisure, at which time the "MINA process" would "read" the data
from the "stored ProtocolSession" and pass that over to the "outside
process".
* Once the "outside process" had finished working on the "data" it
would "pass a reply back" to the "MINA process" and have the MINA
process "write" the reply data down the "stored" ProtocolSession.
Assumptions:
=============
* The ProtocolSession objects can be "stored" for later use and do not
have to read from nor written to immediately. Rather they can be
"set aside" and read from at some later asynch event (inside a timeout
periods of course)
* The use of 2 ThreadPoolFilters (the IO one and the Protocol
one) will enabled a level of "asynchronisity" to allow for "asynch"
servicing of requests.
* The "MINA" process can "listen" on more than 1 port at a time (one
for client request communication and one for "MINA process to outside
process" communication)
* Arbitary "periods" can occur between accepting/reading and writing to the Session objects.
Second Mini Design
================
* The MINA process could do the same sort thing as above but acting as
a client instead of
a server. eg the "outside prcocess" could ask for a client
connection
to be made to some other system. The MINA process would "call
out" as a client and then "store" the outbound Session somewhere.
* Multiple outbound "client calls" could be made with one or more
"selector" threads looking for potential replies, never waiting long
for any given reply. if it gets a reply message, it would read
the data and store it.
* The "outside process" would periodically ask for "replies" (using a
magic key assigned earlier) in which case any replies found with that
key would be returned.
Assumptions:
=============
* MINA can do client style connections as well as server style connections
* MINA code can have multiple outstanding "client connections" with a
"selector" thread that can "tell" when they have become readable?
* Multiple SocketConnectors would be the way to do this?
Cheers
Brad Baker
- [mina] How to delay reading and writing when using Mina Brad Baker
