JMS, EJB, MDB etc.

Hi all,
I've got a client that accesses an EJB which in turn starts an MDB via a queue. The MDB has some processing which can take a while.
The problem I have is I need the client to be able to poll the EJB and see if the MDB has finished its processing yet. I'm stumped to try and think of a way the MDB can report its processing status back to the EJB.
Thanks for any input.

The only way I can think of to do this is to have the MDB send some messages to a Queue, when you poll the EJB it looks on the Queue. If all you want is notification that the MDB has finished just send a message at the end.

Similar Messages

Verify failed; continuing java.lang.NoClassDefFoundError: jms/server/MDB

Hi friend iam trying to deploy my MDB on Jboss as but i get these errors
Verify failed; continuing java.lang.NoClassDefFoundError: jms/server/MDB
i cant find what is the problem
in the jar file i hav directory jms/server under that directory MDB.class exhists. and in the ejb jar i mentioned like this
<ejb-name>MDB</ejb-name>
<ejb-class>jms.server.MDB</ejb-class>
i really dont understand what is the problem.
any help
thanks

Hi,
You can check it out the JNDI name in the JMS. This name is same as the jndi name in the xml file.
Are u going to use Queue or Topic API.
If it is queue, you declare queue in xml file.
I wish you all the best
Maruthi.

WL 8.1 SP6 to WL10.3 upgrade any TIPS on "JMS, EJB, Web Service, JDK" etc?

We are upgrading from BEA Weblogic 8.1 SP6 to Oracle Weblogic 10.3. The application running on WL 8.1 SP6 provides the services like - Web Service consumer, JMS server/consumer, RMI server. The JDK under WL 8.1 being 1.4.
We have a mix of client application that are essentially JMS clients/senders and RMI clients. These clients will also be upgraded to Oracle Weblogic 10.3 but not at the same time as JMS server/consumer. So some clients may still be running on WL 8.1 JDK 1.4 while the server is running on WL 10.3 (that needs JDK 1.6)
Please share any TIPs on compatibility issues (and how to overcome) for this mismatch between WL versions as well as JDK.
Are there any specific details as for as JMS configuration setup from WL 8.1 to WL10.3.
Appreciate your help!

