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 14:31:43 GMT
I don’t understand the options that we are discussing here.  Can we clarify?

* create a new component from sirota, bringing it into commons ( resurrect
commons-monitoring ) and put StackWatch there?


On March 2, 2018 at 08:49:03, Romain Manni-Bucau (rmannibucau@gmail.com)
wrote:

This i right but it started as just a few utilities and interception
modules, then it grows as any performance related project. We also have
skywalking which is quite big but can host all that utility part @asf.


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-03-02 14:45 GMT+01:00 Otto Fowler <ottobackwards@gmail.com>:

> 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