Hi Emmanuel I would like to go back the scenario for outgoing messages. If the application sends a request to an external server and we specify ExecutorFilter in the filter chain, we can decouple the processing from the IO handling. (But)
As most of the time we have to handle problematic cases, we need to know whether we send the request successfully or not. (There might be state update about the request, need to confirm somewhere else in the system about send operation etc) This code is shown in the WriteFuture javadoc with join/awaitUnterruptibly method and checking return value of isWritten. My question: What is the possible benefit of allocating/dedicating 2 threads to send one request if we need to know what is going on underlying transport layer? Do I miss something if I use my business thread to wait on writeFuture coming from AbstractIOSession instead of introducing ExecutorFilter? Thanks Erkin On Tue, Apr 28, 2009 at 7:18 AM, Emmanuel Lecharny <[email protected]>wrote: > David Rosenstrauch wrote: > >> David Rosenstrauch wrote: >> >>> David Rosenstrauch wrote: >>> >>>> Still, wouldn't it also make sense to have a thread pool on writes as >>>> well? That way once a message has been processed, the reader/processor >>>> thread can just dump the response message into a queue for output, thereby >>>> freeing up the reader thread to process new incoming messages. Seems like >>>> in >>>> theory you could handle a lot more message throughput by decoupling message >>>> reading from writing like this. >>>> >>>> Am I offbase in my assumptions here? >>>> >>>> Thanks, >>>> >>>> DR >>>> >>> >>> Hmmm .... answering my own question a bit here, but: >>> >>> The MINA javadocs state: >>> >>> IoSession.write(Object message): >>> >>> "Writes the specified message to remote peer. This operation is >>> asynchronous; IoHandler.messageSent(IoSession,Object) will be invoked when >>> the message is actually sent to remote peer. You can also wait for the >>> returned WriteFuture if you want to wait for the message actually written." >>> >>> So then this is already happening in a separate thread than the reader, >>> and so there's no need for a separate writer thread pool? >>> >>> Confused .... >>> >>> DR >>> >> >> >> Actually, I went digging in the code tonight ... and it looks like even if >> you add an ExecutorFilter with the intention of having socket writes occur >> in a separate thread, MINA won't let that happen. >> >> Apparently as per the code in DefaultIOFilterChain.HeadFilter, all writes >> are getting done by the filter at the head of the chain. The head filter >> puts the write request into a request queue, and the IoProcessor executes >> the request in one of its threads, and not in one of the executor filter's >> threads. >> >> So looks like adding a thread pool for writes is a completely useless >> thing to do. >> >> I guess I understand why the code is written this way - all IO should get >> done in one of the IOProcessor threads. But it does seem a bit confusing >> and misleading for it to be allowable to add an executor filter which will >> accomplish nothing. >> >> DR >> >> DR >> >> MINA uses IoProcessor to handle incoming requests. When you instanciate > the server, more than one of these objects are created, so you can process > more than one request at the same time. Each of those IoProcessor has its > own selector, but then, you should consider that the processing of one > request is done in one single thread, ie the IoProcessor thread. More than > that, each session is associated with a single IoProcessor object, so it > can't be processed by another IoProcessor instance. > > That being said, you may need to decouple the processing from the IO > handling. For instance, assuming that you may have a lot of small and fast > requests to process, plus from time to time one big expensive and CPU > consuming request, you may want to free the IoProcessor as fast as possible > for the small requests to be processed quickly. This is what the Executor > filter is good for. When you add such a filter in the chain, it simply > enqueue all the requests and ask a thread pool to process them, letting the > IoProcessor doing its job quickly. > > In any case, when the request has been processed, the response is written > into a queue by the executor thread, AFAICT. As the write is done at the end > of the processing (in your IoHanlder implementation), it's still traversing > the chain using the thread selected by the executor filter, up to the point > the request is written to the queue. Then the execution stack is unfold. It > seems a bit complex, and it might have been a bit better to separate the > incoming and outgoing chains, but at least, it does the job. > > I hope I brought some faint light about the way MINA is working from the > inside out. Just tell me if it's enough for waht you need. > > Thanks ! > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
