MDB registered to to a Queue

What happens if two different MDBs are listening to a single Queue ?
More clearly, suppose two MDBs are configured to listen on a single Queue through a listener port, then when a message arrives in the Queue which MDBs onmessage() will be called and on what basis?

The answer is which ever MDB gets there first. JMS guarantees that your will be processed by only one of them however.
If you want both MDB's to consume the message use a topic instead of a queue.
If you want to control which MDB will consume the message use a Message Selector.
Try posting MDB related questions on the EJB or JMS forums.

Similar Messages

Urgent : MDB stops listening to the queues after some time !!!

Hi,
I am using OJMS with OC4J 10.1.2 and db 9.2.0.5. I have a web application which send messages into the queue very frequently.
But the problem is the MDBs stop listening to the queues after some time (1-2 days) and no more messages will be dequeued from that point.
All these messages will move to the exception queue after their expiry.
But the dequeing agains resumes after restarting the OC4J !.
I guess, at some point mdbs are either becoming busy (locked ) or some exception occured while dequeing, hence they stop listening to the queues.
Please throw some light on this issue as it is very crucial in my project.
Regards
Prashanth

I've noticed this lately as well, with my iPhone 4. I couldn't confidently pin it directly on any particular iOS update, but my iPhone used to automatically connect up via Bluetooth with my Prius's handsfree feature, and now it doesn't. I work with a CE-based device at my job, with Bluetooth capability, and I used to test out that feature by having it discover my iPhone. This no longer works either.
What I have found (not really a solution, but it does work and may be a clue for Apple) is that if I simply go to the Settings app then the General -> Bluetooth screen and let it sit there, it will pair right up with my car within a few seconds. Bluetooth is always on, and always says "Now Discoverable" at the bottom of the settings screen.

Info! required on subscribing a Weblogic MDB to an Oracle AQ queue

Hi,
we are developing an event notification application and are planning to use Oracle AQ for message propagation, from Oracle DB(oracle 9i) to an application in WLS (Version 9.2). I's there any comprehensive tutorial on how to subscribe a MDB in weblogic to a Queue in AQ.
if any available please kindly reply to this posting.
thanks,
prakash

Did you ever receive information on MDB to AQ? I'm doing a very similar thing.
--Jay

Single MDB on a clustered JMS queues(2)

I have 2 JMS servers in a cluster and each server has a JMS queue, which forms the distributed destination. Now I need a MDB to listen on both these queues. Is it possible?
Thanks
-Ankur

Yes - thats the usual purpose of distributed queues, to allow consumers to consume from the distributed queue (wherever its hosted).
Though distributed destinations are JMS provider specific so do check your providers documentation on using distributed queues. In some providers, like ActiveMQ, distributed queues look and act just like regular queues so they just work from inside a JMS client or MDB.
James
http://logicblaze.com/

MDB deployed in WebLogic and Queues in IBM MQ

Hi all,
I have a MDB which is deployed in Weblogic 10.0 and created queues in IBM MQ 6. The state of MDB is active. But its not picking up the messages from the Queue. And there is no expection thrown also in the Web Logic log file.
To test the MQ series binding file, i created a standalone client, which puts and picks the message. It works fine.If I stop the MQ, Weblogic is throwing error and if I change the Manager name or Connection factory name in binding file, Weblogic throwing error. So its able to get connection.
And the MDB if deployed in OC4J, picks the messages and processes. So MDB also working fine. So I think i have missed out some configuration. Can anyone tell what i have missed out.
Please help me out in this.
Thanks in advance.
Steps used are:
1.Deployed jms-xa-adp.rar file in OC4J.
 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE connector PUBLIC '-//Sun Microsystems, Inc.//DTD Connector 1.0//EN' 'http://java.sun.com/j2ee/dtds/connector_1_0.dtd'>
