ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IIB 9.0.0.7 inconsistent creationTime format in Mon Events

Post new topic  Reply to topic Goto page 1, 2  Next
 IIB 9.0.0.7 inconsistent creationTime format in Mon Events « View previous topic :: View next topic » 
Author Message
john.ormerod
PostPosted: Wed Apr 19, 2017 1:43 am    Post subject: IIB 9.0.0.7 inconsistent creationTime format in Mon Events Reply with quote

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
View user's profile Send private message Send e-mail
smdavies99
PostPosted: Wed Apr 19, 2017 6:01 am    Post subject: Reply with quote

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
View user's profile Send private message
john.ormerod
PostPosted: Wed Apr 19, 2017 6:21 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Apr 19, 2017 6:39 am    Post subject: Reply with quote

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
View user's profile Send private message
john.ormerod
PostPosted: Wed Apr 19, 2017 7:08 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Apr 19, 2017 7:18 am    Post subject: Reply with quote

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
View user's profile Send private message
john.ormerod
PostPosted: Wed Apr 19, 2017 8:14 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
john.ormerod
PostPosted: Thu Apr 20, 2017 2:56 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
IIB_Intel
PostPosted: Fri Jul 31, 2020 5:49 am    Post subject: same problem Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jul 31, 2020 6:07 am    Post subject: Re: same problem Reply with quote

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
View user's profile Send private message
IIB_Intel
PostPosted: Fri Jul 31, 2020 7:57 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jul 31, 2020 10:41 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Jul 31, 2020 8:23 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
IIB_Intel
PostPosted: Mon Aug 03, 2020 3:36 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Aug 03, 2020 4:16 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » IIB 9.0.0.7 inconsistent creationTime format in Mon Events
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.