You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Fedechicco <fe...@gmail.com> on 2006/02/25 16:15:56 UTC

Re: [MINA] What about a cluster for network load balancing?

I have done that stuff, now it works like an IoAcceptor, and it works in
this way:

On the "network-farm" side:

there is an IoHandler (called ForwarderHandler) that need to be connected to
the thinking-block in some way ( by now with some Connector, but it can be
done with an Acceptor too ).
After a "centralConnection" is opened ( the connection to the
thinking-block), the ForwarderHandler will open the tcp ports required by
the thinking block, and then it will forward all the events (receive, close,
open, idle) of every new connection to the thinking block.
And this is all the story of the "network-farm" side.

On the "thinking-block" side:

I developed a IoAcceptor (called ForwarderAcceptor) that is a normal
acceptor on wich you can do the bind() and unbind() methods, as usual,
giving your own IoHandler (that I'll call GenericHandler) and setting your
own filterChains ( I copyed all this stuff from SocketAcceptor ).

ForwarderAcceptor have to talk with the network-farm side, and it does this
task with an IoHandler that works out the messages from and to the
network-farm.
ForwarderAcceptor have a method that return the IoHandler I have just talked
about, so you can do some little hack on it to do interesting thing, like a
tree structure of network-farms ( I'll explain it better ).
ForwarderAcceptor receives the connections of the network-farm programs and
receive from them the messages about the sessions handled.
And after all it forward this events to the GenericHandler, passing through
the appropriate chains.

And this is the end of the implementation.

Some features:
both IoHandler (the ForwarderHandler and the ForwarderAcceptorHandler) use
the same messages that are objects called ForwarderMessage.
Both them use ForwarderCodecFactory to translate messages into ByteBuffers.
In this way it is simple and performant to have a VmPipe connection between
ForwarderAcceptor and ForwarderHandler, you have only to not use the codec
at all.

By now it is not tested with more than one connection, and it do not provide
compression of data or the methods "writeToAll" or "writeToSessionGroup", so
by now it is just an "encapsuler", and by now it do not handle in the right
way the ByteBuffer acquire and release, so it doesn't work in VmPipe mode
because it throws IllegalStateExceptions, I have to work more on that.

It works on the lower level I can imagine, directly with ByteBuffers, so it
can be used to forward every kind of protocol.

Well, this is more or less all the news I can give you about this stuff, I'm
going to test it by my self with my applications, but I have to ask you
something.

There are news about SessionGroup implementation? Because I need it to do
the writeToAll methods, and I don't know how to manage the groups otherwise.

If somebody want to see the code I have written just ask me and I'll put it
on jira, but it is just a stub right now.

Found RC1 Binaries

Posted by Ole Ersoy <ol...@yahoo.com>.
Never mind on the RC1 Binaries Question.

I see all the mirrors are updated now.

There's even an RPM!  I'm impressed!

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com