ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » Reason 2085 on qmgr.put() on solaris

Post new topic  Reply to topic
 Reason 2085 on qmgr.put() on solaris « View previous topic :: View next topic » 
Author Message
EnricoStrydom
PostPosted: Wed May 02, 2018 5:16 am    Post subject: Reason 2085 on qmgr.put() on solaris Reply with quote

Newbie

Joined: 30 Mar 2015
Posts: 5
Location: South Africa

I have a longrunning java application written using the Java MQ libraries (not JMS) that responds to requests from a Client application by using MQQueueManager.put(...) to a temporary dynamic reply-to-queue created by the requesting client application. It then keeps track of the RTQs of any clients, and "push" data to the client when something changes on the server side.

When it tries to "push" and the put call returns a 2085, it assumes the client has terminated. It then removes that specific RTQ from its list of "subscribers" (so next time something changes it will not try to put to a non-existing queue again)

This works perfectly on a number of queue managers (for days/weeks on end) - mostly Red-Hat Linux, some HP-UX. We have two Solaris machines (with MQ 8.0.0.8 ) on which the put works for a while and then fails with a 2085(MQRC_UNKNOWN_OBJECT_NAME). At the point where we get the 2085 on the PUT1 I was able to check and ascertain that the RTQ does actually still exist (and I was able to do a put to that queue using amqsput)

So - in summary
- on Solaris I get 2085 returns on qmgr.put(...) calls even though it was able to put to that same queue just a minute ago, and I can see that the queue still exists (and is not put inhibited).
I only get this on the Solaris machines (not on any of the others)
Back to top
View user's profile Send private message
mvic
PostPosted: Wed May 02, 2018 12:39 pm    Post subject: Re: Reason 2085 on qmgr.put() on solaris Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2080

Is the level of MQ the same as on the working machines?
Did you verify that the application was making the calls it is supposed to be making?
strmqtrc -m QMNAME -t api -p PGMNAME can help with this.
Or activity trace, perhaps.
In the trace, check that the MQOD.ObjectQueueManager is correct (blank or the local qmname, I guess, based on your description).
Back to top
View user's profile Send private message
EnricoStrydom
PostPosted: Wed May 02, 2018 11:36 pm    Post subject: Reply with quote

Newbie

Joined: 30 Mar 2015
Posts: 5
Location: South Africa

MQ level is not the same on all the machines, the two Solaris machines is at 8.0.0.8 and 8.0.0.2.
The other non-Solaris machines are a mixed bunch from 7.5 to 8.0.0.8

I did not think of using trace, thanks for the suggestion.

I see no FDC files, nothing in the AMQERR... error logs
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu May 03, 2018 3:49 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2491
Location: Melbourne, Australia

2085 means at that exact time, the connected qmgr was not able to resolve the queue name and (optional) queue manager name that was provided in the object descriptor on the put call.

Temporary dynamic queues can come and go very quickly, as controlled by the app that created the queue.
_________________
Glenn
Back to top
View user's profile Send private message
EnricoStrydom
PostPosted: Thu May 03, 2018 11:05 pm    Post subject: Reply with quote

Newbie

Joined: 30 Mar 2015
Posts: 5
Location: South Africa

The app that created the temp queue has not closed the queue (or disconnected from the QMan). I was able to verify that the queue does in fact still exist (and that it allows "PUT") at the time (and long after) the server app got a 2085 response to a PUT1 call to that queue.

I was under the impression that 2085 has a very specific meaning (ie. "the queue does not exist"), I wonder if it could also be returned in an "insufficient resources" scenario (maybe the operating system ran out of file handles or semaphores or something).
A a PUT1 behind the scenes does the OPEN and CLOSE of the queue, and those actions probably require OS resources, but I do not know what the return reason code would be in such a situation.
Back to top
View user's profile Send private message
mvic
PostPosted: Fri May 04, 2018 2:19 am    Post subject: Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2080

EnricoStrydom wrote:
I do not know what the return reason code would be in such a situation.

Something other than 2085.

You need to trace this in order to ensure the app is doing what you think it is doing, at the time you think it is doing it.
(To check this, you'd need a trace from the other app at the same time).
Back to top
View user's profile Send private message
EnricoStrydom
PostPosted: Fri May 04, 2018 2:51 am    Post subject: Reply with quote

Newbie

Joined: 30 Mar 2015
Posts: 5
Location: South Africa

The trace is running (on the server side only). Client is running on a windows machine, just sitting there with a GET(WAIT) on the queue.
Any error on the client side (other than 2033/no message) will give me exact detail of the error. A 2033 error will just loop around and GET/WAIT again.

I have proven (to myself/to my satisfaction) that that the client still has access to the queue, and that the queue is fully accessible after the server side reported a 2085 on a PUT1 to the queue. If I use an external tool (like amqsput) to put a message to the queue, then the PUT succeeds AND the client receives and reacts to the message.

I have not had the server fail since starting the trace (still waiting for that to happen so that I can have a look at the trace results)

At this point the available information says
"MQ gave me a 2085 response on a PUT1 but the queue is still there and operational"
Back to top
View user's profile Send private message
mvic
PostPosted: Fri May 04, 2018 2:55 am    Post subject: Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2080

EnricoStrydom wrote:
At this point the available information says
"MQ gave me a 2085 response on a PUT1 but the queue is still there and operational"

Hopefully you will validate this, and not take it as true without doing so.
Back to top
View user's profile Send private message
EnricoStrydom
PostPosted: Fri May 04, 2018 3:28 am    Post subject: Reply with quote

Newbie

Joined: 30 Mar 2015
Posts: 5
Location: South Africa

I am trying to validate - hoping that the trace will give more info.
As luck would have it the server has been running for 24 hours without the error occuring . . .
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Java / JMS » Reason 2085 on qmgr.put() on solaris
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.