| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Use of PutTime/PutDate instead of COA for arriving messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| HenriqueS |
 Posted: Tue Sep 29, 2015 10:05 am Post subject: Use of PutTime/PutDate instead of COA for arriving messages |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Hello,
Today we have a message exit that processes all outgoing messages. If they are COAs, we extract their timestamps and write them in our internal records to know when a certain incoming message was effectively received.
Our developers came to think that we could just write down the timestamp of the actual received messages (PutDate/PutTime fields), not their generated COAs timestamp.
What do you guys think? There is any issues that could arise from this approach? |
|
| Back to top |
|
 |
| hughson |
| Posted: Tue Sep 29, 2015 1:59 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
The message exit sees the message prior to it being put to the target queue by the channel, so recording that time is not proof that it arrived on the queue. Of course capturing the COA time is only proof that the message was on the queue, it is not proof that it was ever processed of course. The opposite is also not true, i.e. if you don't receive a COA it is not proof that the message didn't arrive.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Wed Sep 30, 2015 9:33 am Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Hi hughson, thanks for the feedback.
Let me rephrase:
1) We are storing all COAs that are returning to our remote client in a local queue, using the exit (the exit intercepts the COAs leaving our QM). So for auditing purposes or allegations like "We never received your COA" at least we have a copy of it.
2) Right now, for this COA that is stored using the exit, we scan our queue regularly (every minute or so) and inspect timestamp values to be recorded along our incoming messages as a extra column like "COA timestamp". Sure, this gives some nice overhead to our application.
3) This operation is somewhat slow, due to the scanning process that goes over the queue. The queue is cleaned only at night, when is already filled with a few hundred thousand COAs. The is a offload job that reads this queue and writes everything to a filesystem, in compressed format (i.e.: COA-%date%.zip).
4) Dev team came to this approach:
4.a) Let´s keep storing the COAs the way they are, offloading nightly the queue.
4.b) Instead of using the timestamp those COAs hold to feed the DB columns regarding the incoming messages, let´s just use the timestamp contained in the original message itself.
4.c) There is probably a very small clock difference between the original message timestamp and the COA timestamp. But they think it is not important. We could find easily find COAs related to a incoming message by their CorrelId in our offloaded auditing folder. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 30, 2015 1:00 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I can put a message with a Put Date and Put Time that has zero relevance as to the actual date and time that I put the message.
In other words, because MQ allows suitably authorized apps to set the Put Date/Time to whatever they want, you cannot trust the Put Date/TIme is accurate in 100% of all use cases.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Oct 02, 2015 1:37 pm Post subject: |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
So, since you do not advise on believing on these message fields, do you have any idea on how to deal with this COA time arrival?
It is some extra code, but maybe we sould offload the log queue (that holds all exit captured COAs) on every message that arrives, reading the COA, finding the correlated incoming message in our internal table, and updating the date/time columns following the extracted info from the COA. Then append that COA in our auditing file located on our filesystem.
| PeterPotkay wrote: |
I can put a message with a Put Date and Put Time that has zero relevance as to the actual date and time that I put the message.
In other words, because MQ allows suitably authorized apps to set the Put Date/Time to whatever they want, you cannot trust the Put Date/TIme is accurate in 100% of all use cases. |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 03, 2015 4:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How about looking for the difference between system time between send and COA. This should be negligible if the network conditions are good and no queue is full... And remember COA does not COD make... I can ignore a message on a queue for days... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
