On 7/30/06, rhavyn <[EMAIL PROTECTED]> wrote:
Hello, I am working on integrating a EJB webservice endpoint into our messaging backend. However I'm having some performance issues. I'm using ActiveMQ in the GenericJMS Resource Adaptor with Glassfish.
FWIW ActiveMQ has its own Resource Adapter http://incubator.apache.org/activemq/resource-adapter.html
The problem I'm having specifically is getting a request/response interaction working at the speed we need it to. I've spent the past two days looking into it and what I'm seeing is that creating the MessageConsumer is taking a really long amount of time (on the order of 30-50ms).
These links might help http://incubator.apache.org/activemq/how-do-i-use-jms-efficiently.html http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html
So, I tried caching the Session, MessageProducer and MessageConsumer as the ActiveMQ wiki recommends,
If you are using EJB then you should be using JCA so that it's proxy ConnectionFactory does the connection/session pooling for you?
but that also fails because the EJB specification states that an EJB can only have 1 open Session per Connection. Thus, as soon as a second thread comes a long and tries to open a Session, everything breaks. Closed Sessions to me no good because they close the MessageConsumer too. Is there some best practice that is generally used when creating a request/response iteraction inside the EJB container? 30-50ms might not seem like much but when you need to send to four or five different queues to complete the webservice call, the 200ms delay causes our website to slow to a crawl. This is really frustrating because I can make the same set of calls using PHP and Stomp and the whole interaction takes less time then it takes just to instantiate a single MessageConsumer in Java.
If you are struggling with using JCA/Stomp you might want to just use Lingo (http://lingo.codehaus.org/) or write your own code which pools the connection/session/producer/consumer for doing request/response -- James ------- http://radio.weblogs.com/0112098/
