Simon Trudeau wrote:
I am having trouble coming up with fool proof design because
currently, I must wait for the connection with the remote host to get
established.
What exactly must wait for the connection to be established, and why?
A: Sending a message to a remote host is a two step process. First the
connection with the remote peer needs to be established, second, the
message is sent. Since establishing a connection takes a long time
(assuming you have like me 1000 concurrent connections that you want to
establish), thus the business logic thread gets slowed down when sending
messages.
Is delivery of every message to every peer critical? I.e. can you afford
to lose messages? If not, how have you planned on handling longer
downtime of some peer that you are supposed to send messages to? If on
the other hand losing a message now and then is OK, then just don't send
messages to hosts that aren't connected.
I want to buffer the incoming requests while the connection gets
established and send them all once the session is created.
Why? Which events/calls in MINA are you talking about when you say
"while the connection gets established"? Also, what incoming requests?
The initial description only talks about broadcasting to servers.
A: Sorry, I meant outgoing request. So as not to block the business
logic thread when establishing a connection with a remote peer, I assume
the outgoing request need to be buffered while the connections get
established.
What should the business logic eventually do if a remote peer cannot be
reached? Also, have you planned your business logic so that you can use
non-blocking operations? Ie. is the state stores so that your business
processing can be resumed by some other thread later.
Anyway, connecting without blocking is simple, as Squee mentioned. Just
don't await() on the ConnectFuture, but add a listener that will
continue processing once the connection is established, or the
connection attempt fails.
