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

[Brian Stansberry]

On 12/4/15 9:21 AM, Emmanuel Hugonnet wrote:
>
>
> Le 04/12/2015 16:08, Brian Stansberry a écrit :
>> 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.
>
> Basically we can iterate over the filestore aka partitions/drives so we could display this info in a centralized point.
>

Users should use machine administration tools for that kind of thing.

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


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