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

    Unresponse EPR for JMS

    Its Me Newbie

      This is continuation of :




      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:>,<wsa:ReferenceProperties jbossesb:java.naming.factory.initial :org.jnp.interfaces.NamingContextFactory/>,<wsa:ReferenceProperties jbossesb:java.naming.provider.url :>, <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:




      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


      <properties name="transports" depends="core">


      <property name="org.jboss.soa.esb.jms.connectionPool" value="50"/>



      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?




        • 1. Unresponse EPR for JMS
          Its Me Newbie

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


          Used following inVM parameters



             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.