[kconner]

There is no hard coded poll period that I am aware of, rather there should be a maximum period for which the consumer waits before returning.

The real issue with the jms-provider is that there is a single thread pulling messages and then providing them to a thread pool to execute, done in this manner because some of the couriers requrie it.

If you replace jms-provider with the jms-jca-provider then you will have concurrent threads being 'pushed' by the JMS implementation.

How does this affect your tests?

Kev

[davesiracusa]

>> There is no hard coded poll period that I am aware of, rather there should be a maximum period for which the consumer waits before returning.

I took another look - In the source code, file: JmsGatewayListener.java, the doRun execution thread calles receiveOne which attempts to read from JMS using the overloaded receive with a 200 mSec timeout. I was incorrect, the latency is far shorter however measurable during my tests.  The latency is actually the setup to make the call over again (negligible), not 200 mSec as I originally thought.

>> The real issue with the jms-provider is that there is a single thread pulling messages and then providing them to a thread pool to execute, done in this manner because some of the couriers requrie it.

When I increased the maxThreads for each of the jms-listeners performance went up considerably.

>> If you replace jms-provider with the jms-jca-provider then you will have concurrent threads being 'pushed' by the JMS implementation.

I will try it, so I can compare the performance I originally achieved.  Thanks!

Best,

Dave

[kconner]

When I increased the maxThreads for each of the jms-listeners performance went up considerably

This is the size of the thread pool and controls how many concurrent pipeline requests can be performed.

I will try it, so I can compare the performance I originally achieved.  Thanks!

No problems, please let us know how it goes.

Kev

[davesiracusa]

I repeated my tests: I achieved 1570 TPM for the jms-jca-provider and 2800 TPM for the jms-provider.

--Dave

[kconner]

Interesting, every test we have done shows JCA inflow to be faster.  What is the test doing??

Kev

[davesiracusa]

I drop 1000 messages into a queue.  The messages have a unique number and timestamp.

The service displays the message, threadid and its own timestamp. 

It also performs 250 mSec worth of work.   

In order to get it to perform concurrently I set the number of maxthreads and jms pool sufficiently high.

Right now I'm running everything on one laptop. 

I'll be repeating some of my tests on server-based VMs in a week or so.

I'll let you know how it goes.

Best,

--Dave

[kconner]

Could you send me a copy of this test?

Kev

[davesiracusa]

Sure, I'll upload it tomorrow.  Its just a modified quickstart.

The jmeter test requires a bit of setup.  If you can do without it's probably best.

I created a custom Java Request object which creates a JMS Point to Point which allows me to include tokens in the command message.  Like %x = generate a incrementing number, %d = date, etc.  I also had to add all the jars to the jmeter lib directory, and modify a property file.

[davesiracusa]

I've attached the modified quickstart.