Pending MDBs

I am using MDBs and Stateless Session Beans, transaction timeout for the beans is 120 sec. I face this problem of all messages not being processed (some value in Messages Pending) but not always. I don't see any exceptions in my server log either. It just stops.
          Any clues, way to debug.
          Thanks.
          Weblogic 8.1 sp2
          Message was edited by abhinav at Oct 14, 2004 10:44 AM

Did you check if your MDB is connected to the queue.
          You can find Pending Messages only if:
          1) there is no consumer attached to the queue
          2) the messages are not yet deliverable (only if you send messages with a
          timeToDeliver value).
          Ciao
          Marco
          "Abhinav Srivastava" <[email protected]> wrote in message
          news:15103484.1097775905671.JavaMail.root@jserv5...
          > I am using MDBs and Stateless Session Beans, transaction timeout for the
          beans is 120 sec. I face this problem of all messages not being processed
          (some value in Messages Pending) but not always. I don't see any exceptions
          in my server log either. It just stops.
          > Any clues, way to debug.
          > Thanks.
          >
          > Weblogic 8.1 sp2
          >
          > Message was edited by abhinav at Oct 14, 2004 10:44 AM

Similar Messages

MDB leaving messages pending in a topic

I have a case in production where the MDB
          Pools Beans in use count is -2
          The topic which it subscribes to is having alot of message pending back
          up on our topic.
          Also the bean does not seem to undeploy so I can get rid of it as a
          consumer.
          I am also posting in EJB news group
          Weblogic 7.0 sp1


Well Raskol, you said that you have a (may be more) DurableSubscriber created for a Topic and consuming the messages asynchronously through the onMessage method. Now the question is how to know whether all the messages posted to that Topic are delivered to you so as to enable you to stop the DurableSubscriber from further listening.
My question to you is when do you decide (and convince your self) that no more messages are available on that Topic.
The answer may be to timeout after a predetermined value. But then, what is the guarantee that no more messages will be posted subsequently to this Topic.
Any way, this can not be accomplished as per the suggestion from 'turbobutton', since JMS does not allow for synchronous reception, once you declare an asynchronous listener.
So, try restarting a global timer with each message reception. On crossing a predetermined value, call subscriber.close method. If this is not supported by your provider, try calling connection.stop (but, mind you, this call stops reception by all consumers created on this connection).
-kris teja

MDB (2-phase commit) behavior during abnormal JMS termination

Hello to everyone!
I plan to test the following scenario tomorrow (sort of a bug replication in our system).
Anyway, wanted to know in advance the expected behavior (just in case one of you already know
or have an experience related to this test). Thank you in advance.
Scenario:
I want to test/know the behavior of a 2-phase commit (2PC) MDB when JMS server abnormally exits
(say the process was killed).
Test flow:
start app server --> deploy 2pc-mdb --> send dummy data --> kill jms process --> restart jms process
1. will the connection be closed properly?
2. when jms server restarts, will the value of active consumer(count) doubled?
note: i think after mdb deployment, corresponding destination consumer count is 1.
the problem that occurred in our system was that the consumer count doubled after server restarted.
it seem like the previous connection was not closed when the jms server abnormally terminated.
any inputs will be greatly appreciated.
thanks and best regards.

You have to use TxDataSource for container managed tx or if you are using JTA (in
addition to ofcourse doing 2PC).
S
"Dale Olzer" <[email protected]> wrote:
>
Using weblogic 6.1 SP 4
I have a simple container managed Message Driven Bean. Using a destination
type
javax.jms.Queue.
When the onMessage method finishes the Message is still Pending on the
queue.
see the ejb-jar.xml below
<ejb-jar>
<enterprise-beans>
<message-driven>
<display-name>IvrMessageBean</display-name>
<ejb-name>IvrMsgBean</ejb-name>
<ejb-class>com.edocs.ps.ivr.IvrMsgBean</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>
</message-driven>
</enterprise-beans>
</ejb-jar>
I noticed when I set a JDBC TX DataSource to 2 Phase Commit, the JMS
transaction
started commitig and nothing was left pending in the Queue.
Does 2PC have to be set in a DataSource for Container Managed MDB's to
work?

