Hi Emmanuel, Thanks for that, that makes sense, can you give me guidance as to how to replace the Executor Filter from the chain and use more IoProcessor instead?
Cheers, Brendan -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: 14 August 2012 16:23 To: [email protected] Subject: Re: Thread priorities between request and response Le 8/14/12 4:57 PM, Brendan Crowley a écrit : > The Client complains that it times-out receiving the response, so the > response is within the thread/queue. > If the client stops its load test (stops sending requests) the server is seen > to continue on to finally process the responses. > Rates currently tested are in the region of 4,000 transactions per second. We > would hope to aim for 10,000 transactions per second. > Architecture is pretty simple, as you can be in the applicationContext beans > in my earlier email. Here, what's is going to happen is that the client will totally flood the server with requests. The ExecutorFilter will process all the incoming requests in separate threads, and the response will be pushed back into a queue, until the client have all been processed. The client are being processed by an IoProcessor, which loop on the selector, and process first all the reads, then flush all the events back to the client. If the client does not read enough, the socket will be full, then we will loop again waiting for a OP_WRITE event to happen before being able to write some more data. But if the client sent data in the meantime, then those incoming data will be processed. It's obvisously easy to see how this can lead to an OOM. What if you remove the Executor Filter from the chain, and use more IoProcessor instead ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
