MDB reconnect to AQ

I'm using OC4J 9.0.3 Developer Preview.
I have two MDB's that are listening to AQ-queues in two different databases. I have the server up and running continously, but I can see that the connection to a queue is dropped every 4-5 hours. With dropped I mean that I don't get any messages from these queues anymore. I don't get any error messages, I just stop receiving any messages. The time is not regular, it can be 2 hours or 2 days.
1. Has anybody else experienced this?
2. Is there a way to configure OC4J to reconnect to the queues if they're dropped?
3. Does anybody have any other suggestions?
Thanks

I have the required privileges, in addition - SYS.DBMS_AQ_BQVIEW. Toad says I need DBA access to see the roles I've been granted but I assume the DBAs created the user as I requested.
I get the same error whether I connect to my test user or to the production user. So either both user have something wrong or there's something wrong with the bean.
One additional thing I'm having a problem with is how to specify that this is a DURABLE topic subscription. I have a ejb-jar.xml with (I know the names are different):
<message-driven>
<description>MDB to listen for status changes to reports published from Oracle Advanced Queueing</description>
<display-name>JobStatusChangedListener</display-name>
<ejb-name>JobStatusChangedListenerEJB</ejb-name>
<ejb-class>mil.arf.arfmessaging.ejb.message.JobStatusChangedListenerBean</ejb-class>
<transaction-type>Container</transaction-type>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</message-driven>
But I get get errors that the acknowledge-mode and the message-driven-destination tags are incorrect - must be changes from 10.0 to 10.3. So how do I specify those things? With annotations in the .java?
Jim