Container managed transactions in 9.0.3 (plus AQ JMS/MDB)

Something for "real programmers", similar to MDB Transaction Exception on OC4J 9.0.4 (MDB Transaction Exception on OC4J 9.0.4) but little bit different. Maybe author of the mentioned thread can find some answers here also.
We have an MDB accessing AQ in database (this works either with 9i and 8i). MDB receives the message (actually TextMessage), retrieves the content/properties and calls some EJBs making database operations. When we used just the same DataSource for JMS resource provider and SQL operations, everything worked OK. But we need to move one step further - making calls to several databases, some 8i, some might 9i. We were able to start CMT for one DataSource, i. e. configuring OrionCMTDataSource over JDBC ORACLE driver (if you use different DataSource class, message remains stucked in queue and eventually expires. If you don't specify container managed transactions for MDB in ejb-jar.xml, it works with any DataSource class - but message is lost every time exception occurs - not very pleasant situation).
We are trying to configure DataSources so they provide transactional support while using commit coordinator. There are some documents describing this - in 9iAS Data Sources and JTA, Orion Data Sources and possibly JTA description in 9i database documentation. Both ORACLE documents are very similar. Generally, these are main steps:
1) configure each data source so they provides CMT support (wrap native driver/data source by OrionCMTDataSource class)
2) create datasource commit-coordinator database, also using CMT(?)
3) create user in commit-coordinator database and same in each other database with connect, resource, create session + force any transaction priviledge (since it would commit other users transactions)
4) create database links from commit-coordinator database to each databases (but... see questions below)
5) configure commit coordinator so it uses proper data source
6) add each DB link as a property to data sources
7) configure data source for JMS
8) connect JMS resource provider with JMS data source
9) Start container, send message, etc.
So far the only result we've got is a trace file in database user dumps and generic "javax.transaction.SystemExeption: Could not commit: error code 29540". User dump occurs in a "remote" database, not the one where commit coordinator resides. If I drop database links, result is the same, so it seems like problem with data source itself. In a dump there is piece of text like this: "FATAL ERROR IN TWO-TASK SERVER: error = 12571" and "ksedmp: internal or fatal error
Current SQL statement for this session:
begin dbms_aqin.aq$_dequeue_in( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29); end; ". I think AQ call is just a coincidence since it is the first one involved in transactions. Down there in HEX part of a dump there is a message about protocol or network error ("probably ORA-28546")
Here is an example of data source configuration we are using:

<data-source
name="PassportDS"
class="com.evermind.sql.OrionCMTDataSource"
location="jdbc/PassportDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="int"
password="int"
url="jdbc:oracle:thin:@ws18885:1521:ICON"
inactivity-timeout="30">
<property name="dblink" value="ICON.WS18885.APPG.COM"/>
There are some questions pending. Obvious one is if CMT is working or not at all and we should find some different solution (Bean managed transactions or use XA, hmmm). Other one might be that database link has to be "fully-qualified". I'm not sure what it means: using username and password? Using database name along with domain (if any)? So far it seems links are not used anyway.
We've tried several databases, like 9.2.0.1 and 9.0.3 versions. Result is the same.
We've tried to use XA data source of ORACLE (oracle.jdbc.xa.client.OracleXADataSource) and OrionCMT data source bound by xa-source-location to it but container gets stucked upon restart with "Investingating resource 'XADataSource PassportXADS' for recovery..." and similar messages for an hour.
There is an OracleJTADataSource mentioned in several documents, but I cannot find any in jdbc classes - was it deprecated?
Lies the problem in JMS itself? So far we've been able to use AQ in 8i and 9i and succesfully commit every transaction - provided transaction was local.
Since XA itself is working I guess problem might be with configuration.
I will appreciate any opinion on CMT... also, if you have any questions, please ask.
Myrra

Hi Per,
I don't have an answer for you -- sorry {:-( -- only a suggestion (which
you may have already tried, anyway :-). Have you tried running OC4J
in "debug" mode? The following web-page gives details on how to do that:
http://kb.atlassian.com/content/atlassian/howto/orionproperties.jsp
Also, if you aren't already aware of them, the following web-sites
may also be helpful (not in any particular order):
http://www.orionserver.com
http://www.orionsupport.com
http://www.elephantwalker.com
Good Luck,
Avi.

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

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


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

