MDB Message redelivery
Hi all,
I am using WLS6.1 sp2 running on solaris. I would like to know how I could configure
my MDB and the message sender(JMSConnectionFactory) so that messages will only be
reloaded after the server startup class has completed its execution?
Thanks!
Check if there is any other MDB registered to testweb.queue.AsyncDispatcher_error. I get a feeling that another MDB picks up your errored message which doesn't match the expected message type it requires.
-Kirupa
Similar Messages
-
Re: Constant Message Redelivery Problem
You can get redelivery for other reasons as well. Redelivery occurs if the message is
participating in a transaction, and the transaction fails for any reason.
For example, if the MDB in turn calls an EJB which in
turn calls JDBC then the tx becomes two-phase. If the JDBC call fails then the tx
will roll back. Or if the tx times-out: the default tx timeout is 30 seconds, so if
the MDB takes longer than 30 seconds then the tx will roll-back and message the will
get redelivered.
Even if the tx succeeds, in some cases you may have error states that re-enqueue the
received message but let the transaction commit (WLI, BEA's integration product, can do
this).
This looks like the redelivery of a failed message, but is actually the delivery of a new
version.
Duplicates occur if a Queue MDB's descriptor actually points at a topic destination.
Check for this one by comparing the JNDI name in config.xml against the
descriptor destination type field...
Tom
sunshine wrote:
> I encountered the same problem of repeat message delivery. In our situation, we are
> using JMS JDBC Store and when the database goes down and comes back up, the MDB starts
> processing messages but the messages keep recycling in the JMS Store.
>
> The MDB code tried catching all possible exceptions like RuntimeException and Exception.
> None of these exceptions are logged. When we re-start the WL managed servers, those
> messages in the JMS Store were flushed off.
>
> Any idea what caused the repeat message redelivery?? Thanks.
>
> Tom Barnes <[email protected]> wrote:
> >Your MDB may be throwing a RuntimeException, which forces message
> >redelivery. Put a try/catch/Throwable in the outermost scope of your
> >onMessage() code to see if this is case.
> >
> >Note that in 6.1 and up you can configure redelivery delays, max redelivery
> >counts and error destinations to alleviate this problem...
> >
> >Tom
> >
> >Toad wrote:
> >
> >> I have a message-driven bean listening on a message queue and everything
> >> appears to work the first time the message is sent. The message is processed
> >> and the OnMessage method returns without incident. There are no errors
> >and
> >> no exceptions are thrown by the JMS client or in the MDB itself. PROBLEM:
> >> Message continually redelivered pegging the CPU at 100%. Inspection of
> >the
> >> JMSSTORE and JMSSTATE reveals messages still queued. Any ideas?
> >
And make sure that your MDB is not throwing Errors or RuntimeExceptions,
as these don't necessarily get logged, but they cause rollbacks.
Put a "try {} catch (RuntimeException re)
{ log; throw re; } catch (Error er) { log; throw er; }"
around all the code within the MDB's "onMessage()" callback
to see if this is happening.
Manikyala Peddi wrote:
> Hi,
>
> I have a MDB which is calling an EJB. The redelivery override period was set at 60 sec.
>
> Before completing the first message the same message is redelivered.The processing time in onMessage in MDB takes more than the Redelivery Override Period. Is there a way to prevent the delivery of the duplicate message before completing the first message.Iam using Weblogic 7.1
>
> Thanks
>
> Manikyala
-
Hi there,
I would like to know how to set the JMS Message Redelivery from a server restart
to only redeliver message after all the weblogic startup classes have completed?
The reason for this is because the message consumer(s) depend on some configuration
setting that are setup by the startup classes and I am getting problems during a
server restart because the container is trying to redeliver the persisted message
BEFORE the startup classes have completed there execution.
Thanks!
Vincent
Another approach would be to have your startup class spawn it's own thread
(that contains code to deploy your MDB application) and do a JMX call to
query if the server is up and listening (meaning that all services have been
deployed). The JMX call could be in a loop with a sleep interval. Once the
server is up the thread can deploy your MDBs. This way you don't have to
worry about your MDBs consuming all available threads.
To deploy the application using JMX, you could use code like the below. The
following code also makes sure that the config.xml is not updated so that
you can achieve a custom deploy every time your server is re-cycled.
public class ApplicationDeployer implements Runnable {
private MBeanHome home;
private TargetMBean targetMBean;
private ApplicationMBean appMBean;
private WebLogicObjectName targetObj;
.... include methods to start the thread and check if the server is up
public void doDeploy() {
ComponentMBean deployBean = null;
try
ApplicationMBean appMBean = (ApplicationMBean)
home.findOrCreateAdminMBean(appName, "Application", domainName);
appMBean.setPath(appPath);
if (deployFileName.indexOf(".jar")>0){
deployBean = (EJBComponentMBean)
home.createAdminMBean( deployAppName ,
"EJBComponent", domainName, appMBean);
} else if (deployFileName.indexOf(".war")>0){
deployBean = (WebAppComponentMBean)
home.createAdminMBean( deployAppName ,
"WebAppComponent", domainName, appMBean);
if ( Double.valueOf(getVersion()).doubleValue() > 6.0 )
deployBean.setPersistenceEnabled( false );
deployBean.setURI(deployFileName);
deployBean.addTarget(targetMBean);
appMBean.addComponent(deployBean);
appMBean.deploy();
appMBean.load();
catch (Exception e){
System.err.println("Exception at AppDeployer.doDeploy " , e);
Thanks,
Adarsh
"Tom Barnes" <[email protected]> wrote in message
news:[email protected]...
> The messages on boot are not "redelivered" messages (there is no matching
> recover/rollback in the current server's context), so a delay has no
effect.
> I'm sorry if I gave the impression that a redelivery delay has an effect
at boot time...
> Specifically, redelivery delay configures the amount of time a message
should remain
> in limbo before it is made visible again after an application calls
recover or rollback.
>
> You really should post to the ejb newsgroup. I think there may be some
control
> over startup ordering (MDB after startup classes).
>
> Worse comes to worse, your MDB
> can block (wait()) until the startup class calls notify() - Just make sure
the MDBs max
> pool size is less than the default-thread-pool-size, or make sure to
give the MDBs
> their own thread pool, to prevent them from consuming all available
threads.
>
> Tom
> Vincent wrote:
>
> > Hi Tom,
> >
> > I am using WLS6.1 sp2 running on solaris. The problem I am having is
that messages
> > are getting reloaded and sent at the next server restart before my
weblogic startup
> > class has completed its execution. My onMessage() method in my
MDB(shouldn't matter
> > if it's a MDB or a PTP JMS consumer..?) depends on some objects that are
initialized
> > by the startup class. I tried setting DefaultRedeliveryDelay in the
JMSConnectionFactory
> > to a very long delay but that does not help.
> >
> > Tom Barnes <[email protected]> wrote:
> > >By "containers" I assume you mean MDBs???? Please post your question
to
> > >the ejb newsgroup, along with your version and SP level.
> > >
> > >Tom
> > >
>
-
Disable autmatic mdb message process on server start
How can i disable the automatic MDB message processing when the server is started. I want to manually start(control) the the MDB message processing after the server startup. The application ear contains ejb modules and web module. is it possible to stop an ejb module in an application. I know, we can stop the entire application.
there is a parameter in weblogic application descriptor which delays the message processing till the server is fully started. then also it's not possible to stop/delay further.
the deployment scenario is weblogic+websphere MQ configured as mq foreign server.
pls help. thanksWL JMS provides a programmatic or administrative option for this purpose. The feature is called "destination suspend/resume", and it can be set before shutdown so as to start the destination in a "consumption paused" state after restart. MQ may provide a similar administrative option. I'm not sure if there's a simple way to do what you want with MDBs directly - you might want to try posting to the WebLogic EJB forum, but if MQ doesn't provide an option, perhaps you can forward the MQ messages into WebLogic JMS destinations (either using an MDB or a Messaging Bridge), and then change your MDB to use the WebLogic JMS destinations.
Tom -
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.
>
>
-
Configuring message redelivery with jmcjca (sun-jms-adapter) in Glassfish
I use Glassfish v2 server and its OpenMQ as JMS Provider.
My MDB is configured to use sun-jms-adapter for accessing JMS Provider.
ra.xml of adapter wasn't change so all configuration is done through the sun-ejb-jar.xml of my MDB.
Type of destination my MDB listens to is javax.jms.Topic.
At the same time, I have defined the following redelivery strategy in the sun-ejb-jar.xml
<activation-config-property>
<activation-config-property-name>RedeliveryHandling</activation-config-property-name>
<activation-config-property-value>2:1000; 3:move(queue:*psdmqqueue*)</activation-config-property-value>
</activation-config-property>
psdmqqueue is an administred server Destination of type javax.jms.Queue. So a target destination of MDB is topic and redelivery should be performed to queue
The problem is that application deplyment failes with this configuration with the following exception:
#|2008-11-22T18:38:48.152+0300|WARNING|sun-appserver9.1|com.stc.jmsjca.core.Activation|_ThreadID=169;_ThreadName=JMSJCA connect;_RequestID=ed86af75-1577-4548-ac57-60ca127a28a2;|JMSJCA-E016: [sync-Durable TopicSubscriber(provisioning_subscription)(lookup://targetTopic) @ [mq://localhost:7676/jms]]: message delivery initiation failed (attempt #85); will retry in 10 seconds. The error was: java.lang.ClassCastException: com.sun.messaging.jmq.jmsclient.XATopicSessionImpl
java.lang.ClassCastException: com.sun.messaging.jmq.jmsclient.XATopicSessionImpl
at com.stc.jmsjca.core.RAJMSObjectFactory.createDestination(RAJMSObjectFactory.java:423)
at com.stc.jmsjca.core.Delivery.createDLQDest(Delivery.java:626)
at com.stc.jmsjca.core.SyncDelivery.start(SyncDelivery.java:204)
at com.stc.jmsjca.core.Activation.asyncStart(Activation.java:535)
at com.stc.jmsjca.core.Activation.access$000(Activation.java:80)
at com.stc.jmsjca.core.Activation$1.run(Activation.java:343)
at java.lang.Thread.run(Thread.java:595)
Could you please help me to figure out what is wrong with my configuration?
Part of sun-ejb-jar.xml related to ra activation spec:
<mdb-resource-adapter>
<resource-adapter-mid>sun-jms-adapter</resource-adapter-mid>
<activation-config>
<activation-config-property>
<activation-config-property-name>ConnectionURL</activation-config-property-name>
<activation-config-property-value>lookup://targetConnFactory</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>Destination</activation-config-property-name>
<activation-config-property-value>lookup://targetTopic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>DestinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>RedeliveryHandling</activation-config-property-name>
<activation-config-property-value>2:1000; 3:move(queue:psdmqqueue)</activation-config-property-value>
</activation-config-property>
<!--subscription properties-->
</activation-config>
</mdb-resource-adapter>
</ejb>
</enterprise-beans>
</sun-ejb-jar>Hi Alexej,
I looked at the problem and found out what the issue is. We recently added some functionality that will test if the dead letter destination is in fact a valid destination -- we thought it's better to find that out upfront, rather than if an error occurs. This is especially important with dead letter destinations being looked up in JNDI: mistakes are easily be made there.
In any case, this new functionality introduced a problem where messages are sent from a queue, and the dead letter destination is a topic, or vice versa, where messages are received from a topic, and the dead letter destination is a queue.
In case you're wondering why: we still need to support JMS 1.0.2 servers. For these servers, the queues and topics are strictly segregated. We do have automated tests that test functionality across domains, but as it turns out, these tests also test some other functionality at the same time that fool the dead-letter-destination-validation into thinking it is the same messaging domain.
In any case, I've have created a fix for this, and I'm testing it right now.
I'll send you an updated RAR by email in case you don't want to wait until the updated bits are available for download. What you also could do, as a workaround, is doing the same trick that fooled the automated test: you can specify the redelivery handling in the MDB code, e.g.
public void onMessage(Message message) {
message.setStringProperty("JMS_Sun_JMSJCA_RedeliveryHandling", "2:1000; 3:move(queue:*psdmqqueue*)");
// do stuff
HTH, Frank Kieviet -
Multiple durable subscribers and message redelivery
I am using WLS 8.1 SP1. I have a topic that has several durable MDB subscribers. In the case one of the MDB rolled back the TX, upon redelivery of the message, do all durable subscribers receive the message again, or just the one that rolled back the TX gets the redelivered message?
Thanks.Hi Eric!
Each durable subscription gets its own copy of each published message, and only one MDB deployment can attach to a particular durable subscription at a time. So when an MDB durable subscriber rolls back the receive of a message, the rolled back message will be redelivered to the same MDB deployment only.
The same reasoning applies to non-durable subscriptions as well.
Tom, BEA -
I have a MDB (Bean managed Transaction) listening to a MQ.
App server used: weblogic 8.1
While a message is being processed in the onMessage() of this MDB and if server goes down, will the message be redelivered the next time I start the server?
At what point is the message removed from MQ?
Thanks
MKPHi,
quote from edocs:
"if an application fails, a transaction rolls back, or the hosting server instance fail during or after the onMessage() method completes but before the message is acknowledged or committed, the message will be redelivered and processed again. "
So if you are not acknowledging it before onMessage is completed, it should be reprocessed (Depending also on the redelivery settings of the JMS Queue)
-Kai -
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
-
Trying to understand message redelivery
Hi,
I'm trying to understand redelivery.
I'm using JMS to sync user data from our J2EE system with our Lotus Domino system. I want to be sure that in the advent of any failure in this the sync-ing process, a notification is sent to ensure that at least the Notes Domino stuff can be sync-ed manually by an administrator.
So my question is how to be sure to capture and send notification of EVERY failure with the information needed to manually sync if needed?
As I understand it, it's my responsiblity to ensure that I handle all Exceptions in the onMessage() method of our MessageListener implementation - without throwing any new Exceptions. I do this so I'm confident that things like a Notes Session not being instantiated, or a Notes document not being found are handled and notifcation sent. The result is that if an Exception occurs at this level, I handle it and as far as JMS is concerned the message was consumed and got acknowledged. Right?
But what about messages that fail before the MessageListener is reached - presumeably a problem with the JMS provider (we're using WebLogic 6.1). Can I just rely on JMS to redeliver failed messages and not worry about them? Is there a recommended way to test such failure so I can be sure what happens? I tried throwing a RuntimeException in the onMessage() method, but I did not observe any attempts to resend the message and when I browsed the queue it was empty.
So as you can you see, I'm unclear about this! Appreciate and clarifying points!
TerrenceYou can rely on the JMS provider to take care of it's own failures. However, please note that the JMS provider can fail right after you have successfully done your work in onMessage - but before the message acknowledgement happens. This means that in case of failure, you may get the last consumed message again.
Also note that different JMS providers will handle RuntimeException's raised from onMessage differently, so check your vendor's documentation. After a couple of re-tries, your JMS provider might for instance deem that the receiver/subscriber has a problem consuming said message and move the message into an error queue.
- Bjarne. -
JMS/MDB : message synch problem
We have a WL 8.1 FIFO based queue to which are attached a bunch of MDBs. These MDBs pull messages out of the queue, does some processing and put messages in another queue.
We would like to get the messages in the second queue in the same order in which they were picked up from the first queue.
But because the processing time is slightly different for each type of messages, sometimes some messages jump ahead of another one that was picked up earlier.
We are free to introduce other queues, or to use bridges etc. Can somebody suggest a solution.
( something like using destination key )
Thanks
--sonyHi,
if possible, try with "max-bean-in-free-pool=1".
note: it would be performance impact, as there would be single bean instance.
Thanks,
Qumar Hussain -
Message redelivery with non-transactional message bean JMS standard or weblogic standard?
It is my understanding (or maybe my assumption) that a message is
re-queued only if the transaction attribute of a container-managed
message bean is set to "Required" and the message is PERSISTENT. So if
it's set to "NotSupported", and thus, message receival is not within a
transaction, the message would be un-queued and thus never be
redelivered, should a failure occur within the bean. I discovered that
even if the message bean is set as "NotSupported", should a failure
occur within the bean, the message is re-queued to be received again
at a later time.
I'm very confused as to whether this mechanism is a JMS standard, or a
feature of Weblogic. Well, maybe I'm just confused about message
delivery/re-delivery. I understand that the JMS standard requires
guaranteed delivery of a message to a receiver. Does this mean a
message is only considered delivered if an acknowledgement is
received, regardless of the transaction level? In other words, is the
JMS standard that a message is considered delivered only if
acknowledgement is indicated through the container, regardless of the
transaction level of the message bean itself?
You're right on the second part. That is, a JMS message is not considered to
be "delivered" until it is acknowledged. There are a number of ways to make
this happen when programming to the raw JMS API -- a look at the Javadoc for
JMS or a good JMS book should clarify how to do this.
With a message-driven bean, the EJB container acknowledges the message after
you've successfully returned from the "onMessage" method. If you throw a
RuntimeException from the "onMessage" method, or if it's an MDB with a
transaction mode of "Required" and you call "setRollbackOnly" on the
"MessageDrivenContext" object -- then your message will be redelivered.
Regardless of how a message is acknowledged, if it's not acknowledged then
it will be redelivered. This has nothing to do with whether the message is
persistent. The difference is that if a message is persistent, then the JMS
server is required to keep a copy on stable storage until the message is
acknowledged so that if the JMS server itself crashes, the message will not
be lost. For a non-persistent message, on the other hand, if the JMS server
crashes, then the message may be lost.
greg
"Justin" <[email protected]> wrote in message
news:[email protected]...
> It is my understanding (or maybe my assumption) that a message is
> re-queued only if the transaction attribute of a container-managed
> message bean is set to "Required" and the message is PERSISTENT. So if
> it's set to "NotSupported", and thus, message receival is not within a
> transaction, the message would be un-queued and thus never be
> redelivered, should a failure occur within the bean. I discovered that
> even if the message bean is set as "NotSupported", should a failure
> occur within the bean, the message is re-queued to be received again
> at a later time.
>
> I'm very confused as to whether this mechanism is a JMS standard, or a
> feature of Weblogic. Well, maybe I'm just confused about message
> delivery/re-delivery. I understand that the JMS standard requires
> guaranteed delivery of a message to a receiver. Does this mean a
> message is only considered delivered if an acknowledgement is
> received, regardless of the transaction level? In other words, is the
> JMS standard that a message is considered delivered only if
> acknowledgement is indicated through the container, regardless of the
> transaction level of the message bean itself?
-
Re: MDB messages dont get processed from Queues
Is the durable subscriber forwarder rolling back its >transactions? I receive no log messages or any behavior that would make me think the
transaction was rolled back. The messages arent being returned to be
redelivered and there's no trace of that in the log files (unless there's a
special log for EJB transactions i havent looked at)
>What do the pending counts on the destination queue >look like?
The Messages Pending count on the queue stays at 0, as the Messages Current
count.
That same count on the durable subscriber forwarder (on the Topic's stats)
still displays messages and bytes pending.
(I had checked previously though, and it seems thats a bug in weblogic stats
recording for MDBs in transactions and durable subscriptions to topics).
thanks,
.munir
Hi Munir,
I don't know what is happening. In case you haven't already done
so, I suggest putting in trace statements in your application to
make sure that it is actually invoking the code
you think it is. If that doesn't help, please create a simple
reproducer for the problem and contact customer support.
Tom, BEA
Munir Estevane wrote:
>>Is the durable subscriber forwarder rolling back its >transactions?
>
>
> I receive no log messages or any behavior that would make me think the
> transaction was rolled back. The messages arent being returned to be
> redelivered and there's no trace of that in the log files (unless there's a
> special log for EJB transactions i havent looked at)
>
>
>>What do the pending counts on the destination queue >look like?
>
>
> The Messages Pending count on the queue stays at 0, as the Messages Current
> count.
> That same count on the durable subscriber forwarder (on the Topic's stats)
> still displays messages and bytes pending.
> (I had checked previously though, and it seems thats a bug in weblogic stats
> recording for MDBs in transactions and durable subscriptions to topics).
>
>
> thanks,
> .munir
>
>
-
MDB multiple redelivery problem
I use WL 6.1 SP2.
I got MDB, wchich sometimes can process some operations on external
systems (thru JCA), and it may last some time. It can also sleep,
while one of the systems is down and post it again from MDB (not
rollback, message will be modified) to the queue.
The problem is that while waiting (sleep) to post message, after
several seconds (about 30) the original message is processed again in
another MDB, and so on, so in result i have very many messages in the
queue, instead of one wchich should be processed many times.
I tried
<transaction-descriptor>
<trans-timeout-seconds>120</trans-timeout-seconds>
</transaction-descriptor>
in MDB, but it didn't help.
What can I do to stop it?
Lukasz Borycki wrote:
> I use WL 6.1 SP2.
> I got MDB, wchich sometimes can process some operations on external
> systems (thru JCA), and it may last some time. It can also sleep,
> while one of the systems is down and post it again from MDB (not
> rollback, message will be modified) to the queue.
> The problem is that while waiting (sleep) to post message, after
> several seconds (about 30) the original message is processed again in
> another MDB, and so on, so in result i have very many messages in the
> queue,
There is only one message in the queue, it is just that you
are getting transaction timeouts. As soon as the transaction
times-out it is as if the dequeue and the MDB operations
never occurred, so the message is redelivered. Meanwhile
your particular app continues to hold a defunct copy
of the message and continues to work while not knowing that any
work it does will get rolled back.
> instead of one wchich should be processed many times.
> I tried
> <transaction-descriptor>
> <trans-timeout-seconds>120</trans-timeout-seconds>
> </transaction-descriptor>
> in MDB, but it didn't help.
> What can I do to stop it?
I think there was a bug that caused MDBs ignore the descriptor
trans-timeout-descriptor value, at least
in some versions. Contact customer support to see if this is fixed in a
SP
or if there is a patch, or, alternatively, post to the ejb newsgroup.
Meanwhile, you
can modify the default transaction timeout for the entire domain from its
current value
of 30 seconds. The default tx timeout is configured on the console under
"domain->jta->timeout seconds".
Tom
-
When I look in the weblogic 10 admin console at any of my clustered servers and expand their susystem health display, I see the following warning for all servers. Anyone know how to fix this warning message?
MDBbea_wls9_async_response Warning MDB application bea_wls9_async_response is NOT connected to messaging system.The web-services system creates some hidden MDBs that continuosly poll for specific internal destinations used in their protocols, even when they aren't in use by any application, and I think its these MDBs that might be complaining.
A work around is to configure a JMS server with the required queues on each server, but this can cause additional problems as some environments assume every JMS server is part of their application. Another work around is configure the needed destinations as part of your current JMS servers (one per WL server). Yet another is to use an unpublished -D switch to turn off the MDBs - contact customer support to get the switch - I don't recall the name.
I suggest consulting the web-services documentation and/or posting to a web-services newsgroup.
Tom
Maybe you are looking for
-
I have bought the whole CC and it says my trial has expired. But when i go to license the software, it asks for a serial number and i dont have one. Please help.
-
Hi, Based on our current requirement, the moment we create a sales order, an out bound delivery and TO should get create automatically, if stock is available. We are successfully acheiving this functionality. But system is creating out bound deliveri
-
How can I plot data from excel in a XY graph
Labview experts, I have a really simple problem in labview: I have some data in excel: 2 columns with a certain number data. The two columns are related to each other. So I want to plot all the points in a x y graph. Coordinates point 1: (row1,col1)
-
SSAS Tabular Calculated Column: Want a calc column that only populates if row value = X
I have a table with SalesAgentID, SalesAgentTypeID (can be types 1,2, or 3), and I want to add a new column called Type1, Type2, Type3. Type 1 would only show the SalesAgentID if SalesAgentTypeID =1. It seems like I should be able to do this with a c
-
how can i sort an array by name and also by size size is an int name a string whats the best way thankyou.