<connector>
 <display-name>Weblogic Messaging Bridge Adapter (XA)</display-name>
 <vendor-name>BEA System</vendor-name>
 <spec-version>1.0</spec-version>
 <eis-type>JMS Service</eis-type>
 <version>1.0.2</version>
 <resourceadapter>
 <managedconnectionfactory-class>weblogic.jms.adapter.JMSManagedConnectionFactory</managedconnectionfactory-class>
 <connectionfactory-interface>weblogic.jms.bridge.AdapterConnectionFactory</connectionfactory-interface>
 <connectionfactory-impl-class>weblogic.jms.adapter.JMSBaseConnectionFactory</connectionfactory-impl-class>
 <connection-interface>weblogic.jms.bridge.AdapterConnection</connection-interface>
 <connection-impl-class>weblogic.jms.adapter.JMSBaseConnection</connection-impl-class>
 <transaction-support>XATransaction</transaction-support>
 <config-property>
 <config-property-name>ConnectionURL</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>file:/C:/JNDIDirectory</config-property-value>
 </config-property>
 <config-property>
 <config-property-name>InitialContextFactory</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>com.sun.jndi.fscontext.RefFSContextFactory</config-property-value>
 </config-property>
 <config-property>
 <config-property-name>ConnectionFactoryJNDI</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>WLReceiverQCF</config-property-value>
 </config-property>
 <config-property>
 <config-property-name>DestinationJNDI</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>WLReceiverQueue</config-property-value>
 </config-property>
 <config-property>
 <config-property-name>DestinationType</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>Queue</config-property-value>
 </config-property>
 <config-property>
 <config-property-name>AdapterType</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>XATransaction</config-property-value>
 </config-property>
 <authentication-mechanism>
 <authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
 <credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface>
 </authentication-mechanism>
 <reauthentication-support>false</reauthentication-support>
 </resourceadapter>
</connector>
2. Created JMS Module, under it created Foriegn Server, Inside that created Connection factories and Destinations.
3.Deployed the MDB.
weblogic-ejb-jar.xml
<?xml version="1.0"?>
<!DOCTYPE weblogic-ejb-jar PUBLIC "-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN" "http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd">
<weblogic-ejb-jar>
 <weblogic-enterprise-bean>
 
 <ejb-name>MDB_Bean</ejb-name>
 <message-driven-descriptor>
 <pool>
 <max-beans-in-free-pool>200</max-beans-in-free-pool>
 <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
 </pool>
 <destination-jndi-name>WLReceiverQueue</destination-jndi-name>
 <initial-context-factory>com.sun.jndi.fscontext.RefFSContextFactory</initial-context-factory>
 <connection-factory-jndi-name>WLReceiverQCF</connection-factory-jndi-name>
 </message-driven-descriptor>
 
 <reference-descriptor>
 
 <resource-description>
 <res-ref-name>FCDEV</res-ref-name>
 <jndi-name>FCDEV</jndi-name>
 </resource-description>
 <resource-description>
 <res-ref-name>WLReceiverQCF</res-ref-name>
 <jndi-name>WLReceiverQCF</jndi-name>
 </resource-description>
 
 
 <resource-env-description>
 <res-env-ref-name>WLReplyQueue</res-env-ref-name>
 <jndi-name>WLReplyQueue</jndi-name>
 </resource-env-description>
 <resource-env-description>
 <res-env-ref-name>WLDLQQueue</res-env-ref-name>
 <jndi-name>WLDLQQueue</jndi-name>
 </resource-env-description>
 
 </reference-descriptor>
 
 </weblogic-enterprise-bean>
</weblogic-ejb-jar>ejb-jar.xml
<?xml version="1.0"?>
<ejb-jar id="MDB_Bean" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
 <enterprise-beans>
 <message-driven>
 <display-name>MDB Bean</display-name>
 <ejb-name>MDB_Bean</ejb-name>
 <ejb-class>com.mdb.MDBBean</ejb-class>
 <messaging-type>javax.jms.MessageListener</messaging-type>
 <transaction-type>Container</transaction-type>
 <env-entry>
 <env-entry-name>propertyPath</env-entry-name>
 <env-entry-type>java.lang.String</env-entry-type>
 <env-entry-value>D:/MDB/config/</env-entry-value>
 </env-entry>
 <activation-config>
 <activation-config-property>
 <activation-config-property-name>DestinationType</activation-config-property-name>
 <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
 </activation-config-property>
 <activation-config-property>
 <activation-config-property-name>DestinationName</activation-config-property-name>
 <activation-config-property-value>WLReceiverQueue</activation-config-property-value>
 </activation-config-property>
 <activation-config-property>
 <activation-config-property-name>ConnectionFactoryJndiName</activation-config-property-name>
 <activation-config-property-value>WLReceiverQCF</activation-config-property-value>
 </activation-config-property>
 </activation-config>
 <resource-ref>
 <description>Connection Factory for Response / DLQ</description>
 <res-ref-name>WLReceiverQCF</res-ref-name>
 <res-type>javax.jms.XAQueueConnectionFactory</res-type>
 <res-auth>Container</res-auth>
 <res-sharing-scope>Shareable</res-sharing-scope>
 </resource-ref>
 <resource-env-ref>
 <description>Queue to send reply to</description>
 <resource-env-ref-name>WLReplyQueue</resource-env-ref-name>
 <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
 </resource-env-ref>
 <resource-env-ref>
 <description>MDB Dead Letter Queue</description>
 <resource-env-ref-name>WLDLQQueue</resource-env-ref-name>
 <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
 </resource-env-ref>
 </message-driven>
 </enterprise-beans>
 <assembly-descriptor>
 <container-transaction>
 <method>
 <ejb-name>MDB_Bean</ejb-name>
 <method-name>*</method-name>
 </method>
 <trans-attribute>Required</trans-attribute>
 </container-transaction>
 </assembly-descriptor>