Pending messages

We are having a problem with some messages being stuck in the queue.
          They show as "pending" in the console and, in fact, get delivered to
          the listeners (MDBs) on server restart. The code of MDBs is beyond our
          control (the messages are actually sent to Weblogic Business Process
          Manager, part of WLI). The transaction attribute of the listeners is
          "Not Supported". Any ideas what's going on? It could be related to
          spikes in volume, but would not one expect the messages just sit in
          the queue and be picked up when the volume of incoming messages drops?
          Our biggest concern is finding a way to process these "lost" messages
          without having to restart the server. Any thoughts? Thanks!
          Igor


version? there were some stalled listener problems fixed in 6.1 SP3.
          _sjz.
          "Igor Sidorin" <[email protected]> wrote in message
          news:[email protected]..
          > We are having a problem with some messages being stuck in the queue.
          > They show as "pending" in the console and, in fact, get delivered to
          > the listeners (MDBs) on server restart. The code of MDBs is beyond our
          > control (the messages are actually sent to Weblogic Business Process
          > Manager, part of WLI). The transaction attribute of the listeners is
          > "Not Supported". Any ideas what's going on? It could be related to
          > spikes in volume, but would not one expect the messages just sit in
          > the queue and be picked up when the volume of incoming messages drops?
          > Our biggest concern is finding a way to process these "lost" messages
          > without having to restart the server. Any thoughts? Thanks!
          >
          > Igor

MDB and load balnce

Appreciated for any input in advance.
          I am working on application that is running on a weblogic 9.2 cluster with two managered nodes. There two JMS servers, one for each node instance, and Uniformed Distributed Destination queue is configured for JMS servers (or targeted to cluster). MDB listen to this queue, and configured maxBeansInFreePool = "5", initialBeansInFreePool = "5".
          MDB uses customized connection factory with config
               Maximum Messages per Session = 1
               lient Acknowledge Policy = Previous
          I Sent 40 message to queue in cluster, then from weblogic console, we can see "Messages Current" is 15, and "Message Pending" 5 in the queue for each node, and "Bean In Use Count" is 5.
          MDBs in one node process all message very fast, and MDBs in another node are very slow. for instance, "Messages Current" and "Message Pending" is 0 in the node one, and "Messages Current" 15 and "Message Pending" 5 in node two. My question here is why Weblogic does not move some message from node two to node one? How I can fix this problem?
          Best Regards,
          James

Tom,
          Do you have any further information on the internal extension to do with
          ALSB?
          > I think our ALSB product can use an internal extension to force MDBs
          to consume from all queue members, rather than just the local queue
          members - so if you're using ALSB you might want to investigate this
          option.
          I've a problem at the moment getting an ALSB proxy service to consume
          from all queue members in a cluster - it only consumes from a single
          destination if you've one server in the alsb cluster, yet I've 4 jms
          member destinations.
          We're using ALSB3.0 and it has a proxy listening to a JMS distributed
          destination on a WLS8.1 server.
          Pete
          Tom Barnes wrote:
          > Hi,
          >
          > We don't move messages from slowly served destination members to fast served destinations. You might want to try setting things up to take advantage of the load balancing that queueing naturally provides when their are multiple receivers on the same member:
          >
          > I think our ALSB product can use an internal extension to force MDBs to consume from all queue members, rather than just the local queue members - so if you're using ALSB you might want to investigate this option.
          >
          > If you're not using ALSB, you can match this behavior by either (A) deploying the MDBs to a different cluster than the distributed queue, or (B) deploying two MDBs to the cluster: one that directly consumes from member1 and another that consumes from member2 (rather than a single MDB that consumes from the distributed queue's logical name).
          >
          > Tom

MDB on distributed topic issue (server restart)

