| Author |
Message
|
| john.ormerod |
 Posted: Wed Apr 19, 2017 1:43 am Post subject: IIB 9.0.0.7 inconsistent creationTime format in Mon Events |
 |
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Hello
I'm working with IIB running locally in Win 10, developing a monitoring client in Java. So far I have had to deal with 3 different date-time formats in the published events:
1. millisecs: creationTime="2017-03-20T17:15:10.788Z"
2. microsecs: creationTime="2017-03-20T17:15:10.788001Z"
3. seconds: creationTime="2017-04-18T14:38:55Z"
I'd say 95%+ use millisecs. Yesterday, my parsing failed because the millisecs were missing. The previous event had a timestamp of "2017-04-18T14:38:54.999Z". From this I assume that the millisecs value is '000' and it was omitted.
Is it possible to specify somehow that IIB report creation time in a fixed format?
I found these earlier posts on the topic for milli and micro secs:
http://www.mqseries.net/phpBB/viewtopic.php?p=360439&sid=8316e32a052fbfcf2dfc4422712d5274
This is from 2013 and a reply from 'kimbert' says that timestamp formats being different in different environments is a known problem, and will be addressed. In my case it's within the same system.
http://www.mqseries.net/phpBB2/viewtopic.php?t=63420&sid=f123c839d2466f32528e16fea713e140
This is also from 2013 and reports receiving both milli and micro secs.
Has this inconsistency been resolved in IIB 10?
Regards, John |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Apr 19, 2017 6:01 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
john,
This is something I have seen before on a couple of systems. I don't know if it is fixed in IIB10 but the general dropping of trailing zeroes is what you are seeing.
I got around this in other projects by wrapping up the calls that needed trailing zeroes in a function that added them if they were missing. 99.99% of the time nothing needed to be added.
The first time I encountered this was back in 2006 with WMBIB V6.
_________________
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 |
|
|
| john.ormerod |
| Posted: Wed Apr 19, 2017 6:21 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Thanks smdavies.
As you point out, the genreric issue looks like the dropping of trailing 0s. In the case of microsecs, they could be could have been reported to IIB as 000 and dropped by it. The dropping of the millis being an extreme case of this.
In my PoC-level code, I'm creating an Event POJO and holding the date as string for later processing, which is where I orignally found the format issue. At the moment, I truncate any micro-secs (I have a TODO to consider rounding). Now I'm adding '.000' for missing millis.
You have caused me to think that adding missing micros as '000' would be a better solution - along with the occasional missing millis as '.000000'. That way I won't lose any finer-grained timestamps from platforms that regularly report them.
Thanks for your help.
John |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 19, 2017 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
a) milliseconds is optional in any kind of ESQL/logical message tree time/timestamp field
b) ... I forget if using a fixed number of S, rather than a single S, in a FORMAT string will pad with zeros or not... i.e. that "SSSS" will produce "0000" if the partial seconds field is empty.
So the real question here is, what is your format string when trying to CAST as TIMESTAMP ?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| john.ormerod |
| Posted: Wed Apr 19, 2017 7:08 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Hi mqjeff
I'm subtracting the creation time of Event A 'out' from Event A 'in', to calculate a duration for Event A. This is done when I am creating an XML 'summary' of the path taken through the msgflow, with timings per node.
I am actually using Groovy to create the XML. What I have just tested is adding 'SSS' to the date format:
| Code: |
| new Date().parse("yyyy-MM-dd'T'HH:mm:ss.SSSSSSX", mes.end).getTime() |
For the two timestamps involved, it works - I was pleasantly surprised, after a seach suggested that micro secs not supported before Java 8. What really surprised me was that all of the 5 events published were timed with micro secs. I think I will alter the sequence of 'if' statements when checking the contents of the time in the event.
Regards, John |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 19, 2017 7:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So that worked with your third example, that only had seconds?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| john.ormerod |
| Posted: Wed Apr 19, 2017 8:14 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
My third example with seconds-only, works in my JUnit test. I'd never had one of those until yesterday!
When I run the actual monitoring client, I mostly see the Event creationTime in millisecs - thought the duration is now in microsecs.
For some reason, one test published all 5 Events with each having a microsec timestamp. Now, it's back to millisecs.
As is often said "it keeps us in a job"!
John |
|
| Back to top |
|
|
| john.ormerod |
| Posted: Thu Apr 20, 2017 2:56 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Just to say thank you to everyone that has helped with my query.
Regards, John |
|
| Back to top |
|
|
| IIB_Intel |
| Posted: Fri Jul 31, 2020 5:49 am Post subject: same problem |
|
|
Acolyte
Joined: 07 May 2015
Posts: 64
|
IIB monitoring events are trimming leading 0's for creationTime. This is causing problems.
Any idea on any fix was provided? we are on v10.0.0.20.
Otherwise will go for PMR. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2020 6:07 am Post subject: Re: same problem |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| IIB_Intel wrote: |
| IIB monitoring events are trimming leading 0's for creationTime. This is causing problems. |
What problems? And to be clear, are you saying that:
| Code: |
2020-07-31T09:31:45.223235455
|
is being presented as:
| Code: |
2020-07-31T9:31:45.223235455
|
| IIB_Intel wrote: |
| Any idea on any fix was provided? we are on v10.0.0.20. |
This thread isn't talking about that; it's discussing how many decimal places the milliseconds go down to.
| IIB_Intel wrote: |
| Otherwise will go for PMR. |
It's always an option.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| IIB_Intel |
| Posted: Fri Jul 31, 2020 7:57 am Post subject: |
|
|
Acolyte
Joined: 07 May 2015
Posts: 64
|
Examples:
Instead of sending 2020-07-31T09:31:45.000000z it is sending 2020-07-31T09:31:45z
Instead of sending 2020-07-31T09:31:45.123000z it is sending 2020-07-31T09:31:45.123z |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2020 10:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| IIB_Intel wrote: |
Examples:
Instead of sending 2020-07-31T09:31:45.000000z it is sending 2020-07-31T09:31:45z
Instead of sending 2020-07-31T09:31:45.123000z it is sending 2020-07-31T09:31:45.123z |
Ok, those are not leading zeros, those are trailing zeros.
You have still not said what problems it's causing you, and why the solutions outlined in this thread do not work.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 31, 2020 8:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It looks like you're using java. If you are up to using System.nanoTime(), you can use that. However remember that it is not valid as a Calendar time and should only be used for time differences at the nano level. Very practical when the standard long from date or Calendar or System.currentTimeMillis() would report an elapsed time of 0.
Hope it helps. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| IIB_Intel |
| Posted: Mon Aug 03, 2020 3:36 am Post subject: |
|
|
Acolyte
Joined: 07 May 2015
Posts: 64
|
| Is it an expected behaviour for IIB to remove trailing 0's from the creationTime field of Monitoring events? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 03, 2020 4:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| IIB_Intel wrote: |
| Is it an expected behaviour for IIB to remove trailing 0's from the creationTime field of Monitoring events? |
It is if you're not using a format or cast to get the string value
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
