| Author |
Message
|
| sammyG |
 Posted: Wed Oct 31, 2007 4:52 am Post subject: SOLVEDmessages from persistent queues lost on server restart |
 |
|
Novice
Joined: 15 May 2007
Posts: 10
|
I have a mq v6 installation on windows server 2003.
#1 : I have queues that are configured to be persistent. Messages in that queue are lost when the server is restarted. This is not the behaviour on other similar systems that I have.
Can anyone suggest a reason? or a place to start looking?
#2 : on the same system I have a problem using the server API. We have a locally developed application that finds all the queues in all the queue managers. The application runs on the MQ server and uses MQ server libraries. I see error code 2058 (MQRC_Q_MGR_NAME_ERROR, the queue manager name is wrong) when this code is called (vb.net)
<code>
Imports MQAIX100 '* com library located in amqzaix.dll
Imports MQAX200 '* com library located in mqax200.dll
.
.
.
.
Dim sess As MQSession
sess = New MQSession
mMQQMgr = sess.AccessQueueManager(QueueManagerName)
</code>
I've seen in some other posts that this is associated with the client libraries. But the developer of the app assures me that this is not the case. This application works fine on all the other MQ servers that we have. I suspect that there is something in the environment that is making the connection into a client connection, but this is just a hunch and i'm a real MQ beginner so i don't even know if that is possible.
any suggestions about that?
and finally: is it possible that these problems are connected?
thanks a lot,
sam
Last edited by sammyG on Wed Oct 31, 2007 5:57 am; edited 1 time in total |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Oct 31, 2007 4:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Queues are not "persistent" or "unpersistent". Messages are persistent.
Queues have a default persistance attribute.
This is only used if the application putting the message chooses to use it.
There's a whole bunch of reasons why a server connection would return a 2058. Almost all of them are "because the qmgr name being supplied is wrong".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sammyG |
| Posted: Wed Oct 31, 2007 5:02 am Post subject: |
|
|
Novice
Joined: 15 May 2007
Posts: 10
|
#1: So if these messages are flowing to the server from a remote queue in another company, does our default persistent setting apply or do they need to set the "persistent" property on their queue for the messages to be persistent when they get to us. And/Or is there some other property in some other place (e.g., channel, transmission queue etc etc)?
#2: but why oh why does it work on one machine and not another?.. the QM name is found from the registry so it "can't" be wrong. I say "can't" because it clearly is wrong in some way. is there any chance my "client connection" theory is correct?
thanks for the super rapid response.
sam |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 31, 2007 5:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sammyG wrote: |
#1: So if these messages are flowing to the server from a remote queue in another company, does our default persistent setting apply or do they need to set the "persistent" property on their queue for the messages to be persistent when they get to us. And/Or is there some other property in some other place (e.g., channel, transmission queue etc etc)?
|
The only time the queue's default persistence is used is if an application puts directly to that queue and specifies the option to use that persistence value, versus specifically coding yes or no. Once that message hits that queue, it has a persistence attribute set and it will ignore all other queues' settings as it hops along from q to XMITQ to q to XMITQ etc.
If a program along the way picks it up to do some processing and then reputs the message, that program could choose to use the option to apply the persistence value that the q attribute is set to, or specifically yes or no. Again, this would be applied to the message at that particular MQPUT and would live with that message as it moves along until another app chooses to change it on its subsequent MQPUT.
You might have a channel or API exit configured that changes all messages with SAM in the name passing thru to persistent, for example.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Wed Oct 31, 2007 5:21 am; edited 1 time in total |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 31, 2007 5:18 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
#1: Your application needs to put the messages as persistent (in the PMO structure). They will remain that way unless some other code is introduced to make it otherwise (like an exit).
#2: I would seek the MQI equivalent of dspmq command to get a list of the QMGRs.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| sammyG |
| Posted: Wed Oct 31, 2007 5:20 am Post subject: |
|
|
Novice
Joined: 15 May 2007
Posts: 10
|
Thanks for the help on #1 guys, I think it is clear that we need to ensure that the putting application in the other company is doing the right thing and setting persistence.
if anybody can suggest a reason why #2 is happening i'd be very grateful. I've checked in the registry where the QM name is coming from and I see that it is correct. The QM name is visible in the explorer.
Is there any reason why this machine should be throwing a 2058.. can that error mask some more simple problem? I don't see any differences to the other machines that work ok.
thanks a lot guys, i'm 50% better off than I was this morning..
sam |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 31, 2007 5:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
what happens if you take that QM name that you see and try directly on the server:
| Code: |
C:\>amqsput SYSTEM.DEFAULT.LOCAL.QUEUE YOUR_QM_NAME
|
Also, what MQ Environment Variables does this server have set?
I assume there is no MQ Client parameters being set in your code (hostname, port #, channel name). If not, and there is no MQSERVER or MQCHLLIB / MQCHLTAB variables set then I'm pretty sure you are connecting locally and we just have to figure out why / how your program is using a bad QM name.
If you were connecting in client mode and not setting any connection parms then I think you would be seeing a 2059 error. 2058 indicates you are getting to a QM on the local machine, just not giving the right name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 31, 2007 5:32 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Hmmm, seems there is no API to get the dspmq.
So, have the program run that and parse the output.
Verify the application is using BINDINGs mode and not the client libraries.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| sammyG |
| Posted: Wed Oct 31, 2007 5:41 am Post subject: |
|
|
Novice
Joined: 15 May 2007
Posts: 10
|
amqsput works as expected and dspmq (fromt he command line) also shows the same QM name as I am using.
Also when I hardcode the name of the QM into the application I get the same error. I am reasonably confident that I send in the correct QM name.. so why the 2058.. is it possible that this error code is not correct and there is a different error occuring?
thanks,
sam |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 31, 2007 5:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you use a client connection and you use the correct port # and the correct channel name and the correct hostname but specify the incorrect QM you will get a 2058.
| Quote: |
Also, what MQ Environment Variables does this server have set?
I assume there is no MQ Client parameters being set in your code (hostname, port #, channel name). If not, and there is no MQSERVER or MQCHLLIB / MQCHLTAB variables set then I'm pretty sure you are connecting locally and we just have to figure out why / how your program is using a bad QM name.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sammyG |
| Posted: Wed Oct 31, 2007 5:51 am Post subject: |
|
|
Novice
Joined: 15 May 2007
Posts: 10
|
So you suspect that this IS a client connection? I don't set server address, channel or port, only the Queue Manager name. There are no environment vars on the server like MQSERVER.. I'm confused how this could be a client connection without specifying those things, but it does seem like a lot of people get that error code on client connections..
is this environment var causing this issue.. it is on this machine but not on some others
GMQ_MQ_LIB
as ever, thanks a lot for this help, I can feel the MQ expertise all around me
Sam |
|
| Back to top |
|
|
| sammyG |
| Posted: Wed Oct 31, 2007 5:52 am Post subject: |
|
|
Novice
Joined: 15 May 2007
Posts: 10
|
googled GMQ_MQ_LIB and this was the firs hit....
http://www.mail-archive.com/mqseries@akh-wien.ac.at/msg00834.html
<quote>
Now, you can get around this. If you set a system environment variable GMQ_MQ_LIB to the following, it will behave as a client:
GMQ_MQ_LIB=drive:\<insert path to mqic32>\mqic32.dll.
Hope this helps
<quote>
boom.
I'm rebooting now..
sam |
|
| Back to top |
|
|
| sammyG |
| Posted: Wed Oct 31, 2007 5:53 am Post subject: |
|
|
Novice
Joined: 15 May 2007
Posts: 10
|
done.
Thanks a lot for your help guys. You rock.
Sam |
|
| Back to top |
|
|
|
|