Setup:
          - On WebLogic 8.1 SP3, One cluster with 2 managed servers, S1 and S2.
          - JMS servers are configured for both S1 and S2.
          - ConnectionFactory(load balancing=true, server affinity=false, XA Transaction=true) is deployed to the cluster
          - Distributed topic, DT1, deployed to the cluster with physical memeber on each JMS server, T1 on S1, T2 on S2
          - MDB for DT1 is deployed in both S1 and S2
          - Sending message to DT1 thru a session bean with container managed transaction.
          Test:
          1. Start both server, and send 10 messages to DT1, evenrything is fine, both servers received 10 messsage each
          2. Shutdown S2
          3. Send another 10 messages to DT1, S1 received 10 messages thru MDB deployed on it, and noticed that there are 10 messages pending for T1 (by using console destination monitoring function)
          4. Restart S2
          5. When S2 is fully restarted, noticed that the 10 pending messages are gone for T1, but S1 printout 10 Alert: Tx heuristic result
          6. then, if send another 10 messages thru session bean in S1, both servers receives 10 messages each; if send another 10 messages thru session bean in S2, only S2 will receive them all, S1 receives nothing and noticed that 10 messages pending for T2
          Someone posted a similar issue before, but no clear answer on exactly what happened and how to fix it.
          Thanks,
          JD

The errors are:
          <17-Feb-2005 4:40:45 o'clock PM EST> <Error> <JTA> <BEA-110412> <Xid=BEA1-054635FA5A4B74B8B574(14775730),Status=Committed,HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=300,XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=committed,assigned=server2),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@e8b13,re-Registered = false),SCInfo[NakinaDomain+server2]=(state=committed)) completed heuristically: (weblogic.jdbc.wrapper.JTSXAResourceImpl, HeuristicHazard, (javax.transaction.xa.XAException: No connection associated with xid = BEA1-054635FA5A4B74B8B574-7765626C6F6769632E6A6462632
          E777261707065722E4A545358415265736F75726365496D706C)) >

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 is not picking up messages in the Queue

Hi ,
I am trying to implement a MDB (Producer) , that acts as a Message Producer also . This MDB pickes up a message from a Queue and sends it to another Queue(Queue 2) after some processing. The MDB listening to the Queue 2 is not being able to pick this message.
The Weblogic console shows that the message is pending.
The transaction-type is Container and transaction-attribute is 'Required' for the Producer (MDB) ...
I am creating a QueueSession as con.createQueueSession(true, Session.AUTO_ACKNOWLEDGE) . I also tried specifying queuesession.commit() ...
even then the Message is not picked by the MDB listening on the other side...
Please help me out

any one

Pending message redelivery wait period after server startup

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


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

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

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

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

JMS messages stuck as Pending messages

          Hi.
          I am trying to write an application to process huge amounts of data. I try to
          process around 1,000, 000 messages [java objects] using a single queue and 8 MDB.
          The strange thing is that in the end there are always 10 messages stuck in the
          pending message category.
          I can also observe that a weblogic thread is stuck. [can see it in the console]
          The stuck thread current description is something like "Connectio27.Session28".
          I have tried to use the QueueConnectionFactory from a EJB using resource reference
          instead of fetching it directly. Even this has not helped. I guess the problem
          is that while loading the messages onto the queues, one of the threads gets stuck
          somewhere.
          I am sing MDB's for processing. There doesnot seem to be any problems on the MDB
          side.
          If I reboot the server the 10 messages get processed successfully.
          Any ideas will be highly appreciated.
          -Sharma