Similar Messages

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

    <b>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.</b>
              <b>First, we had an issue where our MDBs were causing the following exception:</b>
              <i>####<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.></i>
              <b>
              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:</b>
              <i>####<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.></i>
              <b>
              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.</b>

    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

  • JMS MDB Clustering destination reconnect problem

    Hey,
              We have got a JMS cluster and we are using MDB:s that listen to a specific
              JMS topic.
              When using MDB:s I have found out, that when the cluster node where my JMS
              server containing the JMS topic is located goes down I get a connection
              problem. The MDB keeps logging following message into weblogic.log:
              The JMS destination with the JNDI name:
              com.nokia.cce.server2.EAIElinkAliveQueue could not be found. Please ensure
              that the
              JNDI name in the weblogic-ejb-jar.xml is correct, and the JMS destination
              has been deployed.>
              <Apr 3, 2002 10:30:39 AM EEST> <Warning> <EJB> <The Message-Driven EJB:
              ElinkKeepAliveManager2 is unable to connect to the J
              MS destination: com.nokia.cce.server2.EAIElinkAliveQueue. The EJB container
              will automatically attempt to re-establish the c
              onnection with the JMS server. This warning may occur during WebLogic
              Cluster start-up if the JMS destination is located on
              another WebLogic Server instance. When the JMS server connection is
              re-established, the Message-Driven EJB will again receiv
              e JMS messages.
              The Error was:
              The JMS destination with the JNDI name:
              com.nokia.cce.server2.EAIElinkAliveQueue could not be found. Please ensure
              that the
              JNDI name in the weblogic-ejb-jar.xml is correct, and the JMS destination
              has been deployed.>
              The MDB tries to reconnect to the JMS topic every 10th second and keeps on
              logging this message until the corresponding JMS server comes up again.
              (the example is from a JMS queue, but the same phenomen occurs also for
              topics).
              It is very irritating to keep on getting this message every 10th second to
              the logging file. The logging file becomes full of these messages, which
              takes a lot of file space + makes reading other error messages from the
              weblogic logging very difficult.
              Is there anything todo to avoid this ?
              Can You reconfigure the reconnect interval ?
              It would be enough to get one message, that the connection is lost but
              weblogic will try to reconnect. And then the next message would tell when
              a connection has succeeded again.
              I assume there is no way to specify a primary/secondary
              <destination-jndi-name> in the MDB's deployment descriptor ?
              Is the only way to avoid this, to rewrite the implementation to use custom
              based JMS subscribers instead of using MessageDrivenBean kind of
              implemetation ?
              This is a little bit sad, since MDB's gives such a nice and simple solution
              otherwise...
              Regards
              Jan-Erik
              PS. I'm using weblogic 6.1 and I can not migrate to 7.0 in a near future.
              

    Your comments are noted.
              I believe you can set "JMSPollingIntervalSeconds" in the weblogic descriptor.
              Jan-Erik Aladin wrote:
              > Hey,
              >
              > We have got a JMS cluster and we are using MDB:s that listen to a specific
              > JMS topic.
              > When using MDB:s I have found out, that when the cluster node where my JMS
              > server containing the JMS topic is located goes down I get a connection
              > problem. The MDB keeps logging following message into weblogic.log:
              >
              > The JMS destination with the JNDI name:
              > com.nokia.cce.server2.EAIElinkAliveQueue could not be found. Please ensure
              > that the
              > JNDI name in the weblogic-ejb-jar.xml is correct, and the JMS destination
              > has been deployed.>
              > <Apr 3, 2002 10:30:39 AM EEST> <Warning> <EJB> <The Message-Driven EJB:
              > ElinkKeepAliveManager2 is unable to connect to the J
              > MS destination: com.nokia.cce.server2.EAIElinkAliveQueue. The EJB container
              > will automatically attempt to re-establish the c
              > onnection with the JMS server. This warning may occur during WebLogic
              > Cluster start-up if the JMS destination is located on
              > another WebLogic Server instance. When the JMS server connection is
              > re-established, the Message-Driven EJB will again receiv
              > e JMS messages.
              > The Error was:
              > The JMS destination with the JNDI name:
              > com.nokia.cce.server2.EAIElinkAliveQueue could not be found. Please ensure
              > that the
              > JNDI name in the weblogic-ejb-jar.xml is correct, and the JMS destination
              > has been deployed.>
              >
              > The MDB tries to reconnect to the JMS topic every 10th second and keeps on
              > logging this message until the corresponding JMS server comes up again.
              > (the example is from a JMS queue, but the same phenomen occurs also for
              > topics).
              >
              > It is very irritating to keep on getting this message every 10th second to
              > the logging file. The logging file becomes full of these messages, which
              > takes a lot of file space + makes reading other error messages from the
              > weblogic logging very difficult.
              >
              > Is there anything todo to avoid this ?
              > Can You reconfigure the reconnect interval ?
              > It would be enough to get one message, that the connection is lost but
              > weblogic will try to reconnect. And then the next message would tell when
              > a connection has succeeded again.
              > I assume there is no way to specify a primary/secondary
              > <destination-jndi-name> in the MDB's deployment descriptor ?
              >
              > Is the only way to avoid this, to rewrite the implementation to use custom
              > based JMS subscribers instead of using MessageDrivenBean kind of
              > implemetation ?
              > This is a little bit sad, since MDB's gives such a nice and simple solution
              > otherwise...
              >
              > Regards
              > Jan-Erik
              >
              > PS. I'm using weblogic 6.1 and I can not migrate to 7.0 in a near future.
              

  • How to make dynamic provider-url for MDB.

    Hi,
              My application has an MDB that need to bind to a remote queue. The .bindigs file is created and put in a specified location. Is there any way I can specify a dynamic value for this location in the <provider-url> tag in my weblogic-ejb.xml file. This is because, in our UNIX test and prod servers, the location of the .bindings file different from what I have on my local box. I have tried like this, but it did not work.
              <provider-url>file:/%DOMAIN_DIR%/config/<provider-url>
              We always have a 'config' directory under the domain and if the domain name changes in different environments, i don't have to make any changes to my descriptor file.
              Thanks,
              Rajeev

    I met a similar problem when I used the foreign JMS server. I configured the foreign server via console. I tried to subscribe a remote topic which was maintained by another WebLogic JMS server. When I built my MDB, I got the following exception. The remote JMS server name could not be resolved. Any suggection is appreciated.
              <Sep 19, 2005 6:11:56 PM EDT> <Warning> <EJB> <BEA-010061> <The Message-Driven E
              JB: SIGNIT is unable to connect to the JMS destination: jms/DCGSCatalogTopic. Th
              e Error was:
              [EJB:010196]'weblogic.jms.common.JMSException: Error creating session' Linked ex
              ception = 'weblogic.jms.dispatcher.DispatcherException: could not find JMS Serve
              r riicServer'
              weblogic.jms.common.JMSException: Error creating session
              at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:79
              8)
              at weblogic.jms.frontend.FESession.consumerCreate(FESession.java:1038)
              at weblogic.jms.frontend.FESession.invoke(FESession.java:2552)
              at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.jav
              a:643)
              at weblogic.jms.dispatcher.DispatcherImpl.dispatchSync(DispatcherImpl.ja
              va:179)
              at weblogic.jms.client.JMSSession.consumerCreate(JMSSession.java:1860)
              at weblogic.jms.client.JMSSession.createConsumer(JMSSession.java:1691)
              at weblogic.jms.client.JMSSession.createSubscriber(JMSSession.java:1422)
              at weblogic.ejb20.internal.JMSConnectionPoller.setUpTopicSessions(JMSCon
              nectionPoller.java:1582)
              at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSCo
              nnectionPoller.java:2009)
              at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectio
              nPoller.java:1180)
              at weblogic.ejb20.internal.JMSConnectionPoller.startJMSConnectionPolling
              (JMSConnectionPoller.java:846)
              at weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.start(MessageDr
              ivenBeanPoolInfoImpl.java:234)
              at weblogic.ejb20.deployer.EJBDeployer.deployMessageDrivenBeans(EJBDeplo
              yer.java:1660)
              at weblogic.ejb20.deployer.EJBDeployer.start(EJBDeployer.java:1488)
              at weblogic.ejb20.deployer.EJBModule.start(EJBModule.java:689)
              at weblogic.j2ee.J2EEApplicationContainer.start(J2EEApplicationContainer
              .java:2127)
              at weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicationContai
              ner.java:2168)
              at weblogic.management.deploy.slave.SlaveDeployer$ComponentActivateTask.
              activateContainer(SlaveDeployer.java:2503)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.doCommit(
              SlaveDeployer.java:2421)
              at weblogic.management.deploy.slave.SlaveDeployer$Task.commit(SlaveDeplo
              yer.java:2138)
              at weblogic.management.deploy.slave.SlaveDeployer$Task.checkAutoCommit(S
              laveDeployer.java:2237)
              at weblogic.management.deploy.slave.SlaveDeployer$Task.prepare(SlaveDepl
              oyer.java:2132)
              at weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.prepare(S
              laveDeployer.java:2384)
              at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTask(Sla
              veDeployer.java:866)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(SlaveDepl
              oyer.java:594)
              at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(SlaveDep
              loyer.java:508)
              at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallbackHan
              dler.java:25)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
              Caused by: weblogic.jms.dispatcher.DispatcherException: could not find JMS Serve
              r riicServer
              at weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(Dispatcher
              Manager.java:330)
              at weblogic.jms.dispatcher.DispatcherManager.dispatcherFindOrCreate(Disp
              atcherManager.java:380)
              at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:79
              6)
              ... 29 more
              Caused by: javax.naming.NameNotFoundException: Unable to resolve 'weblogic.jms.S
              :riicServer' Resolved weblogic.jms; remaining name 'S:riicServer'
              at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(Basic
              NamingNode.java:897)
              at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.jav
              a:230)
              at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.j
              ava:154)
              at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:18
              8)
              at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:19
              6)
              at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:19
              6)
              at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.j
              ava:256)
              at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:359)
              at javax.naming.InitialContext.lookup(InitialContext.java:347)
              at weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(Dispatcher
              Manager.java:314)
              ... 31 more
              >
              <Sep 19, 2005 6:12:06 PM EDT> <Warning> <EJB> <BEA-010096> <The Message-Driven E
              JB: SIGNIT is unable to connect to the JMS destination: jms/DCGSCatalogTopic. Co
              nnection failed after 2 attempts. The MDB will attempt to reconnect every 10 sec
              onds. This log message will repeat every 600 seconds until the condition clears.
              >
              <Sep 19, 2005 6:12:06 PM EDT> <Warning> <EJB> <BEA-010061> <The Message-Driven E
              JB: SIGNIT is unable to connect to the JMS destination: jms/DCGSCatalogTopic. Th
              e Error was:
              [EJB:010196]'weblogic.jms.common.JMSException: Error creating session' Linked ex
              ception = 'weblogic.jms.dispatcher.DispatcherException: could not find JMS Serve
              r riicServer'
              weblogic.jms.common.JMSException: Error creating session
              at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:79
              8)
              at weblogic.jms.frontend.FESession.consumerCreate(FESession.java:1038)
              at weblogic.jms.frontend.FESession.invoke(FESession.java:2552)
              at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.jav
              a:643)
              at weblogic.jms.dispatcher.DispatcherImpl.dispatchSync(DispatcherImpl.ja
              va:179)
              at weblogic.jms.client.JMSSession.consumerCreate(JMSSession.java:1860)
              at weblogic.jms.client.JMSSession.createConsumer(JMSSession.java:1691)
              at weblogic.jms.client.JMSSession.createSubscriber(JMSSession.java:1422)
              at weblogic.ejb20.internal.JMSConnectionPoller.setUpTopicSessions(JMSCon
              nectionPoller.java:1582)
              at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSCo
              nnectionPoller.java:2009)
              at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectio
              nPoller.java:1180)
              at weblogic.ejb20.internal.JMSConnectionPoller.trigger(JMSConnectionPoll
              er.java:978)
              at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.j
              ava:243)
              at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
              dSubject.java:321)
              at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
              121)
              at weblogic.time.common.internal.ScheduledTrigger.executeLocally(Schedul
              edTrigger.java:229)
              at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigg
              er.java:223)
              at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:5
              0)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
              Caused by: weblogic.jms.dispatcher.DispatcherException: could not find JMS Serve
              r riicServer
              at weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(Dispatcher
              Manager.java:330)
              at weblogic.jms.dispatcher.DispatcherManager.dispatcherFindOrCreate(Disp
              atcherManager.java:380)
              at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:79
              6)
              ... 19 more
              Caused by: javax.naming.NameNotFoundException: Unable to resolve 'weblogic.jms.S
              :riicServer' Resolved weblogic.jms; remaining name 'S:riicServer'
              at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(Basic
              NamingNode.java:897)
              at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.jav
              a:230)
              at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.j
              ava:154)
              at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:18
              8)
              at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:19
              6)
              at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:19
              6)
              at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.j
              ava:256)
              at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:359)
              at javax.naming.InitialContext.lookup(InitialContext.java:347)
              at weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(Dispatcher
              Manager.java:314)
              ... 21 more
              >

  • MDB vs standalone JMS client

    I have implemented a transformation server as a JMS client. This is not
    written as a EJB bean, partly because I'm not very familiar with EJB beans.
    I'm being told MDB is the way to go (I'm a bit reluctant in front of the
    additional work) for the usual reasons : transaction-control (not really an
    issue right now for me but may become one), ease of deployment and
    centralized monitoring. Fair enough.
    My standalone JMS client creates a lot of variables at initialization (such
    as a precompiled XSLT stylesheet to substantially improve the speed of each
    transformation).
    Where should this be created if I were to convert my standalone JMS client
    into an MDB ? In ejbCreate() ?
    I'm also a bit worried about a few aspects :
    1) Performance, the size of requests may vary tremendously and I currently
    use a synchronous receive on my input queue, is this more efficient (I pull
    messages when I'm ready) than using beans and onMessage() ? In other words,
    will the container try to push message notifications to MDB bean instances
    that are not ready ?
    2) My standalone JMS consumer is also a producer to several destinations
    (including temporary queues, permanent queues and topics), is there any
    limitation to the use of JMS destinations in an MDB (what about selectors ?)
    vs a standalone java JMS application?
    3) My standalone JMS consumer creates a few threads per request. Any gotchas
    in a MDB vs a standalone Java JMS application ? Are MDB passivated at any
    time ?
    Many thanks for any answer,
    Rosalie
    Rosalie

    Rosalie Mignon wrote:
    I have implemented a transformation server as a JMS client. This is not
    written as a EJB bean, partly because I'm not very familiar with EJB beans.
    I'm being told MDB is the way to go (I'm a bit reluctant in front of the
    additional work) for the usual reasons : transaction-control (not really an
    issue right now for me but may become one), ease of deployment and
    centralized monitoring. Fair enough.There's a number of MDB advantages over writing your own JMS consumers.
    I would recommend MDBs for JMS consumers running within WLS. If you
    have a JMS consumer that is a separate (say client) process, then
    vanilla JMS is still the way to go.
    The MDB container takes care of things like reconnecting you to JMS if
    it fails. It supports foreign JMS providers so your MDBs will work with
    "foreign" messaging systems like MQ-Series.
    >
    My standalone JMS client creates a lot of variables at initialization (such
    as a precompiled XSLT stylesheet to substantially improve the speed of each
    transformation).
    Where should this be created if I were to convert my standalone JMS client
    into an MDB ? In ejbCreate() ?Yes, ejbCreate would be fine.
    >
    I'm also a bit worried about a few aspects :
    1) Performance, the size of requests may vary tremendously and I currently
    use a synchronous receive on my input queue, is this more efficient (I pull
    messages when I'm ready) than using beans and onMessage() ? In other words,
    will the container try to push message notifications to MDB bean instances
    that are not ready ?I'm not sure I understand. You will have a pool of MDB instances all
    receiving from the queue. When an instance is available and there is a
    message pending, the EJB/JMS containers will call your MDB's onMessage
    implementation.
    >
    2) My standalone JMS consumer is also a producer to several destinations
    (including temporary queues, permanent queues and topics), is there any
    limitation to the use of JMS destinations in an MDB (what about selectors ?)
    vs a standalone java JMS application?Not that I can think of.
    >
    3) My standalone JMS consumer creates a few threads per request. Any gotchas
    in a MDB vs a standalone Java JMS application ? You are not really allowed to create threads from an EJB. Why do you
    need to create threads? In general, we wouldn't recommend that
    server-side applications create new threads on each request.
    Are MDB passivated at any
    time ?
    No
    Many thanks for any answer,Your domain name is an unusual one for the J2EE world. If you can tell
    us, I'd be interested to know what you're doing.
    -- Rob
    >
    Rosalie
    Rosalie

  • MDB Deployment Problem in JBoss 4.0.3SP1

    Hi All,
    I am upgrading my App Server from JBoss 323 to JBoss 403.
    I had some MDBs, that are running successfully in JBoss 323.
    But when I tried to redeploy them(after recompiling with jdk1.5), I am facing few issues with them.
    First of all, I have a MDB whose destination was in some other Jboss server instance. That means I am trying to connect my destination "Queue" as remotely. At that time it is thorowing exception like as follows at my server startup time.......
    2006-04-17 07:17:15,191 DEBUG [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Looking up provider adapter:                     java:/Server1JMSProvider
    2006-04-17 07:17:15,191 DEBUG [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Provider adapter:                     org.jboss.jms.jndi.JNDIProviderAdapter@20dcb7
    2006-04-17 07:17:15,191 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler] Creating DLQHandler
    2006-04-17 07:17:15,191 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler] Using factory:                     org.jboss.mq.SpyXAConnectionFactory@1ebe8ec
    2006-04-17 07:17:15,191 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler] Created connection:                     Connection@10751758[token=ConnectionToken:null/b3e21fe26fd3b44f4a0c5bb69995e669                     rcvstate=STOPPED]
    2006-04-17 07:17:15,472 DEBUG [org.jboss.mq.referenceable.SpyDestinationObjectFactory]                     SpyDestinationObjectFactory->getObjectInstance()
    2006-04-17 07:17:15,488 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler] Using Queue: QUEUE.DLQ
    2006-04-17 07:17:15,488 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler] Created DLQHandler
    2006-04-17 07:17:15,488 DEBUG [org.jboss.ejb.plugins.jms.JMSContainerInvoker] context: javax.naming.InitialContext@106989e
    2006-04-17 07:17:15,488 DEBUG [org.jboss.ejb.plugins.jms.JMSContainerInvoker] jndiSuffix: [u]xxxQueue[/u]
    2006-04-17 07:17:15,488 DEBUG [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Got destination type Queue for LifecycleMDB
    2006-04-17 07:17:15,488 DEBUG [org.jboss.jms.ConnectionFactoryHelper] using connection factory:                                         org.jboss.mq.SpyXAConnectionFactory@1ebe8ec
    2006-04-17 07:17:15,488 DEBUG [org.jboss.jms.ConnectionFactoryHelper] using username/password: null/null
    2006-04-17 07:17:15,488 DEBUG [org.jboss.jms.ConnectionFactoryHelper] created XAQueueConnection:                                         Connection@13605872[token=ConnectionToken:null/ea8d256e12a297e358803b37d7bfee4d                               rcvstate=STOPPED]
    2006-04-17 07:17:15,488 DEBUG [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Using client id: null
    2006-04-17 07:17:15,488 WARN  [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Could not find the queue                                         destination-jndi-name=queue/[u]xxxQueue[/u]
    2006-04-17 07:17:15,488 WARN  [org.jboss.ejb.plugins.jms.JMSContainerInvoker] destination not found: queue/[u]xxxQueue[/u]                               reason: javax.naming.NameNotFoundException: [u]xxxQueue[/u] not bound
    2006-04-17 07:17:15,488 WARN  [org.jboss.ejb.plugins.jms.JMSContainerInvoker] creating a new temporary destination:                               queue/[u]xxxQueue[/u]
    2006-04-17 07:17:15,488 DEBUG [org.jboss.mq.server.jmx.DestinationManager] Attempting to create destination:                                    jboss.mq.destination:service=Queue,name=xxxQueue; type=org.jboss.mq.server.jmx.Queue
    2006-04-17 07:17:15,488 INFO  [org.jboss.mq.server.jmx.Queue.xxxQueue] Registration is not done -> stop
    2006-04-17 07:17:15,488 ERROR [org.jboss.ejb.plugins.jms.JMSContainerInvoker] Reconnect failed: JMS provider failure detected:
    org.jboss.deployment.DeploymentException: Error during queue setup; - nested throwable: (javax.management.MBeanException)
         at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:39)My jboss.xml was
    <jboss>
       <enterprise-beans>
          <message-driven>
             <ejb-name>LifecycleMDB</ejb-name>
             <destination-jndi-name>queue/xxxQueue</destination-jndi-name>
             <invoker-bindings>
               <invoker>
                 <invoker-proxy-binding-name>server1-message-driven-bean</invoker-proxy-binding-name>
               </invoker>
             </invoker-bindings>
             <resource-ref>
                <res-ref-name>jms/QueueFactory</res-ref-name>
                <jndi-name>UIL2XAConnectionFactory</jndi-name>
             </resource-ref>
          </message-driven>
       </enterprise-beans>
       <invoker-proxy-bindings>
           <invoker-proxy-binding>
             <name>server1-message-driven-bean</name>
             <invoker-mbean>default</invoker-mbean>
             <proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory>
             <proxy-factory-config>
             <JMSProviderAdapterJNDI>Server1JMSProvider</JMSProviderAdapterJNDI>
             <ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
             <CreateJBossMQDestination>true</CreateJBossMQDestination>
                <MaximumSize>15</MaximumSize>
                <MaxMessages>1</MaxMessages>
                <MDBConfig>
                   <ReconnectIntervalSec>10</ReconnectIntervalSec>
                   <DLQConfig>
                      <DestinationQueue>queue/DLQ</DestinationQueue>
                      <MaxTimesRedelivered>10</MaxTimesRedelivered>
                      <TimeToLive>0</TimeToLive>
                   </DLQConfig>
                </MDBConfig>
             </proxy-factory-config>
          </invoker-proxy-binding>
      </invoker-proxy-bindings>
    </jboss>and my deployment file consist of the following code
    <server>
    <!-- The JMS provider loader -->
      <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
          name="jboss.mq:service=JMSProviderLoader,name=Server1MQProvider">
        <attribute name="ProviderName">Server1JMSProvider</attribute>
        <attribute name="ProviderAdapterClass">
          org.jboss.jms.jndi.JNDIProviderAdapter
        </attribute>
        <!-- The combined connection factory -->
        <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
        <!-- The queue connection factory -->
        <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
        <!-- The topic factory -->
        <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
        <!-- Uncomment to use HAJNDI to access JMS-->
        <attribute name="Properties">
           java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
           java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
           java.naming.provider.url=jnp://SERVER:1499
        </attribute>
      </mbean> 
    </server>

    Did you find a solution to this problem?

  • Weblogic app server: MDB is unable connect to JMS Queue!

    29-Jun-2006 16:22:23 o'clock SGT> <Warning> <EJB> <BEA-010096> <The Message-Driven EJB: YCCEventsMDB is unable to connect to the JMS destination: jms/citos/ycds/RecvYCCEvents_Q. Connection failed after 7 attempts. The MDB will attempt to reconnect every 10 seconds. This log message will repeat every 600 seconds until the condition clears.>
    <29-Jun-2006 16:22:23 o'clock SGT> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: YCCEventsMDB is unable to connect to the JMS destination: jms/citos/ycds/RecvYCCEvents_Q. The Error was:
    [EJB:011009]Unable to create a JNDI InitialContext to lookup the JMS destination.
    javax.naming.ServiceUnavailableException [Root exception is java.net.UnknownHostException: ycds_app_svr]
         at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:41)
         at weblogic.jndi.WLInitialContextFactoryDelegate.toNamingException(WLInitialContextFactoryDelegate.java:618)
         at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:306)
         at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:239)
         at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:135)
         at

    Any update on this. I am getting the same error.

  • MDB cannot connect to JMS destination using Foreign Server

    Hi everyone,
    I have configured foreign jms server in weblogic but when MDB tries to connect to specific queue, it gets the following exception:
    I would really appreciate if anyone could help me.
    <Sep 28, 2012 5:23:34 PM CEST> <Warning> <EJB> <BEA-010096> <The Message-Driven EJB: SmsReceiver is unable to connect to the JMS destination or bind to JCA resource adapter: xcg2/smsInQueue. Connection failed after 2 attempts. The MDB will attempt to reconnect/rebind every 10 seconds. This log message will repeat every 600 seconds until the condition clears.>
    <Sep 28, 2012 5:23:34 PM CEST> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: SmsReceiver is unable to connect to the JMS destination: xcg2/smsInQueue. The Error was:
    [EJB:011010]The JMS destination with the JNDI name: jmsxcg.out could not be found. Please ensure that the JNDI name in the weblogic-ejb-jar.xml or corresponding annotation is correct, and the JMS destination has been deployed.
    javax.naming.InvalidNameException: jmsxcg.out: [LDAP: error code 34 - Invalid DN]; remaining name 'jmsxcg.out' NestedException Message is :jmsxcg.out: [LDAP: error code 34 - Invalid DN]>
    MDB annotation looks like this:
    @MessageDriven(name="SmsReceiver", mappedName="xcg2/smsInQueue",
    activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public class SmsReceiverBean implements MessageListener
    weblogic-ejb-jar.xml excerpt:
         <weblogic-enterprise-bean>
              <ejb-name>SmsReceiver</ejb-name>
              <message-driven-descriptor>
                   <pool>
                        <max-beans-in-free-pool>10</max-beans-in-free-pool>
                        <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
                   </pool>
                   <connection-factory-jndi-name>echoQueueConnectionFactory</connection-factory-jndi-name>
              </message-driven-descriptor>
              <transaction-descriptor>
                   <trans-timeout-seconds>600</trans-timeout-seconds>
              </transaction-descriptor>
    <dispatch-policy>MdbSmsWorkManager</dispatch-policy>
         </weblogic-enterprise-bean>
    and the configuration of foreign-server:
    <?xml version="1.0" encoding="UTF-8"?>
    <weblogic-jms xmlns="http://www.bea.com/ns/weblogic/weblogic-jms">
    <foreign-server name="serverr">
    <sub-deployment-name>Subdeployment</sub-deployment-name>
    <foreign-destination name="sms queue>
    <local-jndi-name>xcg2/smsInQueue</local-jndi-name>
    <remote-jndi-name>jmsxcg.out</remote-jndi-name>
    </foreign-destination>
    <foreign-connection-factory name="Connection Factory">
    <local-jndi-name>echoQueueConnectionFactory</local-jndi-name>
    <remote-jndi-name>QueueConnectionFactory</remote-jndi-name>
    </foreign-connection-factory>
    <initial-context-factory>com.tibco.tibjms.naming.TibjmsInitialContextFactory</initial-context-factory>
    <connection-url>tibjmsnaming://xx.xx.xx.xx:7222</connection-url>
    </foreign-server>
    </weblogic-jms>
    PS. I'm able to connect to the weblogic jndi, get connectionFactory echoQueueConnectionFactory, then lookup queue and grab messages so that's i suspect there is something wrong with configuration

    Hmm - I'm not sure what's going on. Two thoughts --
    Thought 1 - According to my (admittedly minimal) research, Tibco is complaining about a syntax error in the lookup name. Perhaps the problem has something to do with your use of a "." in the queue name "jmsxcg.out": WL or Tibco JNDI might be interpreting the "." as a subcontext or some-such. Perhaps try renaming the queue to "jmsxcg_out" throughout (in Tibco and in your Foreign JMS reference).
    Thought 2 - It probably won't make a difference, but you might want try specifying the source destination via the "destinationJndiName" config property instead of via "mappedName".
    @MessageDriven(
      name = "MyMDB",
      activationConfig = {
        @ActivationConfigProperty(propertyName  = "destinationType",
                                  propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName  = "destinationJndiName",
                                  propertyValue = "MyQueue") // Ext. JNDI Name
    )HTH,
    Tom

  • Error when deploying MDB : when connecting to my destination

    I am getting this followin error in my webLogic server 7.0 log:
    The Error was:
    The Message-Driven EJB attempted to connect to the JMS destination with the JNDI
    name:
    multiPub1. However, the object with the JNDI name: multiPub1 is not a JMS destination
    , or the destination found was of the wrong type (Topic or Queue).>
    <May 18, 2003 11:13:34 AM PDT> <Warning> <EJB> <010096> <The Message-Driven EJB:
    simpl
    eMDB is unable to connect to the JMS destination: multiPub1. Connection failed
    after 2
    ,592 attempts. The MDB will attempt to reconnect every 10 seconds, this log message
    wi
    ll repeat every 600 seconds until the condition clears.>
    <May 18, 2003 11:13:34 AM PDT> <Warning> <EJB> <010061> <The Message-Driven EJB:
    simpl
    eMDB is unable to connect to the JMS destination: multiPub1. The EJB container
    will au
    tomatically attempt to re-establish the connection with the JMS server. This warning
    m
    ay occur during WebLogic Cluster start-up if the JMS destination is located on
    another
    server. When the JMS server connection is re-established, the Message-Driven
    EJB will
    again receive JMS messages.
    I have the destination defined. I am working with multiple JMS providers. I am
    not using startup class. I read the white paper and am following directions. It
    can recognise my Connection Factory but not my destination. I defined the destination
    in the JNDI tree using the weblogic Admin console. I also have the destination
    defined in my SUN's JNDI provider. The bean is deployed but I keep getting this
    error.
    PLEASE HELP!
    sheela

    There are a lot of reason to caused it,but the fact reason is that your destination doesnot exist in weblogic server jndi tree.

  • MDB on Tibco JMS Queue

    Hy, I'm writing about a technical problem with BeaWebLogicServer 6.1 sp5.
    I've a MessageDrivenBean in the BeaWebLogic Container that must be connected to
    a remote Tibco JMS queue.
    When the remote Tibco queue is not protected by a password this works fine (my
    MDB receives the message from Tibco queue), instead if the remote queue is password
    protected, i've this Bea Weblogic server error log:
    <Jun 18, 2004 3:06:06 PM CEST> <Warning> <EJB> <The Message-Driven EJB: BuyResponseConsumer
    is unable to connect to the JMS destination: TELECOMIT.IPBILLING.SVIL.PI.PORTALE.ORDER.BUYRESP.
    Connection failed after 850 attempts. The MDB will attempt to reconnect every
    10 seconds, this log message will repeat every 600 seconds until the condition
    clears.>
    How may I resolve this problem?
    These are my xml descriptors:
    EJB-JAR.XML:
    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
    2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
    <ejb-jar>
    <enterprise-beans>
    <message-driven>
    <ejb-name>BuyResponseConsumer</ejb-name> <ejb-class>it.telecomitalia.wonderland.ipbilling.buyresponse.BuyResponseConsumer</ejb-class>
    <transaction-type>Container</transaction-type> <acknowledge-mode>auto-acknowledge</acknowledge-mode>
    <message-driven-destination> <destination-type>javax.jms.Queue</destination-type>
    </message-driven-destination>
    <security-identity>
    <use-caller-identity id="XXXXX" />
    </security-identity>
    </message-driven>
    </enterprise-beans>
    <assembly-descriptor>
    <security-role>
    <role-name>XXXXX</role-name>
    </security-role>
    </assembly-descriptor>
    </ejb-jar>
    WEBLOGIC-EJB-JAR.XML
    <?xml version="1.0"?> <!DOCTYPE weblogic-ejb-jar PUBLIC "-//BEA Systems, Inc.//DTD
    WebLogic 6.0.0 EJB//EN" "http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd">
    <weblogic-ejb-jar>
    <weblogic-enterprise-bean> <ejb-name>BuyResponseConsumer</ejb-name> <message-driven-descriptor>
    <pool>
    <max-beans-in-free-pool>200</max-beans-in-free-pool> <initial-beans-in-free-pool>20</initial-beans-in-free-pool>
    </pool> <destination-jndi-name>REMOTE-MESSAGE-QUEUE-NAME</destination-jndi-name>
    <initial-context-factory>com.tibco.tibjms.naming.TibjmsInitialContextFactory</initial-context-factory>
    <provider-url>tcp://XXX.XXX.XXX.XXX:YYY</provider-url> <connection-factory-jndi-name>QueueConnectionFactory</connection-factory-jndi-name>
    </message-driven-descriptor> <jndi-name>BuyResponseConsumer</jndi-name> </weblogic-enterprise-bean>
    <security-role-assignment>
    <role-name>XXXXX</role-name> <principal-name>XXXXX</principal-name> </security-role-assignment>
    </weblogic-ejb-jar>
    Thanks in advance,
    Best Regards
    Demis Gallisto

    Hy, I'm writing about a technical problem with BeaWebLogicServer 6.1 sp5.
    I've a MessageDrivenBean in the BeaWebLogic Container that must be connected to
    a remote Tibco JMS queue.
    When the remote Tibco queue is not protected by a password this works fine (my
    MDB receives the message from Tibco queue), instead if the remote queue is password
    protected, i've this Bea Weblogic server error log:
    <Jun 18, 2004 3:06:06 PM CEST> <Warning> <EJB> <The Message-Driven EJB: BuyResponseConsumer
    is unable to connect to the JMS destination: TELECOMIT.IPBILLING.SVIL.PI.PORTALE.ORDER.BUYRESP.
    Connection failed after 850 attempts. The MDB will attempt to reconnect every
    10 seconds, this log message will repeat every 600 seconds until the condition
    clears.>
    How may I resolve this problem?
    These are my xml descriptors:
    EJB-JAR.XML:
    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
    2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
    <ejb-jar>
    <enterprise-beans>
    <message-driven>
    <ejb-name>BuyResponseConsumer</ejb-name> <ejb-class>it.telecomitalia.wonderland.ipbilling.buyresponse.BuyResponseConsumer</ejb-class>
    <transaction-type>Container</transaction-type> <acknowledge-mode>auto-acknowledge</acknowledge-mode>
    <message-driven-destination> <destination-type>javax.jms.Queue</destination-type>
    </message-driven-destination>
    <security-identity>
    <use-caller-identity id="XXXXX" />
    </security-identity>
    </message-driven>
    </enterprise-beans>
    <assembly-descriptor>
    <security-role>
    <role-name>XXXXX</role-name>
    </security-role>
    </assembly-descriptor>
    </ejb-jar>
    WEBLOGIC-EJB-JAR.XML
    <?xml version="1.0"?> <!DOCTYPE weblogic-ejb-jar PUBLIC "-//BEA Systems, Inc.//DTD
    WebLogic 6.0.0 EJB//EN" "http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd">
    <weblogic-ejb-jar>
    <weblogic-enterprise-bean> <ejb-name>BuyResponseConsumer</ejb-name> <message-driven-descriptor>
    <pool>
    <max-beans-in-free-pool>200</max-beans-in-free-pool> <initial-beans-in-free-pool>20</initial-beans-in-free-pool>
    </pool> <destination-jndi-name>REMOTE-MESSAGE-QUEUE-NAME</destination-jndi-name>
    <initial-context-factory>com.tibco.tibjms.naming.TibjmsInitialContextFactory</initial-context-factory>
    <provider-url>tcp://XXX.XXX.XXX.XXX:YYY</provider-url> <connection-factory-jndi-name>QueueConnectionFactory</connection-factory-jndi-name>
    </message-driven-descriptor> <jndi-name>BuyResponseConsumer</jndi-name> </weblogic-enterprise-bean>
    <security-role-assignment>
    <role-name>XXXXX</role-name> <principal-name>XXXXX</principal-name> </security-role-assignment>
    </weblogic-ejb-jar>
    Thanks in advance,
    Best Regards
    Demis Gallisto

  • MDB Migration

    hi,
    I need to come up with a solution that requires high availbility to a topic and a Mdb that consumes messages from this topic.
    I´ve a cluster with two Managed Servers: Ms1 and Ms2.
    I´ve created a JMSServer that has a target to a migratable target (Ms1 migratable) that will migrate to Ms2 in case of Ms1 failure.
    I´ve created a module with a connection factory and a Topic. The module´s target is the cluster and i,ve created a subdeployment (JmsGroup) for this module that targets the JMSServer hence when the JMSServes migrates also will the connection factory and the topic.
    The topic and connection factory targets are the subdeployment(JmsGroup).
    I deploy my mdb homogeneously to the cluster following the section Migration and Recovery for Clustered MDBs
    from Oracle documentation http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ejb/message_beans.html
    Everything runs fine, the MDB(instance in Ms1) consumes the messages and when i shutdown Ms1 to simulate a failure, the JMSServer , connection factory and Topic are migrated to Ms2 and the Mdb (instance in Ms2) connects to the destination (Topic) and begins to consume the messages.
    The only problem is when i deploy the mdb in the cluster i got this warning in Ms2 server log.
    <BEA-010061> <The Message-Driven EJB: TopicMDB is unable to connect to the JMS destination: jndi.optareTopic. The Error was:
    The destination for the MDB TopicMDB(Application: TopicMDBApp, EJBComponent: TopicMDB.jar) could not be resolved at this time. Please ensure the destination is available at the JNDI name jndi.Topic. The EJB container will periodically attempt to resolve this MDB destination and additional warnings may be issued.>
    And in administration server console the MDB is in active state but has the warning icon instead of the green one.
    Can i stop this warning since it´s obvious the destination is not availble in Ms2.
    Did i made some mistake in this setup?
    How could i solve this problem? Any clue that could help me?
    Thanks in advance all the helping.

    Hi TomB, First of all thanks for your helping. I just have finished to prove your solution.
    First i got this warning.
    ###<Nov 2, 2010 2:11:59 AM EDT> <Warning> <EJB> <localhost.localdomain> <node2Server> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1288678319770> <BEA-010096> <The Message-Driven EJB: TopicMDB is unable to connect to the JMS destination or bind to JCA resource adapter: jndi.optareDistTopic. Connection failed after 2 attempts. The MDB will attempt to reconnect/rebind every 10 seconds. This log message will repeat every 600 seconds until the condition clears.>
    ####<Nov 2, 2010 2:11:59 AM EDT> <Warning> <EJB> <localhost.localdomain> <node2Server> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1288678319771> <BEA-010061> <The Message-Driven EJB: TopicMDB is unable to connect to the JMS destination: jndi.optareDistTopic. The Error was:
    weblogic.jms.common.InvalidClientIDException: Client id, TopicMDB_optareTest_node1Server (migratable)_TopicMDBAppTopicMDB.jarTopicMDB, is in use. The reason for rejection is "The JNDI name weblogic.jms.connection.clientid.TopicMDB_optareTest_node1Server (migratable)_TopicMDBAppTopicMDB.jarTopicMDB was found, and was bound to an object of type weblogic.jms.frontend.FEClientIDSingularAggregatable : FEClientIDSingularAggregatable(SingularAggregatable(<855227821040290852.1>:45):TopicMDB_optareTest_node1Server (migratable)_TopicMDBAppTopicMDB.jarTopicMDB)"
    Nested exception: weblogic.jms.common.InvalidClientIDException: Client id, TopicMDB_optareTest_node1Server (migratable)_TopicMDBAppTopicMDB.jarTopicMDB, is in use. The reason for rejection is "The JNDI name weblogic.jms.connection.clientid.TopicMDB_optareTest_node1Server (migratable)_TopicMDBAppTopicMDB.jarTopicMDB was found, and was bound to an object of type weblogic.jms.frontend.FEClientIDSingularAggregatable : FEClientIDSingularAggregatable(SingularAggregatable(<855227821040290852.1>:45):TopicMDB_optareTest_node1Server (migratable)_TopicMDBAppTopicMDB.jarTopicMDB)">
    I´ve removed
    @ActivationConfigProperty(
                   propertyName = "subscriptionDurability",
                        propertyValue = "Durable")     
    from my MDB and the deployment was suscessfully without any warning.
    The problem now i got the mdb active in Ms1 and Ms2 and messages are processed twice. I dont understand how the mdb in Ms2 is able to connect to a destination that in theory is currently in Ms1 only.
    Anyway thanks for your support.

  • MDB ClientId Already in Use

              Hello,
              Using WLS 8.1. Occasionally after restarting the server, we receive a ClientId
              already in use exception when deploying MDBs. They are using the same connection
              factory, but it does not specify a clientId. The MDBs are letting the clientId
              default to the bean names (and the exception messages indicate as such). Any
              suggestions?
              Thanks,
              Bob
              

    Hi Bob,
              If a durable subscriber fails, its client-id reservation
              may take a few seconds to get cleaned up. Does the MDB
              manage to reconnect after retrying for a couple minutes?
              Do the JMS server statistics show an active consumer for
              the durable subscription even after the MDB has been
              down for a couple minutes?
              Tom
              Bob Stevenson wrote:
              > Hello,
              >
              > Using WLS 8.1. Occasionally after restarting the server, we receive a ClientId
              > already in use exception when deploying MDBs. They are using the same connection
              > factory, but it does not specify a clientId. The MDBs are letting the clientId
              > default to the bean names (and the exception messages indicate as such). Any
              > suggestions?
              >
              > Thanks,
              >
              > Bob
              

  • Can I recover a damaged SQL Server 2008 database with the undamaged .mdb and .ldf files?

    Their original SQL Server was 2008, with SP unknown, but installed on D: and C: drives.  The power spike corrupted their O/S on the C:
    drive and someone reinstalled both the O/S and the SQL Server, which is now SQL 2008, SP4.  They have intact files for all system databases, both .mdb and .ldf.  Is there some way they can reconnect with the user databases using the intact copies
    of the previous system databases? I have heard that if the SQL Server is stopped, previous Master and Msdb .mdb and .ldf files moved into place and the server restarted, that any previous user database .mdb and .ldf files can be accessed by the SQL server.
    Is this the case, or are there details missing?

    Hello! try this steps
     1 Open your SQL Server Management Studio console. This application shortcut is available in the SQL Server directory in the Windows Start button.
    2  Enter the system administrator user name and password. SQL Server's administrator user name is "sa." This account is required for privileges to restore the database. If your restoring on a host provider server, use the administrator user name
    and password they supplied for your account.
     3 Right-click your database name and select "Attach." In the new window that opens, click the "Add" button to open a dialog box.
     4 Select your MDF file and press the "Ok" button. It may take several minutes to restore the database if it is a large file. Once the process is finished, browse your tables to verify the data. The database is now restored.
    If nothing helped try to use: 
    https://www.youtube.com/watch?v=1cbOYdvBW2c

  • WLS MDB and MQ Series

    Hi ,
              I have an MDB deployed under WLS6.1 which is listening to a WLS
              JMS Queue and the MDB(which calls a MQ Client) has to deliver the
              message to MQ Server once it recieves a message from WLS JMS Queue .
              Now how do I enable the JDBC store to take the messages which fail on
              the MDB side assuming the MQ Server is failing and the MDB should
              retry it again. Or what is the best solution in this scenario without
              using any transactional object . Any suggestions pls about .
              thanks
              taniga s
              

    Approach One:
              Could you have a three bridges all reading the queue, one for each target MQ server?
              This would not be fail-over, but may solve your problem - as it is high-availability.
              (Bridges automatically attempt reconnect on failure.)
              Approach Two:
              Could you forward the message using error destinations, this
              is a feature in 6.1 that redirects recovered or rolled back messages
              to an error destination:
              Q1, error dest is ERROR1, set redeliveryLimit to 0
              ERROR1 error dest is ERROR2, set redeliveryLimit to 0
              ERROR2 error dest is ERROR3, set redelivery limit to 0
              MDB on Q1 goes to MQ queue A
              MDB on ERROR1 goes to MQ queue B
              MDB on ERROR3 goes to JDBC
              taniga wrote:
              > Hi Tom,
              > Thanks a lot and I appreciate your help on this. Actually my
              > situation is kinda different. Our MDB has to be looking for
              > alternative MQ Servers if one is failing and hence we cannot bind the
              > MDB to just a single Queue. So I think i cannot utilize the Bridging
              > btwn MQ and WLS JMS.My aim is like I have to handle the error when MQ
              > Server is down and I should be able to route it to another MQ Server.
              > And in this case too if it fails I should be able to take this message
              > to JDBC Store(considering MDB could not deliver the message to MQ
              > Server). I hope this one explains my problem.
              >
              > thanks
              > taniga s
              >
              > Tom Barnes <[email protected]> wrote in message news:<[email protected]>...
              > > Probably the best solution is to use a bridge to automatically
              > > forward messages between WL and MQ. See the
              > > post on "How to use IBM MQ as a JMS Provider".
              > >
              > > Some possible solutions:
              > >
              > > 1 MDB could accept the message and resend it to its WLS queue with
              > > a birth-time (time-to-deliver) for later retry.
              > >
              > > 2 MDB could reject message (by throwing a runtime exception, such
              > > as NullPointerException). WL behavior here is to call recover() and
              > > resend message. (Alternatively make the MDB transactional and set
              > > rollback-only.) To prevent message from being immediately
              > > redelivered, configure a redelivery delay on the destination.
              > >
              > > 3 MDB could be undeploy self on failure, and a timer object or some such
              > > thing could be initiated to redeploy MDB once it detects
              > > MQ dest comes up.
              > >
              > > Redelivery delay and time-to-deliver are both WL extensions. They
              > > are described in detail in the JMS programmer's guide.
              > >
              > > taniga wrote:
              > >
              > > > Hi ,
              > > > I have an MDB deployed under WLS6.1 which is listening to a WLS
              > > > JMS Queue and the MDB(which calls a MQ Client) has to deliver the
              > > > message to MQ Server once it recieves a message from WLS JMS Queue .
              > > > Now how do I enable the JDBC store to take the messages which fail on
              > > > the MDB side assuming the MQ Server is failing and the MDB should
              > > > retry it again. Or what is the best solution in this scenario without
              > > > using any transactional object . Any suggestions pls about .
              > > >
              > > > thanks
              > > > taniga s
              

  • Exception when using TIBCO EMS for a WebLogic MDB - intermittent issue

    We have a weblogic app that uses an MDB to retreive messages from TIB EMS.
    There are no exceptions at first - the messages are retreived and everything works well.
    But after a few days and then we see the following exception:
    ####<Apr 13, 2009 2:11:43 PM EDT> <Error> <Kernel> <dhbpmapp2.is.bear.com> <mngENS_dhbpmapp2> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1239646303673> <BEA-000802> <ExecuteRequest failed
    java.lang.ClassCastException: com.tibco.tibjms.naming.TibjmsFederatedQueue.
    java.lang.ClassCastException: com.tibco.tibjms.naming.TibjmsFederatedQueue
    at weblogic.jms.common.CDS.ddLookup(CDS.java:759)
    at weblogic.jms.common.CDS.access$400(CDS.java:37)
    at weblogic.jms.common.CDS$DDLookupTimerListener.timerExpired(CDS.java:612)
    at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
    at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManag erImpl.java:464)
    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
    at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
    We do not know why this comes up after a few days.
    Any help in tracking this down will be greatly appreciated.
    We are using Weblogic Server 10.0

    Hi,
    This might be happening when the MDB tries to reconnect to the foreign destination.
    Have you configured the TIB EMS as Foreign JMS provider in WLS ?
    Do you know whether this issue happens only when
    1) the MDB gets redeployed ?
    2) the server instance that hosts the foreign dest gets bounced?
    3) the JMS module that defines the foreign JMS server gets redeployed ?
    Anyway, based on a quick search in support cases, looks like this issue has been already fixed.
    Please contact the customer support to get the appropriate patch.
    Thanks
    Kats

Maybe you are looking for