| Author |
Message
|
| dosttumhara1810 |
 Posted: Fri Mar 25, 2011 2:28 am Post subject: Very strange issue with CURRENT_TIMESTAMP |
 |
|
Voyager
Joined: 01 Dec 2010
Posts: 76
|
Hi All,
I am facing avery starnge issue with using CURRENT_TIMETSAMP in COmpute node.
I am giving this command in compute node
DECLARE time CHARACTER CURRENT_TIMESTAMP;
and i am getting this value in time variable
TIMESTAMP '2011-06-29 13:55:00.406241';
But strange thing here is this is not the curent date and not even the current time..Also not even this Even if i run this flow later on this value is never changing..means same timestamp same seconds...How is this possible.. |
|
| Back to top |
|
 |
| dosttumhara1810 |
| Posted: Fri Mar 25, 2011 2:29 am Post subject: |
|
|
Voyager
Joined: 01 Dec 2010
Posts: 76
|
| Please help me on this issue.. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Mar 25, 2011 2:51 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| dosttumhara1810 wrote: |
| Please help me on this issue.. |
Please have a little patience.
You only waited a very short time before asking this. If you meant to add it to your original post, there is an Edit facility.
Please also remember that this is not a formal support forumm.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 25, 2011 2:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It is documented that each time you runn CURRENT_TIMESTAMP in the same instance of the same flow you will get the same value. That is, you can't use it to time your flow, you have to use something else).
But that doesn't sound like what you are saying is happening.
It sounds you are saying that you are always getting the same value in all flows.
Which means something is wrong with the system clock when the broker started up, or that something very very odd is going on. |
|
| Back to top |
|
|
| dosttumhara1810 |
| Posted: Fri Mar 25, 2011 3:25 am Post subject: |
|
|
Voyager
Joined: 01 Dec 2010
Posts: 76
|
| I have tried this same command in two different flows..and same values are still coming.. that means timestamp value is not changing with time..How is this possible.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 25, 2011 4:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It is possible because something is broken.
There isn't any information you have given about what.
Does it stay the same if you restart the Broker?
What version are you on? What platform? |
|
| Back to top |
|
|
| dosttumhara1810 |
| Posted: Fri Mar 25, 2011 6:46 am Post subject: |
|
|
Voyager
Joined: 01 Dec 2010
Posts: 76
|
| Yes i restarted the broker ..problem still persist |
|
| Back to top |
|
|
| deepeshk79 |
| Posted: Sun Aug 28, 2011 6:24 am Post subject: Current_TimeStamp issue in ESQL |
|
|
Apprentice
Joined: 25 Mar 2007
Posts: 45
Location: Los Angeles
|
I'm posting this in response to an old thread, so apologies for that, but we too are facing the same problem with TimeStamp
The details are as below
--Compute Node 1 - display Time Stamp (using env variable and then env variable is written to a trace file) - results in T1
--Propagate to Compute Node 2 - display TimeStamp - results in T2
--The propagte is over and returns to Compute Node 1
--Compute Node 1 - display Time Stamp - results in T1 again.
My query is that when we propagate to another compute node, why does the timestamp get's different though we are in the same instance/thread ?
When I look at my trace file, it shows T2 > T1 and then when we come back to Compute Node 1 - the timestamp again shows the old T1.
Appreciate any inputs here.
Thanks,
Deep |
|
| Back to top |
|
|
| sankritya |
| Posted: Sun Aug 28, 2011 6:44 am Post subject: |
|
|
Centurion
Joined: 14 Feb 2008
Posts: 100
|
| Quote: |
| why does the timestamp get's different though we are in the same instance/thread ? |
Timestamp is same in the same compute node only for same instance in same thread . So it is changing in second compute node.
| Quote: |
| when we come back to Compute Node 1 - the timestamp again shows the old T1 |
It is in the same instance of same flow and flow has not been completed for that compute node with time stamp T1.
If you verify T2 in the trace it will get changed every time message is processed from Compute(T1) to Compute(T2) as processing in second compute node is getting completed each time(assuming that you are running some loop in first compute node). |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sun Aug 28, 2011 8:54 am Post subject: Re: Current_TimeStamp issue in ESQL |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| deepeshk79 wrote: |
| I'm posting this in response to an old thread, so apologies for that, but we too are facing the same problem with TimeStamp |
This is not the same problem.
| deepeshk79 wrote: |
The details are as below
--Compute Node 1 - display Time Stamp (using env variable and then env variable is written to a trace file) - results in T1
--Propagate to Compute Node 2 - display TimeStamp - results in T2
--The propagte is over and returns to Compute Node 1
--Compute Node 1 - display Time Stamp - results in T1 again.
My query is that when we propagate to another compute node, why does the timestamp get's different though we are in the same instance/thread ? |
The InfoCenter explains this:
| Quote: |
| All calls to CURRENT_TIMESTAMP within the processing of one node are guaranteed to return the same value. |
For each transaction, there is one value of CURRENT_TIMESTAMP per node, (not one value per instance/thread). |
|
| Back to top |
|
|
| harishrad |
| Posted: Fri Sep 21, 2012 5:08 am Post subject: |
|
|
Newbie
Joined: 13 Jun 2012
Posts: 3
|
| This is a crappy functionality to keep the timestamps the same within the nodes as it serves no purpose to log the times, when will IBM fix it |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Sep 21, 2012 5:21 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| harishrad wrote: |
| This is a crappy functionality to keep the timestamps the same within the nodes as it serves no purpose to log the times, when will IBM fix it |
This is function-by-design. A node is an interruption to the execution path of a message. At the time the node is called, the thread is suspended and a call to get current timestamp retrieves the time value stored in the environment at the time the execution path was interrupted.
If you want to measure time between certain points within your ESQL logic of the same node, you can do so by calling Date.getTime() Java api call from ESQL.
Why do you say "this is crappy functionality"? What is crappy about it? It is documented as it behaves and there are other calls to do what you want. Why do you say the functionality is bad when you can get the desired functionality by calling the proper function?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 21, 2012 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| harishrad wrote: |
| This is a crappy functionality to keep the timestamps the same within the nodes as it serves no purpose to log the times |
What about those of us who use timestamp to correlate functions, or have (relatively) long running code which all needs to logically happen at "the same time". The question is why are you trying to use it to log the times? If you're trying to work out how long you're spending in a given node, the software provides an inbuilt method to determine this which IMHO is better than writing out a list of times to a log file.
| harishrad wrote: |
| when will IBM fix it |
Never. It's not broken. It's clearly documented that CURRENT_TIMESTAMP behaves like this. That it works like this is no more crappy than your design for obtaining statistics on run times.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Sep 22, 2012 5:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| lancelotlinc wrote: |
| If you want to measure time between certain points within your ESQL logic of the same node, you can do so by calling Date.getTime() Java api call from ESQL. |
There are also the java.lang.System methods, currentTimeMillis() and nanoTime(). But ESQL can't call any of these Java methods directly, due to ESQL to Java data type mapping constraints; it needs an additional wrapper class.
An additional ESQL function might be useful for measuring the time between two points within the ESQL (beyond what the runtime statistics can provide). Anyone who felt strongly enough about it could always open a request for enhancement. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Sep 22, 2012 5:48 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| An additional ESQL function might be useful for measuring the time between two points within the ESQL (beyond what the runtime statistics can provide). Anyone who felt strongly enough about it could always open a request for enhancement. |
even just a modification to the ESQL log statement to allow it to write to User Trace, in the way that the .NET APIs can write to User Trace would likely be sufficient for most purposes. |
|
| Back to top |
|
|
|
|
