eagle-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DanielZhou (JIRA)" <j...@apache.org>
Subject [jira] [Created] (EAGLE-880) Policy get corrupted when timestamp is given a valid date in milliseconds
Date Fri, 20 Jan 2017 19:59:26 GMT
DanielZhou created EAGLE-880:

             Summary: 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
         Environment: OS: centos 6
Database: MySQL
Storm: 0.10

            Reporter: DanielZhou

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]

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,

This message was sent by Atlassian JIRA

View raw message