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.
Using jstack i can see that the flow is:
"pool-1-thread-1" prio=10 tid=0x8f6c8c00 nid=0x20e3 in Object.wait()
[0x91f7d000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at
org.apache.mina.core.future.DefaultIoFuture.awaitUninterruptibly(DefaultIoFuture.java:133)
- locked <0xb4eabfa8> (a
org.apache.mina.core.polling.AbstractPollingIoConnector$ConnectionRequest)
at
org.apache.mina.core.future.DefaultConnectFuture.awaitUninterruptibly(DefaultConnectFuture.java:112)
at
com.tango.ssrv.itel.client.ItelConnectionFactory.makeObject(ItelConnectionFactory.java:57)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1148)
at
com.tango.ssrv.itel.client.ItelClient.writeMessage(ItelClient.java:72)
at
com.tango.ssrv.itel.service.impl.ItelServiceImpl.callItelServer(ItelServiceImpl.java:267)
at
com.tango.ssrv.itel.service.impl.ItelServiceImpl.processItelRequest(ItelServiceImpl.java:137)
at
com.tango.ssrv.itel.se.impl.ItelRequestMessageProcessorImpl.processMessage(ItelRequestMessageProcessorImpl.java:59)
at
com.tango.ssrv.itel.se.impl.ItelRequestMessageProcessorImpl.processMessage(ItelRequestMessageProcessorImpl.java:18)
at
com.tango.se.message.handler.impl.MessageProcessingHandlerImpl.handleMessage(MessageProcessingHandlerImpl.java:67)
at com.tango.se.handler.SeIoObserver.update(SeIoObserver.java:24)
at
com.tango.se.handler.SeObservableIoHandler.notifyObservers(SeObservableIoHandler.java:44)
at
com.tango.se.handler.SeObservableIoHandler.messageReceived(SeObservableIoHandler.java:92)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:752)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832)
at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:60)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
-----Original Message-----
From: Emmanuel Lécharny [mailto:[email protected]]
Sent: 14 August 2012 14:37
To: [email protected]
Subject: Re: Thread priorities between request and response
Le 8/14/12 2:03 PM, Brendan Crowley a écrit :
> My application is configured as below. Under high load, I've seen that
> responses build up and eventually cause OOM errors. Would i be correct to say
> that threadPoolFilter is given priority for requests more than responses?
You may have an issue when you are dealing with "slow readers" : the
writing queue may grow and grow if the client is not reading the
response fast enough.
Now, there is no simple ways to deal with such scenarios... The best
solution would be to start writing when the MessageSent event have been
received for the last message you've wrote.
It all depends on your server architecture too...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
