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

[Emmanuel Hugonnet]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151204/746b9c45/attachment.bin