</ejb-jar>Edited by: shruthi04 on Nov 22, 2008 10:51 AM
Edited by: shruthi04 on Nov 22, 2008 11:42 AM
Edited by: shruthi04 on Nov 22, 2008 11:44 AM

Does your MDB require transactions ? If so you need to XA enable the connection factory. Looks like you are using a transactional MDB with non XA connection factory.

Throttling MDB performance running against MQSeries queue

I have an unusual requirement for an application. We have a non-transactional MQSeries queue that is bound as a foreign JMS destination in client mode (thanks to the folks on the forum who helped me configure that!).
          The problem is that the cluster that we are running our application on has limited capacity and I need to make sure that the MDB that will be listening to the queue does not surpass a certain TPS limit (say, 1 TPS). This article explains how to throttle performance using a separate execute thread -- http://e-docs.bea.com/wls/docs81/perform/AppTuning.html#1105201
          However, this requires you to set the MDB's "dispatch-policy' attribute to the lower priority queue in ejb-jar.xml. However, the documentation on this attribute -- http://edocs.beasys.com/wls/docs81/ejb/DDreference-ejb-jar.html#1113605 -- indicates that this attribute is only honoured if the source queue is transactional in nature.
          What to do? A transactional queue is a hard sell to our infrastructure folks. Can I use the extended transactional client and have this work?
          FYI - using the max-beans-in-free-pool does not do a sufficiently good job of limiting performance.
          Any other ideas?

another possibility might be the following scenario:
          create a local jms-destination, maybe with a jdbc-store.
          then use the weblogic bridge to transfer messages into the local jms-queue.
          at this point you can configure flow-control for the connection factory
          to limit transferred messages.
          the problem in this case is, that unprocessed messages have to be stored
          on the application server or in the database.
          but maybe this can help you.
          --Klaas
          gbrail schrieb:
          > As the doc describes, your MDB's "onMessage" method is invoked by a thread created by MQ. That means we have no control over it, or how fast it runs. I don't know of any "throttling" features in MQ either that would help.
          >
          > The only (ugly!) suggestion I can think of is that you should set "max-beans-in-free-pool" to 1 and periodically "sleep" in your onMessage method so that you don't get messages too fast!
          >
          > (And even if you were able to use a separate execute queue, or a transactional queue, you still could potentially get messages more than once per second, so you might still need to sleep anyway.)

MDB connecting to Remote Distributed Queue

