search

BroadSoft-Xtended / BroadWorks-Dashboards-and-Discovery

This repository contains the BroadWorks Dashboards and Discovery components to extend BroadWorks data mining, reporting, and analysis capabilities.
23 stars 4 forks source link

bwlogreceiver_1020 java.text.ParseException #48

Open taranion opened 6 years ago

taranion commented 6 years ago

I am experiencing the following bug when running the bwlogreceiver java.text.ParseException: Unparseable date: "2018-05-25 23:00:04.798 CEST" at java.text.DateFormat.parse(DateFormat.java:366) at com.broadsoft.eslogzipreceiver.LogData.getESTimestamp(LogData.java:196) at com.broadsoft.eslogzipreceiver.IndexBuilders.DefaultChannelIndexBuilder.BuildAndSend(DefaultChannelIndexBuilder.java:58) at com.broadsoft.eslogzipreceiver.LogProcessor.deliver(LogProcessor.java:154) at com.broadsoft.eslogzipreceiver.LogProcessor.run(LogProcessor.java:91) at java.lang.Thread.run(Thread.java:748)

Is this a bug (e.g. due to a 4-letter timezone) or is it necessary to configure the format for timestamps received from the Broadworks (and if so, where to do this?)

Regards, Stefan

gokulbsft commented 6 years ago

The 4-letter timezone should not be the reason behind this issue.

Anyway, how does the date timestamp display in the log file processed?

Is it same as 2018-05-25 23:00:04.798 CEST? (please ensure the dot before the seconds in time string).

taranion commented 6 years ago

Yes, it is the same.

I digged a little deeper, decompiled your LogData.class and developed the following program which could reproduce the error:

public static void main(String[] args) throws ParseException {
    String formatted = "2018-05-25 23:00:04.798 CEST";
    SimpleDateFormat gmtFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS z");
    Date date = gmtFormat.parse(formatted);
    System.out.println("Parsed "+date);
}

When changing this to SimpleDateFormat gmtFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS z", Locale.US); the exception was gone.

StackOverFlow helped (as usual) ;-)

gokulbsft commented 6 years ago

Ok. Here the exception is not thrown even if the locale is not set explicitly. What is the default locale set in your case? I.E. What is the result of Locale.getDefault()?

Also, the log file I asked in my previous comment is the Broadworks Log, not the receiver log. Hope you checked the same.

taranion commented 6 years ago

Regarding the logs: I don't know for sure which Broadworks Log causes the problem. There are several timestamp formats in the logfiles:

The Linux locale when testing was "de_DE" (which was also reported by Locale.getDefault() ) For our elastic search installation, we solved the problem by setting the Linux system locale to "en_US.utf8". Now the bwlogreceiver works as expected.

gokulbsft commented 6 years ago

Yes, Got it! This exception raises when the default locale is de_DE and the time zone is CEST. We will consider and include this fix after verifying with other locales and timezones. Thanks.