On Wed, 15 Oct 2008 12:12:42 +0200 Lorenz Breu <[EMAIL PROTECTED]> wrote:
> Hi Julien, hi list > > OK, so polling won't work with java.io streams... So I was thinking > about just implementing a non-polling basic set of IoProcessor, > IoAcceptor and IoSession using java.io. My first set of questions > concern the threading issues: > A MINA application creates an acceptor, configures it and binds it. > So the acceptor then waits for connections...then the accept() method > fires and a new session is passed... to whom? then the session reads > data, passes it through the filter chain to the registered handler, > who then processes the data (application logic). the handler gets > kicked off when data is ready to be processed. So what I haven't been > able to figure out is the threading model. The polling processors > just keep checking if data is available, if it is then the worker > thread calls process() which I guess kicks off the whole chain of > filters and the ultimate handler in a separate thread. But if I use > ServerSocket and java.io Streams, then I won't be able to poll them > for read/write readiness, I just have to run ServerSocket.accept() to > get a Socket and then read/write. The question now is if I have to > use a ThreadPool or something to process incoming connections, or if > MINA already spawns a new thread on Acceptor.accept()... Sorry to > bother you with these questions, I just want to find a starting > point. At the moment I am basically flipping through classes with a > big question mark on my forehead ;) > > Regards, > Lorenz I think it's possible to write a java.io based transport (not based on AbstractPollingXXXX) but it's prolly a bit complicated. I think the simplest is perhaps to use new NIO2 API for multicast and jsut extends current NioDatagram.. classes Julien
signature.asc
Description: PGP signature
