commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DISCUSS] new component for timing?
Date Fri, 02 Mar 2018 14:45:42 GMT
On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler <ottobackwards@gmail.com> wrote:

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

Something like that. For my money, I'd like this into a (probably new)
component that is not [lang] since it feels out of scope. StopWatch would
move to this new place (deprecate it in [lang] and copy it.)

Gary


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