Here are the answers to your questions:

Simon Trudeau wrote:
> I am currently writing an apache mina 2.x-M3 high performance client.
> This client connects and broadcast to 1000 different servers 
> concurrently.

Presumably you have some requirements about the reliability of the
broadcase, otherwise I'm not sure I see the problem here. Please
elaborate - I've added some questions below :)

> 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.

> 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.

> I also want to be able to handle cases where I am reconnecting to the 
> remote host.

How and why is this different from initially connecting to the same
host?

> Anyway, are there example out there of robust mina client connection 
> handling, something that properly handles concurrency scenarios?

Most likely not. However, it's hard to say since I don't really
understand what you want, and why.

A: That would be really nice to post "production code" example of
connection management and sending!


Thanks,


Simon

Reply via email to