We are using JBoss Fuse with Camel/Mina2 to handle TCP traffic from a
Northbound interface that sends XML. This is then processed via a Camel
route(Active MQ) towards Southbound in another format.
While load testing, we created 5000 individual TCP sessions (in ~3 secs.)
and for each of these sessions, the client sent the same one liner text
towards JBoss Fuse using Camel running Mina2. We configured the mina2 in our
blueprint as follows:
/<from
uri="mina2:tcp://{{mina-ip}}:{{mina-port}}?lazySessionCreation=false&noReplyLogLevel=OFF&exchangePattern=InOut&minaLogger=true&textline=true&textlineDelimiter=DEFAULT&filters=#keepAliveFilter{{ssl-context-parameters}}"/>/
What we notice is that the throughput (*The time that the message is
received for decoding to the time that it is sent to the ActiveMQ route;
essentially the time consumed by the textline codec*) just keeps increasing
exponentially. For the first call (of these 5000) to be processed by the
textline codec took 2 ms. and the last call took 7 *minutes*. We don't
understand why Mina2 is not able to handle this. The only relevant debug log
in ProtocolCodecFilter is:
/"Processing a MESSAGE_RECEIVED for session"/
which doesn't give a clue where the bottleneck is. Since textlineCodec is
the default for Mina2, we expected a great performance out of the box. So
this is a surprise.
Before diving in using a profiler, we just wanted run this question through
the users' forum to see if we might be overlooking any blind spots. All
ideas/tips are welcome.
--
View this message in context:
http://camel.465427.n5.nabble.com/Exponentially-growing-latency-while-processing-using-textline-codec-tp5790070.html
Sent from the Camel - Users mailing list archive at Nabble.com.
