[jira] [Updated] (EAGLE-880) Policy get corrupted when timestamp is given a valid date in milliseconds

["DanielZhou (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/EAGLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

DanielZhou updated EAGLE-880:
-----------------------------
    Affects Version/s: v0.4.0

> Policy get corrupted when timestamp is given a  valid date in milliseconds
> --------------------------------------------------------------------------
>
>                 Key: EAGLE-880
>                 URL: https://issues.apache.org/jira/browse/EAGLE-880
>             Project: Eagle
>          Issue Type: Bug
>    Affects Versions: v0.4.0
>         Environment: OS: centos 6
> Database: MySQL
> Storm: 0.10
>            Reporter: DanielZhou
>
> Description:
> Timestamp metadata type: long
> Input for timestamp: 1484938526200 (equaisl to Fri Jan 20 2017 10:55:26 GMT-0800 )
> In storm topology log, it indicates policy get corrupted because the input of timestamp.
> Error messages:
> Caused by: java.lang.NumberFormatException: For input string: "1484938526200"
>  at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[na:1.7.0_55]
>  at java.lang.Integer.parseInt(Integer.java:495) ~[na:1.7.0_55]
>  at java.lang.Integer.parseInt(Integer.java:527) ~[na:1.7.0_55]
> Cause:
> Siddhi query parser ALWAYS parse field timestamp  as "singed_int", no matter the constant type defined in siddhi stream is of type "long", "double" or "float".
> org.wso2.siddhi.query.compiler.internal.SiddhiQLBaseVisitorImpl: 1177
> public Constant visitConstant_value(@NotNull Constant_valueContext ctx) {
>         if(ctx.bool_value() != null) {
>             return Expression.value(((BoolConstant)this.visit(ctx.bool_value())).getValue().booleanValue());
>         } else if(ctx.signed_double_value() != null) {
>             return Expression.value(((DoubleConstant)this.visit(ctx.signed_double_value())).getValue().doubleValue());
>         } else if(ctx.signed_float_value() != null) {
>             return Expression.value(((FloatConstant)this.visit(ctx.signed_float_value())).getValue().floatValue());
>         } else if(ctx.signed_long_value() != null) {
>             return Expression.value(((LongConstant)this.visit(ctx.signed_long_value())).getValue().longValue());
>         } else if(ctx.signed_int_value() != null) {
>             return Expression.value(((IntConstant)this.visit(ctx.signed_int_value())).getValue().intValue());
>         } else if(ctx.time_value() != null) {
>             return (TimeConstant)this.visit(ctx.time_value());
>         } else if(ctx.string_value() != null) {
>             return Expression.value(((StringConstant)this.visit(ctx.string_value())).getValue());
>         } else {
>             throw this.newSiddhiParserException(ctx);
>         }
>     }
> 	
> Possible solutions:
> - We can update the dependency from "3.0.5" to "3.1.x" to verify if this is a siddhi engine related bug.
>   This approach will introduce code changes related to siddhi's API call as some api has changed.
> - Or instead of using "milliseconds", we can use "seconds" as input , then in all audit event parser I we convert date time to seconds.
> 	
> Let me know if you can reproduce this bug and which approach you prefer.
> Thanks and regards,
> Da



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)