Author |
Message
|
rjl_state |
Posted: Fri Oct 17, 2003 10:37 am Post subject: NSK TMF Issue |
|
|
 Apprentice
Joined: 04 Oct 2002 Posts: 48 Location: Des Moines, IA
|
I thought I could stop a lot of the information being stored in the audittrails on Tandem, by turning persistence off on all the queues. I did this, but the amount written to the audittrails hasn't changed.
I have an application that generates a lot of large sized, non-critical messages, and I don't want them to cause the audittrails to fill up too quickly.
I feel like I am missing something, but I don't know what.
Thanks. |
|
Back to top |
|
 |
mqonnet |
Posted: Fri Oct 17, 2003 11:10 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Turning persistence off from your queue doesnt mean that the messages arent. Make sure that the messages are NOT persistent within your app, and put/get them outside UOW.
If you put/get persistent messages within UOW, TMF would write to the audit logs and there is NO way you can avoid it, at least as far as i know.
Cheers
Kumar |
|
Back to top |
|
 |
rjl_state |
Posted: Fri Oct 17, 2003 11:31 am Post subject: |
|
|
 Apprentice
Joined: 04 Oct 2002 Posts: 48 Location: Des Moines, IA
|
I need to change the application to not do 'BEGINTRANSACTION', change the MQGET and MQPUT options to NO-SYNCHPOINT.
I think that is what you are saying.
Would I then avoid the TMF hit?
Thanks Kumar.
Rob |
|
Back to top |
|
 |
mqonnet |
Posted: Fri Oct 17, 2003 11:41 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
You got it!!!
Or you could have your transactions in place, but make the messages non-persistent in your program by coding MQPER_NOT_PERSISTENT. You could in that case still have SYCNPOINT and BEGINTRANSACTION.
Cheers
Kumar |
|
Back to top |
|
 |
rjl_state |
Posted: Fri Oct 17, 2003 12:19 pm Post subject: |
|
|
 Apprentice
Joined: 04 Oct 2002 Posts: 48 Location: Des Moines, IA
|
We are doing this. And I have confirmed it by turning TMF off on the Server class that does both the GETS and the PUTS. The server is working without any errors. But we are still creating quite a bit of Audittrail data.
Any ideas on what I am missing?
Thanks again. |
|
Back to top |
|
 |
mqonnet |
Posted: Fri Oct 17, 2003 12:33 pm Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
So, the first question is. What is that is being reported by tmf. Post the contents from viewpoint or web viewpoint(if you have it).
Also did you confirm and verify that you are for sure not doing Syncpoint persistent puts/gets. Whats the size of messages and how many messages being transacted.
Cheers
Kumar |
|
Back to top |
|
 |
rjl_state |
Posted: Fri Oct 17, 2003 1:57 pm Post subject: |
|
|
 Apprentice
Joined: 04 Oct 2002 Posts: 48 Location: Des Moines, IA
|
The MQREPSVR is the process with an active transaction.
Do I need to inquire what files these queues are using, and alter TMF OFF at the guardian file level? Do I need to stop an restart MQ Series on the node?
At this point, I don't know what else to do. Since the Pathway server has TMF OFF, I can verify the application is not doing any TMF so it is being done by MQ Series itself.
Thanks again for all you do. |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Oct 20, 2003 5:08 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
As i mentioned in my previous post, paste the output of the error that is logged to viewpoint with regards to the ems events to see whats going on.
Also bear in mind, just modifying a server class to TMF OFF does not mean there would be NO tmf transaction. It just means that this particular server class would not use a transaction by itself, for events such as modifying a file etc. Thats it. It does not prevent it from inheriting one, as far as i recollect. You could verify this in TIM if you like.
So, the alternatives that you have are.
1) Shut TMF, which i would never ever advise.
2) Make sure that your apps are doing No-Syncpoint gets/puts or make them Non-Persistent so that nothing is logged to ems.
As far as i can recollect NO MQ process log anything to EMS. So, i would bet that its one of your application processes that is reporting to TMF and causing the audit trail overflow, if that is what is in fact happening.
Cheers
Kumar |
|
Back to top |
|
 |
rjl_state |
Posted: Tue Oct 21, 2003 9:44 am Post subject: |
|
|
 Apprentice
