eagle-issues mailing list archives

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

     [ 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)

Mime
View raw message