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


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)

Mime
View raw message