> > In the case I will need to implement the concurrency control > over the session, so that only one thread can use the > session, as sessions are implemented for serial use? Rght?
Yes, you should add your own concurrency control for the session. > > I tried the first case in which i implemented the > multithreading, each thread running its own session and each > session having one producer. But the results were not even > close to our requriment (result in msges/sec). > Were you using openwire or stomp as the protocol? We have seen cases where small messages with openwire cause extra delay due to the naggle algorithm and that message footprints are smaller than their stomp counterpart. If you're using openwire, I suggest you switch over to stomp and see if you have different results. If that does the trick, our next release will allow a user-specified TCP-NODELAY socket option that should fix the problem for openwire (for small messages). > Do you think the other case can give us the better results > (i.e. "The ActiveMQ-CPP implementation, however, will allow > you to share a session across threads.") > Without understanding your particular usage of the client, I would guess that a different usage wouldn't help much. Just to make sure, however, you could slightly modify our example application https://svn.apache.org/repos/asf/activemq/activemq-cpp/trunk/src/example s/main.cpp and see if you can get it to meet your requirements. Regards, Nate
