[wildfly-dev] Shall we limit size of the deployment in WildFly?

[Brian Stansberry]

On 12/4/15 6:41 AM, Emmanuel Hugonnet wrote:
> Keeping only the relevant parts, remarks inlined :
>
>>>    * for space availability this might depend on the different mount points:
>>>         - should we provide it for every path since we wouldn't know in advance to which mount point each path is on
>>
>> I don't understand this question. How were you planning to get the space
>> availability information?
>>
>> My instinct is the closer this conforms to what the standard java (n)io
>> API provides the better.
>>
>
> What I mean is that since we don't know to which mount point/drive each path is using, we would have to define the space availability per
> path instead of as a global metric/value.

I don't think we should try to do any kind of aggregation or analytical 
work. A path resolves to a File and a File reports getUsableSpace(). If 
a user looks at two paths on the same partition and double counts by 
assuming he can use that much for each path, that's a user error. But 
it's kind of a "duh" kind of error, so long as we document the semantic 
(including a reference to the JDK javadoc we rely upon) and are careful 
about how the data is presented in any UI. The UI is probably the bigger 
problem.

> So I was wondering if this is really something that makes sense. Which explains the next question aka are these informations valuable.
>

That I don't know, but it seems useful. It provides information that a a 
user can then reason with, either well or poorly. It's not rocket 
science to reason intelligently though.

I rarely object to not including something that hasn't been specifically 
asked for though, so I don't mind not including this if no one makes a 
case for it.

>>>         - or maybe this info is not that important
>>>
>
> Cheers,
> Emmanuel
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat