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

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