This type of post comes up from time to time (too often ) , so it's worth searching through this forum for similar posts which have been posted before. A few points:
1) Please always report issues with TRUNK, as described on the wiki page "how to report an issue"
2) Try removing MDB and JCA from the picture, i.e. use a standard JMS consumer, not an MDB.
3) Measuring round trip time doesn't really give a pointer to the performance of the system. In most cases it just measures your network round trip or disk latency (sync rate - we'll come to this later). For instance, if my network has a round trip time (latency) of 0.1 ms, that means I can send a maximum of 10000 messages per second with a single producer. This is irrespective of the messaging system, it's a limit of your network. For a proper test you would need to either use async, or scale up with many producers/consumers. Real applications generally have more than one producer.
4) Your test isn't warming up. Microbenchmarks should always warm up before taking results. JIT can make a *huge* difference.
5) You are sending persistent messages to a persistent queue. By default HornetQ will make sure message data is durably persisted before returning from the send. JBoss Mesaging by default uses HSQL which *does not sync*. This has been discussed *at length* on several other threads.
Assuming you are using a normal disk what you should expect to see is around 200 msgs/sec. This is approx. the limit of a normal disk for write latency, and is a hardware limit. (I.e. your test will just measure the performance of your hardware not the messaging system)
For some more sensible benchmarks please take a look at the performance wiki page.
Thanks for the quick reply. Your response helped me a lot to find out key mistakes i have done.
Applogies for posting the same question again on the forum.
Thanks ans regards,