Agreed... doing all IO through one thread is prob dumb. Like Synapse, I have a few threads listening, then I put the request through an "assembly line" to modify the request, then I proxy the request to the back-end server using another pool of threads, finally modifying the response before sending it back to the requestor.
Hopefully we will open-source this at some point as it is fairly generic. Bill- On Aug 26, 2011 1:01 PM, "Oleg Kalnichevski" <[email protected]> wrote: > On Fri, 2011-08-26 at 11:55 -0400, Bill Speirs wrote: >> I'm not trying to be pedantic, just trying to understand this... >> >> From the Synapse source code for HttpCoreNIOListener: >> 250 Thread t = new Thread(new Runnable() { >> 251 public void run() { >> 252 try { >> 253 ioReactor.execute(ioEventDispatch); >> >> From the source code for HttpCoreNIOSender: >> 195 Thread t = new Thread(new Runnable() { >> 196 public void run() { >> 197 try { >> 198 ioReactor.execute(ioEventDispatch); >> >> It appears to me that two threads are created for two different >> IOReactor objects: one for listening to incoming requests, and another >> for sending requests. While this is 100% acceptable (and close to what >> I'm currently doing), is it possible to have both running in one >> thread? How would the IOEventDispatch which would be handling >> everything know that connected() one time would mean that someone has >> connected to the server, and another time it meant a connection was >> made to the back-end service. Maybe through an attribute (and >> associated getAttribute call) in the IOSession? >> >> Thanks... >> >> Bill- >> > > You could do that, albeit with a bit of custom coding. You could extend > BaseIOReactor and add methods to open outgoing connections and listen > for incoming ones. The question is whether or not that would make a lot > of sense. Multi-core systems are commonplace nowadays. If all i/o events > were handled by one thread only one core could be utilized for i/o > operations, thus making the system less scalable. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
