[
https://issues.apache.org/jira/browse/EAGLE-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DanielZhou updated EAGLE-880:
-----------------------------
Description:
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 we convert date time to seconds.
Let me know if you can reproduce this bug and which approach you prefer.
Thanks and regards,
Da
was:
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
> 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 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)