Hi,
I am trying to deploy a MDB in weblogic 10.0 and this will listen to a Distributed Queue in another weblogic version10 server.
my MDB code looks like
@MessageDriven(mappedName = "jms/DMSQueue", activationConfig = {
 @ActivationConfigProperty(propertyName = "initial-context-factory ", propertyValue = "weblogic.jndi.WLInitialContextFactory"),
 @ActivationConfigProperty(propertyName = "connectionFactoryJndiName", propertyValue = "jms/cf"),
 @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
 @ActivationConfigProperty(propertyName="destination", propertyValue="jms/DMSQueue"),
 @ActivationConfigProperty(propertyName = "destinationJndiName", propertyValue = "jms/DMSQueue"),
 @ActivationConfigProperty(propertyName = "providerAdapterJNDI", propertyValue = "java:/RemoteJMSProvider"),
 @ActivationConfigProperty(propertyName = "provider-url", propertyValue = "t3://10.54.115.171:80")
public class TestMdb implements MessageListener {
 public void onMessage(Message message) {
 System.out.println("Received Message: " + message);
if the I configure the bean for a local Queue it works properly.
But if I provide the url of the remote Queue, it does not get connected.
my ejb-jar.xml
contains only
<enterprise-beans>
<message-driven>
<ejb-name>ejbsms</ejb-name>
<ejb-class>hmil.TestMdb</ejb-class>
</message-driven>
</enterprise-beans>
I guess we need to provide the security credentials of the remote server and may be missing some thing else.
Please guide me on what changes required in annotations to get it working
I prefer to use container independent propertyName
Edited by: user13583038 on Jan 3, 2011 4:08 AM

You can try posting JMS related questions to the JMS newsgroup.

PL/SQL Callback registered on multi consumer queue takes 6 seconds to call

Registered a PL/SQL callback procedure on multi consumer Queue. if I enqueue message into queue, it takes 6 seconds to call PL/SQL callback procedure.
Why does it takes 6 seconds ?
I believe Queue submits DBMS Job to execute the Callback. I am not sure why it is taking 6 seconds to execute the callback.
are there any configarable parameters to set which allows callbacks to be executed more frequently?

You can try to change jobqueue_interval=1
This is a scan rate interval (seconds) of job queue parameter.
it is 5 sec by default.
Regards,
Sergey

MDB not listening to JMS Queue

We are using OC4J 10.1.2 We are using JMS for queueing, the Queueing application sucessfully displays the JMS message id, but MDB is NOT listening to the JMS for some reason. We have verified the deployment config files etc. Can amy one help

1 - It doesn't appear that targets were set for any of the administered WL objects. In WL, most administered objects must have a configured target so that WL knows which servers to run them on.
2 - There's no need to specify a URL or initial-context-factory in the MDB. In your case, you're referencing JNDI objects on the MDB's local cluster (which, in turn, map to foreign references).
3 - Note that URL and connection-factory have been re-specified in the foreign JMS server properties, and there 's a mix of delimiters ";" and " ". Normally, no JNDI props are needed except, depending on the use case, for security credentials.

MDBs in 9.1 continue to consume JMS queues even after being deleted

We have an MDB application that reads a batch message off of a JMS queue, archives it in a database, parses the batch message into individual messages and writes them onto other JMS queues to be consumed by another application. Everything was running fine in Weblogic 8.1.5. However, due to problems with XA drivers and the MSDTC(predictable SQL server crashes), we decided to upgrade to Weblogic 9.1 to take advantage of the LLR option.
 First, we had an issue where our MDBs were causing the following exception:
 ####<May 26, 2006 7:42:12 PM EDT> <Error> <JMX> <ist-clft2> <wltest1> <ExecuteThread: '1' for queue: 'default'> <<WLS Kernel>> <> <> <1148686932991> <BEA-149500> <An exception occurred while registering the MBean null.
 java.lang.IllegalArgumentException: Registered more than one instance with the same objectName : com.bea:ServerRuntime=wltest1,MessageDrivenEJBRuntime=RhapsodyMDB_DMBModule!JMSServer4@DMB_BEAN_QUEUE,Name=RhapsodyMDB_DMBModule!JMSServer4@DMB_BEAN_QUEUE,ApplicationRuntime=DataBrokerEAR1_2,Type=EJBPoolRuntime,EJBComponentRuntime=DataBrokerEJB new:[email protected] existing weblogic.ejb.container.monitoring.EJBPoolRuntimeMBeanImpl@7db003
 at weblogic.management.jmx.ObjectNameManagerBase.registerObject(ObjectNameManagerBase.java:146)
 at weblogic.management.mbeanservers.internal.WLSObjectNameManager.lookupObjectName(WLSObjectNameManager.java:133)
 at weblogic.management.jmx.modelmbean.WLSModelMBeanFactory.registerWLSModelMBean(WLSModelMBeanFactory.java:86)
 at weblogic.management.mbeanservers.internal.RuntimeMBeanAgent$1.registered(RuntimeMBeanAgent.java:104)
 at weblogic.management.provider.internal.RegistrationManagerImpl.invokeRegistrationHandlers(RegistrationManagerImpl.java:205)
 at weblogic.management.provider.internal.RegistrationManagerImpl.register(RegistrationManagerImpl.java:85)
 at weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:320)
 at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:257)
 at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:222)
 at weblogic.ejb.container.monitoring.EJBPoolRuntimeMBeanImpl.<init>(EJBPoolRuntimeMBeanImpl.java:32)
 at weblogic.ejb.container.monitoring.MessageDrivenEJBRuntimeMBeanImpl.<init>(MessageDrivenEJBRuntimeMBeanImpl.java:49)
 at weblogic.ejb.container.manager.MessageDrivenManager.initialize(MessageDrivenManager.java:503)
 at weblogic.ejb.container.manager.MessageDrivenManager.setup(MessageDrivenManager.java:120)
 at weblogic.ejb.container.manager.MessageDrivenManager.setup(MessageDrivenManager.java:146)
 at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.createMDManager(MessageDrivenBeanInfoImpl.java:1481)
 at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.createDDMDManagers(MessageDrivenBeanInfoImpl.java:1378)
 at weblogic.ejb.container.deployer.MessageDrivenBeanInfoImpl.onDDMembershipChange(MessageDrivenBeanInfoImpl.java:1285)
 at weblogic.jms.common.CDS$DD2Listener.listChange(CDS.java:454)
 at weblogic.jms.common.CDSServer$DDHandlerChangeListener.statusChangeNotification(CDSServer.java:167)
 at weblogic.jms.dd.DDHandler.callListener(DDHandler.java:318)
 at weblogic.jms.dd.DDHandler.callListeners(DDHandler.java:344)
 at weblogic.jms.dd.DDHandler.run(DDHandler.java:282)
 at weblogic.jms.common.SerialScheduler.run(SerialScheduler.java:37)
 at weblogic.work.ExecuteRequestAdapter.execute(ExecuteRequestAdapter.java:21)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
 >
 ####<May 26, 2006 7:42:13 PM EDT> <Info> <EJB> <ist-clft2> <wltest1> <ExecuteThread: '1' for queue: 'default'> <<WLS Kernel>> <> <> <1148686933069> <BEA-010060> <The Message-Driven EJB: RhapsodyMDB has connected/reconnected to the JMS destination: weblogic.jms.DMB_BEAN_QUEUE.>
 
 Generally this happend after there were cluster communication issues. Multi-cast messages were lost and our MDB reconnects to the JMS queues as indicated by the below log:
 ####<May 30, 2006 5:19:06 PM EDT> <Info> <EJB> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '54' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1149023946040> <BEA-010060> <The Message-Driven EJB: DataBrokerMDB has connected/reconnected to the JMS destination: weblogic.jms.PHINMS_DMB_QUEUE.>
 ####<May 30, 2006 5:19:10 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023950228> <BEA-000112> <Removing RAPBEA3S jvmid:720875810499147484S:cmts-rap-bea3:[7005,-1,-1,-1,-1,-1,-1]:DMBstg:RAPBEA3S from cluster view due to timeout.>
 ####<May 30, 2006 5:19:11 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023951009> <BEA-000115> <Lost 2 multicast message(s).>
 ####<May 30, 2006 5:19:11 PM EDT> <Info> <Cluster> <AMTC-RAP-STG3> <RAPBEA1S> <[ACTIVE] ExecuteThread: '22' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1149023951040> <BEA-000111> <Adding RAPBEA3S with ID 720875810499147484S:cmts-rap-bea3:[7005,-1,-1,-1,-1,-1,-1]:DMBstg:RAPBEA3S to cluster: DMBstg_cluster view.>
 
 This would cause the queues to eventually have hundreds of consumers and cause the server to fail.
 Basically, it seems as though the MDBs that are supposed to stop continue and attempt to process, while new threads connect to the JMS queues.
 I tried undeploying our application and deleted it from the configuration. However there were consumers still on the respective queues and when I sent messages, I got an error indicating a "Class Not Found exception" due to the fact that the EJB was undeployed and deleted from the configuration, however the MDB component was not and continued to listen for messages. In 8.1.5, as soon as the application was undeployed, there were zero consumers on the JMS queues.
 I have read the posts about a soon to be released fix that would have the MDBs connect only to the queues locally and not go out the the cluster. Would this fix my issue?
 Is there something in the deployment descriptor to configure that will cause it to disconnect and now spawn so many consumers to the JMS queues?
 Why is it that the number of MDB consumers on the JMS queues stayed static in 8.1.5, but they are erratic in 9.1 even after I set our 9.1 server to use the 8.1.5 execute queue policy. Help would be much appreciated.

I recommend contacting customer support. There's a known problem with MDBs listening to distributed destinations that are local to the same cluster as the MDB, you're problem may be related (the clue is that the stack trace contains jms.dd.DDHandler.callListeners()). The problem is that the MDB connects to all physical queues in a distributed destination rather than just the local queue.
 Tom

WL6.1 - browsing and receiving from queues with MDBs

Hi all,
          I have hit on a problem that has been brought up previously without,
          as far as I can tell, any conclusive response.
          I am using a queue which is processed by message driven beans. This
          queue contains jobs which may take a long time to execute and hence it
          is important to allow users to manage the queue. Ideally this
          management should work in the same way as, say, a printer queue where
          it is possible to view queued jobs and cancel them if necessary.
          It has been said that MDBs in WLS6.1 use an internal pipeline which
          [quote from previous thread " QueueBrowser not working in WL6"]
          "uses an optimistic algorithm and pushes the message at the bean
          before it is ready"
          and, sure enough, pointing a queue browser, activated from a JSP, at
          the queue always returns a queue length of zero, whatever the number
          of pooled MDBs and whatever the actual number of messages queued. I
          have worked around this by creating a second 'monitoring' queue not
          listened to by any MDBs and which I then have to manually synchronise
          with the 'real' jobs queue. However, removing jobs does not work
          either (I am storing the job message ID and trying to access the jobs
          queue using this as a selector) since the queue is empty when looked
          at from any client which is not the listening MDB. In contrast with
          the browsing, there seems to be no obvious way around this as I need
          to access the jobs queue itself before I can remove any jobs.
          My intended 'queue management' functionality does not seem
          particularly esoteric to me and hence I am puzzled that this appears
          difficult to implement. I have therefore been wondering whether I have
          been missing any obvious point and I would be grateful to hear of
          anybody else's experiences trying to achieve similar functionality.
          It would also be interesting to hear whether moving to WLS 7.0 would
          change/fix this 'pipelining' behaviour of MDBs.
          Many thanks.
          Peter


Hi Peter,
          Since 6.0, when pipelining was introduced,
          the pipeline size is configurable via the connection
          factory (see "MessagesMaximum"). To tune this setting,
          you will need to configure a
          custom connection factory for the MDB rather than use
          the default one, and specify its name in the xml descriptor.
          I'm a little surprised you did not find reference to this
          setting in your search.
          Regardless, you will not be able to stop the current message in the MDB.
          In the next release (beta December) you can force the current tx to
          rollback through the JTA mbeans. Of course, this won't stop
          the onMessage() from continuing its work, but it will
          guarantee that any of its transactional
          work will be ultimately discarded.
          Since the app server has no control of the thread
          once it is passed to the MDB app (it can't just kill
          the thread), you will need to roll your
          own mechanism to make it stop. One possibility is to have your MDB
          "register" that it is starting with a "manager" application, and then
          have the MDB poll this application to see if the system admin
          has requested that the current job be aborted.
          You will likely find it useful to read through the JMS FAQ. You
          might also find it useful to look at the jsp queue browser app
          posted on dev2dev by Adarsh...
          Tom, BEA
          P.S. The release after next release will contain more advanced message
          management features.
          Peter Case wrote:
          > Hi all,
          >
          > I have hit on a problem that has been brought up previously without,
          > as far as I can tell, any conclusive response.
          > I am using a queue which is processed by message driven beans. This
          > queue contains jobs which may take a long time to execute and hence it
          > is important to allow users to manage the queue. Ideally this
          > management should work in the same way as, say, a printer queue where
          > it is possible to view queued jobs and cancel them if necessary.
          > It has been said that MDBs in WLS6.1 use an internal pipeline which
          >
          > [quote from previous thread " QueueBrowser not working in WL6"]
          > "uses an optimistic algorithm and pushes the message at the bean
          > before it is ready"
          >
          >
          > and, sure enough, pointing a queue browser, activated from a JSP, at
          > the queue always returns a queue length of zero, whatever the number
          > of pooled MDBs and whatever the actual number of messages queued. I
          > have worked around this by creating a second 'monitoring' queue not
          > listened to by any MDBs and which I then have to manually synchronise
          > with the 'real' jobs queue. However, removing jobs does not work
          > either (I am storing the job message ID and trying to access the jobs
          > queue using this as a selector) since the queue is empty when looked
          > at from any client which is not the listening MDB. In contrast with
          > the browsing, there seems to be no obvious way around this as I need
          > to access the jobs queue itself before I can remove any jobs.
          > My intended 'queue management' functionality does not seem
          > particularly esoteric to me and hence I am puzzled that this appears
          > difficult to implement. I have therefore been wondering whether I have
          > been missing any obvious point and I would be grateful to hear of
          > anybody else's experiences trying to achieve similar functionality.
          > It would also be interesting to hear whether moving to WLS 7.0 would
          > change/fix this 'pipelining' behaviour of MDBs.
          >
          > Many thanks.
          >
          > Peter

MDB messages dont get processed from Queues when involving a remote Topic in transaction

Using WLS 6.1 SP4 on winXP Pro boxes, I have come across a peculiar problem:
          I have several MDBs that process ObjectMessages from queues and forward their payload (wrapped in another new ObjectMessage) to other queues, all of which are located within the same WLS server.
          Right now I'm adding a new MDB that gets messages from a remote Topic with a durable subscription, and forwards the payload to local queues after some processing.
          When the Topic is local as well, there is no problem. But when the Topic is set up in a remote machine, only the MDB that has the remote durable subscription works the way it should. It receives the remote message and forwards it to the corresponding local queue. But then the messages in those local queues dont get processed. The 'Messages Received' count rises and the 'Messages' count stays at 0, as if the messages had been correctly processed and acknowledged, but no onMessage() method is called besides the one from the MDB that has the durable subscription to the remote Topic (I can tell because there's no further processing from the queue those messages get put in). It's as if those messages were simply received and acknowledged without being passed to other MDBs by WLS.
          * All queue MDBs use Required container-managed transaction management and auto-acknowledge
          * All queue MDBs have default durability for their queue subscriptions
          * The topic MDB has a durable subscription stored in a filestore
          * Lookup of the remote Topic is done via JNDI
          Since the processing and forwarding of messages occurs the way it should when everything is local, I am inclined to believe one of two things:
          a) There's some issue with the way WLS treats messages (or even just payloads) when they come from a remote server
          b) WLS is doing something I'm not aware of when propagating a transaction that begins with the delivery of a message from a remote JMS Topic when it involves further forwarding of messages in local JMS Queues.
          Any help will be appreciated.
          regards,
          .munir estevane


