[ 
https://issues.apache.org/jira/browse/STORM-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056387#comment-14056387
 ] 

Robert Joseph Evans commented on STORM-328:
-------------------------------------------

Like I said when I filed the JIRA there are two possibilities to fix this.  We 
can either update Config.java to properly enforce ranges for different numbers, 
based off of how they will be interpreted.  Or we need to update 
Utils.get{Int,Long,Etc.} to handle numbers outside of the allowed range in a 
sensible way. Possibly something like If the number is too big to fit, make it 
MAX whatever. If it is too small to fit make it MIN whatever.

I think I would prefer to have Config be more restrictive, than to have the 
interpretation of the values be more lenient.

It should not be hard to come up with an IntegerValidator, LongValidator, etc. 
And replace all of the instances of Number.class with one of these two.  Or 
DoubleValidator, etc. if we find that they are being used that way instead.

There already is an PowerOf2Validator in ConfigValidation that you can use as a 
staring point.
https://github.com/apache/incubator-storm/blob/master/storm-core/src/jvm/backtype/storm/ConfigValidation.java#L87-105


> Config.java and Utils.get{Int,Long} are not in sync for floating point
> ----------------------------------------------------------------------
>
>                 Key: STORM-328
>                 URL: https://issues.apache.org/jira/browse/STORM-328
>             Project: Apache Storm (Incubating)
>          Issue Type: Bug
>    Affects Versions: 0.9.2-incubating, 0.9.1-incubating, 0.9.0.1
>            Reporter: Robert Joseph Evans
>              Labels: newbie
>
> For most numeric configuration values Config.java has a type of Number 
> listed, but the values are parsed using Utils.getInt or Utils.getLong, which 
> means if someone gave a floating point number it would pass the 
> ConfigValidation, but would blow up when it is used.  This is most critical 
> for values that Nimbus reads, but would be good to have them consistent 
> everywhere.
> We should also check that getInt works properly for numbers that are larger 
> then would fit in an integer.
> Either we need to update Utils to be more lenient when looking at doubles, or 
> we need to make Config more strict, which may be difficult with the YAML and 
> JSON parsing that happens, where ints are often converted into longs.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to