MQJMS2008 when sending a message

rubenh

unread,

Nov 4, 2002, 10:57:22 AM11/4/02

to

Hi!
I'm getting the following error when publishing a JMS message:

javax.jms.JMSException: MQJMS2008: failed to open MQ queue

The environment is WAS 4.0.4, MQSeries 5.2 and the support packs for
publish/subscribe and MQSeries classes for Java and JMS.

The behaviour is also very strange, since the application publishes the
messages to a topic perfectly for a while, and suddenly raises this error
and it fails.

I also found some errors and warnings in the event viewer of the server that
is running the MQSeries that happened at the same time that the
JMSException, but I'm not able to understand them very well... If it helps,
below is an abstract of the application log events.

Thanks for any help!

=====

Event Type: Error
Event Source: MQSeries
Event Category: None
Event ID: 6119
Date: 04/11/2002
Time: 15:13:57
User: N/A
Computer: mqserver
Description:
An internal MQSeries error has occurred (WinNT error 5 from CopyFile.)

MQSeries detected an unexpected error when calling the operating system. The
MQSeries error recording routine has been called.
===
Event Type: Warning
Event Source: MQSeries
Event Category: None
Event ID: 6184
Date: 04/11/2002
Time: 15:13:57
User: N/A
Computer: mqserver
Description:
An internal MQSeries error has occurred on queue manager QM_jabba.

An error has been detected, and the MQSeries error recording routine has
been
called. The failing process is process 3564.
===
Event Type: Error
Event Source: MQSeries
Event Category: None
Event ID: 6177
Date: 04/11/2002
Time: 15:13:57
User: N/A
Computer: mqserver
Description:
An internal MQSeries error has occurred.

An error has been detected, and the MQSeries error recording routine has
been
called.

Details of the error have been stored at C:\Program
Files\MQSeries\errors\AMQ03564.0.FDC. A synopsis is given in the data
section
below. Use the standard facilities supplied with your system to record the
problem identifier, and to save the generated output files. Contact your IBM
support center. Do not discard these files until the problem has been
resolved.
===
Event Type: Error
Event Source: MQSeries
Event Category: None
Event ID: 9208
Date: 04/11/2002
Time: 15:13:57
User: N/A
Computer: mqserver
Description:
Error on receive from host mqclient (172.16.9.48).

An error occurred receiving data from mqclient (172.16.9.48) over TCP/IP.
This may be due to a communications failure.

The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record
these
values and tell the systems administrator.

Gareth Matthews

unread,

Nov 4, 2002, 1:28:19 PM11/4/02

to

Hi,

There are two extra pieces of information that would be helpful to try and
work out what is going on here. Firstly, each JMSException that gets caught
will have an associated 'linked' exception that will explain the underlying
MQ cause for this error. This can usually give more clues to what is
happening here. To retrieve this do something similar to:

catch (JMSException je) {
System.err.println("Caught a JMSException: " + je);
je.printStackTrace();

Exception le = je.getLinkedException();
if (le != null) {
System.err.println("Linked exception was: " + le);
le.printStackTrace();
}
}

The other thing that may help is the FDC file. The error logs below indicate
the a file called C:\Program
Files\MQSeries\errors\AMQ03564.0.FDC was created because of an error and if
you post the top of that file along with the linked exception stack trace
that will give a clearer picture of what is going on.

You seem to be doing a connection to the queue manager through the client
route and so you should make sure that all your channels are started and are
running. If you have had problems with setup previously it is also worth
resetting the channels as that can also cause problems.

Please feel free to post that information here and someone will take a look
at it.

Gareth Matthews

"rubenh" <rub...@newknow.com> wrote in message
news:aq658j$3sdu$1...@news.boulder.ibm.com...

rubenh

unread,

Nov 5, 2002, 5:35:19 AM11/5/02

to

Thanks for your quick answer, Gareth.

I have little experience with MQSeries... what do you mean with resetting
the channels? Stop and start the queue manager? I do have a server
connection channel to communicate with the Java client, is this the one to
reset? Maybe both?

On the other hand, below are the beginning of the FDC file (with a size of
more than 20 MB!!) and the stack trace I got when retriving the
LinkedException

*** Caught jmsException javax.jms.JMSException: MQJMS2008: failed to open MQ

queue
javax.jms.JMSException: MQJMS2008: failed to open MQ queue

at
com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.jav
a:530)
at com.ibm.mq.jms.MQTopicSession.createPublisher(MQTopicSession.java:869)

