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)