Author |
Message
|
vnbharath |
Posted: Mon Jun 23, 2008 1:06 am Post subject: Messages deleted on qmgr crash |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
hi all
in our company we are using crossworlds and mq series.
now i have a problem. I need to investigate on it.
We have developed interfaces which use unicode (japanese) characters. ie, we send and receive unicode characters through our sender and receiver channels.
we have ".in" queue as our local queue to receive messages and ".out" queue as our remote queue to send the messages. we also have ".in.log" and".out.log" queues to store the backup copies of the messages which transfer from the channel.
ie, whenever we receive a message from our client through our receiver channed it ll get stored in ".in.log" queue and if a message is transfered from our sender channel to client, it gets stored in ".out.log" queue.
Now the problem is,
recently we had a server crash and the messages from ".in.log" got cleared automatically. this is not happening with .out.log and other clients' .in.log which are not using unicode characters.
whenever the server crashes all the cleints which are using unicode charaters ".in.log" is getting cleared automatically.
is there any special settings has to be done to the queue properties to handle unicode characters?
is there any oother way to resolve the issue?
please help me.
Thanks
Bharath
Last edited by vnbharath on Mon Jun 23, 2008 9:20 pm; edited 1 time in total |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jun 23, 2008 3:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Looks like you have a message persistence problem. Non persistent messages generally do not survive a qmgr restart.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
crossland |
Posted: Mon Jun 23, 2008 5:19 am Post subject: |
|
|
Master
Joined: 26 Jun 2001 Posts: 248
|
Either different applications are setting different values for the message persistence when the message is put, or (if the persistence depends upon the queue definition) different queues have different settings for persistence.
Have a look at the Persistence field in the message descriptor and the default persistence of the queues.
Tim
http://www.inspirotechnic.com |
|
Back to top |
|
 |
vnbharath |
Posted: Mon Jun 23, 2008 7:26 pm Post subject: |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
Thanks Tim and fjb_saper.
I will look into it and get back to you
cheers
Bharath
Last edited by vnbharath on Mon Jun 23, 2008 9:17 pm; edited 1 time in total |
|
Back to top |
|
 |
vnbharath |
Posted: Mon Jun 23, 2008 8:40 pm Post subject: |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
I checked the default persistence of our local queues it is set as as "persistent". But the messages we received from our client are "non persistent". Do u sugest that I need to check the default persistence value for the client's queue also?
Thanks
Bharath |
|
Back to top |
|
 |
Gaya3 |
Posted: Tue Jun 24, 2008 12:21 am Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
infact the persistant message wont get lost at any way.
There are couple of places where you can verify
1. Local queue properties (Persistant / Non-Persistant)
2. Transmission Queue Properties. (Persistant / Non-Persistant)
If the business data is pretty critical it will be good if you make default persistance on Client side queue manager too. _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
crossland |
Posted: Tue Jun 24, 2008 12:35 am Post subject: |
|
|
Master
Joined: 26 Jun 2001 Posts: 248
|
Check if your client is putting messages with "persistence as per queue definition". If this is the case, you should see that the messages are persistent after the default persistence for the queue has been set.
Tim
http://www.inspirotechnic.com |
|
Back to top |
|
 |
vnbharath |
Posted: Wed Jun 25, 2008 1:58 am Post subject: |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
Thanks a lot for your help. The issue is almost resolved.
But our client is sayin that in their remote queue default persistence is set to "persisntent" but we are still getting the messages from them as "not persistent". Is there anything which can change the message's persistence field? |
|
Back to top |
|
 |
crossland |
Posted: Wed Jun 25, 2008 2:19 am Post subject: |
|
|
Master
Joined: 26 Jun 2001 Posts: 248
|
The queue setting only matters if they are putting messages with MQPER_PERSISTENCE_AS_QDEF. Check with your client that they are doing this.
Regards,
Tim
http://www.inspirotechnic.com |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jun 25, 2008 6:15 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Programmers must pick from one and only only one of these persistence settings:
1) this message is persistent
2) this message is non-persistent
3) this message should take on the attribute of the queue that the application mqopened
If the programmer picks option 3, then the persistence attribute of the queue determines the persistence of the message.
So, you need to ask the programmer which of these persistence values he/she specified in the MQMD at mqput. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
vnbharath |
Posted: Thu Jun 26, 2008 6:13 pm Post subject: |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
Issue is completely resolved!
Thanks a lot all for helping.
Cheers
Bharath |
|
Back to top |
|
 |
exerk |
Posted: Fri Jun 27, 2008 12:24 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Please post how it was resolved - just to close the circle  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
crossland |
Posted: Fri Jun 27, 2008 12:44 am Post subject: |
|
|
Master
Joined: 26 Jun 2001 Posts: 248
|
What did you do to fix it? |
|
Back to top |
|
 |
vnbharath |
Posted: Sun Jun 29, 2008 8:23 pm Post subject: |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
crossland wrote: |
What did you do to fix it? |
The problem of queue getting cleared was with the message persistence.
As a first step we requested our client to change their remote and transmission queue's default persistence level to "Persistent".
But still we continued to receive Non Persistet messages.
Later we found out that in their interface programs, the value for MQPER_PERSISTENCE_AS_QDEF should be set to "YES".
So,we requested them to change MQPER_PERSISTENCE_AS_QDEF in their interface programs(one that does MQPUT) to "YES".
Now We are receiving the message as Persistent.
To summerize
To get the message as Persistent we need the following.
1.remote and transmission queue's Default persistence" field should be set to "Persistent"
2.In interface programs(one that does MQPUT), the value for MQPER_PERSISTENCE_AS_QDEF should be set to "YES".
Cheers!
Bharath |
|
Back to top |
|
 |
vnbharath |
Posted: Sun Jun 29, 2008 8:39 pm Post subject: |
|
|
Newbie
Joined: 22 Jun 2008 Posts: 8
|
Now, one more new issue!
We are using ftp protocol for the particular client.
We had few failed events.
we restarted ICS and connectors for the failed events.
We are getting an error.....
[Time: 2008/05/22 22:15:03.281] [System: Collaboration] [SS: Coll_Obj] [Thread:
Coll_Obj.thread1 (#1141278494)] [Type: Error] [MsgID: 11106] [Mesg: A collaborat
ion exception occurred at step 2 in Coll_Obj.thread1JTextConnector_100CxCommon.F
lowExecContext@401b4711.Coll_Scen:, Error 11106 The request generic.Create sent
to JTextConnector was not processed. Reason: ****
ERROR : java.net.ConnectException: Connection refused: connect Error11106.]
Anybody knows what this error is about?
Thanks
Bharath |
|
Back to top |
|
 |
|