JMS message redelivery in EJB 3
Hi,
We are using EJB 3, message driven bean as a subscriber to JMS queues.
I am looking for an option which could enable us in driving the redeliver on failure & forwarding the messages to different queue in case of failure & reprocessing of messages on failure.
Does anybody has any idea how can we do this.
Can it we done through annotations or there is some other way.
Thanks & Regards,
Manish
Edited by: mjain1983 on May 31, 2009 9:27 PM
Manish,
These options will be provided by most of the application servers and can be easily configured.
What is the application server that you are using?
Similar Messages
-
Using OC4J 9.0.4.0.0 i've set up a message driven ejb that consumes messages from a queue. I've got a scenario whereby on rare occasions my bean won't be able to process the message due to the absence of an external service. When this happens, i roll back the transaction so the message is returned to the queue, the idea being that it can be processed later when the external service may/may not be available.
The problem is that the message is redelivered straight away - i want to be able to specify a delay. Can anyone help?Try the following two attributes.
dequeue-retry-count="10"
dequeue-retry-interval="300".
For me it didn't help.I have my Oracle Advanced Queue's as my JMS Provider.So I changed init parameters for my Oracle where I have queues , as follows.
ALTER SYSTEM SET aq_tm_processes=1;
It then started working as expected.
Good luck.
Giri Kosuru.
Sample orion-ejb-jar.xml
<message-driven-deployment
name="GiriMDB"
connection-factory-location= "java:comp/resource/prototypeRP/TopicConnectionFactories/myTCF"
destination-location="java:comp/resource/prototypeRP/Topics/rpTestTopic"
subscription-name="MDBSUB"
dequeue-retry-count="10"
dequeue-retry-interval="300"
listener-threads="1"> -
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 -
JMS Message redelivery in BPEL
Hi,
I have a requirement that I want to distinguish the instance consuming original message from the instance consuming the retried message.
eg. I have the requirement that if its the original message then I need to take the action A in the BPEL and if it is the retried one then I want to take the action B.
Is there some mechanism with which I can differentiate the above stuff?
Thanks in Advance.
Best Regards,
Amit JainHi,
I have got the solution to above issue.
Once my JMS adapter picks the message, it passed the message to BPEL through mediator.
In Mediator assign, by using $in.property.jca.jms.JMSProperty.JMSXDeliveryCount I got the value.
Thanks & Regards,
Amit Jain -
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
> > >
>
-
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 -
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?
-
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.
>
>
-
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
-
Need suggestion on implementing JMS message error recovery
Hi,
Our application has a JMS topic where we publish application events. Now, there can be scenarios where the consumers cannot process the message due to some infrastructure issues and would error out. We need a way so that those messages can be reprocessed again later. we are thinking of the following design for JMS message error recovery
1. Use a persistent TOPIC (this would ensure guaranteed delivery)
2. Configure a error destination on JMS topic e.g a jms queue
3. Have an error handling MDB listening to the Error destination. An error handling MDB would dequeue the errored messages from error destination and persist it to a Data base "error" table..
4. Provide a mechanism to republish those messages to topic (e.g a scheduler or admin ui or a command line utility) .. The messages would deleted from database "error" table and published to topic again....
A. Are there any issues with the above design which we need to handle?
B. Are there any additional steps required in a Cluster environment with a distributed topic and distribute error destination? (our error mdb will have one-copy-per-application setting)
B. From a performance angle, Is it OK to use persistent TOPIC ? Or will it better to persist the message to the db table and then publish it as a non persistent message ... ? (But i guess the performance should be more or less the same in both of these approaches)
C. Are there any other recommended design patterns for error recovery of JMS messages
Please advise.
Regards,
ArifThanks Tom !
We may not be able to go with the approach of delaying/pausing redelivery of the messsage because
1. Pausing entire MDB approach: Our MDB application consumes messages generated by different producers and our MDB needs to continue processing the messages even if messages corresponding to one producer is erroring out
2. Redelivery delay : This would only delay the retry of an errored message. But there would still be a problem if the message fails during all retries (i.e redelivery limit count). We don't want to lose this message. In our case, It is possible that a particular message cannot be processed due to unavailability of a third party system for hours or may be a day.
Basically, i am looking on approaches for a robust and performant error recovery/retry framework for our application (refer details in my first post on this thread) while fully making use of all features provided by middleware (WLS). Please advise.
Regards,
Arif -
How to stop and start MDBs to listen for JMS messages
Hello! This might be more of an architecture question rather than a technical questing, but I post it here, in the lack of a better place...
For several years I have been using Webster and Webster MQ to send messages back and forth to clients. The architecture for the middleware platform has been designed around the functionality of ListenerPorts. Listenerports is a Webster functionality that let you "stop" and start to listen to JMS messages for a given MDB either by admin console, or by JMX.
The arhitecture we used was something like this :
1.Client sends a persistent message to a queue. (order)
2. An MDB pics up the order message, calls a SessionBean that "fronts" the IIOP back end system.
This is quite "out of the box" architecture, but we used the Listenerports to solve a stability problem for our back end system.
The backEnd system was quite unstable, so the EJB threw an exception (typically because of timeout or connection refused) back to the MDB.
The Listenerport was "defined" to handle 3 errors before stopping, so the MDB resent the message twice before the listenerport automatically stopped. The nice thing about this feature was that the client could continue to send orders, and was not bothered when the back end system was down.
When the backEnd system was up and running, we could start the listenerport and it was all back to normal state. We even had a start script that checked the state of the listenerport every 30 minute, and started it automatically if it was stopped, making the admin task of starting the MDB unnecessary..
Now.. Why am I telling this story..
I would like to know how this could be done using "clean" J2EE technologies..That is..Not using any technology that is not portable..
I`m playing with glassfish at home, and it struck me that there is nothing in the J2EE spec that defines the functionality described above ? Am i missing something ?
I Do not want to stop My application because the back end system is down? That is the only way (i know of) that i can "stop" to listen for messages..
I can put all the messages on an error queue when the backbend system is down, but that would lead to more code just to handle the error messages. Maybe the easiest way to solve this is to "move" (programmatically) all messages from the error queue over to the "standard" queue every XX minute, but somehow that sounds "wrong"
Can anyone give me some advice to how this problem situation should be solved ? I`m interested in the solution both from an architectural perspective and from a more technical perspective..
Best regards
Hans-Jacob MelbyBreakpoints, whether normal or conditional, are just meant for debugging of your code. I had the sense from your question that the pausing you want to do is a part of normal operation of your code. I would NOT recommend using a breakpoint for that situation. It would bring up the block diagram showing the breakpoint when it occurs. A user besides the programmer would not know what to do in that case.
Yes, both the inner and outer loops would have shift registers.
Putting a case structure with a small while loop inside the "Pausing Case" is doable. It just depends on what you are doing or waiting for while the program operation is "paused". -
Weblogic Message Bridge Producing Duplicate JMS Messages
We have a message bridge that we use to integrate with TIBCO. The message bridge is deployed on a WL cluster. We see duplicate JMS messages produced by the bridge when it is deployed on the cluster. We don't see this behavior when only one ManagedServer in the cluster is active,.
TIBCO version: 4.4.3 V5
WLS: 10.3.3 with patch for bug BUG8732539 (BQC6)
java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Oracle JRockit(R) (build R28.0.0-679-130297-1.6.0_17-20100312-2121-linux-x86_64, compiled mode)
We are also seeing a lot of exceptions related to
<May 27, 2011 4:11:57 PM PDT> <Warning> <Connector> <BEA-190032> << eis/jms/WLSConnectionFactoryJNDIXA > ResourceAllocationException thrown by resource adapter on call to ManagedConnectionFactory.createManagedConnection(): "javax.resource.ResourceException: Failed to start the connection ">
However the bridge is active. We are monitoring the message-out count on TIBCO and we observed that we see duplicates whenever there a message is re-delivered. We opened a case with Oracle support and they suggested patch 10258751 which didn't help. The next suggestion was a patch for "Bug 11852771 - [WLS10.3.2]MISSING AND DUPLICATE IN JMS QUEUE MESSAGE MONITORING" but I don't think it will help since our JMS consumers are getting duplicate messages and this is not just a UI issue.
Here is the message behavior when we send a single message:
Timelines
11:34:17 --> Message sent to TIBCO EMS queue
11:34:17 --> WL MS3 throws an javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMFAIL : Resource manager is unavailable exception
11:34:17 --> WL MS1 says it got the message and committed the transaction
11:34:17 --> Message is visible in the JMS queue in the admin console
11:34:17 --> TIBCO EMS has still not received an ACK from WL for the message
11:34:31 --> TIBCO EMS resends the same JMS message to WL
11:34:31 --> WL MS2 says it got the message and committed the transaction
11:34:31 --> WL MS1 throws an javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMFAIL : Resource manager is unavailable exception
11:34:31 --> Message is visible in the JMS queue in the admin console (At this point there are two messages in the JMS queue)
11:34:31 --> TIBCO EMS has still not received an ACK from WL for the message
11:34:54 --> TIBCO EMS resends the same JMS message to WL
11:34:31 --> WL MS4 says it got the message and committed the transaction
11:34:31 --> WL MS2 throws an javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMFAIL : Resource manager is unavailable exception
11:34:31 --> Message is visible in the JMS queue in the admin console (At this point there are three messages in the JMS queue)
11:34:31 --> TIBCO EMS receives an ACK from WL for the message
MS04
####<May 27, 2011 11:34:54 AM PDT> <Debug> <MessagingBridgeRuntime> <> <MS04> <[ACTIVE] ExecuteThread: '109' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-6A59E8FE76C4FC4CA149> <> <1306521294611> <BEA-000000> <Bridge: MessageBridge1 (processMessages()) received message:
JMS Message Class: TextMessage
JMSMessageID: ID:MS01.4B044DDFEE1F1:25354AD
JMSCorrelationID: null
JMSDeliveryMode: PERSISTENT
JMSDestination: Queue[SourceQueue1]
JMSExpiration: 0
JMSPriority: 4
JMSRedelivered: true
JMSReplyTo: null
JMSTimestamp: 1306521256905 (Fri May 27 11:34:16 PDT 2011)
JMSType: null
Transaction Id: BEA1-6A59E8FE76C4FC4CA149
<?xml version="1.0" encoding="UTF-8"?>
<commands ...
>
####<May 27, 2011 11:34:54 AM PDT> <Debug> <MessagingBridgeRuntime> <MS04> <MS04> <[ACTIVE] ExecuteThread: '109' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-6A59E8FE76C4FC4CA149> <> <1306521294611> <BEA-000000> <Bridge: MessageBridge1 (processMessages()) successfully sent message:
JMS Message Class: TextMessage
Old JMS MessageID: ID:MS01.4B044DDFEE1F1:25354AD
New JMS MessageID: ID:<193654.1306521294611.0>
<?xml version="1.0" encoding="UTF-8"?>
<commands ...
>
MS03
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntime> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521257342> <BEA-000000> <Bridge MessageBridge1 Successfully got connection to the target destination>
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntime> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521257343> <BEA-000000> <Bridge MessageBridge1: both source and target adapters support XA = true>
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntime> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521257343> <BEA-000000> <Bridge MessageBridge1 supportsMDBTX = false supportsXA = true async = true>
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntime> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521257343> <BEA-000000> <Bridge MessageBridge1 WorkMode = Exactly-once>
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntimeVerbose> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521257343> <BEA-000000> <Bridge MessageBridge1 Entering processMessages() ------ >
####<May 27, 2011 11:34:17 AM PDT> <Error> <MessagingBridge> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-3AA29116A4CA622834EA> <> <1306521257343> <BEA-200015> <An error occurred in bridge "MessageBridge1" during the transfer of messages (java.lang.Exception: javax.resource.ResourceException: Failed to setup the Resource Adapter Connection for enlistment in the transaction, Pool = 'eis/jms/WLSConnectionFactoryJNDIXA', javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMFAIL : Resource manager is unavailable
javax.transaction.xa.XAException: Internal error: XAResource 'eis/jms/WLSConnectionFactoryJNDIXA' is unavailable
at weblogic.transaction.internal.XAResourceDescriptor.checkResource(XAResourceDescriptor.java:948)
at weblogic.transaction.internal.XAResourceDescriptor.startResourceUse(XAResourceDescriptor.java:634)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1227)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1161)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:507)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:434)
at weblogic.connector.transaction.outbound.XATxConnectionHandler.enListResource(XATxConnectionHandler.java:117)
at weblogic.connector.outbound.ConnectionWrapper.invoke(ConnectionWrapper.java:218)
at $Proxy62.receive(Unknown Source)
at weblogic.jms.bridge.internal.MessagingBridge.processMessages(MessagingBridge.java:1431)
at weblogic.jms.bridge.internal.MessagingBridge.beginForwarding(MessagingBridge.java:1006)
at weblogic.jms.bridge.internal.MessagingBridge.run(MessagingBridge.java:1083)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
at weblogic.connector.transaction.outbound.XATxConnectionHandler.enListResource(XATxConnectionHandler.java:200)
at weblogic.connector.outbound.ConnectionWrapper.invoke(ConnectionWrapper.java:218)
at $Proxy62.receive(Unknown Source)
at weblogic.jms.bridge.internal.MessagingBridge.processMessages(MessagingBridge.java:1431)
at $Proxy62.receive(Unknown Source)
at weblogic.jms.bridge.internal.MessagingBridge.processMessages(MessagingBridge.java:1431)
at weblogic.jms.bridge.internal.MessagingBridge.beginForwarding(MessagingBridge.java:1006)
at weblogic.jms.bridge.internal.MessagingBridge.run(MessagingBridge.java:1083)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMFAIL : Resource manager is unavailable
javax.transaction.xa.XAException: Internal error: XAResource 'eis/jms/WLSConnectionFactoryJNDIXA' is unavailable
at weblogic.transaction.internal.XAResourceDescriptor.checkResource(XAResourceDescriptor.java:948)
at weblogic.transaction.internal.XAResourceDescriptor.startResourceUse(XAResourceDescriptor.java:634)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1227)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1161)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:507)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:434)
at weblogic.connector.transaction.outbound.XATxConnectionHandler.enListResource(XATxConnectionHandler.java:117)
at weblogic.connector.outbound.ConnectionWrapper.invoke(ConnectionWrapper.java:218)
at $Proxy62.receive(Unknown Source)
at weblogic.jms.bridge.internal.MessagingBridge.processMessages(MessagingBridge.java:1431)
at weblogic.jms.bridge.internal.MessagingBridge.beginForwarding(MessagingBridge.java:1006)
at weblogic.jms.bridge.internal.MessagingBridge.run(MessagingBridge.java:1083)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1185)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:507)
at weblogic.transaction.internal.ServerTransactionImpl.enlistResource(ServerTransactionImpl.java:434)
at weblogic.connector.transaction.outbound.XATxConnectionHandler.enListResource(XATxConnectionHandler.java:117)
... 8 more
).>
####<May 27, 2011 11:34:17 AM PDT> <Warning> <MessagingBridge> <MS03> <MS03> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521257344> <BEA-200026> <Bridge "MessageBridge1" encountered some problems in one of its adapters or underlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (The exception caught was java.lang.Exception: MessagingBridgeException: Messaging bridge operation failed
.)>
MS02
####<May 27, 2011 11:34:31 AM PDT> <Debug> <MessagingBridgeRuntime> <MS02> <MS02> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-679AF074F381152F047C> <> <1306521271386> <BEA-000000> <Bridge: MessageBridge1 (processMessages()) received message:
JMS Message Class: TextMessage
JMSMessageID: ID:MS01.4B044DDFEE1F1:25354AD
JMSCorrelationID: null
JMSDeliveryMode: PERSISTENT
JMSDestination: Queue[SourceQueue1]
JMSExpiration: 0
JMSPriority: 4
JMSRedelivered: true
JMSReplyTo: null
JMSTimestamp: 1306521256905 (Fri May 27 11:34:16 PDT 2011)
JMSType: null
Transaction Id: BEA1-679AF074F381152F047C
<?xml version="1.0" encoding="UTF-8"?>
<commands ...
>
####<May 27, 2011 11:34:31 AM PDT> <Debug> <MessagingBridgeRuntime> <MS02> <MS02> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-679AF074F381152F047C> <> <1306521271392> <BEA-000000> <Bridge: MessageBridge1 (processMessages()) successfully sent message:
JMS Message Class: TextMessage
Old JMS MessageID: ID:MS01.4B044DDFEE1F1:25354AD
New JMS MessageID: ID:<196075.1306521271386.0>
<?xml version="1.0" encoding="UTF-8"?>
<commands ...
>
####<May 27, 2011 11:34:54 AM PDT> <Error> <MessagingBridge> <MS02> <MS02> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521294610> <BEA-200015> <An error occurred in bridge "MessageBridge1" during the transfer of messages (java.lang.Exception: weblogic.transaction.RollbackException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMERR : A resource manager error has occured in the transaction branch
javax.transaction.xa.XAException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:495)
at weblogic.connector.transaction.outbound.XAWrapper.setTransactionTimeout(XAWrapper.java:457)
at weblogic.connector.transaction.outbound.RecoveryOnlyXAWrapper.setTransactionTimeout(RecoveryOnlyXAWrapper.java:34)
at weblogic.transaction.internal.XAResourceDescriptor.setXAResourceTransactionTimeoutIfAppropriate(XAResourceDescriptor.java:1422)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1223)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1161)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.XAServerResourceInfo.enlistIfStatic(XAServerResourceInfo.java:181)
at weblogic.transaction.internal.ServerTransactionImpl.enlistStaticallyEnlistedResources(ServerTransactionImpl.java:1565)
at weblogic.transaction.internal.ServerTransactionManagerImpl.dispatchRequest(ServerTransactionManagerImpl.java:551)
at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:132)
at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.NullPointerException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:485)
... 14 more
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1871)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:330)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:225)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:293)
at weblogic.jms.bridge.internal.MessagingBridge.processMessages(MessagingBridge.java:1534)
at weblogic.jms.bridge.internal.MessagingBridge.beginForwarding(MessagingBridge.java:1006)
at weblogic.jms.bridge.internal.MessagingBridge.run(MessagingBridge.java:1083)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMERR : A resource manager error has occured in the transaction branch
javax.transaction.xa.XAException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:495)
at weblogic.connector.transaction.outbound.XAWrapper.setTransactionTimeout(XAWrapper.java:457)
at weblogic.connector.transaction.outbound.RecoveryOnlyXAWrapper.setTransactionTimeout(RecoveryOnlyXAWrapper.java:34)
at weblogic.transaction.internal.XAResourceDescriptor.setXAResourceTransactionTimeoutIfAppropriate(XAResourceDescriptor.java:1422)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1223)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1161)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.XAServerResourceInfo.enlistIfStatic(XAServerResourceInfo.java:181)
at weblogic.transaction.internal.ServerTransactionImpl.enlistStaticallyEnlistedResources(ServerTransactionImpl.java:1565)
at weblogic.transaction.internal.ServerTransactionManagerImpl.dispatchRequest(ServerTransactionManagerImpl.java:551)
at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:132)
at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.NullPointerException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:485)
... 14 more
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1185)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.XAServerResourceInfo.enlistIfStatic(XAServerResourceInfo.java:181)
at weblogic.transaction.internal.ServerTransactionImpl.enlistStaticallyEnlistedResources(ServerTransactionImpl.java:1565)
at weblogic.transaction.internal.ServerTransactionManagerImpl.dispatchRequest(ServerTransactionManagerImpl.java:551)
at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:132)
at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
... 2 more
).>
####<May 27, 2011 11:34:54 AM PDT> <Warning> <MessagingBridge> <MS02> <MS02> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521294610> <BEA-200026> <Bridge "MessageBridge1" encountered some problems in one of its adapters or underlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (The exception caught was java.lang.Exception: MessagingBridgeException: Messaging bridge operation failed
MS01
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntime> <MS01> <MS01> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-72BC818FE2BB8C2655C6> <> <1306521257536> <BEA-000000> <Bridge: MessageBridge1 (processMessages()) received message:
JMS Message Class: TextMessage
JMSMessageID: ID:MS01.4B044DDFEE1F1:25354AD
JMSCorrelationID: null
JMSDeliveryMode: PERSISTENT
JMSDestination: Queue[SourceQueue1]
JMSExpiration: 0
JMSPriority: 4
JMSRedelivered: false
JMSReplyTo: null
JMSTimestamp: 1306521256905 (Fri May 27 11:34:16 PDT 2011)
JMSType: null
Transaction Id: BEA1-72BC818FE2BB8C2655C6
<?xml version="1.0" encoding="UTF-8"?>
<commands ...
>
####<May 27, 2011 11:34:17 AM PDT> <Debug> <MessagingBridgeRuntime> <MS01> <MS01> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <BEA1-72BC818FE2BB8C2655C6> <> <1306521257542> <BEA-000000> <Bridge: MessageBridge1 (processMessages()) successfully sent message:
JMS Message Class: TextMessage
Old JMS MessageID: ID:MS01.4B044DDFEE1F1:25354AD
New JMS MessageID: ID:<195581.1306521257536.0>
<?xml version="1.0" encoding="UTF-8"?>
<commands ...
>
####<May 27, 2011 11:34:31 AM PDT> <Error> <MessagingBridge> <MS01> <MS01> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521271384> <BEA-200015> <An error occurred in bridge "MessageBridge1" during the transfer of messages (java.lang.Exception: weblogic.transaction.RollbackException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMERR : A resource manager error has occured in the transaction branch
javax.transaction.xa.XAException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:495)
at weblogic.connector.transaction.outbound.XAWrapper.setTransactionTimeout(XAWrapper.java:457)
at weblogic.connector.transaction.outbound.RecoveryOnlyXAWrapper.setTransactionTimeout(RecoveryOnlyXAWrapper.java:34)
at weblogic.transaction.internal.XAResourceDescriptor.setXAResourceTransactionTimeoutIfAppropriate(XAResourceDescriptor.java:1422)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1223)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1161)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.XAServerResourceInfo.enlistIfStatic(XAServerResourceInfo.java:181)
at weblogic.transaction.internal.ServerTransactionImpl.enlistStaticallyEnlistedResources(ServerTransactionImpl.java:1565)
at weblogic.transaction.internal.ServerTransactionManagerImpl.dispatchRequest(ServerTransactionManagerImpl.java:551)
at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:132)
at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.NullPointerException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:485)
... 14 more
at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1871)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:330)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:224)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:293)
at weblogic.jms.bridge.internal.MessagingBridge.processMessages(MessagingBridge.java:1534)
at weblogic.jms.bridge.internal.MessagingBridge.beginForwarding(MessagingBridge.java:1006)
at weblogic.jms.bridge.internal.MessagingBridge.run(MessagingBridge.java:1083)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: javax.transaction.SystemException: start() failed on resource 'eis/jms/WLSConnectionFactoryJNDIXA': XAER_RMERR : A resource manager error has occured in the transaction branch
javax.transaction.xa.XAException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:495)
at weblogic.connector.transaction.outbound.XAWrapper.setTransactionTimeout(XAWrapper.java:457)
at weblogic.connector.transaction.outbound.RecoveryOnlyXAWrapper.setTransactionTimeout(RecoveryOnlyXAWrapper.java:34)
at weblogic.transaction.internal.XAResourceDescriptor.setXAResourceTransactionTimeoutIfAppropriate(XAResourceDescriptor.java:1422)
at weblogic.transaction.internal.XAServerResourceInfo.start(XAServerResourceInfo.java:1223)
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1161)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.XAServerResourceInfo.enlistIfStatic(XAServerResourceInfo.java:181)
at weblogic.transaction.internal.ServerTransactionImpl.enlistStaticallyEnlistedResources(ServerTransactionImpl.java:1565)
at weblogic.transaction.internal.ServerTransactionManagerImpl.dispatchRequest(ServerTransactionManagerImpl.java:551)
at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:132)
at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.lang.NullPointerException
at weblogic.connector.security.layer.AdapterLayer.setTransactionTimeout(AdapterLayer.java:485)
... 14 more
at weblogic.transaction.internal.XAServerResourceInfo.xaStart(XAServerResourceInfo.java:1185)
at weblogic.transaction.internal.XAServerResourceInfo.enlist(XAServerResourceInfo.java:282)
at weblogic.transaction.internal.XAServerResourceInfo.enlistIfStatic(XAServerResourceInfo.java:181)
at weblogic.transaction.internal.ServerTransactionImpl.enlistStaticallyEnlistedResources(ServerTransactionImpl.java:1565)
at weblogic.transaction.internal.ServerTransactionManagerImpl.dispatchRequest(ServerTransactionManagerImpl.java:551)
at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:132)
at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:34)
at weblogic.messaging.dispatcher.DispatcherServerRef$2.run(DispatcherServerRef.java:111)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
... 1 more
).>
####<May 27, 2011 11:34:31 AM PDT> <Warning> <MessagingBridge> <MS01> <MS01> <[ACTIVE] ExecuteThread: '36' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1306521271384> <BEA-200026> <Bridge "MessageBridge1" encountered some problems in one of its adapters or underlying systems. It stopped transferring messages and will try to reconnect to the adapters shortly. (The exception caught was java.lang.Exception: MessagingBridgeException: Messaging bridge operation failed
.)>@Tom, thanks for your hints and sorry for my delayed response. Here are my answers to your queries…
-- Does messaging work, without any exceptions, when only one bridge is active?
It works fine when only one node of the cluster is active. -- I'm not familiar with Tibco monitoring, but I suspect that the "message-out count on TIBCO" stat doesn't always imply that there's a duplicate message. It could mean that an initial message delivery attempt failed, it's transaction rolled back, and the message was redelivered. Redelivery after a failure is normal - the original delivered message, if one actually made it onto a WebLogic queue, should be discarded by WebLogic when its failed transaction eventually rolls back (before its ever handed to a consumer application).
You are absolutely right. The mismatch in count was due to redelivery attempts. We could see that as soon as we turned on trace in TIBCO-- The posted stack traces look like they may be JVM stdout/stderr scrapes, which are often automatically truncated, for example, see the "... 8 more" listed at the bottom of one of the stack traces below. There might be more information in the full stack trace for the "Resource manager is unavailable" exception. Full traces are logged in each WebLogic Server's log files.
I tried redirecting the output and even set "stdout Stack Trace Depth:" to -1 but I am not albe to see the complete trace.-- The setTransactionTimeout NullPointerException error message looks like it is collateral damage from the original reported "Resource manager is unavailable" exception that's thrown earlier during the enlistResource() step. If you are truly getting duplicates, then I think this is a clue that the bridge is somehow (stupidly) trying to proceed with forwarding the message despite the fact that there's no current transaction on the thread...
I have a case open with Oracle support and we have extensive debugging turned on. Here is what the engineer came back with. There is an issue with XA transactions in JCA adapter when it talks to third party providers like TIBCO. Since the resource names are not unique across the cluster, a XA transaction is started on multiple nodes in the cluster for the same message. All transactions abort but the message is persisted and TIBCO redelivers the message since the connection is severed when the transaction aborts. We were able to reproduce this scenario at will with our setup and Oracle was able to reproduce the issue too. -- Can you check the state of the message on the WebLogic Q? The fact that a message is shown on the WL console doesn't necessarily mean that the state of the message is visible (it could be waiting for the transaction to commit - something that apparently never happens). On the console: Services -> Messaging -> JMS Modules -> [module name] -> [destination name].
Our consumer was getting duplicate messages. This confirms that the console was not giving us incorrect information. The console showed that 2/3/4 messages were in "current" state when we expected only one message. -- Make sure that the bridge's Tibco destination is a Tibco queue not a Tibco topic (it's happened).
Yeah we made sure it was a Queue. -- Can you post your bridge and destination stanzas from your config.xml?
Will try to do this shortly but have to strip out lot of information. -- I vaguely recall that there was a problem with untyped connection factories in Tibco at one point (not sure). You might want to try changing the Tibco configuration to spin-up "XA Queue Connection Factory" instead of just an "XA Connection Factory" (plus modify the bridge configuration accordingly).
We tried this but it didn't eliminate this issue. One thing we did notice however was that the number of rollbacks were greatly reduced.
Here is the workaround that Oracle is suggesting: Create pinned destinations and assign it to a distributed queue. This will keep the transactions local and hence eliminate the duplicate transactions and rollback. We tried it and it eliminated the dups issue. However I discovered another bug during my testing. Our cluster messaging mode is "Unicast" and message forwarding from zero consumer queues to queues with consumers fails. We have four/five nodes in the cluster and two consumer threads. I observed that the zero consumer queues always forward to one queue in the cluster that has consumers. The forwarding stalls when I bring down the node that has consumers. Again, we were able to reproduce this issue at will and Oracle has acknowledged that it is a bug. They've reported that Unicast fails without any warning whereas Multicast fails with a warning in the log. We have observed this message forwarding stalling even with UDQs.
I have another case open for an issue where our message bridges that transfer messages from TIBCO to WLS stalls after sometime. The status is shown as active but it is not doing anything. The server instance shows stuck threads trying to roll back a message. TIBCO logs indicate that it is receiving a request to rollback a transaction but it is not finding the transaction to rollback. The only way to recover from this condition is to restart the cluster. I am fairly confident that he root case for this issue is again the XA transaction issue. I changed our UDQ to pinned destination in one environment and we are no longer seeing dups or bridge stalling there. Hopefully Oracle can resolve the message forwarding issue.Thanks again…. -
Hi all,
I am using Netbeans 5.5 but in JMS i got the error. Do you have any idea for this error?
Error:
Could not verify successfully.
java.lang.IllegalArgumentException: This ejb has no message destination reference by the name topic
at com.sun.enterprise.deployment.EjbDescriptor.getMessageDestinationReferenceByName(EjbDescriptor.java:1379)
at com.sun.enterprise.deployment.node.runtime.MessageDestinationRefNode.setElementValue(MessageDestinationRefNode.java:86)
at com.sun.enterprise.deployment.node.SaxParserHandler.endElement(SaxParserHandler.java:408)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:633)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:260)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleEndElement(XMLDTDValidator.java:2059)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.endElement(XMLDTDValidator.java:932)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:719)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1685)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:279)
at com.sun.enterprise.deployment.archivist.Archivist.readRuntimeDeploymentDescriptor(Archivist.java:514)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:309)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:200)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:308)
at com.sun.enterprise.tools.verifier.VerificationHandler.createApplicationDescriptor0(VerificationHandler.java:442)
at com.sun.enterprise.tools.verifier.VerificationHandler.createApplicationDescriptor(VerificationHandler.java:252)
at com.sun.enterprise.tools.verifier.VerificationHandler.initStandalone(VerificationHandler.java:203)
at com.sun.enterprise.tools.verifier.VerificationHandler.<init>(VerificationHandler.java:96)
at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:127)
at com.sun.enterprise.tools.verifier.Verifier.main(Verifier.java:101)
But my code is here..
@MessageDriven(mappedName = "jms/SavingsMessage", activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),
@ActivationConfigProperty(propertyName = "destinationName", propertyValue = "jms/Topic"),
@ActivationConfigProperty(propertyName = "subscriptionDurability", propertyValue = "Durable"),
@ActivationConfigProperty(propertyName = "clientId", propertyValue = "SavingsMessage"),
@ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "SavingsMessage")
public class SavingsMessage implements MessageListener {
/** Creates a new instance of SavingsMessage */
public SavingsMessage() throws NamingException {
try{
InitialContext ctx = null;
try {
ctx = new InitialContext();
} catch (NamingException ex) {
ex.printStackTrace();
ConnectionFactory factory = null;
try {
factory = (ConnectionFactory) ctx.lookup("jms/SavingsMessage");
} catch (NamingException ex) {
ex.printStackTrace();
Topic topic = (Topic)ctx.lookup("jms/Topic");
Connection connect = factory.createConnection();
Session session = connect.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer consumer = session.createConsumer(topic);
consumer.setMessageListener(this);
connect.start();
}catch(JMSException ex){
public void onMessage(Message message) {
TextMessage msg = (TextMessage)message;
String txtmsg = "";
try {
txtmsg = msg.getText();
} catch (JMSException ex) {
ex.printStackTrace();
System.out.println("Receive message:" + txtmsg.toString());
XML Descriptor:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 EJB 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-ejb-jar_3_0-0.dtd">
<sun-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>SavingsAccountBean</ejb-name>
<jndi-name>jdbc/SavingsAccount</jndi-name>
<message-destination-ref>
<message-destination-ref-name>topic</message-destination-ref-name>
<jndi-name>jms/Topic</jndi-name>
</message-destination-ref>
</ejb>
<ejb>
<ejb-name>SavingsMessage</ejb-name>
<jndi-name>jms/SavingsMessage</jndi-name>
<jms-durable-subscription-name>SavingsMessage</jms-durable-subscription-name>
</ejb>
</enterprise-beans>
</sun-ejb-jar>
Thank you for your reply...
Best Regards,
ChrisHi,
Thanks a lot for your response. The oc4j-ra.xml is located in C:\product\10.1.3.1\OracleAS_1\j2ee\home\application-deployments\default\JmsAdapter
Entry is :
<connector-factory location="TestRequestQueueJNDI" connector-name="Jms Adapter">
<config-property name="connectionFactoryLocation" value="TestJMSCF"/>
<config-property name="factoryProperties" value="java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory; java.naming.provider.url=t3://hostName:port; java.naming.security.principal=weblogic;java.naming.security.credentials=weblogic"/>
<config-property name="acknowledgeMode" value="AUTO_ACKNOWLEDGE"/>
<config-property name="isTopic" value="false"/>
<config-property name="isTransacted" value="false"/>
<config-property name="username" value="weblogic"/>
<config-property name="password" value="weblogic"/>
<connection-pooling use="none">
</connection-pooling>
<security-config use="none">
</security-config>
</connector-factory>
Thanks
Chandra -
I am trying to deploy a MDB PTP implementation within WebLogic 7 and I keep getting the following error. Could some please enlighten me to what configuration or code changes I need to make?
Thankyou in advance for any help :-)
####<4/10/2002 10:20:56> <Warning> <EJB> <WSJON> <T5MBankServer> <ExecuteThread: '9' for queue: 'default'> <kernel identity> <> <010061> <The Message-Driven EJB: mBankingJMSBean is unable to connect to the JMS destination: mBankingJMSQueue.
The EJB container will automatically attempt to re-establish the connection with the JMS server. This warning may occur during WebLogic Cluster start-up if the JMS destination is located on another WebLogic Server instance. When the JMS server connection is re-established, the Message-Driven EJB will again receive JMS messages.
The Error was:
Message Driven Bean 'mBankingJMSBean' is transacted but the provider defined in the ejb is not transacted. Provider should be transacted if onMessage method in MDB is transacted.>The connection factories that you configure for your MDB must return XAConnection. From that the MDB container can create XASessions and ultimately get access to the XAResource for your JMS provider. If your factory is not returning XA connections.
My guess is you are using container managed transactions. That is you want everything in the same transaction. Without XA support from your JMS provider the container cannot provide the guarantees that you have requested, therefore it fails the connection (rather than lie to you and give you something that is not atomic). -
How to test BPEL Process that starts with a pick consuming a JMS message
Hi,
We are using App Server v 10.1.3.3.0 and attempting to test a BPEL process which starts with a pick operation which is awaiting a JMS message on a specific queue.
We are using the Oracle JMS adapter to achieve this.
Is there any way in which this particular configuration can be easily tested using the BPEL testing framework? I have problems when I write the first initiate XML statement in my test case (stack trace below)
<2011-01-27 10:23:47,028> <ERROR> <ProvisioningInterface.collaxa.cube.bpeltest> test run failed!
ORABPEL-20011
Instance initiation error.
An error occurred while launching an instance for suite "BasicTest", test "baseline.xml".
Please examine the log file for details or contact the system administrator.
at com.collaxa.cube.engine.test.BPELTestRunManager.initiate(BPELTestRunManager.java:218)
at com.collaxa.cube.ejb.impl.BPELTestBean.runSuites(BPELTestBean.java:625)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Unfortunately, there are no further details or any example I can see which simulate the kind of setup I have for my test.
Any help much appreciated,
Kind Regards,
Colin.Hi,
I assume you mean the JMS example under the $OH BPEL examples area. Unfortunately, this only shows how to get a BPEL process kicked off by awaiting a JMS message - but there is no test code there! There are specific examples which show off the testing framework facilities but it appears that all the examples which use async type of interactions are in the middle of a process which is kicked off by a normal synchronous client interaction.
Any further help much appreciated.
Colin.
Maybe you are looking for
-
Navigation Web Item Behavior BI 7.0
Hi, I have an initially collapsed Nav Item and a report in a container. After I drag a characteristic from the Nav Item onto my report the Nav Web Item Collapses. So now I have to expand the Nav Item again to drag another characteristic to my repor
-
How to hide username and passward in web reports
Dear friends Im runing one report on web but its showing the username and passward in the URL (address bar) can you please help me how to hide that passward....... let suppose the username/passward is scott/tiger thanks with regards
-
I don't know if other people also have this problem, but I noticed an issue which makes Photoshop CS5 completely useless for me: It is scrolling incredibly slow. With CS4 I am able to scroll much faster and with different speeds. In CS5 it seems like
-
I need some help with port forwarding for Minecraft application (port 25565). I use modem and router to connect to the internet. When I connect my PC directly to modem port forwarding is working. When I connect my PC through my router the port is cl
-
Iputils issue, when connecting with netcfg.
I hope what I will do is correct to put it here. I updated today iputils and suddenly I couldn't connect to my networks anymore. I'm not an expert and I don't know exactly what was going on. 1) I tried to connect using netcfg to wireless with WPA sec