if you waited for a minute or so between each threaddump, it definitly
          sounds like an issue around the database query not returning or there is too
          much data being returned.
          sree
          "Ghanshyam Sharma" <[email protected]> wrote in message
          news:40e2d9d6$1@mktnews1...
          >
          > Hmm, I didnt wait too much between thread dumps. Probably a minute or two.
          >
          > Let me check the oracle stuff.
          >
          > Thanks a Lot.
          >
          > -Sharma
          >
          > "sree bodapati" <iwillreply@thenewsgroups> wrote:
          > >Threaddumps dont seem to show much except for it looks like both execute
          > >thread 13 and 12 are stuck reading from oracle , you may want to see
          > >what
          > >query is being sent to oracle by instrumenting you MDB code see that
          > >query
          > >properly returns. The threads are runnable but they dont seem to move
          > >, what
          > >was the duration between each thread dump ?
          > >
          > >/
          > >sree
          > >
          > >
          > >"Ghanshyam Sharma" <[email protected]> wrote in message
          > >news:40e2ce39$1@mktnews1...
          > >>
          > >> Hi Tom.
          > >>
          > >> I am attaching a thread dump of the server on windows, when I have
          > >20
          > >messages
          > >> stuck as pending with MDB's having not-supported transaction attribute.
          > >>
          > >> I hope this helps in debugging the problem. Please let me know if
          > >something is
          > >> needed.
          > >>
          > >> Thanks everyone.
          > >> -Sharma
          > >>
          > >>
          > >> Tom Barnes
          >
          ><[email protected].bea.com>
          > >> wrote:
          > >> >As I wrote below, a thread-dump of the WL Server that hosts
          > >> >the stuck MDB might help explain things.
          > >> >
          > >> >Sharma wrote:
          > >> >
          > >> >> Hm, this is confirmed. I pumped in one million messages a few time
          > >> >with and without
          > >> >> file stores to differe the performance, but every time I get a clean
          > >> >slate :)
          > >> >>
          > >> >> Looks like having required transaction attribute somehow removes
          > >this
          > >> >problem.
          > >> >>
          > >> >>
          > >> >> But still I do not understand why messages were getting stuck with
          > >> >not-supported
          > >> >> attribute. Tom is it possible to understand this. The
          > >phenomenon/Reason
          > >> >behind
          > >> >> this may show up somewhere else :)
          > >> >>
          > >> >> -Sharma
          > >> >>
          > >> >> Tom Barnes
          >
          ><[email protected].bea.com>
          > >> >> wrote:
          > >> >>
          > >> >>>The default is no transactions. I also find it curious
          > >> >>>that this helps. I wonder if tx timeouts are helping here...
          > >> >>>
          > >> >>>Sharma wrote:
          > >> >>>
          > >> >>>
          > >> >>>>Surprisingly I could process all one million messages if I
          configure
          > >> >>>
          > >> >>>the MDB's
          > >> >>>
          > >> >>>>as folowing.
          > >> >>>>
          > >> >>>>Default-transaction=required
          > >> >>>>Transaction-typr=container
          > >> >>>>
          > >> >>>>When I was getting the problem, I had nothing for these settings.
          > >> >I
          > >> >>>
          > >> >>>do not know
          > >> >>>
          > >> >>>>what is the default, probably Not-supported ???
          > >> >>>>
          > >> >>>>Let me try my testing a few times and than confirm to you guys.
          > >> >>>>
          > >> >>>>Tom Barnes
          >
          ><[email protected].bea.com>
          > >> >>>>wrote:
          > >> >>>>
          > >> >>>>
          > >> >>>>>Since you narrowed the problem down to the MDB side, can
          > >> >>>>>post a thread dump of the server when it is stuck? That
          > >> >>>>>might help diagnose the problem.
          > >> >>>>>
          > >> >>>>>Ghanshyam Sharma wrote:
          > >> >>>>>
          > >> >>>>>
          > >> >>>>>
          > >> >>>>>>Infact The thread which is stuck is not the loader/message
          producer
          > >> >>>>>
          > >> >>>>>thread. It
          > >> >>>>>
          > >> >>>>>
          > >> >>>>>>is a thread handling message driven beans. My producers end up
          > >populating
          > >> >>>>>
          > >> >>>>>the
          > >> >>>>>
          > >> >>>>>
          > >> >>>>>>JMS correctly.
          > >> >>>>>>
          > >> >>>>>>This is 81sp02.
          > >> >>>>>>-Sharma
          > >> >>>>>>
          > >> >>>>>>"Ghanshyam Sharma" <[email protected]> wrote:
          > >> >>>>>>
          > >> >>>>>>
          > >> >>>>>>
          > >> >>>>>>>Hi.
          > >> >>>>>>>
          > >> >>>>>>>I am trying to write an application to process huge amounts
          > >of
          > >> >data.
          > >> >>>>>>>I try to
          > >> >>>>>>>process around 1,000, 000 messages [java objects] using a single
          > >> >>>
          > >> >>>queue
          > >> >>>
          > >> >>>>>>>and 8 MDB.
          > >> >>>>>>>The strange thing is that in the end there are always 10
          messages
          > >> >>>
          > >> >>>stuck
          > >> >>>
          > >> >>>>>>>in the
          > >> >>>>>>>pending message category.
          > >> >>>>>>>
          > >> >>>>>>>I can also observe that a weblogic thread is stuck. [can see
          > >it
          > >> >in
          > >> >>>>>
          > >> >>>>>the
          > >> >>>>>
          > >> >>>>>
          > >> >>>>>>>console]
          > >> >>>>>>>The stuck thread current description is something like
          > >"Connectio27.Session28".
          > >> >>>>>>>
          > >> >>>>>>>I have tried to use the QueueConnectionFactory from a EJB using
          > >> >resource
          > >> >>>>>>>reference
          > >> >>>>>>>instead of fetching it directly. Even this has not helped. I
          > >guess
          > >> >>>>>
          > >> >>>>>the
          > >> >>>>>
          > >> >>>>>
          > >> >>>>>>>problem
          > >> >>>>>>>is that while loading the messages onto the queues, one of the
          > >> >threads
          > >> >>>>>>>gets stuck
          > >> >>>>>>>somewhere.
          > >> >>>>>>>
          > >> >>>>>>>I am sing MDB's for processing. There doesnot seem to be any
          > >problems
          > >> >>>>>>>on the MDB
          > >> >>>>>>>side.
          > >> >>>>>>>
          > >> >>>>>>>If I reboot the server the 10 messages get processed
          successfully.
          > >> >>>>>>>
          > >> >>>>>>>Any ideas will be highly appreciated.
          > >> >>>>>>>-Sharma
          > >> >>>>>>
          > >> >>>>>>
          > >> >>
          > >> >
          > >>
          > >
          > >
          >