Some thoughts:
* WL 10.3 fully supports 8.1 clients, so you can simply continue to use the 8.1 client jars. The drawback is that the clients won't be able to use new features like unit-of-order, and you may not get some performance benefits of the later clients.
* I think WL 10.3 clients support the 1.5 and 1.6 JVMs.
* I think WL 9.2 clients support 1.5 and 1.4 JVMs, so you might consider using 9.x clients during your transition period. This will give you access to more new features without forcing the client to use the 1.5 or 1.6 JVM.
* As for mix-and-matching of JDK versions, you will need to develop your applications and serializable applications objects so that they continue to use the lowest common denominator. For example, if the same application code must run on 1.4 and a 1.5 client, then don't use generics. Also, avoid using new 1.5 or later JDK classes for serializable objects, if the objects must be passed to older clients (which, of course, will not be able to unmarshal such classes).
* WL 10.3 and later stand-alone "full clients" can no longer always simply just use the "weblogic.jar". You can only include the weblogic.jar in the client classpath if the jar is embedded with a full weblogic install, otherwise, you must generate a "full client jar" using a command line utility and reference the generated jar instead. See [ Overview of Stand-alone Clients | http://download.oracle.com/docs/cd/E12839_01/web.1111/e13717/basics.htm#i1062773 ].
* WL 10.3 configuration is quite different than 8.1 configuration. Some things to keep in mind:
-- You now must also configure "WL Stores" (target to same target as the JMS server that uses the store). For JMS purposes, I recommend configuring a custom store per server and avoiding use of the default store.
-- You still must configure JMS server(s) (configure each to reference a WL store that has the same target)
-- You now must configure "JMS Modules", which contains definitions for destinations.
-- In most cases, best practice is that you should configure one system module per set of JMS servers in a cluster and define a single "subdeployment" target for the module that directly lists each JMS server, target the module itself to a cluster, target destinations within the module to the subdeployment. Avoid "default targeting" for destinations, but its OK for connection factories.
-- If some destinations are distributed across multiple JMS servers, while others are restricted to a single JMS server, then use two modules each with its own subdeployment. One module for the restricted case that uses regular destinations, and the other for the distributed case.
Hope this helps,
Tom

Weblogic JMS EJB : ThreadLocal access query : getting null in same thread

We have two applications(one is jms and other is ejb) on single instance of weblogic managed server.
On receving a new jms message the jms application call the ejb application by passing the new xml message.
ejb application creates a threadlocal object and allocated transaction id to this transaction. I want to access this transactionid(present in threadlocal) in my jms application. But i am getting null.
I believe i am in the same thread as i printing the thread number in the both the application log. I verified that same thread number was present for multiple messages
in both logs [Except if one scenario of thread pooling is present that when jms calls ejb it frees the thread(23) and when ejb completes its job if gives back the thread(23) to jms...but it resets thread local]
I need answer to following question
1. Why is my transaction id null when i access through jms application.
2. I believe i am in the same jvm instance.
3. I believe i am in the same thread instance...( looking at logs except if someone can tell me i am not.....)
4. Or if there is alternative solution to pick up threadlocal variable in my jms application.
JMS application is new application trying to connect to existing ejb application which had the thread local design and we want to use that existing architecture before we decide to change. We need the transactionid for log corelation.

I assume that either your JMS destination is backed by a database or your application is doing some database operations in the same transaction as the JMS send operation. I suspect that there is some kind of database maintenance process going on every night, which causes the database operations to be slow or not responding, which in turn causes the MDB transaction that the JMS send operation participates in to timeout.

Starvation in EJB/MDB thread pool ?

I am re-posting this article including the acronym EJB in the subject so that the EJB experts don't overlook this question. This question was moved from the JMS newsgroup to this newsgroup by a BEA moderator.
Our application receives 10 different types of messages on one queue each. Thus we have 10 queues (MQ as a Foreign JMS provider with MDBs in a WLS). We have MDBs processing each of these queues. The producer (mainframe) that sends messages to these queues operates in batch mode.
Option (1) Configure all MDBs in the same custom thread pool. If a blast of 500 messages arrives on one of the queues and all the threads start consuming messages, what happens to new messages that arrive on other queues ? Do they have to wait until these 500 messages are processed ? I would like someone from the BEA JMS implementation team to comment on this.
Option (2) Configure smaller custom thread pools - one for each queue. Solves the problem above. Let us say we allocate 2 threads per MDB in custom thread pools. This ensures that none of the queues starve, however, if there is a practical limit on the maximum number of threads that can be configured, then this option introduces an inefficiency. What if there are 200 messages in one queue and zero messages in all others ? We are allowing only two threads to process those 200 messages while the other threads just sit and watch.

I am re-posting this article including the acronym EJB in the subject so that the EJB experts don't overlook this question. This question was moved from the JMS newsgroup to this newsgroup by a BEA moderator.
Our application receives 10 different types of messages on one queue each. Thus we have 10 queues (MQ as a Foreign JMS provider with MDBs in a WLS). We have MDBs processing each of these queues. The producer (mainframe) that sends messages to these queues operates in batch mode.
Option (1) Configure all MDBs in the same custom thread pool. If a blast of 500 messages arrives on one of the queues and all the threads start consuming messages, what happens to new messages that arrive on other queues ? Do they have to wait until these 500 messages are processed ? I would like someone from the BEA JMS implementation team to comment on this.
Option (2) Configure smaller custom thread pools - one for each queue. Solves the problem above. Let us say we allocate 2 threads per MDB in custom thread pools. This ensures that none of the queues starve, however, if there is a practical limit on the maximum number of threads that can be configured, then this option introduces an inefficiency. What if there are 200 messages in one queue and zero messages in all others ? We are allowing only two threads to process those 200 messages while the other threads just sit and watch.

Weblogic 6.1 JMS/EJB Design Question

Any thoughts from gurus or those who have skinned their knees on similar
issues would be GREATLY appreciated!
Environment:
Weblogic 6.1 sp3/Oracle 8.1.7 on Solaris
I've got a webservice that invokes the webservice ejb and then delegates
down to business layer ejb that delegates down to data layer dao classes
that store off on average 150 records which include a clob field containing
about 4k of data. (All in one JTA transaction) (I'll refer to this as
operation 1)
There is a logically independent process (parsing the clob data elements)
that I'd like to kick off after all 150 records have been stored. (Needs
access to the committed data) (I'll refer to this as operation 2)
Questions:
1. Can a stateless session ejb running under a single phase JTS transaction
safely post a message to a JMS topic or queue running on the same weblogic
instance?
2. If so, are there any guidelines as to whether the transaction for
operation 1 will complete before the sender receives notification? (the
concern being that operation 2 will be notified but the data it is
interested in will not be visible yet) If no guarantees, would configuring
a JMS message delivery delay help?
3. This operation will get invoked perhaps a thousand times a day, and I'm
fearful of falling into the message redelivery trap from transaction
rollbacks which possibly could occur from operation 2. Above all else, I
care about NOT having the queue get clogged up with resends. Given that
bias, should I use NOTSUPPORTED then have the session bean that the MDB
delegates to start a transaction or would using BMT from the MDB be more
correct?
4. Any other thoughts?
Thanks!

Alan May wrote:
Any thoughts from gurus or those who have skinned their knees on similar
issues would be GREATLY appreciated!
Environment:
Weblogic 6.1 sp3/Oracle 8.1.7 on Solaris
I've got a webservice that invokes the webservice ejb and then delegates
down to business layer ejb that delegates down to data layer dao classes
that store off on average 150 records which include a clob field containing
about 4k of data. (All in one JTA transaction) (I'll refer to this as
operation 1)
There is a logically independent process (parsing the clob data elements)
that I'd like to kick off after all 150 records have been stored. (Needs
access to the committed data) (I'll refer to this as operation 2)
Questions:
1. Can a stateless session ejb running under a single phase JTS transaction
safely post a message to a JMS topic or queue running on the same weblogic
instance?So is the first transaction going to be writing 150 records to the
database and the publishing a JMS message? Yes, this can all be one in
one transaction in WLS, but it will be a XA/2PC transaction. I'm
curious why you specified single-phase?
>
2. If so, are there any guidelines as to whether the transaction for
operation 1 will complete before the sender receives notification? (the
concern being that operation 2 will be notified but the data it is
interested in will not be visible yet) I'm not sure I follow you here. If the message publish is part of the
transaction then no consumer will receive the message before the publish
transaction commits.
If no guarantees, would configuring a JMS message delivery delay help?
3. This operation will get invoked perhaps a thousand times a day, and I'm
fearful of falling into the message redelivery trap from transaction
rollbacks which possibly could occur from operation 2. There's 2 important WLS JMS features I would suggest you look into:
1) Message redelivery delay & limits
2) Error destinations
Take a look at
http://e-docs.bea.com/wls/docs81/jms/implement.html#1255066
Above all else, I
care about NOT having the queue get clogged up with resends. Given that
bias, should I use NOTSUPPORTED then have the session bean that the MDB
delegates to start a transaction or would using BMT from the MDB be more
correct?I think you'd be better off using redelivery limits and delay than
trying to do the JMS acknowledgement and transaction management yourself.
-- Rob
>
4. Any other thoughts?
Thanks!