Is the durable subscriber forwarder rolling back its transactions?
          That would cause the behavior you describe (eg the message gets
          placed in the queue, but is never made visible). What do
          the pending counts on the destination queue look like?
          Munir Estevane wrote:
          > Using WLS 6.1 SP4 on winXP Pro boxes, I have come across a peculiar problem:
          >
          > I have several MDBs that process ObjectMessages from queues and forward their payload (wrapped in another new ObjectMessage) to other queues, all of which are located within the same WLS server.
          > Right now I'm adding a new MDB that gets messages from a remote Topic with a durable subscription, and forwards the payload to local queues after some processing.
          >
          > When the Topic is local as well, there is no problem. But when the Topic is set up in a remote machine, only the MDB that has the remote durable subscription works the way it should. It receives the remote message and forwards it to the corresponding local queue. But then the messages in those local queues dont get processed. The 'Messages Received' count rises and the 'Messages' count stays at 0, as if the messages had been correctly processed and acknowledged, but no onMessage() method is called besides the one from the MDB that has the durable subscription to the remote Topic (I can tell because there's no further processing from the queue those messages get put in). It's as if those messages were simply received and acknowledged without being passed to other MDBs by WLS.
          >
          > * All queue MDBs use Required container-managed transaction management and auto-acknowledge
          > * All queue MDBs have default durability for their queue subscriptions
          > * The topic MDB has a durable subscription stored in a filestore
          > * Lookup of the remote Topic is done via JNDI
          >
          > Since the processing and forwarding of messages occurs the way it should when everything is local, I am inclined to believe one of two things:
          > a) There's some issue with the way WLS treats messages (or even just payloads) when they come from a remote server
          > b) WLS is doing something I'm not aware of when propagating a transaction that begins with the delivery of a message from a remote JMS Topic when it involves further forwarding of messages in local JMS Queues.
          >
          > Any help will be appreciated.
          >
          > regards,
          > .munir estevane

