APAR status
Closed as program error.
Error description
IBM WS using SOAP over JMS uses an MDB as the SOAP router.
This MDB is always deployed using container managed
transaction demarcation. Also, this MDB invokes either an EJB
or a Java Class that represents the deployed web service.
The problem is that if the called EJB, or Java class, throws a
non-application exception (e.g. RuntimeException) then the
Container automatically marks the transaction for roll back
(according to the J2EE and EJB Spec's). Marking the
transaction for rollback causes the SOAP message to be
put back on the JMS Queue, as well as preventing the Fault
message from being sent on the Reply-To Queue (since the send
is not committed as it is part of the same transaction).
Since the message is put back on the queue, it is re-delivered
again and the whole cycle repeats over and over. Eventually
the maximum redeliver threshold is reached for the listener
port and it completely shuts down, thus disabling the web
service altogether.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server users of web *
* services *
****************************************************************
* PROBLEM DESCRIPTION: SOAP/JMS invoking EJB does not handle *
* RuntimeExceptions *
****************************************************************
* RECOMMENDATION: *
****************************************************************
IBM WS using SOAP over JMS uses an MDB as the SOAP router.
This MDB is always deployed using container managed
transaction demarcation. Also, this MDB invokes either an EJB
or a Java Class that represents the deployed web service.
The problem is that if the called EJB, or Java class, throws a
non-application exception (e.g. RuntimeException) then the
Container automatically marks the transaction for roll back
(according to the J2EE and EJB Spec's). Marking the
transaction for rollback causes the SOAP message to be
put back on the JMS Queue, as well as preventing the Fault
message from being sent on the Reply-To Queue (since the send
is not committed as it is part of the same transaction).
Since the message is put back on the queue, it is re-delivered
again and the whole cycle repeats over and over. Eventually
the maximum redeliver threshold is reached for the listener
port and it completely shuts down, thus disabling the web
service altogether.
Problem conclusion
In order to solve this problem, a change was made to the
MDB so that it will suspend the active transaction soon after
entering the onMessage() method. The MDB will then call the
ServerEngine.invoke() method outside of any active
transaction. The MDB will receive the response from
ServerEngine.invoke(), then resume the transaction prior to
sending the reply message back to the reply queue. By doing
this, we are isolating the transaction that controls the MDB's
receipt of the request message from whatever transaction the
EJB might be operating under. This way, any failures that
might occur in the application do not affect the receipt of
the request message off the queue or sending the reply message
back to the reply queue.
Temporary fix Comments
APAR information |
APAR number |
PQ84107 |
Reported component name |
WAS BASE 5.0 |
Reported component ID |
5630A3600 |
Reported release |
10W |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2004-02-03 |
Closed date |
2004-02-10 |
Last modified date |
2004-02-10 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
Applicable component levels |
R003 PSY |
UP |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
R103 PSY |
UP |
R10A PSY |
UP |
R10H PSY |
UP |
R10I PSY |
UP |
R10P PSY |
UP |
R10S PSY |
UP |
R10W PSY |
UP |
|