*** Linked exception was: com.ibm.mq.MQException: Message catalog not found
com.ibm.mq.MQException: Message catalog not found
at com.ibm.mq.MQQueueManager.accessQueue(MQQueueManager.java:1365)
at com.ibm.mq.jms.MQTopicSession.createPublisher(MQTopicSession.java:863)

|
| (WinNT error 5 from CopyFile.)
|

| Comment1 :- WinNT error 5 from CopyFile.
|
|
|
|
|
+---------------------------------------------------------------------------
--+

MQM Function Stack
ccxResponder
rrxResponder
rrxReportError
xcsDisplayMessageForSubpool
xcsFFST

MQM Trace History
------} xcsRequestThreadMutexSem rc=OK
------{ xcsReleaseThreadMutexSem
------} xcsReleaseThreadMutexSem rc=OK
-----} gethostbyaddr rc=OK
-----{ rrxError
-----} rrxError rc=OK
-----{ ccxFreeMem
-----} ccxFreeMem rc=OK
----} cciTcpReceive rc=rrcE_RECEIVE_FAILED
---} ccxReceive rc=rrcE_RECEIVE_FAILED
---{ rriCommsError
---} rriCommsError rc=OK
---{ cccFreeMem
----{ xcsFreeMem
----} xcsFreeMem rc=OK
(...)

"Gareth Matthews" <matthew...@nospam.hotmail.com> wrote in message
news:aq6e34$40ee$1...@news.boulder.ibm.com...

Gareth Matthews

unread,

Nov 5, 2002, 3:08:14 PM11/5/02

to

Rubenh,

For the linked exception to work, you need to put the 'C:\Program
Files\MQSeries\Java\lib' directory in your CLASSPATH. I.e. run the command
SET CLASSPATH=%CLASSPATH%;C:\Program Files\MQSeries\Java\lib. The linked
exception is trying to tell you what the MQ reason was but could not get the
message from the language files. Unfortunately, I also only speak English,
so if it is possible to have the exception and linked exception in English I
may be able to help you some more (although my English isn't that good
either :-) ).

'Resetting' the channels is a processes that sets the 'Message sequence
number' back to 1. I believe messages are tracked through the channels using
a sequence number and if the receiving channel is expecting, say message
number 50, and you are sending message number 60, MQ complains. This can
happen sometimes if one of you channels goes down abnormally. You can reset
the channel, either from the MQ Explorer (right click the channel and go to
All Tasks -> Reset) or use the runmqsc command 'RESET CHANNEL'. The channel
to reset is whichever one is being used by the application. You are doing
JMS Pub Sub and this information is help in the Topic Connection Factory
instance that you use to create a topic connection from. I think by default
it uses SYSTEM.DEF.SVRCONN.

Hope this helps,
Gareth Matthews

"rubenh" <rub...@newknow.com> wrote in message

news:aq86p4$2lci$1...@news.boulder.ibm.com...

rubenh

unread,

Nov 6, 2002, 7:32:45 AM11/6/02

to

You were right about the CLASSPATH. This is what I get now:

*** Linked exception was: com.ibm.mq.MQException: MQJE001: Completion Code
2, Reason 2017
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2017

at com.ibm.mq.MQQueueManager.accessQueue(MQQueueManager.java:1365)
at com.ibm.mq.jms.MQTopicSession.createPublisher(MQTopicSession.java:863)

On the other hand, when trying to reset the channel as you mention, right
clicking on the it and in All Tasks doesn't show me a Reset option, but
Stop. So I tried to stop and start and when I check the Status, it hasn't
change at all.

I did also try with runmqsc RESET CHANNEL and got that the channel was not
found. Checking some MQ documentation I found that this command "can be
issued to a channel of any type except SVRCONN and CLNTCONN channels". In my
case, I created a server connection channel on my queue manager (in fact,
the status of SYSTEM.DEF.SVRCONN used to be empty), so I guess it may not be
possible to reset it (???)

Thanks for any new idea

-ruben

"Gareth Matthews" <matthew...@nospam.hotmail.com> wrote in message

news:aq98b0$3ohk$1...@news.boulder.ibm.com...

Gareth Matthews

unread,

Nov 6, 2002, 10:24:05 AM11/6/02

to

Ok - thanks for the extra info.

