ReDelivery

          I have 10 machines executing a stand alone java application listening for messages
          on a queue(asynchronously) defined on WLS 7 sp1.
          These apps receive the message and process them. They use transacted sessions.
          After processing every message they issue
          session.commit.
          When they are processing these messages I have terminated the app on 3 machines,
          assuming that the messages they are processing will go back to the queue and one
          of the other 7 machines will pick these messages. Unfortunately that is not happening.
          But when I see the console it shows a nonzero pending message count against the
          queue. But if I restart my WL server application and restart my listener app the
          pending messages are processed.
          My connectionactory is defined as
          <JMSConnectionFactory JNDIName="test/QueueConnectionFactory"
          Name="TestQueueConnectionFactory" Targets="testserver" UserTransactionsEnabled="true"/>
          My transaction timeout is set to 600Secs.
          I have researched this newsgroups and someone had the exact same problem in WL
          6.1 and the case# is CR080301.
          Any ideas anyone?
          

Transacted sessions use their own internal transaction, the timeout
          for which is set on the connection factory in the TransactionTimeout
          field and defaults to 3600 seconds (1 hour). You mention
          600 seconds below, but I don't see it in your Connection Factory
          settings...
          The CR you posted seems unrelated - it makes no mention
          of killing the clients.
          Never-the-less I think that a transacted session's transaction
          should rollback as soon as the session is killed - no matter
          what the timeout.
          And so I suspect you may be running into a bug where JMS connections may
          not get cleaned up when clients are killed - a bug that is
          unique to 7.0SP1. I suggest contacting customer support
          for a patch.
          Tom, BEA
          Kishore wrote:
          > I have 10 machines executing a stand alone java application listening for messages
          > on a queue(asynchronously) defined on WLS 7 sp1.
          >
          > These apps receive the message and process them. They use transacted sessions.
          > After processing every message they issue
          > session.commit.
          >
          > When they are processing these messages I have terminated the app on 3 machines,
          > assuming that the messages they are processing will go back to the queue and one
          > of the other 7 machines will pick these messages. Unfortunately that is not happening.
          > But when I see the console it shows a nonzero pending message count against the
          > queue. But if I restart my WL server application and restart my listener app the
          > pending messages are processed.
          >
          > My connectionactory is defined as
          >
          > <JMSConnectionFactory JNDIName="test/QueueConnectionFactory"
          > Name="TestQueueConnectionFactory" Targets="testserver" UserTransactionsEnabled="true"/>
          >
          > My transaction timeout is set to 600Secs.
          >
          > I have researched this newsgroups and someone had the exact same problem in WL
          > 6.1 and the case# is CR080301.
          >
          > Any ideas anyone?
          >
          >
          >
          

