I started working on an application, it's an EJB web service, deployed on IBM websphere 8 and consumes requests from an incoming queue. In the test environments, we frequently get the error "The method 'xa_start' has failed with errorCode '-6'". I needed some pointers to related documentation to do some root cause analysis. I am doing the usual google search, but has not yielded anything useful
Looking at this IBM support doc, that error code maps to this XA error constant:
-6 XAER_PROTO Routine was invoked in an improper context.
There are numerous hits in IBM MQ documentation for that error.
Related
In my Quarkus app I get Enlisted connection used without active transaction errors around once a day (on a public API used quite a lot).
It seems to come from Agroal (here https://github.com/agroal/agroal/blob/master/agroal-pool/src/main/java/io/agroal/pool/ConnectionHandler.java#L393).
According to the stack trace it fails at various places in REST endpoints annotated with #Transactional.
In PostgreSQL I only get the following:
ERROR: canceling statement due to user request
I worked around this issue by firing an event which is listened in a TransactionPhase.AFTER_SUCCESS method (and this method send the Kafka message).
I realize there is a method to set on MQConnectionFactory to attempt to reconnect if the connection of a consumer or producer is broken. However, I'm wondering if one can do something similar for an application that is starting up and setting up consumers and producers. The code I have right now will not recover if the server is down when my client application comes up.
Is there a common/recommended practice here?
My recommendation would simply be to use the tools that are provided in the Java language itself. For example, you could write a loop with exception handling to retry the initial connection or JNDI lookup a configurable number of times. It's hard to provide more specific recommendations when you haven't provided any client code of your own.
MQPUT returns a successful post response (00) on IBM ZOS IMS online service, but the message is not getting inserted into the Remote queue. The queue connection was successful as well.
Program is written in cobol with IMS interface and the module is invoked through the IMS Websphere bridge interface.
By default for MQ on z/OS, MQPUTs are done under a local UOW. i.e. MQPMO-SYNCPOINT is set for Put Message Options. Hence, the code must perform an MQCMIT API call.
Update the code to use MQPMO-NO-SYNCPOINT and then the message will not be held waiting for an MQCMIT.
Thanks for your response, actually, the program had a rollback on the Logical unit of work when the program faces a failure situation, so in this case the program updated to the MQ but the roll back happened at the end of the processing ...
I'm by no means an MQ expert. However, I'm assigned a task to integration 3rd party Application --> MQ --> SAP PI --> SAP ECC
As we are facing problems on PI with duplicate (JMS) message IDs, I'd like to know if it is possible to log / trace which (JMS) messages with their respective IDs were put or retrieved from a queue.
My overall goal is to verify or falsify the assumption that the sending application or MQ is generating duplicate IDs.
3rd party app version = 7.1
queue manager version = 7.5
I hope this is not all too basic.
It so happened that there was indeed a legacy MQ client program which occasionally didn't initialize all it's respective variables and hence created duplicate JMS IDs.
We found that out through extensive MQ tracing which happened on each hop the message flowed through.
Hope this helps somebody out there with a similar situation.
Cheers
Jens
Im a web developer ended up in some j2ee development (newbie). I sincerely need this theory confirmed.
I been given the privilege to deliver a message from our system (producer) to the SOA Enterprice service bus (consumer) when the user hits the save button. The information can not be missed or not delivered and the delivery order must be kept.
Environment:
Jboss eap 5.1 as the producer.
JNDI server is the ESB (maybe standard).
Jboss ESB as the consumer.
My weapon of choice is JMS, p2p, due to the asynchronous nature.
When the producer is abut to send the message some problems can occur:
ESB is down causing JNDI exception
Queue manager is for some reason not awake or wrongly configured. This should cause some JMS exception.
Network hickup, causing a JMS error.
So Im looking for some failover pattern. Here is my suggestion:
Add a internal JMS queue to which the message is initially added.
Add a MDB that listen to the internal queue and tries to send it to the target queue (ESB).
If failing in any way log fatal and send email to cool support people.
This should generate a reliable pattern where a message remains on the internal que until processed by the MDB.
Please advice.
Best Regards
ds
Well a 'temporary' queue is not a totally bad idea, but during the time from moving data from one queue to putting it on another you'll have a potential window of risk. Even though that window is close to nothing, what would happen if you got some failure right there and then? -You'd have to put the message back on the queue (and there you'd get into the problem with getting it in the correct order - nasty stuff!) or hold on to it in some way until you put it the other queue (which in turn can be cumbersome if you'd e g get into some failure-situaton.
A more stable solution would be to put data in a db with a queue-order column. You can then select your data in the correct order, send it to the new queue, and finally flag it as 'done' or something or even (better?) remove the data in the db.