Message sitting in Queues for 30 minutes before MDB picks them up

We're seeing a situation where we place messages on a queue and a small percentage of them will sit on the queue for 30 minutes before being picked up by the MDB to process. Anyone see this before?
          Here is the background. We're running 3 distributed queues on a cluster of 4 Weblogic 8.1 sp3 servers. The 30 minute issue happens on all 3 queues on all 4 servers. Currently we do not see a pattern. It can happen at a busy hour and in the middle of the night with nothing going on. During a busy timeframe, we can get up to 50 msg that hangup over a few minutes; less than 5 minutes.
          Our Service is an enterprise email service where various clients send email request to us via EJB. The EJB puts an entry into the database and puts a request msg into the queue. The MDB pulls it off the queue sends it to an email subsystem and updates the database.
          We added log msgs in both the EJB and MDB to track messages and narrowed it down to the requests just sitting in the JMS queue. We DO NOT set a delivery time via setJMSDeliveryTime().
          As mentioned is happens anytime during the day (busy or idle), may go for days without occuring, on any of the 3 JMS queues, on any of the 4 cluster servers, and for any of the clients. It's consistantly 30 minutes. This occurs on a small number of requests, but is enough to concern our business owner.
          Any thoughts on possible problems or any thoughts on monitoring or tracking down the issue is greatly appreciated.
          Thanks. Later...
          - Wayne