Bytes pending

          Hi,
          Our MDB's (Using Queue) are processing the message perfectly, without any exception
          , all messages are consumed, but Bytes Pending count goes on increasing even there
          is no exception and finally we are getting memory out of exception.
          Thanks and Regards
          Sanjay.


          version and SP?
          On 13 Dec 2002 04:11:05 -0800, "Sanjay"
          <[email protected]> wrote:
          >
          >Hi,
          >
          >Our MDB's (Using Queue) are processing the message perfectly, without any exception
          >, all messages are consumed, but Bytes Pending count goes on increasing even there
          >is no exception and finally we are getting memory out of exception.
          >
          >Thanks and Regards
          >Sanjay.
          >

Messages moving to Pending message state

          Hi
          Using: Weblogic 7.0 with SP2
          1. We have an Application server communicating with a JMS Hub that has a two server
          cluster. This server has an MDB configured dually - one MDB definition listening
          to each of the two physical queues of a virtual queue.
          2. A client writes a message to the virtual queue (causing it to be picked up
          by one of the physical queues). The client exits. I verify that the message actually
          lands up in one of the physical queues using console.
          3. I start the App server, and immediately the message moves to 'Messages Pending'
          column.
          4. The onMessage() of my MDB does not get called at all - I have a log in the
          first line of onMessage() that I do not see.
          5. Any further attempt by the client to put messages into the queue causes it
          to move over to the pending message state as long as the app server is up.
          Any ideas? Thanks bunch in advance.
          Here are the relevant ejb-jar and weblogic-ejb-jar.xml snippets:
          ejb-jar.xml:
               <message-driven>
                    <ejb-name>AcqPoolClosingResponseMDB</ejb-name>
                    <ejb-class>com.fanniemae.core.sec.packetization.acq.ejb.AcqPoolClosingResponseMDB</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>
               </message-driven>
               <container-transaction>
               <method>
               <ejb-name>AcqValidationResponseMDB.OOPSResponseQueue</ejb-name>
               <method-name>*</method-name>
               </method>
               <trans-attribute>NotSupported</trans-attribute>
               </container-transaction>
          weblogic-ejbjar.xml:
               <weblogic-enterprise-bean>
                    <ejb-name>AcqPoolClosingResponseMDB.LoanSetupQueue</ejb-name>
                    <message-driven-descriptor>
                         <pool>
                         <max-beans-in-free-pool>10</max-beans-in-free-pool>
                         <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
                         </pool>
                    <destination-jndi-name>LoanSetupQueue@SecJmsHub-jms04-1</destination-jndi-name>
                    <initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
                    <provider-url>t3://dcore-ap04:7159</provider-url>
                    </message-driven-descriptor>
                    <jndi-name>ejb/AcqPoolClosingResponseMDB</jndi-name>
               </weblogic-enterprise-bean>