EJB - MDB Transaction

          Hi,
          I am trying to configure a transaction to span between one Stateless EJB and MANY
          JMS Messages sent to a topic consumed via a MDB.
          I have a Stateless EJB Services called copyOffers(List offerIds). For each offerId
          in OfferIds it sends a JMS Message to the CopyOffer Topic. I have one MDB subscribed
          to the Topic that does the work of copying the ONE offer it was provided. I also,
          have configured the JMSReplyTo with a temp. Topic so that all the CopyOfferMDBs
          can notify the Stateless EJB when they are done.
          I want all the EJB and MDB calls to act within ONE transaction. The Stateless
          Session Bean is marked as REQUIRED and the MDB is marked as CONTAINER and also
          REQUIRED.
          Here is what I have done...
          If I mark my JMS Connection Factory as User Transaction Enabled = true... ALL
          the MDB messages are only delivered once the Stateless EJB is commited. Then each
          MDB is in its own transaction.
          I can not get all the MDBs and the EJB to be in ONE transaction whereby if ONE
          MDB failed ALL failed.
          Any ideas?
          Thanks,
          Mike Porter


Cool!
          There is no standard J2EE API or WebLogic J2EE extension
          for handling multiple asynchronous workers
          in the same transaction, but there is a supported non-J2EE
          "back-door". Use the (free) Tuxedo java client's "tpacall()"
          methods, and program your EJBs to be Tuxedo aware. (Tuxedo
          is BEA's "C" based app server, but no Tuxedo server is needed.)
          http://edocs.bea.com/wls/docs81/wtc.html
          I do not know of any customers without a Tuxedo background that
          are doing this. But, if you are interested, the "wtc" newsgroup
          should be able to get you started.
          Tom
          P.S. The alternative is to use multiple transactions, which
          inform some stateful central location when they are done. This
          stateful thing could be an entity bean. This requires extra
          code for failure cases - as it requires code for detecting the
          failures in the first place, code for fixing up the failed
          transaction(s), and for undoing the committed transactions(s).
          This kind of code is generally referred to as
          "compensating transactions", and, as you can imagine, sometimes
          gets pretty hairy pretty fast...
          Mike Porter wrote:
          > I was afraid of that.
          >
          > Any ideas how I can asynchronously handle multiple workers(IE:my offer copiers)
          > in one transaction. I thought JMS would help but I guess not.
          >
          > Thanks,
          >
          > Mike
          >
          > Tom Barnes <[email protected]> wrote:
          >
          >>Hi Mike,
          >>
          >>As with any messaging system, the production of a message can
          >>not participate in the same transaction as the consumption of
          >>a message. The producer's commit call is what makes
          >>the message available for consumption.
          >>
          >>You may want to read the "transactions" chapter of the
          >>JMS Programmer's guide.
          >>
          >>Tom
          >>
          >>
          >>Mike Porter wrote:
          >>
          >>>Hi,
          >>>
          >>>I am trying to configure a transaction to span between one Stateless
          >>
          >>EJB and MANY
          >>
          >>>JMS Messages sent to a topic consumed via a MDB.
          >>>
          >>>I have a Stateless EJB Services called copyOffers(List offerIds). For
          >>
          >>each offerId
          >>
          >>>in OfferIds it sends a JMS Message to the CopyOffer Topic. I have one
          >>
          >>MDB subscribed
          >>
          >>>to the Topic that does the work of copying the ONE offer it was provided.
          >>
          >>I also,
          >>
          >>>have configured the JMSReplyTo with a temp. Topic so that all the CopyOfferMDBs
          >>>can notify the Stateless EJB when they are done.
          >>>
          >>>
          >>>I want all the EJB and MDB calls to act within ONE transaction. The
          >>
          >>Stateless
          >>
          >>>Session Bean is marked as REQUIRED and the MDB is marked as CONTAINER
          >>
          >>and also
          >>
          >>>REQUIRED.
          >>>
          >>>Here is what I have done...
          >>>If I mark my JMS Connection Factory as User Transaction Enabled = true...
          >>
          >>ALL
          >>
          >>>the MDB messages are only delivered once the Stateless EJB is commited.
          >>
          >>Then each
          >>
          >>>MDB is in its own transaction.
          >>>
          >>>I can not get all the MDBs and the EJB to be in ONE transaction whereby
          >>
          >>if ONE
          >>
          >>>MDB failed ALL failed.
          >>>
          >>>Any ideas?
          >>>
          >>>Thanks,
          >>>
          >>>Mike Porter
          >>>
          >>
          >

Ejb MDB Pool Settings ignored?

Hi.
I have a series of MDBs, and have tried to increase performance by setting the InitialSize and MaxSize values of the bean in the ejb-j2ee-engine.xml (not version 3!).
However, it doesnt seem to make any difference and messages seem to be getting processed sequentially, as if there was only one instance of the bean.
Here is the layout of my xml.
<ejb-j2ee-engine
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ejb-j2ee-engine.xsd">
<description/>
<enterprise-beans>
<enterprise-bean>
<ejb-name>mySimpleMDB</ejb-name>
<jndi-name>jms/myTestQueue</jndi-name>
<message-props>
<destination-name>jms/myTestQueue</destination-name>
<connection-factory-name>jms/queueConnectionFactory</connection-factory-name>
<property>
<property-name>InitialSize</property-name>
<property-value>1</property-value>
</property>
<property>
<property-name>MaxSize</property-name>
<property-value>1</property-value>
</property>
<property>
<property-name>ResizeStep</property-name>
<property-value>1</property-value>
</property>
</message-props>
</enterprise-bean>
</enterprise-beans>
</ejb-j2ee-engine>
Is this the correct location - i am pretty sure it is by looking at the documentation.
regards,
Andrew

Hi Vladimir - here are the relevant XML files:
ejb-jar.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!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>
     <display-name>TestApp</display-name>
          <message-driven>
               <description>Validates</description>
               <display-name>Validation</display-name>
               <ejb-name>FileValidationMDB</ejb-name>
               <ejb-class>com.test.dts.ejb.FileValidationMDBBean</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>
               <env-entry>
                    <description/>
                    <env-entry-name>ejb/beanRefContext</env-entry-name>
                    <env-entry-type>java.lang.String</env-entry-type>
                    <env-entry-value>classpath:beanRefContext.xml</env-entry-value>
               </env-entry>
          </message-driven>
     </enterprise-beans>
     <assembly-descriptor>
        <container-transaction>
            <method>
                <ejb-name>FileValidationMDB</ejb-name>
                <method-name>onMessage</method-name>
                <method-params>
                    <method-param>javax.jms.Message</method-param>
                </method-params>
            </method>
            <trans-attribute>Required</trans-attribute>
        </container-transaction>
    </assembly-descriptor>
</ejb-jar>
ejb-j2ee-engine.xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ejb-j2ee-engine
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="ejb-j2ee-engine.xsd">
     <description/>
     <enterprise-beans>
          <enterprise-bean>
               <ejb-name>FileValidationMDB</ejb-name>
               <jndi-name>jms/dts/registeredFiles</jndi-name>
               <message-props>
                    <destination-name>jms/dts/registeredFiles</destination-name>
                    <connection-factory-name>jms/dts/queueConnectionFactory</connection-factory-name>
                    <property>
                         <property-name>parallel-consumers</property-name>
                         <property-value>10</property-value>
                    </property>
                    <property>
                         <property-name>InitialSize</property-name>
                         <property-value>10</property-value>
                    </property>
                    <property>
                         <property-name>MaxSize</property-name>
                         <property-value>10</property-value>
                    </property>
                    <property>
                         <property-name>ResizeStep</property-name>
                         <property-value>1</property-value>
                    </property>
               </message-props>
          </enterprise-bean>
     </enterprise-beans>
</ejb-j2ee-engine>
jms-resources.xml
<?xml version="1.0" encoding="UTF-8"?>
<jms-resources xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="jms-resources.xsd">
     <connection-factory>
          <name>jms/dts/XAConnectionFactory</name>
          <sap-local-factory-type>
               <type>javax.jms.XAConnectionFactory</type>
               <virtual-provider>default</virtual-provider>
          </sap-local-factory-type>
     </connection-factory>
     <connection-factory>
          <name>jms/dts/queueConnectionFactory</name>
          <sap-local-factory-type>
               <type>javax.jms.XAQueueConnectionFactory</type>
               <virtual-provider>default</virtual-provider>
          </sap-local-factory-type>
     </connection-factory>
     <connection-factory>
          <name>jms/dts/topicConnectionFactory</name>
          <sap-local-factory-type>
               <type>javax.jms.XATopicConnectionFactory</type>
               <virtual-provider>default</virtual-provider>
          </sap-local-factory-type>
     </connection-factory>
     <destination>
          <name>jms/dts/registeredFiles</name>
          <type>javax.jms.Queue</type>
          <sap-local-destination-type>
               <virtual-provider>default</virtual-provider>
               
          <property>
            <description>
               Message Delivery Attempts Limited - We dont limit...
            </description>
            <config-property-name>
               deliveryAttemptsLimited
            </config-property-name>
            <config-property-value>false</config-property-value>
         </property>
         <property>
            <description>Delay in Milliseconds</description>
            <config-property-name>
               deliveryDelayInterval
            </config-property-name>
            <config-property-value>60000</config-property-value>
         </property>
          </sap-local-destination-type>
     </destination>
</jms-resources>
Hope this sheds some light on the subject...
Andrew

Distributed transaction (JDBC+JMS), durable MDB, NullPointException in weblogic

          I am cross posting to transaction & jms, sorry if this is a mistake...
          We have a setup where JMS messages are published to a topic. The posting is transacted
          (XA) and is a consequence of a CMP update so JMS and JDBC (Oracle OCI) cooperate
          to commit, or not.
          Most of the time, transactions issue just a few JMS messages but at least once
          a day, we issue hundred of thousands of such messages (max has been about 600000
          but typically 300000).
          Our setup is four instances of Weblogic 6.1SP3 (two clustered, two not), the topic
          is on one of them (all 3 other servers connect to that instance to publish) and
          we have a couple MDBs deployed only on the instance that has the JMSServer and
          they all listen to the local topic. The transactionnal settings of these MDBs
          is CMT and XA (because the beans will write to the DB). Furthermore, these MDB
          have been setup to be durable. One of these is just a logger MDB with 20 instances
          max.
          It worked fine for a couple weeks but we have been running into problems for the
          past two days. All of a sudden, the server no longer responds to weblogic.ADMIN
          PING. The server log indicates the following error repetitively (MB of logs just
          of this)
          ####<13 nov. 03 23:15:41 CET> <Alert> <JMS> <XXXXXXX> <send1> <ExecuteThread:
          '32' for queue: 'default'> <> <> <040060> <JMSServer "OutputServerSend1", unhandled
          exception during rollback, java.lang.NullPointerException.>
          java.lang.NullPointerException
          at weblogic.jms.backend.BEDurableTopicMessageInfo.rollbackReceiveTran(BEDurableTopicMessageInfo.java:352)
          at weblogic.jms.backend.BEXATranEntrySubscribe.startRollback(BEXATranEntrySubscribe.java:145)
          at weblogic.jms.backend.BEXATranEntry.execute(BEXATranEntry.java:127)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          The logger MDB seems to have started processing the JMS messages. This means that
          the transaction that included the JMS message publishing must have commited. Unfortunatly,
          there are only 20 log lines before the server restart, so the server must have
          hanged although it did commit the messages processed by the logger since the log
          messages are apparently not repeated. I have no idea why. I think this is coherant
          with the fact that exception above seems to relate to subscribers.
          When we restart the server, the topic gets purged and seem to be processed (we
          have not found a way to verify that each message has been processed but it's looking
          good)
          Any ideas ?
          Thanks
          Philippe


          I am cross posting to transaction & jms, sorry if this is a mistake...
          We have a setup where JMS messages are published to a topic. The posting is transacted
          (XA) and is a consequence of a CMP update so JMS and JDBC (Oracle OCI) cooperate
          to commit, or not.
          Most of the time, transactions issue just a few JMS messages but at least once
          a day, we issue hundred of thousands of such messages (max has been about 600000
          but typically 300000).
          Our setup is four instances of Weblogic 6.1SP3 (two clustered, two not), the topic
          is on one of them (all 3 other servers connect to that instance to publish) and
          we have a couple MDBs deployed only on the instance that has the JMSServer and
          they all listen to the local topic. The transactionnal settings of these MDBs
          is CMT and XA (because the beans will write to the DB). Furthermore, these MDB
          have been setup to be durable. One of these is just a logger MDB with 20 instances
          max.
          It worked fine for a couple weeks but we have been running into problems for the
          past two days. All of a sudden, the server no longer responds to weblogic.ADMIN
          PING. The server log indicates the following error repetitively (MB of logs just
          of this)
          ####<13 nov. 03 23:15:41 CET> <Alert> <JMS> <XXXXXXX> <send1> <ExecuteThread:
          '32' for queue: 'default'> <> <> <040060> <JMSServer "OutputServerSend1", unhandled
          exception during rollback, java.lang.NullPointerException.>
          java.lang.NullPointerException
          at weblogic.jms.backend.BEDurableTopicMessageInfo.rollbackReceiveTran(BEDurableTopicMessageInfo.java:352)
          at weblogic.jms.backend.BEXATranEntrySubscribe.startRollback(BEXATranEntrySubscribe.java:145)
          at weblogic.jms.backend.BEXATranEntry.execute(BEXATranEntry.java:127)
          at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
          at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          The logger MDB seems to have started processing the JMS messages. This means that
          the transaction that included the JMS message publishing must have commited. Unfortunatly,
          there are only 20 log lines before the server restart, so the server must have
          hanged although it did commit the messages processed by the logger since the log
          messages are apparently not repeated. I have no idea why. I think this is coherant
          with the fact that exception above seems to relate to subscribers.
          When we restart the server, the topic gets purged and seem to be processed (we
          have not found a way to verify that each message has been processed but it's looking
          good)
          Any ideas ?
          Thanks
          Philippe

Using Spring beans from EJB MDB

I have a situation where I need to use spring beans from an EJB 3.0 MDB. The project does not have any webapps or anything,
it will be only a MessageBean facade that needs to call spring beans. It is meant to be a service, that can be called by usign a single EJB message.
The problem is I cannot get the spring context to load properly, since the MDBean it self is initialized(constructor called) only when it receives the first message from the broker, thus It's "too late" to initialize the spring context. What I want to do is load the spring context when the EJB is deployed in the Java EE container. So, is there a way I can call a some method, class, anything when the EJB is deployed in the container. Can I do something with a deployment descriptor?
I am using glassfish V2 UR1, EJB 3.0, Spring 2.0.7 The project is deployed as a jar.

Miku wrote:
I have a situation where I need to use spring beans from an EJB 3.0 MDB. The project does not have any webapps or anything,
it will be only a MessageBean facade that needs to call spring beans. It is meant to be a service, that can be called by usign a single EJB message. Why not make it a real service? Spring's contract first web services are a very nice way to go. It hides the fact that you're using a message-driven component for processing, too.
%

How JMS and MDB works?

Hi,
I am writing a portion of a J2EE application and would like to perform asynchronous processing. Im new to JMS. Following are some questions i have:
- How does JMS process message, queue and MDB? I mean when a message is send to a queue, how does it know which MDB should be receiving the message?
- Im using JBoss which has JMS support. Under normal circumtances, is it all right to use the default queue that comes with the JMSProvider (i.e. the application server in this case)? Or should we write some other codes for create queue?
- In terms of design, should one MDB only performs a single function? The reason for this is that a MDB seems to only have a single 'onMessage' method?
- The following is what my application tries to achieve: Servlet will call a method in a StatelessSessionBean. SessionBean perform first some processing. And since part of the process does not require to be done at the same time, i would like it to happen asynchronously. I actually intend to have that part of the processing happens in an MDB. Is that the correct way to use JMS & MDB? How else could i perform asynchronous processing?
Thanks much.
Veny

- how does it know which MDB should be receiving the message?
The MDB is configured to consume messages from a specific queue in one of the J2EE xml files (Haven't written them in a while so can't be sure which one).
- is it all right to use the default queue that comes with the JMSProvider
I wouldn't, because your queue names won't reflect the job they are doing.
Create some new queues by updating your jms providers config files.
- In terms of design, should one MDB only performs a single function
This is a reasonable approach to take, although it's sometimes OK to have an MDB act like a controller and delegate to handler classes (possibly session beans) based on the message type. The latter approach is suitable only for small apps as it's far less configurable / scalable (e.g. you can't say I want 10 MDB instances to processing message X and 50 MDB instances to process message Y).
- Is that the correct way to use JMS & MDB
Yes, that's pretty much it, although I would still delegate the work to a handler class. It will make if easier to test and more portable.

Dynamically Undeploying EJBs / MDBs

Hi,
Is there a way to programmatically undeploy EJBs or MDBs. I am working with WLS6.1.
I have a Message Driven Bean which should take messages from the Queue and parse
the XML body of the message and save it into the database.
In the MDB, onMessage(), I am checking if the Database is available, if it is
not available, I am rolling back the message. But the problem is the message
is consumed again. So I want to undeploy the MDB after some retries.
Can I programmatically undeploy a Message Driven Bean or EJB.
Thanks in advance
Venkatesan

Hi,
Is there a way to programmatically undeploy EJBs or MDBs. I am working with WLS6.1.
I have a Message Driven Bean which should take messages from the Queue and parse
the XML body of the message and save it into the database.
In the MDB, onMessage(), I am checking if the Database is available, if it is
not available, I am rolling back the message. But the problem is the message
is consumed again. So I want to undeploy the MDB after some retries.
Can I programmatically undeploy a Message Driven Bean or EJB.
Thanks in advance
Venkatesan

WLS6.1 sp3, jms/mq MDB

Hi
          We are using WLS6.1 sp3, accessing MQ through MQ/JMS and Bean managed MDBs. We are managing transaction by throwing Runtime exception and sending the message for requeueing for any issue. We are not using any Messaging bridge approach.
          Has any faced any issue with this approach? May be with later SPs or 7.0, does any foresee any problem in this approach?
          Thanks
          Srinivas


(1) MDB container managed transactions are not
          supported in 6.1SP3 for most foreign vendors. This type
          of question is pretty common, here is the cut and
          paste response:
          Start by reading this white-paper on dev2dev.bea.com
          "Using Foreign JMS Providers with WebLogic Server"
          Be aware that WL 8.1 provides a couple new features that
          simplify integration. The white-paper does not cover them:
          Resource-Reference JMS Pooling (pooling and auto-enlistment)
          Foreign Destination Wrappers (register foreign dest in local JNDI)
          See http://edocs.bea.com/wls/docs81/notes/new.html#1160067
          (2) Managing the operation by using two different atomic operations
          (one for receive, one for send), and failing the send on
          certain failures does not guarantee exactly-once. No matter
          what messaging system is used. There are fundamental race
          conditions that can cause lost or duplicate messages. The
          only way to force exactly once when using two atomic operations
          is to write the code in such
          a way that allows duplicate receives to occur, and to detect if
          the received message has already been operated on by
          checking a history record that was recorded
          for each previous receive. Where the history record
          must be written to a database atomically
          as part of the send transaction using a transaction.
          (3) I recommend using the bridge, or moving up to
          version 7.0 or later.
          Tom
          Srinivas wrote:
          > Hi
          >
          > We are using WLS6.1 sp3, accessing MQ through MQ/JMS and Bean managed MDBs. We are managing transaction by throwing Runtime exception and sending the message for requeueing for any issue. We are not using any Messaging bridge approach.
          >
          > Has any faced any issue with this approach? May be with later SPs or 7.0, does any foresee any problem in this approach?
          >
          > Thanks
          > Srinivas

EJB - MDB and Session and Entity - Seem to always run under same Thread

I am working on an application that implemets a connection from an MDB to a Session EJB which inturn connects to a Entity EJB. All connections are impemented as Local Home. I use log4j for tracing and notice that the thread ID reported for all activity is the same "Thread ID: MessageListenerThreadPool : 0" .
This confuses me because I thought that all EJB's would execute under different threads. Have I done something wrong? Have I missinterpreted the EJB implementation? Any opinions would be greatly appreciated!!

Hi Kelly,
This is a slight misinterpretation of the EJB threading requirements. There are a couple different issues as play here. First, the main threading guarantee made by the spec is that a particular instance of an EJB will not be invoked by the container on more than one thread at a time. This is one of the guarantees that simplifies the EJB programming model so that developers don't have to do anything special (e.g. the use of synchronized blocks) to handle concurrent access. Second, the EJB Local programming model requires that invocations have pass-by-reference semantics. Of course, the easiest way for the container to provide that behavior is to literally make the local invocation on the same thread.
The call-flow you're describing touches a single instance from three different beans, so the threading guarantee is not violated. Hope that clears things up a bit.
--ken

JMS with MDB design question

Hi All,
Here is my situation. I have a JMS Queue and a MDB that consumes the messages delivered to this queue. In the OnMessage method of the MDB,I do some business processing including talking to a database. My requirement is that if the database is not available for some reason,I have to keep retrying the whole thing for half an hour at some predefined intervals. How can this be achieved?
Thanks

hi.
i agree with arnaud that the use of timer is better. thanks for that, arnaud.
additionally, i'd like to add that i don't think you should use a transaction for this sort of messaging, since from what i understand, you are talking single messaging here, and creating transactions for a single message flow is an overkill for most needs. also, it takes a lot of resources from the application server.
the other point to consider is that you are not talking about a case where a message did not reach it's destination. as far as the messaging provider is concerned, the message was consumed by the MDB, and the problem occured in latter processing. you also, as crackers noted, have the issue of configuring the provider to handle the redeliveries, which is again a pain in a body-part.
i think this is a design-related case, and i might go over the messaging-provider's acks here, and send acks on a different queue.
nimo.

JMS, EJB, MDB etc.

Similar Messages

Maybe you are looking for