Joined: 04 Oct 2002 Posts: 48 Location: Des Moines, IA
|
Thanks Kumar.
There are no errors to show you. Shutting TMF OFF on the server class in pathway does prevent it from inheriting a transaction.
I went to the IMB Support web site, and basically I learned that the steps I have taken will remove TMF protection from the messages I am sending and receiving. So that if something happened to my server (CPU died), any changes I made to the queues (GET or PUT) would not be backed out. But that MQ Series still uses TMF in the background to gaurantee delivery of your messages to the other queue manager. On one of the posts they mentioned you could alter TMF OFF on the files it uses on the disk, but that you would be running un-supported.
Thanks again for your suggestions!  |
|
Back to top |
|
 |
mqonnet |
Posted: Tue Oct 21, 2003 10:44 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
So, does this mean you got around your problem???
As i meantioned earlier, my recollection is that turning TMF OFF in a server class does NOT mean that that server class WOULD NOT inherit the transaction started by an app. It just means that it would not use on by itself internally, pathsends to be precise.
So, in your case, if your app starts a TMF transaction then the server class, for example the QS process would still Inherit this transaction to put/get messages even if you have TMF OFF on QS server class in your pathway.
Moreover turning TMF OFF is NEVER suggested as an solution to any problem. In fact you would never get into a situation where you would need to do this being an application programmer. At least i have never come accross one.
So, again, if the problem persists i would go back and check to see if any errors reported to EMS.
In your recent post you mentioned that there were NO errors reported. Then how come your tmf audit files filled up without logging any EMS event. This is Impossible. Since audit logs are managed under TMF transactions, TMF would raise an EMS event from the time when the audit log reaches a threashold.
Hope this helps.
Cheers
Kumar |
|
Back to top |
|
 |
rjl_state |
Posted: Wed Oct 22, 2003 11:36 am Post subject: |
|
|
 Apprentice
Joined: 04 Oct 2002 Posts: 48 Location: Des Moines, IA
|
[quote][color=darkred]So, does this mean you got around your problem??? [/color]
[/quote]
No, I did not get around my problem.
[quote][color=darkred]As i meantioned earlier, my recollection is that turning TMF OFF in a server class does NOT mean that that server class WOULD NOT inherit the transaction started by an app. It just means that it would not use on by itself internally, pathsends to be precise[/color][/quote]
I happen to [b]know[/b] that if you turn TMF OFF for a server class, it can not inherit a transaction by another app. If you do a BEGINTRANSACTION and try to send to that server, your send will fail. I altered TMF OFF in my application that runs as a Pathway server. I did not alter TMF OFF on any of the MQ Series servers that run in Pathway.
[quote][color=darkred]In your recent post you mentioned that there were NO errors reported. Then how come your tmf audit files filled up without logging any EMS event. This is Impossible. Since audit logs are managed under TMF transactions, TMF would raise an EMS event from the time when the audit log reaches a threashold.[/color]
[/quote]
I did not say I had any troubles with TMF handling the audit trails. My concern was with the amount of data being written to the audit trail files by one partitcular application that was using MQ Series. I am not trying to solve a TMF issue, I was trying to get MQ Series to not write to the TMF audit trails for non-persistent messages. I must not have made this very clear previously.
Thanks again.
[color=#444444][/color][color=#444444][/color] |
|
Back to top |
|
 |
mqonnet |
Posted: Wed Oct 22, 2003 12:04 pm Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Ok, firstly, MQ Under NO Circumstance would write to Audit log unless the messages are Persistent. This is a family behaviour. In the event the messages needed to be rolled back, they must be logged some place and this is how MQ Does this.
So, i would again reiterate my question. Who is writing to Audit logs and How do you conclude so. There must be some sort of logging(such as ems events) that says something was logged to Audit logs. How do you know that there was any, and it was from MQ.
If you run your application within Pathway, that is the ONLY time the Server that has TMF OFF would NOT inherit the transaction if one is started by the app. Say you run your app X within pathway, start a TMF transaction and do a pathsend to the Server that has TMF OFF, then the transaction would NOT be inherited. But again, MQ does NOT accept any PATHSENDS from APPS directly, At least QS does not. So, turning TMF OFF for the QS server does not mean that your app's transaction is NOT inherited. It infact would be. Moreover you cannot directly under any circumstance talk to the QS process. Qmgr agent does that for you.
Hope this clarifies stuff a little.
Cheers
Kumar |
|
Back to top |
|
 |
|