to be more precise, the delay occurs between calling the "deliverySync" method and reaching the first "action" of the service-pipeline and then after executing the last "action" and returning the response message through the "deliverSync" method.
Has nyone encountered this problem before?
Which messaging system are you using? Is your messaging system backed by a database? Are you passing in a rather large object or large object graph, requiring significant work to serialize and deserialize? What about your registry? Is it rather full? (check the DB for entries which have not been cleaned up). Does RegistryUtil.getEPRs(category, service) respond in a reasonable time when executed in the same context as the call to deliverSync? Is deliverSync happening over a network?
Try turning on debug logging. The whole system will run more slowly, as a consequence, but you'll be able to see the relative times between operations and determine where the wait periods are.
That's how I would attack it, but perhaps one of the project developers has a better idea.
- No (simple/small xml)
i solved the problem as stated here:
5. Tuning for JMS listeners
here I changed the maxThread parameter to 10 for ServiceInvoker class and my problem got solved.
I have tried your change but it did nothing for performance locally. Just to be sure, could you look at the thread http://community.jboss.org/message/534575#534575 for me? There I have described the changes.
The maxThreads attribute tells the pipeline how many messages can be processed concurrently by the service pipeline, it is not specific to the ServiceInvoker although any deliverSync call would need to wait on the service to provide the result. By default this is set to 1, so the service requests will be handled concurrently.
If you are using JMS for your service then also try jms-jca-provider rather than jms-provider, as this performs better within a server environment.