1 Reply Latest reply on Apr 25, 2011 11:14 AM by heyyou

Unresponse EPR for JMS

heyyou Apr 18, 2011 11:18 PM

This is continuation of :

http://community.jboss.org/thread/165618

When routing JMS messages from an inbound JMS queue to an outbound JMS queue and I apply load,

these messages will be generated:

12:01:12,450 WARN [ActionProcessingPipeline] No fault address definedfor fault message! To: InVMEpr [ PortReference < <wsa:Addressinvm://4a4d53506173737468727524242424242424242424242453696d706c654c697374656e6572/false?false#10000/>,<wsa:ReferenceProperties jbossesb:passByValue : false/> > ]MessageID: aa4d2b39-9c15-4f10-b27d-2a2ffad8b1fe RelatesTo:jms:correlationID#CLIENTH61_Thread0

12:01:12,491 INFO [ServiceInvoker] Unresponsive EPR: JMSEpr [PortReference < <wsa:Addressjms:127.0.0.1:1099#queue/DeadMessageQueue/>,<wsa:ReferenceProperties jbossesb:java.naming.factory.initial :org.jnp.interfaces.NamingContextFactory/>,<wsa:ReferenceProperties jbossesb:java.naming.provider.url :127.0.0.1:1099/>, <wsa:ReferencePropertiesjbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>,<wsa:ReferenceProperties jbossesb:destination-type : queue/>,<wsa:ReferenceProperties jbossesb:destination-name :queue/DeadMessageQueue/>, <wsa:ReferencePropertiesjbossesb:specification-version : 1.1/>, <wsa:ReferencePropertiesjbossesb:connection-factory : ConnectionFactory/>,<wsa:ReferenceProperties jbossesb:persistent : true/>,<wsa:ReferenceProperties jbossesb:acknowledge-mode :AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted: false/>, <wsa:ReferenceProperties jbossesb:type :urn:jboss/esb/epr/type/jms/> > ] for message: header: [ To:InVMEpr [ PortReference < <wsa:Addressinvm://4a4d53506173737468727524242424242424242424242453696d706c654c697374656e6572/false?false#10000/>,<wsa:ReferenceProperties jbossesb:passByValue : false/> > ]MessageID: b72a5a48-9a38-4006-b0bd-8f6d19f7acda RelatesTo:jms:correlationID#CLIENTH61_Thread0 ]

I'm just sending the same message repeatedly. It appears random when these

occur. In some cases, I can rerun the same test ( # of messages ) and I will get none of these

messages and in other cases I will get some random # of them. When the error occurs,

I do not receive all of the JMS messages from my outbound queue.

It seems like this could be related to an old JIRA:

https://issues.jboss.org/browse/JBESB-2255

that was associated with the webservice_producer quickstart. I see other postings

with similar messages but they do not seem to have a clear resolution.

The workaround was to increase the connectionPool beyond the default value.

I have updated the jbossesb-properties.xml in my ESB to

....

</property>

and undeployed and redeployed. I've tried values of 50, 75, 100, 200, 1000, 2000

will little impact.

This is a very vanilla configuration ( see http://community.jboss.org/thread/165618 ) for

simply routing JMS messages from one queue to another queue.

Anyone know how to get beyond this message when loaded is apply to the ServiceInvoker?

Is this a limitation with JBoss ESB?

Thanks,

Jon

1. Unresponse EPR for JMS

heyyou Apr 25, 2011 11:14 AM (in response to heyyou)

This appears to be a load issue when using the invmscope.

Used following inVM parameters

inVMLockStep
inVMLockStepTimeout ( values from 1000 to 10000 )

Since this does require more heap, I bumped the heap using values going to 16G ( which is getting on the excessive side for an ESB )
and made various GC tuning to minimize GCs.

I'm some cases, these messages would start to occur soon after a minor GC ( could be 1st, 2nd or 3rd minor GC). I can't say
that is the case 100% of the time, but is frequent. Looks like if the timing of JBoss ESB gets interupted (e.g., GC), thrown off or overloaded (too many messages) it starts to generate these errors. But the messages that are impacted occur at random times. That is, it could be 100, 200, or 1000.

If I use the do not is invmscope="GLOBAL", but instead use an "internal" queue as the gateway, the problem occur much less frequency ( the
messages are different in that they reference the queue names instead of invmepr ).

So it looks like you should not us invmscope="GLOBAL" for high volume ( 10K or higher ) messages.
Actions