| Author |
Message
|
| rjl_state |
 Posted: Tue Feb 18, 2003 1:13 pm Post subject: NSK 5.1 Getting Resource Problem |
 |
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
I am on an NSK G06.16 with v. 5.1 with CSD01 and EFIX02 applied.
The problem I am having is getting an intermittent error 2102 MQRC_RESOURCE_PROBLEM on a call the MQCONN. 
Any ideas on what I can check?
The manual says to consult the FFST record to obtain more detail, but I am not getting a FFST.
I have coded aroung the problem by delaying and retrying and that usually works. But I am worried that this could be a sympton of something else.
Thanks in advance for your response. |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Tue Feb 18, 2003 4:56 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
How do you reproduce it. Can you reproduce it using the standard IBM supplied sample, amqsput/get and get this at the time of conn.
If not, then what is your app doing. More info would be helpful to asses the situation.
Did you apply Efix04 which has many more fixes in this area.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| rjl_state |
| Posted: Wed Feb 19, 2003 8:48 am Post subject: |
|
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
Thanks Kumar.
I can't reproduce it. It is very intermittent.
My program is basically a copy of one of the supplied sample programs that does the following:
- Connects to the QMGR
- Opens a queue for Browse
- Gets messages from the queue
- Sees if current messages are the same ones as the last time through, if so it reports an error
- Saves any messages found (up to 200) for comparison the next time through
- Close the queue
- Disconnect from the QMGR
- Delay for period of time
- Start at the beginning.
The work around I put in is if it fails on the connect I go straight to the delay and start again. If it fails more than three times in-a-row I then abend the program. So far no programs have abended because of this error.
This is a home grown queue monitor that has worked very well except for the RESOURCE PROBLEM on the connect.
The reason I clsoe the queue and disconnect from the QMGR is that when I want to stop the process(because I want to stop the QMGR), I thought it would be better if I was disconnected from the QMGR.
I have several of these queue monitors running, all monitoring different queues. I didn't think it would be a problem having all of the disconnects and connects going on.
The delay times vary from 3 minutes to 10 minutes depending on how important the queue is to our system.
If you need more info let me know.
I knew there was an Efix03, but there is an Efix04? |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Feb 19, 2003 11:21 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Firstly Efix04 was released just recently.
I shall try to test out the scenario you mentioned, when i get a chance. But if you can send me the source of your app, that would save some time addressing this issue.
Just out of curiousity. Why dont you use FAIL_IF_QUESCING around put/get in your application rather than doing an explicit Disc and then reconnecting. There are No or rather very very few advantages in this design as opposed to the disadvantages.
1) Performance is a big hiccup. Doing conns and discs on regular basis is very expensive.
2) You would be creating a NEW agent all the time when you disc and reconnect, that would mean an additional overhead.
3) From your desing it looks like you dont have FAIL_IF_QUESCING, and thats why you are doing CONNS and Discs. Because if you have it, you dont have to do conns and discs(from what i understand about your design). Which means, your code is not safe any ways in the event of a QM is going down due to some error somewhere else.
Not clear what you meant by
"The reason I clsoe the queue and disconnect from the QMGR is that when I want to stop the process(because I want to stop the QMGR), I thought it would be better if I was disconnected from the QMGR.
".
Does this mean, in your app you have some sort of a controlling handle that if set somehow ends this app. And you want to end gracefully.???
Hope this helps.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| rjl_state |
| Posted: Thu Feb 20, 2003 12:18 pm Post subject: |
|
|
Apprentice
Joined: 04 Oct 2002
Posts: 48
Location: Des Moines, IA
|
Thanks for your suggestions Kumar. I was using FAIL_IF_QUIESCING. but I wasn't taking advantage of it. Meaning I didn't code for a graceful shutdown if I received that error. I had originally written the program as a stand alone program, so when I wanted to shut it down I had to stop the process. That is why I didn't want to have the process always be connected with the queue open.
As a result of your suggestion, I rewrote the program as a pathway server. With the delay being a timed read on $RECEIVE. And when I receive a shutdown command (eof on $RECEIVE), I shut down my connection to the QMGR gracefully. I also shut down properly on a FAIL_IF_QUIESCING.
I am sure this will solve my problems that were caused by all of the connects and disconnects.  |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Feb 20, 2003 12:31 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Glad to note that you have restructured your app and hopefully it would work too.
But nowhere did you mention whether you removed your conns and disc's which you were doing probably in a loop. Also i was unsure of you writing your app as pathway server would make any difference in this context.
Hope you get your issue resolved.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| bkasisch |
| Posted: Fri Mar 07, 2003 12:36 pm Post subject: RE: NSK 5.1 Getting Resource Problem |
|
|
Novice
Joined: 14 Oct 2002
Posts: 16
|
I have seen this message on occasion. In my case it was because there was no
"PARAM MQNEWSEGALLOC ON" in your setup for the environment.
Have you checked that?
You also may want to check to see if IPM T9050AOE is installed. It is required for MQ V5.1. (I
thought it was included in G06.13 or G06.14 but am unsure) |
|
| Back to top |
|
|
| LuisFer |
| Posted: Sat Mar 08, 2003 10:06 pm Post subject: Re: RE: NSK 5.1 Getting Resource Problem |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| I had this problem (with Efix 2 & 3) when started (at the same moment) many programs in paralel. (Doing stress probes). |
|
| Back to top |
|
|
|
|
