| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMB v6.1 upgrade caused strange CURRENT_TIMESTAMP behaviour. |
« View previous topic :: View next topic » |
| Author |
Message
|
| woodoo2k |
 Posted: Fri Jun 26, 2009 9:34 am Post subject: WMB v6.1 upgrade caused strange CURRENT_TIMESTAMP behaviour. |
 |
|
Apprentice
Joined: 07 Feb 2005
Posts: 28
Location: USA
|
We are running WMBv6.1 on Solaris platform. It was upgraded recently from 6.0. After upgrade, one of the message flows that uses CURRENT_TIMESTAMP value to log processing time in oracle db, is displaying strange behaviour. Let me explain the message flow design.
1. Message flow consists of two nodes.
2. First node captures the CURRENT_TIMESTAMP and stores in an environment variable, StartTime.
3. Then it executes some DB operations in a loop. At this step, the database timestamp is also captured and put in the body of the message.
4. The Second Node captures the EndTime and puts the data into an Oracle Audit table, including the message body.
The problem that we are facing is this:
1. Before upgrade to v6.1, the audit table was reflecting the time taken by message flow correctly. Both the DB time as well as message flow time were in sync.
2. After upgrade to v6.1, the timing as captured by DB are no more in sync with timing captured by Message Broker message flow.
3. Observation is that the compute node is capturing the timestamp towards the end, before exit, instead of at the beginning where the statement occurs, causing the process to appear faster than it really is.
4. The DB timestamps are still showing the correct time taken in processing.
I need other users to share their experience if they have observed this behaviour. Is it some bug or changed feature of MB with v6.1?
We have many options to remediate the situation but first want to understand the sudden change of behaviour after upgrade!
Thanks a lot for any help/insight you could provide!
Regards,
Rana |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sat Jun 27, 2009 2:46 am Post subject: Re: WMB v6.1 upgrade caused strange CURRENT_TIMESTAMP behavi |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| woodoo2k wrote: |
| I need other users to share their experience if they have observed this behaviour. Is it some bug or changed feature of MB with v6.1? |
Not something I've experienced as I tend to take timings differently, but I'll mention for the record that CURRENT_TIMESTAMP is guaranteed to return the same value every time it's called in a given node. So it's certain that whatever the function's doing under the covers, it's not just looking at the system clock!
I suspect some change in this "guarantee" mechanism is the cause of this problem, and leave it to a passing IBMer to talk with more authority.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Jun 27, 2009 4:30 am Post subject: Re: WMB v6.1 upgrade caused strange CURRENT_TIMESTAMP behavi |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| woodoo2k wrote: |
| 3. Then it executes some DB operations in a loop. At this step, the database timestamp is also captured ... |
At what point does the message flow capture the database timestamp? Before the loop? After the loop? Inside the loop?
| woodoo2k wrote: |
The problem that we are facing is this:
1. Before upgrade to v6.1, the audit table was reflecting the time taken by message flow correctly. Both the DB time as well as message flow time were in sync. |
What does "in sync" mean here? Is the DB time the same as the StartTime, or the same as the EndTime, or something else?
| woodoo2k wrote: |
| 2. After upgrade to v6.1, the timing as captured by DB are no more in sync with timing captured by Message Broker message flow. |
What does "in sync" mean here? Does the DB time occur before the StartTime, or after the EndTime, or something else?
| woodoo2k wrote: |
| 3. Observation is that the compute node is capturing the timestamp towards the end, before exit, instead of at the beginning where the statement occurs, causing the process to appear faster than it really is. |
What does that mean? ESQL is a sequential programming language. CURRENT_TIMESTAMP, like any other function, has to calculate a value before it can return one; the broker won't execute subsequent statements until the function call completes.
| woodoo2k wrote: |
| 4. The DB timestamps are still showing the correct time taken in processing. |
DB timestamps? Plural? 
Run a usertrace.
How do the various timestamps correlate with usertrace timestamps? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jun 27, 2009 6:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Additional food for thoughts: What is the time difference between your broker box and the DB box? Have you any way of measuring that? And please don't just tell us they are ntp synched, verify it and prove it. 
_________________
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
|
|
|
|