One possibility is that the messages have already been pushed to an MDB instance in the JMS asynchronous consumer pipeline, but the MDB instance has stalled during message processing - which delays processing of the following messages. The waiting messages count as "pending" in the JMS statistics.
          You can reduce the number of messages in a JMS asynchronous consumer's pipeline via the "MessagesMaximum" connection factory setting (default is 10). First: create a custom connection factory with transactions enabled (to support transactional MDBs), and ack-mode set to "previous" (to support pub/sub MDBs), and MessagesMaximum set to its lowest possible value. Second: specify this connection factory's JNDI name in the MDB's weblogic descriptor.
          Tom, BEA

MDB's keep consuming messages after queue purged

I have a pool of 5 mdbs processing messages from a queue. The queue had 500 messages in it.
I used the imqcmd purge dst ... command to clear a queue.
The mdb's continued to consume messages. I would think that at most 5 messages could have been in the middle of processing and then it would stop but it processed another 30 messages before I killed the app server. I assume it would have gone through the 500.

I have a pool of 5 mdbs processing messages from a queue. The queue had 500 messages in it.
I used the imqcmd purge dst ... command to clear a queue.
The mdb's continued to consume messages. I would think that at most 5 messages could have been in the middle of processing and then it would stop but it processed another 30 messages before I killed the app server. I assume it would have gone through the 500.

Multiple Topics/Queue for Single MDB?

Hi -
Is it possible to configure single MDB to handle multiple Topic/Queue in JMS? I used two <jndi-name/> tags for two topics, but only the first one got picked up by the AS7 server. If one MDB can be configured to take multiple topics, how should I configure it? Some configuration example would be most helpful.
Thanks!

Hello,
According to the Ejb 2.1 specifications, in section 15.4.12 "Association of a Message-Driven Bean with a Destination or Endpoint.
A message-driven bean is associated with a destination or endpoint when the bean is deployed in the container. It is the responsibility of the Deployer to associate the message-driven bean with a destination or endpoint."
Based on this sentence, I would be led to beleive that a single mdb reading on multiple destinations would not be supported. You can try x-posting this to the application server forum.
If you desire the same behavior for the multiple topics, you could always use inheritance on your mdb class, or transfer the logic code into a helper class that is reused by multiple, independent MDBs classes....

MDB registered to to a Queue

Similar Messages

Maybe you are looking for