Lost Messages Between SAF and JMS Servers
(Doc ID 2095334.1)
Last updated on JULY 26, 2023
Applies to:
Oracle WebLogic Server - Version 10.3.6 and laterInformation in this document applies to any platform.
Symptoms
The number of messages SAF agent forwarded does not match the number of messages received at the receiver end.
Replication steps
------------------
- A single WebLogic Domain contains the followings managed servers:
i) safserver01 - hosting a SAF agent and also a *local* Queue with name jms/DummyQueueForMDB
ii) server01 - hosting a *remote* Queue with name, jms/DummyQueue
- There is a MDB deployed on safserver01 which, consumes message from DummyQueueForMDB (No UOO) and then send a new message to jms/DummyQueue (*with* UOO) in a single JTA Global transaction.
- There is a servlet deployed on safserver01 which can send message to jms/DummyQueueForMDB *without* UOO or to jms/DummyQueue *with* UOO
- No Expiration set for SAF and no Error Handler configured for the SAFImported Destination
i) safserver01 - hosting a SAF agent and also a *local* Queue with name jms/DummyQueueForMDB
ii) server01 - hosting a *remote* Queue with name, jms/DummyQueue
- There is a MDB deployed on safserver01 which, consumes message from DummyQueueForMDB (No UOO) and then send a new message to jms/DummyQueue (*with* UOO) in a single JTA Global transaction.
- There is a servlet deployed on safserver01 which can send message to jms/DummyQueueForMDB *without* UOO or to jms/DummyQueue *with* UOO
- No Expiration set for SAF and no Error Handler configured for the SAFImported Destination
The replication steps are as followings:
- shutdown server01
- start safserver01 with debug mode. Break on weblogic.store.gxa.internal.GXAResourceImpl.commit(Xid, boolean)
- send a message to jms/DummyQueueForMDB via the servlet
- You will notice that, the thread stopped at the break point. For the first time, "resume" the run. When it stopped at the break point the *second* time, kill the safserver01 (kill -9 on Linux or end process in Windows Task Manager)
- start server01
- start safserver01 after server01 is started
- After safserver01 turns into running state, send few more new messages directly to jms/DummyQueue. And also check the safserver01 -> Monitoring -> JTA -> Recovery Services. There should have 1 "Initial Recovered Transaction Total Count"
- After a moment, all messages will be forwarded (confirmed in jms log of safserver01). However, you can see there is only 1 message in server01's jms/DummyQueue. Cross check the debug log of server01, you can see there is message saying the messages are being discarded.
- start safserver01 with debug mode. Break on weblogic.store.gxa.internal.GXAResourceImpl.commit(Xid, boolean)
- send a message to jms/DummyQueueForMDB via the servlet
- You will notice that, the thread stopped at the break point. For the first time, "resume" the run. When it stopped at the break point the *second* time, kill the safserver01 (kill -9 on Linux or end process in Windows Task Manager)
- start server01
- start safserver01 after server01 is started
- After safserver01 turns into running state, send few more new messages directly to jms/DummyQueue. And also check the safserver01 -> Monitoring -> JTA -> Recovery Services. There should have 1 "Initial Recovered Transaction Total Count"
- After a moment, all messages will be forwarded (confirmed in jms log of safserver01). However, you can see there is only 1 message in server01's jms/DummyQueue. Cross check the debug log of server01, you can see there is message saying the messages are being discarded.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |
| References |