commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: [DISCUSS] new component for timing?
Date Fri, 02 Mar 2018 13:45:11 GMT
My understanding is that sirona was/is a complete system, as opposed to a
collection of utilities.
If StackWatch is too big for LANG it seems too small for sirona.  Along
with sirona being retired etc.



On February 28, 2018 at 15:06:52, Romain Manni-Bucau (rmannibucau@gmail.com)
wrote:

Le 28 févr. 2018 19:27, "Matt Sicker" <boards@gmail.com> a écrit :

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.


Sirona started from commons-monitoring ;)



On 28 February 2018 at 10:56, Gilles <gilles@harfang.homelinux.org> wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles <gilles@harfang.homelinux.org>:
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,
>>>>
>>>> On that topic we can keep in mind we retired not a lot time ago Apache
>>>> Sirona which was a perf framework industrializing a stopwatch to
>>>> summarize
>>>> it.
>>>> We can make it live again and would probably be a better fir than
>>>> commons
>>>> cause you quickly need more than just some time measurement when you
>>>> start
>>>> to work on these topics.
>>>>
>>>>
>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the
project
>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
> https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>
>>>> <https://www.packtpub.com/application-development/java-ee-8-
>>>> high-performance>
>>>>
>>>>
>>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <garydgregory@gmail.com>:
>>>>
>>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <gilles@harfang.homelinux.org>
>>>>
>>>>> wrote:
>>>>>
>>>>> > Hello.
>>>>> >
>>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >> In the course of working through my pull request for adding
new
LANG
>>>>> >> functionality on top of the StopWatch class, the issue has been
>>>>> raise
>>>>> as
>>>>> >> to
>>>>> >> if this functionality is ‘common’ or should
>>>>> >> be placed in a more specialized commons-xxxx component.
>>>>> >>
>>>>> >> We would like to take the discussion to the list for this, and
see
>>>>> what
>>>>> >> everyone thinks.
>>>>> >>
>>>>> >> The StackWatch provides for tracking nested timings backed by
>>>>> StopWatch.
>>>>> >> You can start the watch, and start and stop multiple timings
through
>>>>> the
>>>>> >> call stack. Each timing is named and tag and has it’s own
time.
>>>>> >> You can visit all the timings, perhaps using the tags to filter
when
>>>>> you
>>>>> >> are done. Please see the PR/Jira for more details. You should
look
>>>>> at
>>>>> >> both, since the review has been split between the two.
>>>>> >>
>>>>> >> If not LANG, then where? The commons-testing component has been
>>>>> >> mentioned. But this code is not ‘test’ code explicitly.
In my use
>>>>> case (
>>>>> >> I wrote this for the Apache Metron project and thought it might
be
>>>>> useful
>>>>> >> here) it would not be test code, in the sense that it would
be
used
>>>>> in
>>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production,
in
>>>>> a
>>>>> >> REPL,
>>>>> >> and perhaps in other runtime components.
>>>>> >>
>>>>> >
>>>>> > Part of what makes a good component is that it does not dictate
>>>>> > how and where applications should use it.
>>>>> > The name "Testing" does not imply that its contents must be used
>>>>> > within "test" scope.
>>>>> >
>>>>> > A utility such as "StackWatch" could be another tool to integrate
>>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>>>>> > report than Junit does). Hence the module in which "StackWatch"
>>>>> > will belong is to become a dependency of modules that target
>>>>> > specific test framework (and that is true whether the former is
>>>>> > defined within "Testing" or in another component).
>>>>> >
>>>>> > I would not want to pull in junit
>>>>> >> or other dependencies with any component containing it.
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > Must be ensured by proper granularity of the modular design.
>>>>> >
>>>>> > If we put it in commons-testing ( which already has sub-modules
which
>>>>> are
>>>>> >> geared towards junit ) it may be confusing, even if the module
is
>>>>> explicit
>>>>> >> about purpose and keeping out junit dependent code ( or other
>>>>> testing
>>>>> >> code).
>>>>> >>
>>>>> >
>>>>> > Why would it be confusing? The module will stand out on its own
>>>>> > (artefact/description/doc/web site) and be more visible than yet
>>>>> > another class in the already too large "Commons Lang".
>>>>> >
>>>>> > Also, besides the StackWatch, what else would go into the new
target
>>>>> >> component? Would StopWatch move as well for example?
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > But creating a new component for two small classes can reasonably
>>>>> > be argued as overkill.
>>>>> > FTR: I was asked to collect the sampling utilities within a
>>>>> > module of "Commons RNG" even though it could have warranted its
>>>>> > own component (being a plain "client" of the core functionality
>>>>> > of [RNG]). In the present case, "StackWatch" would belong to
>>>>> > "core" utilities of "Testing" that are pulled (along with other
>>>>> > dependencies by the more specific modules.
>>>>> >
>>>>>
>>>>> I would ask all of us to step back for a moment and consider the big
>>>>> picture.
>>>>>
>>>>> Specifically, what do you consider the mandate or guidelines for
>>>>> Commons
>>>>> Lang to be? For me, this is code that should or could have been in
the
>>>>> JRE
>>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
should
>>>>> likely only depend on java.base (it does today but this should be
>>>>> enforced
>>>>> with the Maven JDeps Plugin IMO.)
>>>>>
>>>>> If you look at StringUtils, you can then see how this class has grown
>>>>> into
>>>>> a giant. You can also then see why other related code like a fancier
>>>>> String.replace() could creep in as StrSubstitutor and friends. Should
>>>>> variable interpolation have been in the JRE? Debatable, but it would
be
>>>>> useful on top of Properties and ResourceBundle, one might argue; also
>>>>> handy
>>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
rightly
>>>>> IMO
>>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
>>>>> home
>>>>> in Commons Text, where is has evolved further.
>>>>>
>>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE or
>>>>> Commons Lang. It should sit slightly above that level. Where, is the
>>>>> question.
>>>>>
>>>>> Commons Testing for Stop/StackWatch does not seen quite right to me.
I
>>>>> could see a new Commons Timing or a more general Commons Measurement;
>>>>> with
>>>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > Gilles
>>>>> >
>>>>> >
>>>>> >> https://issues.apache.org/jira/browse/LANG-1373
>>>>> >>
>>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>>>>> >> https://github.com/apache/commons-lang/pull/311
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message