Similar Messages

  • JMS - How to configure incremental redelivery intervals for an MDB

    Hi all,
    I noticed that when message delivery in an MDB fails, the time to the next delivery attempt for the message increases with every failed delivery. The intervals are 5, 10, 20, 40 and 60 seconds. After this the interval stays at 60 seconds.
    Now I was trying to find out how to change this behavior, but did not find the appropriate configuration elements in the console or the documentation. What I found are the options to configure "Default Redelivery Delay" in the ConnectionFactory which is set to 0 and in the Queue "Redelivery Delay Override" which is set to -1.
    Both of these settings do not explain the incremental delay. Can anyone tell me how to configure this? Is that part of the MDB deployment descriptors?
    Thanks,
    Chris

    Hi Tom,
    thanks again for your answer :-) I am sorry, i forgot to mention in my initial post, that i had a look at those parameters. But according to the documentation the default values for both are 60 seconds. In my MDB i did not set any of those, so it should not start at 5 seconds like it does but at 60 seconds. Additionally this suspension, I if understood correctly, should only kick in if the JMS resource (I figure this is the queue in this case) is unavailable, which is not the case in my scenario. And as a third the suspension described there is not growing exponentially as I experienced.
    Sorry if I am just thick here, but the documentation just does not look like what I am looking for. Are there any misunderstandings on my side?
    Thanks, Chris

  • Redelivery of message ,If there is an exception in onMessage() method

              Hi ,
              Is it possible to send acknowledge from the onMessage() method of any MDB to the
              JMS server (Queue). And how to make JMS server redeliver the message ? What properties
              are to be set for this in Weblogic server ,JMS server . And do we need to do modify
              onMessage() method . If anybody has the code snippet and properties setting ,pleas
              let me know .
              TIA
              Prabir
              [redelivery.txt]
              

    If MDB is transactional, you can call setRollbackOnly() on it (not sure of exact syntax),
              this is
              standard J2EE.
              If it is not transactional you can throw a RuntimeException (such as
              ArrayIndexOutOfBounds, etc)
              this will force a redelivery. (J2EE provides no standard here, but BEA does the sane
              thing here.)
              Note that 6.1 and above provides optional redelivery delays and redelivery limits.
              Tom
              Prabir wrote:
              > Hi ,
              > Is it possible to send acknowledge from the onMessage() method of any MDB to the
              > JMS server (Queue). And how to make JMS server redeliver the message ? What properties
              > are to be set for this in Weblogic server ,JMS server . And do we need to do modify
              > onMessage() method . If anybody has the code snippet and properties setting ,pleas
              > let me know .
              > TIA
              > Prabir
              >
              > ------------------------------------------------------------------------
              > Name: redelivery.txt
              > redelivery.txt Type: Plain Text (text/plain)
              > Encoding: base64
              

  • Redelivery of messages to JMS queue

    Hi,
              I am using weblogic 9.2 JMS and MDB for processing messages from queue. Only one instance of Container Managed MDB is running and the important point is that queue sequence should be maintained. I have a problem now. Each message will be picked by MDB and does some db lookups and it is sent over to another system. If there is any communication failure, the message has to be redelivered back to the front of the queue so that sequence is not lost. Even the same message is failing for more than one time, it should still be placed at the front of the queue becoz there is another mechanism that will pause the queue in case of communication exception.
              I tried with throwing Runtime exception but it is crashing the MDB and is getting deployed again which I think is not the right approach.
              I had set the transaction attribute as Required and tried to do setRollBackOnly on that for any exceptions but the message is not in the front of the queue. It is going to the back or somewhere in the queue.
              I also tried to put the message back with higher priority but did not seem to work.
              I have the redelivery delay as 0, I am not sure if I am missing any configuration settings. Pls let me know if there is a way to redeliver the message to the front of the queue for any exceptions in the message procesing by MDB.
              Thanks
              Srini

    Srini,
              WebLogic JMS' Unit-of-Order (UOO) feature was very specifically designed to handle strictly ordered message processing. The feature ensures that messages with the same UOO name are processed strictly in order - regardless of the number of concurrent consumers, redelivery delays, rollbacks, etc.
              If the entire queue is to be processed single threaded, you can very simply configure a default UOO for the queue, otherwise there are a variety of other UOO options. A good place to start is the JMS developer guide's UOO chapter.
              And yes, "setRollbackOnly" is the best way to force a rollback of an MDB CMT.
              Tom

  • Redelivery limit not working for transaction timeout?

    hi,
              we have a redelivery limit on a queue that works, except for when there is a transaction timeout. in this case, the message seems to be redelivered infinitely. Is this a bug? a feature?
              we are using Weblogic Server 8.1 SP4. we don't have the source code, so i am not sure how the error handling is done or what exceptions are thrown.
              ------------------ejb-jar.xml------------
              <message-driven>
              <ejb-name>ImporFileReceiver</ejb-name>
              <ejb-class>au.com.auspost.pcms.common.integration.ejb.mdb.ImporFileReceiverMdb</ejb-class>
              <transaction-type>Container</transaction-type>
              <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              <subscription-durability>NonDurable</subscription-durability>
              </message-driven-destination>
              </message-driven>
              <container-transaction>
              <method>
              <ejb-name>ImporFileReceiver</ejb-name>
              <method-intf>Local</method-intf>
              <method-name>onMessage</method-name>
              <method-params>
              <method-param>javax.jms.Message</method-param>
              </method-params>
              </method>
              <trans-attribute>NotSupported</trans-attribute>
              </container-transaction>
              <container-transaction>
              <method>
              <ejb-name>ImporFileReceiver</ejb-name>
              <method-intf>Remote</method-intf>
              <method-name>onMessage</method-name>
              <method-params>
              <method-param>javax.jms.Message</method-param>
              </method-params>
              </method>
              <trans-attribute>NotSupported</trans-attribute>
              </container-transaction>
              ------------------------ weblogic-ejb-jar.xml ---------
              <weblogic-enterprise-bean>
              <ejb-name>ImporFileReceiver</ejb-name>
              <message-driven-descriptor>
              <pool>
              <max-beans-in-free-pool>10</max-beans-in-free-pool>
              <initial-beans-in-free-pool>10</initial-beans-in-free-pool>
              </pool>
              <destination-jndi-name>jms/pcmsImportFileQueue</destination-jndi-name>
              <connection-factory-jndi-name>jms/pcmsConnectionFactory</connection-factory-jndi-name>
              </message-driven-descriptor>
              <transaction-descriptor>
              <trans-timeout-seconds>3600</trans-timeout-seconds>
              </transaction-descriptor>
              <reference-descriptor>
              </reference-descriptor>
              <dispatch-policy>pcms.execute.queue.mdb.internal</dispatch-policy>
              <remote-client-timeout>0</remote-client-timeout>
              </weblogic-enterprise-bean>
              ------------------------ config.xml -----------------
              <JMSServer Name="eParcel JMS server"
              Store="eParcel JMS Server File Store" Targets="wls_pcms_prod1">
              <JMSQueue CreationTime="1190981682976"
              ErrorDestination="PCMS Import File Error Queue"
              JNDIName="jms/pcmsImportFileQueue"
              Name="PCMS Import File Queue" RedeliveryLimit="2"/>
              <JMSQueue CreationTime="1208347415759"
              JNDIName="jms/pcmsImportFileErrorQueue" Name="PCMS Import File Error Queue"/>
              </JMSServer>
              <JMSConnectionFactory JNDIName="jms/pcmsConnectionFactory"
              Name="eParcel JMS Connection Factory" Targets="wlc_pcms_prod"/>
              <JMSConnectionFactory JNDIName="jms/pcmsXAConnectionFactory"
              Name="eParcel JMS XA Connection Factory" Targets="wlc_pcms_prod" XAConnectionFactoryEnabled="true"/>
              -------------- weblogic log ---------------
              ####<24/04/2008 01:53:58 PM EST> <Warning> <EJB> <HX415> <wls_pcms_prod1> <ExecuteThread: '12' for queue: 'weblogic.kernel.Default'> <project_admin> <> <BEA-010065> <MessageDrivenBean threw an Exception in onMessage(). The exception was:
              javax.ejb.EJBException: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 3599 seconds
              Name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)],Xid=BEA1-696C9947A48195BA18DC(68926234),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3599,seconds left=60,activeThread=Thread[ExecuteThread: '12' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@447373e,re-Registered = false),SCInfo[wlsd_auspost_prod+wls_pcms_prod1]=(state=active),properties=({weblogic.transaction.name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)], weblogic.jdbc=t3://10.3.2.35:7003}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+, XAResources={JMS_eParcel JMS Server File Store, weblogic, wlsd_auspost_prod, com},NonXAResources={})],CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+)
              at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(I)V(ServerTransactionImpl.java:1614)
              at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(Ljava/util/List;I)V(ServerTransactionManagerImpl.java:1117)
              at weblogic.transaction.internal.TransactionManagerImpl.wakeUp()V(TransactionManagerImpl.java:1881)
              at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp()V(ServerTransactionManagerImpl.java:1034)
              at weblogic.transaction.internal.WLSTimer.trigger(Lweblogic/time/common/Schedulable;)V(WLSTimer.java:31)
              at weblogic.time.common.internal.ScheduledTrigger.run()Ljava/lang/Object;(Optimized Method)
              at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic/security/subject/AbstractSubject;Ljava/security/PrivilegedAction;)Ljava/lang/Object;(Optimized Method)
              at weblogic.security.service.SecurityManager.runAs(Lweblogic/security/acl/internal/AuthenticatedSubject;Lweblogic/security/acl/internal/AuthenticatedSubject;Ljava/security/PrivilegedAction;)Ljava/lang/Object;(SecurityManager.java:121)
              at weblogic.time.common.internal.ScheduledTrigger.executeLocally()V(ScheduledTrigger.java:229)
              at weblogic.time.common.internal.ScheduledTrigger.execute(Lweblogic/kernel/ExecuteThread;)V(ScheduledTrigger.java:223)
              at weblogic.kernel.ExecuteThread.execute(Lweblogic/kernel/ExecuteRequest;)V(Optimized Method)
              at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
              at java.lang.Thread.startThreadFromVM(Ljava/lang/Thread;)V(Unknown Source)
              ; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 3599 seconds
              Name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)],Xid=BEA1-696C9947A48195BA18DC(68926234),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=3599,seconds left=60,activeThread=Thread[ExecuteThread: '12' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@447373e,re-Registered = false),SCInfo[wlsd_auspost_prod+wls_pcms_prod1]=(state=active),properties=({weblogic.transaction.name=[EJB au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean.handleMessage(org.apache.xmlbeans.XmlObject)], weblogic.jdbc=t3://10.3.2.35:7003}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+, XAResources={JMS_eParcel JMS Server File Store, weblogic, wlsd_auspost_prod, com},NonXAResources={})],CoordinatorURL=wls_pcms_prod1+10.3.2.35:7003+wlsd_auspost_prod+t3+).

    Thanks Tom,
              Good point. The timeout exception is on ImportFileHandlerBean.handleMessage()....which is a session bean. The MDB must call this session bean, which also has a 3600 second timeout. It is confusing since the descriptor for the MDB has the transaction-timeout set, but i assume this is ignored for 'not-supported').
              I guess you would need to look at the code, but is there anyway a message go back on the queue, and not get the redelivery incremented?
              (I just had an evil thought...maybe the code could be physically sending the message onto the queue again when there is a timeout on the session bean.....hence would not get the redelivery incremented.....)
              -------------- ejb-jar.xml ----------------
              <session>
              <ejb-name>ImportFileHandler</ejb-name>
              <local-home>au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerLocalHome</local-home>
              <local>au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerLocal</local>
              <ejb-class>au.com.auspost.pcms.common.integration.ejb.ImportFileHandlerBean</ejb-class>
              <session-type>Stateless</session-type>
              <transaction-type>Container</transaction-type>
              </session>
              ----------- weblogic-ejb.jar.xml -----------
              <weblogic-enterprise-bean>
              <ejb-name>ImportFileHandler</ejb-name>
              <stateless-session-descriptor>
              </stateless-session-descriptor>
              <transaction-descriptor>
              <trans-timeout-seconds>3600</trans-timeout-seconds>
              </transaction-descriptor>
              <reference-descriptor>
              </reference-descriptor>
              <enable-call-by-reference>True</enable-call-by-reference>
              <local-jndi-name>ejb/ImportFileHandlerLocal</local-jndi-name>
              <remote-client-timeout>0</remote-client-timeout>
              </weblogic-enterprise-bean>

  • Trying to understand message redelivery

    Hi,
    I'm trying to understand redelivery.
    I'm using JMS to sync user data from our J2EE system with our Lotus Domino system. I want to be sure that in the advent of any failure in this the sync-ing process, a notification is sent to ensure that at least the Notes Domino stuff can be sync-ed manually by an administrator.
    So my question is how to be sure to capture and send notification of EVERY failure with the information needed to manually sync if needed?
    As I understand it, it's my responsiblity to ensure that I handle all Exceptions in the onMessage() method of our MessageListener implementation - without throwing any new Exceptions. I do this so I'm confident that things like a Notes Session not being instantiated, or a Notes document not being found are handled and notifcation sent. The result is that if an Exception occurs at this level, I handle it and as far as JMS is concerned the message was consumed and got acknowledged. Right?
    But what about messages that fail before the MessageListener is reached - presumeably a problem with the JMS provider (we're using WebLogic 6.1). Can I just rely on JMS to redeliver failed messages and not worry about them? Is there a recommended way to test such failure so I can be sure what happens? I tried throwing a RuntimeException in the onMessage() method, but I did not observe any attempts to resend the message and when I browsed the queue it was empty.
    So as you can you see, I'm unclear about this! Appreciate and clarifying points!
    Terrence

    You can rely on the JMS provider to take care of it's own failures. However, please note that the JMS provider can fail right after you have successfully done your work in onMessage - but before the message acknowledgement happens. This means that in case of failure, you may get the last consumed message again.
    Also note that different JMS providers will handle RuntimeException's raised from onMessage differently, so check your vendor's documentation. After a couple of re-tries, your JMS provider might for instance deem that the receiver/subscriber has a problem consuming said message and move the message into an error queue.
    - Bjarne.

  • Pending message redelivery wait period after server startup

    Hi, I have seen an strange behaviour in the way pending JMS messages are
              redelivered to MDBs at server startup.
              In my unit test I have seen that, killing Weblogic during an MDB code
              execution as expected makes the container to redelivery unconfirmed message
              at server startup. I have also seen that it's redelivered about 4 minutes
              after server is started (more info of this in thread: "Problem with
              persistent messages and MDBs" 25 October 2002)
              After a recent crash we have had on the system in wich there were a lot of
              messages pending to deliver to an MDB we saw that they were being
              redelivered just after the MDBs were deployed while system was starting. Of
              course due to the fact that some components needed by the MDB were not
              deployed by that time, a lot of exceptions were raised making messages to be
              queued again and promptly delivered wich caused more exceptions. Just a big
              mess!
              I'm tring to figure a good work-around about this, what I wanted to know is
              how is implemented the "delay" to send messages after server startup. Is it
              done by comparing timestamp of message (when did it enter the queue and
              thereby persisted on the store) with current system time?. That approach of
              course will fail if any of the messages were sent before that "delay" time.
              If this is the case and there isn't a fix for it this is what I have in
              mind:
              Each MDB will have a private attribute wich will be used to detect when
              system has completely started. By default it will be false and after a
              message is sent to the MDB the first line of the onMessage method will test
              wether system has started or not (by checking weblogic connection port i.e.
              7001. Btw. is there any better way of checking server has finished start-up)
              if not, a runtime exception will be launched that will force message to be
              redelivered (without trying to execute any MDB code), I think setting a
              proper redelivery delay i.e. 30-60 secs. will allow server to startup with
              less problems (in the situation I described above JVM crashed with an 11
              system signal)
              Any other ideas to deal with this?
              Thanks in advance.
              Regards.
              Ignacio.
              

    Hi Ignacio,
              I think you can usually control the order in which ejb's are booted,
              through a combination of console settings and
              meta file entries. I suggest posting to the ejb newsgroup
              to find out how.
              The four minute delay you see is normal for resolving
              interrupted transactions, but I believe that an enhancement
              was put into a 7.0 SP to reduce or eliminate this interval,
              and that 8.1 has no interval. Post to the transaction
              newsgroup for more info, or contact customer support.
              Given that you referenced earlier posts on this issue, you
              probably already know how to tune the interval down to one
              minute even without the enhancements.
              There is no other delay for sending messages at system startup,
              as soon as the MDB is booted it attaches to JMS, and JMS
              starts delivering messages whose transactional state is known.
              Tom
              P.S. I suppose one way to detect end-of-boot is to
              place a startup class last in the boot order.
              P.P.S. For MDBs one alternative is to code a "sleep" in the onMessage if
              an unavailable resource is detected - this
              is hokey, but works as long as you have made sure that
              max-beans-in-free-pool totals do not come near or exceed
              available thread pool size.
              Ignacio G. Dupont wrote:
              > Hi, I have seen an strange behaviour in the way pending JMS messages are
              > redelivered to MDBs at server startup.
              >
              > In my unit test I have seen that, killing Weblogic during an MDB code
              > execution as expected makes the container to redelivery unconfirmed message
              > at server startup. I have also seen that it's redelivered about 4 minutes
              > after server is started (more info of this in thread: "Problem with
              > persistent messages and MDBs" 25 October 2002)
              >
              > After a recent crash we have had on the system in wich there were a lot of
              > messages pending to deliver to an MDB we saw that they were being
              > redelivered just after the MDBs were deployed while system was starting. Of
              > course due to the fact that some components needed by the MDB were not
              > deployed by that time, a lot of exceptions were raised making messages to be
              > queued again and promptly delivered wich caused more exceptions. Just a big
              > mess!
              >
              > I'm tring to figure a good work-around about this, what I wanted to know is
              > how is implemented the "delay" to send messages after server startup. Is it
              > done by comparing timestamp of message (when did it enter the queue and
              > thereby persisted on the store) with current system time?. That approach of
              > course will fail if any of the messages were sent before that "delay" time.
              >
              > If this is the case and there isn't a fix for it this is what I have in
              > mind:
              >
              > Each MDB will have a private attribute wich will be used to detect when
              > system has completely started. By default it will be false and after a
              > message is sent to the MDB the first line of the onMessage method will test
              > wether system has started or not (by checking weblogic connection port i.e.
              > 7001. Btw. is there any better way of checking server has finished start-up)
              > if not, a runtime exception will be launched that will force message to be
              > redelivered (without trying to execute any MDB code), I think setting a
              > proper redelivery delay i.e. 30-60 secs. will allow server to startup with
              > less problems (in the situation I described above JVM crashed with an 11
              > system signal)
              >
              > Any other ideas to deal with this?
              >
              > Thanks in advance.
              >
              > Regards.
              >
              > Ignacio.
              >
              >
              

  • How to set maximum redelivery count

    hi,
    Within my JCD I am throwing an exception to roll back a message so that it will be redelivered in case of an error. From the log I can see that the message is redelivered.
    Now, I'm trying to find a way to set the maximum redelivery count within the JCD. Or a better way maybe find out how many times the message has been redelivered, so I can send it to a dead message/error queue when it reaches a certain number.
    Is this possible? Has anyone done similar thing?
    thanks
    Ari

    For JCAPS 5.1.1 see
    <CAPSInstallRoot>/lofgicalhost/extra/JMSJCA-readme.html, section named
    Redelivery Handling (deadletter queue).
    Thanks Frederic :-)

  • Move to error queue after certain redelivery limit

    Hi,
              I am newbie to Weblogic. I am currently using Weblogic8.1.4.
              I have written an MDB say mdbx which listens on a specific queue say QA, once it receives a message it will send this message to another queue QB. I have configured the queue QA such that it will try to redeliver the message 3 times to QB, if it fails in its first attempt. I have also configured an error queue to which the message should finally be placed when all the 3 attempts fails.
              My problem is, i find the redelivery limit and error queue i have configured for queue QA doesn't take effect. Please help me to resolve this.
              More Info:
              I am trying to send message from mdbx on the onMessage() method.
              Thanks and Regards
              A.SathishKumar

    Please refer : http://www.javaoracleblog.com/java/How_to_set_minimumDelayBetweenMessages_for_delay_between_messages_for_JCA_adapters.jsf

  • Configuring message redelivery with jmcjca (sun-jms-adapter) in Glassfish

    I use Glassfish v2 server and its OpenMQ as JMS Provider.
    My MDB is configured to use sun-jms-adapter for accessing JMS Provider.
    ra.xml of adapter wasn't change so all configuration is done through the sun-ejb-jar.xml of my MDB.
    Type of destination my MDB listens to is javax.jms.Topic.
    At the same time, I have defined the following redelivery strategy in the sun-ejb-jar.xml
    <activation-config-property>
    <activation-config-property-name>RedeliveryHandling</activation-config-property-name>
    <activation-config-property-value>2:1000; 3:move(queue:*psdmqqueue*)</activation-config-property-value>
    </activation-config-property>
    psdmqqueue is an administred server Destination of type javax.jms.Queue. So a target destination of MDB is topic and redelivery should be performed to queue
    The problem is that application deplyment failes with this configuration with the following exception:
    #|2008-11-22T18:38:48.152+0300|WARNING|sun-appserver9.1|com.stc.jmsjca.core.Activation|_ThreadID=169;_ThreadName=JMSJCA connect;_RequestID=ed86af75-1577-4548-ac57-60ca127a28a2;|JMSJCA-E016: [sync-Durable TopicSubscriber(provisioning_subscription)(lookup://targetTopic) @ [mq://localhost:7676/jms]]: message delivery initiation failed (attempt #85); will retry in 10 seconds. The error was: java.lang.ClassCastException: com.sun.messaging.jmq.jmsclient.XATopicSessionImpl
    java.lang.ClassCastException: com.sun.messaging.jmq.jmsclient.XATopicSessionImpl
    at com.stc.jmsjca.core.RAJMSObjectFactory.createDestination(RAJMSObjectFactory.java:423)
    at com.stc.jmsjca.core.Delivery.createDLQDest(Delivery.java:626)
    at com.stc.jmsjca.core.SyncDelivery.start(SyncDelivery.java:204)
    at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:535)
    at com.stc.jmsjca.core.Activation.access$000(Activation.java:80)
    at com.stc.jmsjca.core.Activation$1.run(Activation.java:343)
    at java.lang.Thread.run(Thread.java:595)
    Could you please help me to figure out what is wrong with my configuration?
    Part of sun-ejb-jar.xml related to ra activation spec:
    <mdb-resource-adapter>
    <resource-adapter-mid>sun-jms-adapter</resource-adapter-mid>
    <activation-config>
    <activation-config-property>
    <activation-config-property-name>ConnectionURL</activation-config-property-name>
    <activation-config-property-value>lookup://targetConnFactory</activation-config-property-value>
    </activation-config-property>
    <activation-config-property>
    <activation-config-property-name>Destination</activation-config-property-name>
    <activation-config-property-value>lookup://targetTopic</activation-config-property-value>
    </activation-config-property>
    <activation-config-property>
    <activation-config-property-name>DestinationType</activation-config-property-name>
    <activation-config-property-value>javax.jms.Topic</activation-config-property-value>
    </activation-config-property>
    <activation-config-property>
    <activation-config-property-name>RedeliveryHandling</activation-config-property-name>
    <activation-config-property-value>2:1000; 3:move(queue:psdmqqueue)</activation-config-property-value>
    </activation-config-property>
    <!--subscription properties-->
    </activation-config>
    </mdb-resource-adapter>
    </ejb>
    </enterprise-beans>
    </sun-ejb-jar>

    Hi Alexej,
    I looked at the problem and found out what the issue is. We recently added some functionality that will test if the dead letter destination is in fact a valid destination -- we thought it's better to find that out upfront, rather than if an error occurs. This is especially important with dead letter destinations being looked up in JNDI: mistakes are easily be made there.
    In any case, this new functionality introduced a problem where messages are sent from a queue, and the dead letter destination is a topic, or vice versa, where messages are received from a topic, and the dead letter destination is a queue.
    In case you're wondering why: we still need to support JMS 1.0.2 servers. For these servers, the queues and topics are strictly segregated. We do have automated tests that test functionality across domains, but as it turns out, these tests also test some other functionality at the same time that fool the dead-letter-destination-validation into thinking it is the same messaging domain.
    In any case, I've have created a fix for this, and I'm testing it right now.
    I'll send you an updated RAR by email in case you don't want to wait until the updated bits are available for download. What you also could do, as a workaround, is doing the same trick that fooled the automated test: you can specify the redelivery handling in the MDB code, e.g.
    public void onMessage(Message message) {
    message.setStringProperty("JMS_Sun_JMSJCA_RedeliveryHandling", "2:1000; 3:move(queue:*psdmqqueue*)");
    // do stuff
    HTH, Frank Kieviet

  • Re: Constant Message Redelivery Problem

    You can get redelivery for other reasons as well. Redelivery occurs if the message is
              participating in a transaction, and the transaction fails for any reason.
              For example, if the MDB in turn calls an EJB which in
              turn calls JDBC then the tx becomes two-phase. If the JDBC call fails then the tx
              will roll back. Or if the tx times-out: the default tx timeout is 30 seconds, so if
              the MDB takes longer than 30 seconds then the tx will roll-back and message the will
              get redelivered.
              Even if the tx succeeds, in some cases you may have error states that re-enqueue the
              received message but let the transaction commit (WLI, BEA's integration product, can do
              this).
              This looks like the redelivery of a failed message, but is actually the delivery of a new
              version.
              Duplicates occur if a Queue MDB's descriptor actually points at a topic destination.
              Check for this one by comparing the JNDI name in config.xml against the
              descriptor destination type field...
              Tom
              sunshine wrote:
              > I encountered the same problem of repeat message delivery. In our situation, we are
              > using JMS JDBC Store and when the database goes down and comes back up, the MDB starts
              > processing messages but the messages keep recycling in the JMS Store.
              >
              > The MDB code tried catching all possible exceptions like RuntimeException and Exception.
              > None of these exceptions are logged. When we re-start the WL managed servers, those
              > messages in the JMS Store were flushed off.
              >
              > Any idea what caused the repeat message redelivery?? Thanks.
              >
              > Tom Barnes <[email protected]> wrote:
              > >Your MDB may be throwing a RuntimeException, which forces message
              > >redelivery. Put a try/catch/Throwable in the outermost scope of your
              > >onMessage() code to see if this is case.
              > >
              > >Note that in 6.1 and up you can configure redelivery delays, max redelivery
              > >counts and error destinations to alleviate this problem...
              > >
              > >Tom
              > >
              > >Toad wrote:
              > >
              > >> I have a message-driven bean listening on a message queue and everything
              > >> appears to work the first time the message is sent. The message is processed
              > >> and the OnMessage method returns without incident. There are no errors
              > >and
              > >> no exceptions are thrown by the JMS client or in the MDB itself. PROBLEM:
              > >> Message continually redelivered pegging the CPU at 100%. Inspection of
              > >the
              > >> JMSSTORE and JMSSTATE reveals messages still queued. Any ideas?
              > >
              

    And make sure that your MDB is not throwing Errors or RuntimeExceptions,
              as these don't necessarily get logged, but they cause rollbacks.
              Put a "try {} catch (RuntimeException re)
              { log; throw re; } catch (Error er) { log; throw er; }"
              around all the code within the MDB's "onMessage()" callback
              to see if this is happening.
              Manikyala Peddi wrote:
              > Hi,
              >
              > I have a MDB which is calling an EJB. The redelivery override period was set at 60 sec.
              >
              > Before completing the first message the same message is redelivered.The processing time in onMessage in MDB takes more than the Redelivery Override Period. Is there a way to prevent the delivery of the duplicate message before completing the first message.Iam using Weblogic 7.1
              >
              > Thanks
              >
              > Manikyala
              

  • Message Redelivery

              Hi there,
              I would like to know how to set the JMS Message Redelivery from a server restart
              to only redeliver message after all the weblogic startup classes have completed?
              The reason for this is because the message consumer(s) depend on some configuration
              setting that are setup by the startup classes and I am getting problems during a
              server restart because the container is trying to redeliver the persisted message
              BEFORE the startup classes have completed there execution.
              Thanks!
              Vincent
              

    Another approach would be to have your startup class spawn it's own thread
              (that contains code to deploy your MDB application) and do a JMX call to
              query if the server is up and listening (meaning that all services have been
              deployed). The JMX call could be in a loop with a sleep interval. Once the
              server is up the thread can deploy your MDBs. This way you don't have to
              worry about your MDBs consuming all available threads.
              To deploy the application using JMX, you could use code like the below. The
              following code also makes sure that the config.xml is not updated so that
              you can achieve a custom deploy every time your server is re-cycled.
              public class ApplicationDeployer implements Runnable {
              private MBeanHome home;
              private TargetMBean targetMBean;
              private ApplicationMBean appMBean;
              private WebLogicObjectName targetObj;
              .... include methods to start the thread and check if the server is up
              public void doDeploy() {
              ComponentMBean deployBean = null;
              try
              ApplicationMBean appMBean = (ApplicationMBean)
              home.findOrCreateAdminMBean(appName, "Application", domainName);
              appMBean.setPath(appPath);
              if (deployFileName.indexOf(".jar")>0){
              deployBean = (EJBComponentMBean)
              home.createAdminMBean( deployAppName ,
              "EJBComponent", domainName, appMBean);
              } else if (deployFileName.indexOf(".war")>0){
              deployBean = (WebAppComponentMBean)
              home.createAdminMBean( deployAppName ,
              "WebAppComponent", domainName, appMBean);
              if ( Double.valueOf(getVersion()).doubleValue() > 6.0 )
              deployBean.setPersistenceEnabled( false );
              deployBean.setURI(deployFileName);
              deployBean.addTarget(targetMBean);
              appMBean.addComponent(deployBean);
              appMBean.deploy();
              appMBean.load();
              catch (Exception e){
              System.err.println("Exception at AppDeployer.doDeploy " , e);
              Thanks,
              Adarsh
              "Tom Barnes" <[email protected]> wrote in message
              news:[email protected]...
              > The messages on boot are not "redelivered" messages (there is no matching
              > recover/rollback in the current server's context), so a delay has no
              effect.
              > I'm sorry if I gave the impression that a redelivery delay has an effect
              at boot time...
              > Specifically, redelivery delay configures the amount of time a message
              should remain
              > in limbo before it is made visible again after an application calls
              recover or rollback.
              >
              > You really should post to the ejb newsgroup. I think there may be some
              control
              > over startup ordering (MDB after startup classes).
              >
              > Worse comes to worse, your MDB
              > can block (wait()) until the startup class calls notify() - Just make sure
              the MDBs max
              > pool size is less than the default-thread-pool-size, or make sure to
              give the MDBs
              > their own thread pool, to prevent them from consuming all available
              threads.
              >
              > Tom
              > Vincent wrote:
              >
              > > Hi Tom,
              > >
              > > I am using WLS6.1 sp2 running on solaris. The problem I am having is
              that messages
              > > are getting reloaded and sent at the next server restart before my
              weblogic startup
              > > class has completed its execution. My onMessage() method in my
              MDB(shouldn't matter
              > > if it's a MDB or a PTP JMS consumer..?) depends on some objects that are
              initialized
              > > by the startup class. I tried setting DefaultRedeliveryDelay in the
              JMSConnectionFactory
              > > to a very long delay but that does not help.
              > >
              > > Tom Barnes <[email protected]> wrote:
              > > >By "containers" I assume you mean MDBs???? Please post your question
              to
              > > >the ejb newsgroup, along with your version and SP level.
              > > >
              > > >Tom
              > > >
              >
              

  • After redelivery attempt limit reached, where does the msg go ?

    hi,
              I have weblogic6.1sp3 on windows nt. I have some questions regarding
              the redelivery behaviour of weblogic. I have a mdb listening on a
              queue set up so that it prints the msg recieved and rolls back (for
              test purposes). I have redelivery attempt limit set to 5 and the time
              between each redelivery set to 20 seconds.
              - When a rollback occurs, shouldnt i be able to see the message that
              was put back on the Q via the weblogic console ? currently the console
              simply shows that the message recieved count has increased.
              - After the 5th attempt to redeliver fails, the msg simply dissapears.
              I guess this means that it has been dropped. Is this normal ? is there
              any system Q where dropped msgs are placed ?
              - If I specify a Error Queue, would the msg be placed on it after the
              redelivery attempts fail as mentioned above ?
              Any help would be greatly appreciated.
              Thanks in advance,
              Raj
              

    raj wrote:
              > hi,
              >
              > I have weblogic6.1sp3 on windows nt. I have some questions regarding
              > the redelivery behaviour of weblogic. I have a mdb listening on a
              > queue set up so that it prints the msg recieved and rolls back (for
              > test purposes). I have redelivery attempt limit set to 5 and the time
              > between each redelivery set to 20 seconds.
              >
              > - When a rollback occurs, shouldnt i be able to see the message that
              > was put back on the Q via the weblogic console ? currently the console
              > simply shows that the message recieved count has increased.
              The "pending" count will remain the same. A messing is "pending"
              if it is currently associated with a tx, unacknowledged, or in
              "delayed" delivery - otherwise it is counted as "current".
              >
              > - After the 5th attempt to redeliver fails, the msg simply dissapears.
              > I guess this means that it has been dropped. Is this normal ?
              Yes. This is the documented behavior for redelivery limit.
              > is there
              > any system Q where dropped msgs are placed ?
              No. See next question.
              >
              > - If I specify a Error Queue, would the msg be placed on it after the
              > redelivery attempts fail as mentioned above ?
              Yes, in 6.1, this is the sole purpose of an error queue.
              See the programmer's guide documentation for "Redelivery Limit"
              and or "Error Queue", or the JMX configuration bean javadoc, or
              look at the console help.
              >
              > Any help would be greatly appreciated.
              > Thanks in advance,
              > Raj
              

  • JMS (bea 9) redelivery does not work ?

    I'm a bit at a loss. Any help is therefore welcome.
    I am using Bea 9 and Java 1.5.
    I have a MDB bean that attempts to transmit data to a foreign site via ftp. When it fails to transmit files, it errors and the message's content (a file) that I attempted to send to remote system is rollbacked. I have set the redelivery count to -1 and the redelivery delay to 1 minute. After a minute, the message is replayed and this as long as the bean is unable to transfer the file. This is what I wanted to do. And all is fine.
    But...
    If I stop the server while messages are waiting to be redelivered and then launch again the server just after, then the server only replays 2 or 3 messages (or 2 or 3 times the same message) and then stop replaying messages which should be redelivered every minute. New messages sent to the bean are also not presented to the bean. Everything seems frozen as far as this bean is concerned..
    But, if I look at the console and display the monitoring info of this MDB after a restart, I read :
    Beans In Use Count 0
    Waiter Current Count 0     
    Timeout Total Count     0
    Access Total Count     2
    Destroyed Total Count     2
    Connection Status Connected     
    Destination FtpQueue
    JMS Client ID
    Status running
    Last Exception      java.lang.Error: com.mycompany.FtpException: Could not connect to server ftpsrv2
    It is "running"...
    Any ideas ?
    Thanks in advance for any tips.
    P.Z.

    Hi,
    Redelivery delays themselves are not persisted - messages that are subject to a redelivery delay should be immediately redelivered if their host JMS server is shutdown and restarted.
    MDBs that are causing rollbacks/recovers have a built in pause/retry algorithm that causes them to automatically shutdown after a certain number of failures and then restart after an interval. The purpose is to prevent failing MDBs from running in a tight loop. The MDB edocs provide a bit more detail.
    If this doesn't help, I have some questions that might help narrow down the problem:
    -- Are the messages persistent?
    -- Is the JMS server running on the same server as the MDB? If not, which server are you stopping?
    -- How are you stopping the server?
    -- What do the pending and current counts look like on the destination?
    -- Are you using the "unit-of-order" feature?
    Tom Barnes
    WebLogic Messaging Developer Team

  • JMS Clustering -- Automatic Redelivery

              Hi:
              Here is my understanding of distributed JMS. We are clustering three machines
              (A, B and C).
              Since JMS Servers themselves cannot have a cluster as a Target deployment,
              We create a 3 JMS Servers
              JMSServer1 with a Target of A
              JMSServer2 with a Target of B
              JMSServer3 with a Target of C
              Now we create a distributed Queue/Topic. (JNDI Name - MyQueue)
              We have the weblogic console autocreate topics and queues on each of the JMS
              Servers. They are JNDI named something like MyQueue@JMSServer1 , MyQueue@JMSServer2
              and MyQueue@JMSServer3
              Now -- Correct me if I am wrong -- When I do a JNDI Lookup for MyQueue --
              the WLConnectionfactory will give me a reference to an object in one of the three
              servers right. Now after I get the reference, the server that I have a remote
              reference goes down. When I try to post a message into the queue with the same
              remote reference Is there any kind of automatic redelivery or a relookup and
              get the next available server proxy (like in the EJB's) that is there ?
              What happens in such a case? Can the JMS stub that I have on the client dynamically
              (after it has been looked up) do redelivery on another server?
              I understand that if I do a lookup again I will not be pinned to the machine
              that just went down. This would be guaranteed by the ConnectionFactory right?
              Please let me know if this is not the case.
              Thanks and I really appreciate any help and input in the matter.
              Vivek Bhaskaran
              [email protected]
              

              In our practice with Weblogic 7 JMS, we use distributed destination to handle sender
              and MDB. If your sender fails because of JMS server down, you should catch exceptions
              and resend it. When poll the message from the queue, we talk to the individual
              physical queues directly.
              "Vivek Bhaskaran" <[email protected]> wrote:
              >
              >Hi:
              >
              > Here is my understanding of distributed JMS. We are clustering three
              >machines
              >(A, B and C).
              >
              > Since JMS Servers themselves cannot have a cluster as a Target deployment,
              >
              > We create a 3 JMS Servers
              > JMSServer1 with a Target of A
              > JMSServer2 with a Target of B
              > JMSServer3 with a Target of C
              >
              > Now we create a distributed Queue/Topic. (JNDI Name - MyQueue)
              > We have the weblogic console autocreate topics and queues on each
              >of the JMS
              >Servers. They are JNDI named something like MyQueue@JMSServer1 , MyQueue@JMSServer2
              >and MyQueue@JMSServer3
              >
              >
              > Now -- Correct me if I am wrong -- When I do a JNDI Lookup for MyQueue
              >--
              >the WLConnectionfactory will give me a reference to an object in one
              >of the three
              >servers right. Now after I get the reference, the server that I have
              >a remote
              >reference goes down. When I try to post a message into the queue with
              >the same
              >remote reference Is there any kind of automatic redelivery or a relookup
              >and
              >get the next available server proxy (like in the EJB's) that is there
              >?
              >
              > What happens in such a case? Can the JMS stub that I have on the
              >client dynamically
              >(after it has been looked up) do redelivery on another server?
              >
              > I understand that if I do a lookup again I will not be pinned to
              >the machine
              >that just went down. This would be guaranteed by the ConnectionFactory
              >right?
              >Please let me know if this is not the case.
              >
              > Thanks and I really appreciate any help and input in the matter.
              >
              >
              >Vivek Bhaskaran
              >[email protected]
              

  • Delivery/redelivery count

              Hi
              I guess this topic might have been discussed earlier - but I am still trying to
              put it up again.
              We somehow need to know how many times the message is being redelivered/delivered.
              Now I know that there is a optional JMS property which is JMSXDeliveryCount which
              can tell me how many times the message has been delivered. Does weblogic implement
              it?
              If not is there any Weblogic specific way that I can access that - because weblogic
              does use that feature to determine when to write to error queue ie the "Redelivery
              Limit:" feature. So there must be some way to get that. I dont mind using weblogic
              specific apis to get - but I really need that feature.
              Any pointers would be of great help.
              thanks
              Anamitra
              

              Anamitra wrote:
              > Hi tom
              > thanks for the quick reply. I know u cant make promises - but approxmately which
              > release are u talking abt - 9.x?
              Yes.
              > Also that you asked me to contact support - so they can provide me a custom api
              > to get that data with 7.x?
              It is rare to get custom features put into current releases,
              but not completely impossible. I was trying to let you know
              there is such an option.
              > thanks
              > Anamitra
              > Tom Barnes <[email protected]> wrote:
              >
              >>There is no WL specific API to get redelivery count. As usual,
              >>all I can tell you is to contact customer support. Such as a
              >>feature is scheduled for the next release (but it is not
              >>my place to make promises).
              >>
              >>Anamitra wrote:
              >>
              >>
              >>>Hi
              >>>I guess this topic might have been discussed earlier - but I am still
              >>
              >>trying to
              >>
              >>>put it up again.
              >>>We somehow need to know how many times the message is being redelivered/delivered.
              >>>Now I know that there is a optional JMS property which is JMSXDeliveryCount
              >>
              >>which
              >>
              >>>can tell me how many times the message has been delivered. Does weblogic
              >>
              >>implement
              >>
              >>>it?
              >>>If not is there any Weblogic specific way that I can access that -
              >>
              >>because weblogic
              >>
              >>>does use that feature to determine when to write to error queue ie
              >>
              >>the "Redelivery
              >>
              >>>Limit:" feature. So there must be some way to get that. I dont mind
              >>
              >>using weblogic
              >>
              >>>specific apis to get - but I really need that feature.
              >>>Any pointers would be of great help.
              >>>thanks
              >>>Anamitra
              >>
              >
              

Maybe you are looking for