| Author |
Message
|
| garonne |
 Posted: Tue May 30, 2006 1:17 am Post subject: ConnectionConsumer can not be closed |
 |
|
Acolyte
Joined: 26 Jan 2006
Posts: 59
|
I don't know why sometimes the ConnectionConsumer objects take much time to be closed or they are blocked.
Can anybody help me?
Thanks. |
|
| Back to top |
|
 |
| vennela |
| Posted: Tue May 30, 2006 10:25 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
You probably need to give more information
When where what versions etc. |
|
| Back to top |
|
|
| garonne |
| Posted: Tue May 30, 2006 11:25 pm Post subject: |
|
|
Acolyte
Joined: 26 Jan 2006
Posts: 59
|
In fact, I have done a test for WS MQ 6.0.
While my MDB is receiving 100 messages from remote QueueManager, I disconnect the cable, the reception is stopped. I undeploy the MDB and ConnectionConsumer is blocked until an exception is generated and then ConnectionConsumer is closed.
Here is how exception is generated:
About to stop consuming messages...
About to close ServerSession pool
connection consumer about to be closed
TransactionImpl.delistResource : Cannot send XA end:javax.transaction.xa.XAException: XA operation failed, see errorCode (error code = -3) --XA operation failed, see errorCode
2006.05.31 09:17:17 MQJMS1023E rollback failed
...
javax.jms.JMSException: MQJMS1025: failed to browse message
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:567)
at com.ibm.mq.jms.MQQueueAgentThread1Impl.browse(MQQueueAgentThread1Impl.java:279)
at com.ibm.mq.jms.MQQueueAgentThread.run(MQQueueAgentThread.java:1718)
at java.lang.Thread.run(Thread.java:595) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 31, 2006 2:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This is all very normal and expected.
You killed the physical connection with the server, but the app does not know or need to know this.
So when you try to shutdown the MDB, the shutdown process as every well behaved app is trying to free the MQ resources it used. This is not possible as the connection was physically removed.
At this point all you can do is wait for the exception and then the objects and resources will be removed.
The qmgr however will only be able to remove its resources after timeout.
By the way you should have a transaction that did not get committed.(XA rollback failed...) If the prepare commit has been issued you may find it by running dspmqtrn on the qmgr.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| garonne |
| Posted: Thu Jun 01, 2006 1:51 am Post subject: |
|
|
Acolyte
Joined: 26 Jan 2006
Posts: 59
|
| fjb_saper wrote: |
By the way you should have a transaction that did not get committed.(XA rollback failed...) If the prepare commit has been issued you may find it by running dspmqtrn on the qmgr.
|
I do reconnect the cable before undeploy the MDB but I still receive this exception :
TransactionImpl.delistResource : Cannot send XA end:javax.transaction.xa.XAException: XA operation failed, see errorCode (error code = -3) --XA operation failed, see errorCode
2006.05.31 09:17:17 MQJMS1023E rollback failed |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 01, 2006 6:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The problem you have with the XA part is that the transaction manager was aware of the disconnect and is no longer playing nice when you reconnect. (There are good reasons for this behavior)
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| garonne |
| Posted: Fri Jun 02, 2006 1:02 am Post subject: |
|
|
Acolyte
Joined: 26 Jan 2006
Posts: 59
|
| fjb_saper wrote: |
The problem you have with the XA part is that the transaction manager was aware of the disconnect and is no longer playing nice when you reconnect. (There are good reasons for this behavior)
Enjoy |
Can I free the XAResource and make Transaction Manager play nice like before ? 
Cause I would like my MDB (and the others MDBs) works after redeployment. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 02, 2006 2:08 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| garonne wrote: |
| fjb_saper wrote: |
The problem you have with the XA part is that the transaction manager was aware of the disconnect and is no longer playing nice when you reconnect. (There are good reasons for this behavior)
Enjoy |
Can I free the XAResource and make Transaction Manager play nice like before ?
Cause I would like my MDB (and the others MDBs) works after redeployment. |
Well after the rollback aren't you supposed to free all resources anyways?
In order for your MDB to play nice you need to set up some additional parms: - a backout threshold on the queue
- a retry count on the MDB. This should be at least 1 higher than the bothresh.
- not need the processing to be serialized. If you do keep the bothresh at 0. This way the MDB will not try to put the message into the DLQ/BOQ (WAS only) but just recognize that it can't process one of the messages and stop.
Enjoy and read the chapter about error handling with MDB's (WAS redbook?)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| garonne |
| Posted: Thu Jun 15, 2006 4:07 am Post subject: |
|
|
Acolyte
Joined: 26 Jan 2006
Posts: 59
|
| fjb_saper wrote: |
Well after the rollback aren't you supposed to free all resources anyways?
In order for your MDB to play nice you need to set up some additional parms: - a backout threshold on the queue
- a retry count on the MDB. This should be at least 1 higher than the bothresh.
- not need the processing to be serialized. If you do keep the bothresh at 0. This way the MDB will not try to put the message into the DLQ/BOQ (WAS only) but just recognize that it can't process one of the messages and stop.
Enjoy and read the chapter about error handling with MDB's (WAS redbook?) |
Hi, sorry for long time not follow your answer.
I have done another test and I think that the problem can not be resolved by your solution.
This time I connect to 2 WSMQ QueueManager: one in localhost and the other in a distant machine. Then I deploy 2 MDBs which use 2 topic from the 2 QueueManagers. When I do disconnect the physical connection with the distant machine, both 2 MDBs don't work anymore and I see exception is always generated from the TransactionManager!!! (JOTM) of the Application Server (contact admin).
So my question is that: when exception is generated, can I do something with the XAResource extracted from the MQ XASession in order that the TransactionManager can work like exception never generated.
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 15, 2006 2:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| garonne wrote: |
Hi, sorry for long time not follow your answer.
I have done another test and I think that the problem can not be resolved by your solution.
This time I connect to 2 WSMQ QueueManager: one in localhost and the other in a distant machine. Then I deploy 2 MDBs which use 2 topic from the 2 QueueManagers. When I do disconnect the physical connection with the distant machine, both 2 MDBs don't work anymore and I see exception is always generated from the TransactionManager!!! (JOTM) of the Application Server (contact admin).
So my question is that: when exception is generated, can I do something with the XAResource extracted from the MQ XASession in order that the TransactionManager can work like exception never generated.
|
OH MY GOD? Do you realize what you are asking for?
The XA transaction manager noticed there was a problem and really wants to rollback everything.
It may be waiting for the elusive XA resource from MQ that you just lost when disconnecting physically. Your transaction is no longer in a known state and MUST be rolled back. This cannot happen as the MQ resource may non longer be available. So you get an XA exception.
You will need to handle it, rollback everything else, free the MQ resource and reacquire them. Then you will be ready to reprocess the transaction that was caught in your test...
Enjoy
[edit]This is why usually you have a local qmgr to the appserver that is serving the J2EE beans and handling communications with MQ. (appserver and qmgr in same box)[/edit]
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