Hi Srikant,
          I'm somewhat familiar with "core". The "ejb-class" gives
          you away. :-) I'm not sure what the problem is, but here
          are some things you can try:
          Item number one. The conflicting
          descriptor combo of "container" managed transaction and
          "not-supported" may be the issue. For container
          managed transactions in an MDB, I think the assembly-descriptor
          for the onMessage method should be set to "Required" in
          addition to setting the transaction type to "Container":
          <container-transaction>
          <method>
          <ejb-name>......</ejb-name>
          <method-name>onMessage()</method-name>
          </method>
          <trans-attribute>Required</trans-attribute>
          </container-transaction>
          If you don't want container managed transactions, do not
          specify a "transaction-type" of "Container".
          Item number two. The ejb-name field in container-transaction
          does not match the the ejb-name field in message-driven.
          Furthermore, with container managed transactions
          the acknowledge-mode is ignored so it need not be set.
          Item number three. It is possible that your MDB app
          is throwing a runtime exception before it hits your
          onMessage trace statement. This would cause the MDB container
          to roll-back the tx. The message will then remain
          in a pending state if it is immediately redelivered
          or if there is a redelivery delay configured.
          Hope this helps,
          Tom, BEA
          Srikanth Meenakshi wrote:
          > Hi
          >
          > Using: Weblogic 7.0 with SP2
          >
          > 1. We have an Application server communicating with a JMS Hub that has a two server
          > cluster. This server has an MDB configured dually - one MDB definition listening
          > to each of the two physical queues of a virtual queue.
          >
          > 2. A client writes a message to the virtual queue (causing it to be picked up
          > by one of the physical queues). The client exits. I verify that the message actually
          > lands up in one of the physical queues using console.
          >
          > 3. I start the App server, and immediately the message moves to 'Messages Pending'
          > column.
          >
          > 4. The onMessage() of my MDB does not get called at all - I have a log in the
          > first line of onMessage() that I do not see.
          >
          > 5. Any further attempt by the client to put messages into the queue causes it
          > to move over to the pending message state as long as the app server is up.
          >
          > Any ideas? Thanks bunch in advance.
          >
          > Here are the relevant ejb-jar and weblogic-ejb-jar.xml snippets:
          >
          > ejb-jar.xml:
          >      <message-driven>
          >           <ejb-name>AcqPoolClosingResponseMDB</ejb-name>
          >           <ejb-class>com.fanniemae.core.sec.packetization.acq.ejb.AcqPoolClosingResponseMDB</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>
          >      </message-driven>
          >
          >
          >      <container-transaction>
          >      <method>
          >      <ejb-name>AcqValidationResponseMDB.OOPSResponseQueue</ejb-name>
          >      <method-name>*</method-name>
          >      </method>
          >      <trans-attribute>NotSupported</trans-attribute>
          >      </container-transaction>
          >
          > weblogic-ejbjar.xml:
          >
          >      <weblogic-enterprise-bean>
          >           <ejb-name>AcqPoolClosingResponseMDB.LoanSetupQueue</ejb-name>
          >           <message-driven-descriptor>
          >                <pool>
          >                <max-beans-in-free-pool>10</max-beans-in-free-pool>
          >                <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
          >                </pool>
          >           <destination-jndi-name>LoanSetupQueue@SecJmsHub-jms04-1</destination-jndi-name>
          >
          >           <initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
          >           <provider-url>t3://dcore-ap04:7159</provider-url>
          >           </message-driven-descriptor>
          >           <jndi-name>ejb/AcqPoolClosingResponseMDB</jndi-name>
          >      </weblogic-enterprise-bean>
          >
          >

Pending MDBs

Similar Messages

Maybe you are looking for