| Author |
Message
|
| rizzo |
 Posted: Tue Aug 02, 2005 3:06 pm Post subject: MDB (WAS 5.1 NT) not receiving messages (WMQ 6 z/OS) |
 |
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hello,
I have an message driven bean (MDB) in WAS 5.1 on Windows NT configured to receive messages from a WMQ 6 local queue on z/OS V1R4 with the Client Attachment Feature installed. The problem at the moment is that once started, the MDB doesn't receive any messages although messages are present in the queue.
The JMS listener port in WAS is started with no errors reported. The setMessageDrivenContext method of the bean is called at startup but the onMessage method is never called.
From the same NT machine I can PUT a message onto the queue and GET the message back again via the WMQ base Java API (non-JMS) with no problems so the problem doesn't seem to lie in the communication between the two machines.
The mqver progam of the messageing client on the WAS machine reports the client version as being 5.3.1 with CSD4.
Does this problem sound familiar to anyone? Are there issues with this configuration or is it supported at all? Can the v5.3.1 client talk to a v6 queue on z/OS?
I appreciate any advice you can offer.
Thanks
Steve |
|
| Back to top |
|
 |
| malammik |
| Posted: Tue Aug 02, 2005 4:23 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 02, 2005 5:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Make sure that the jndi definitions are correct and match the reality.
Make sure that the message port is defined correctly and active and not turned off. (MDB setup)
Enjoy  |
|
| Back to top |
|
|
| rizzo |
| Posted: Thu Aug 04, 2005 7:15 am Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hi,
Thanks for the swift replies.
Re: JNDI definitions:
I double-checked the JNDI definitions and they are correct. The message port is using the correct JNDI resources and starts successfully upon server startup. The MDB is associated with the correct listener port. To make sure the problem didn't lie in my MDB or its EAR file, I mapped the MDB to a different listener port listening on a queue on a non-z/OS queue manager. Once a message was placed on the queue, the MDB received it with no problems so the problem is specific to the queue on our z/OS.
Re: Shareable queues:
WAS seems to use the exclusive open option. No-one can access the queue when WAS is running. The WAS server process, not just the listener port, must be stopped before another client can access the queue. The "MQ config" link under the JMS queue settings in the admin console usually provides the ability to change the shared/exclusive option but clicking the link displays the WMQ 3001 reason code, meaning that WMQ PCF commands are not supported by WMQ on z/OS. Thus I can't change the setting.
In WAS, I switched on the tracing of the JMS components (com.ibm.ejs.jms.* and com.mq.*) and after a while I noticed something intriguing. WAS is receiving something from the z/OS queue but not propagating the message to the MDB. It seems to keep trying to deliver a message although no errors are present in the trace or the logs. Below is an example of the output which occurs repeatedly in the trace:
[04.08.05 16:00:12:844 CEST] 36e68ec7 ServerSession > start
[04.08.05 16:00:12:844 CEST] 36e68ec7 ServerSession < start
[04.08.05 16:00:12:844 CEST] 4ba9cec7 ServerSession > run
[04.08.05 16:00:12:844 CEST] 4ba9cec7 MDBWrapper > setLastFailedDeliveryCount
0
[04.08.05 16:00:12:844 CEST] 4ba9cec7 MDBWrapper < setLastFailedDeliveryCount
[04.08.05 16:00:12:844 CEST] 4ba9cec7 ServerSession > Dispatch
[04.08.05 16:00:12:844 CEST] 4ba9cec7 ServerSession > onMessage
MessageDrivenBeanO(BeanId(JMSTestEAR#JMSTestEJB.jar#JMSTestEventConsumer, null), state = IN_METHOD)
[04.08.05 16:00:12:844 CEST] 4ba9cec7 JMSSessionHan > enlist
[04.08.05 16:00:12:844 CEST] 4ba9cec7 JMSManagedSes > enlist
[04.08.05 16:00:12:844 CEST] 4ba9cec7 JMSManagedSes > localTransactionStarted
[04.08.05 16:00:12:844 CEST] 4ba9cec7 JMSManagedSes > begin
[04.08.05 16:00:12:844 CEST] 4ba9cec7 JMSManagedSes < begin
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSManagedSes < localTransactionStarted
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSManagedSes < enlist
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSSessionHan < enlist
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession > connectionConsumerOnMessage
MessageDrivenBeanO(BeanId(JMSTestEAR#JMSTestEJB.jar#JMSTestEventConsumer, null), state = IN_METHOD)
[04.08.05 16:00:12:969 CEST] 4ba9cec7 MDBWrapper > setMessageListener
com.aops.hostaccess.ejb.JMSTestEventConsumerBean@4d1f0ed3
[04.08.05 16:00:12:969 CEST] 4ba9cec7 MDBWrapper < setMessageListener
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSSessionHan > run
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSSessionHan < run
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession < connectionConsumerOnMessage
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession < onMessage
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession < Dispatch
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSManagedSes > commit
[04.08.05 16:00:12:969 CEST] 4ba9cec7 JMSManagedSes < commit
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession > afterCompletion
3
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession < afterCompletion
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession > putServerSession
com.ibm.ejs.jms.listener.ServerSession@511b4ecd
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession < putServerSession
[04.08.05 16:00:12:969 CEST] 4ba9cec7 ServerSession < run
[04.08.05 16:01:13:594 CEST] 36e68ec7 ServerSession > getServerSession
[04.08.05 16:01:13:594 CEST] 36e68ec7 ServerSession < getServerSession
com.ibm.ejs.jms.listener.ServerSession@511b4ecd
[04.08.05 16:01:13:594 CEST] 36e68ec7 ServerSession > getSession
[04.08.05 16:01:13:594 CEST] 36e68ec7 ServerSession < getSession
com.ibm.mq.jms.MQQueueSession@6b40cec8
If I let the server run, the trace file grows larger and larger even though the MDB is not doing anything (there are no other apps running in WAS). The depth of the queue on z/OS does not change during this time however.
Does the problem look familiar to anyone?
Once again any help is appreciated.
Steve |
|
| Back to top |
|
|
| malammik |
| Posted: Thu Aug 04, 2005 7:21 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2005
Posts: 397
Location: Philadelphia, PA
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 04, 2005 11:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do you by chance have a poison message as first on the queue ?  |
|
| Back to top |
|
|
| rizzo |
| Posted: Thu Aug 04, 2005 12:31 pm Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hi
malammik:
The MDB ist listening on a QueueDestination.
fjb_saper:
We thought this at first, some of the first test messages put into the queue were too big to be read by certain clients, causing the "message too large for receive buffer" error (reason code 2080). We cleared these and I PUT a message (ca. 100 bytes) onto the queue using an MQ base Java program (non-JMS) but the MDB still isn't receiving anything although WAS itself seems to get something judging by the trace log contents. The message still stays on the queue...
Steve |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 04, 2005 1:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Carefull with MQ Base ... you could still have a poison message:
Imagine expecting a TextMessage (JMS) and getting a message that does not have the format set to MQSC.MQ_STRING !! (MQSC.MQ_NONE)
This would be a BytesMessage and as such most probably a poison message to your app.
Enjoy  |
|
| Back to top |
|
|
| rizzo |
| Posted: Thu Aug 04, 2005 5:10 pm Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
fjb_saper,
I'm pretty sure I'm setting the format to MQC.MQFMT_STRING in the base Java program, so the WMQ client in WAS should map this to a JMS TextMessage. I'll double-check tomorrow. In my experience at least, these kinds of problems usually result in reason codes being logged somewhere but we are getting nothing at the moment. I'm told there are no errors in the WMQ error log on the z/OS either but I can't check this myself.
Maybe the next thing to try is to PUT a message on the queue using a JMS program and see if WAS receives it correctly then.
Steve |
|
| Back to top |
|
|
| rizzo |
| Posted: Fri Aug 05, 2005 6:07 am Post subject: Problem solved |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hi
We have since solved the problem. I asked for the DEFSOPT of the queue to be double-checked, as previously suggested. The DEFSOPT was set to EXCL so it was changed to SHARED. Also the NOSHARE option was set to SHARE though I am not sure if the latter change was really necessary.
WAS now receives the messages (from all clients, base Java, JMS and COBOL).
Could someone explain why WAS couldn't receive the messages correctly even when it was the only client connected to the queue?
Thanks to all who helped with this problem.
Regards
Steve |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Aug 05, 2005 7:28 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
The DEFSOPT was set to EXCL so it was changed to SHARED. Also the NOSHARE option was set to SHARE though I am not sure if the latter change was really necessary.
|
Actually, the NOSHARE option would have been your problem, becuase if thats set on the queue, the "default share option" doesn't matter.
I can only speculate that WAS opens that queue more than once. Now that its working, do a "dis qstatus(qname) type(handle)" and see who has it open....
_________________
-wayne |
|
| Back to top |
|
|
| rizzo |
| Posted: Mon Aug 08, 2005 1:33 am Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hi
| Quote: |
| I can only speculate that WAS opens that queue more than once. Now that its working, do a "dis qstatus(qname) type(handle)" and see who has it open.... |
Thanks for the tip. The command you mentioned showed a count of 4. The netstat command on the WAS machine also displays 4 connections to the host, so WAS does open more than one connection.
Steve |
|
| Back to top |
|
|
|
|