Firstly, can I be 100% sure about the scenario here, just so that I am
clear. You are using WAS 4.0.4 and MQ5.2 and the MA0C (pub sub broker)
support pac as well as MA88 (the MQ classes for Java support pac). Can I
just confirm that you have the queue manager / broker and the WAS appserver
on the same machine or are they split between different machines?

The reason I thought you may needed to reset your channels was because the
first post you sent had an error at the bottom about a network error and so
I assumed that you are doing some kind of client connect. Please let me know
what things are running on which box - just so that I can understand it!

The Linked Exception here however, does provide us with some more
information. Reason 2017 is MQRC_HANDLE_NOT_AVAILABLE. A handle is what is
used to refer to an MQ object (such as a queue) from within a program. The
MQ docs seem to suggest that this occurs when it cannot allocate a handle
for this request because there are none left. Either because there is an
application that has opened lots of objects and not closed them, or because
a distribution list is being used that has a large number of queues on it.

If you are the only person using the queue manager, then you could restart
it as that will disconnect every process and should replenish the handles -
if you are not, then find out and see if someone else has got an application
that has taken all the available handles. Luckily in Java we don't deal
direct with handles but, do ensure that your application is not opening
queues / topics, creating queue / topic connections and then not calling the
appropriate close() method when it is finished with it. Do you have any
'java' instances lying around that have failed but have not terminated and
so are still holding on to a connection to the queue manager? Remember also,
that the AppServer may have a connection open on the queue manager so make
sure you restart that also.

There is a queue manager attribute that can by adjusted with runmqsc that
can change the maximum number of handles. Type 'ALTER QMGR MAXHANDS(...)'.
By default it is set I believe to 256, so you may wish to increase that.

Please feel free to post back the exact scenario you are in and I will think
some more about it,
Gareth Matthews

"rubenh" <rub...@newknow.com> wrote in message

news:aqb20u$3a90$1...@news.boulder.ibm.com...

rubenh

unread,

Nov 6, 2002, 1:27:03 PM11/6/02

to

The exact scenario is:
1) server running WAS 4.0.4 and MQ 5.2 (with MA0C and MA88)
2) server with the MQSeries Classes for Java and JMS (MA88) that acts as
client for the MQSeries server. I mean, publishes messages to the topics
when needed, etc.

I defined the JMS administered objects as follows:

define TCF(JmsTopicConnectionFactory) qmgr(QM_jabba) clientid(1-rates)
tran(CLIENT) host(mqserver) port(1414) channel(nk.jms.channel)
define T(alerts) topic(alerts)
(...)

where nk.jms.channel is a server connection channel I have created to
communicate with the Java client.

The server2 produces messages with an average rate of one per second
(sometimes it's faster!), so maybe the problem has to do with the maximum
number of handles, as you suggest...

I was starting to think that it was a subscritpion store issue related with
the SUBSTORE property of the TCF (maybe increasing the frecuency of the
cleanup process, ...)

Anyway, I'll try to change the queue manager MAXHANDS and make sure that the
JMS objects connections are properly closed. There is a shutdown method
responsible for that, but it could be that when stopping the web application
through the WAS web console it is not really called...

Thank you very much for checking the LinkedException. A reasonable
explanation to the problem is now nearer.

-ruben

"Gareth Matthews" <matthew...@nospam.hotmail.com> wrote in message

news:aqbc28$n3u$1...@news.boulder.ibm.com...

James Kingdon

unread,

Nov 7, 2002, 4:00:49 AM11/7/02

to rubenh

Hello Ruben,

Each instance of TopicPublisher contains a handle, so the first thing to
check here is that every TopicPublisher created in the application is
explicitly closed when finished with. It is not sufficient to rely on
garbage collection for cleaning up JMS objects. This would be most
likely to cause the sorts of problems you are seeing if each application
call to publish a message created a new TopicPublisher. It may be more
appropriate to create a single TopicPublisher and preserve it across
multiple publish calls.

Regards,
James.

rubenh

unread,

Nov 8, 2002, 4:51:28 AM11/8/02

to

I have increased the queue manager MAXHAND to 512 and also create the topic
connection factory with the following new attributes: cleanupint(30000)
statrefreshint(30000).

With this configuration, the problem is not yet gone, it just happens
later... I don't think that increasing the max number of handles and the
frecuency of the cleanup utility execution is the right solution, although
it helps... Probably a fine tuning of the JMS code we used is necessary.

Thanks for all explanations and ideas.

-ruben

"James Kingdon" <kin...@hursley.ibm.com> wrote in message
news:3DCA2BC1...@hursley.ibm.com...