osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] new component for timing?


Side note: geronimo just started to implement Microprofile metrics which is
a kind of copy of the dropwizard/codehale API, maybe it can be a place to
host this kind of thing too. [1] is quite close I think

[1]
https://gitbox.apache.org/repos/asf?p=geronimo-metrics.git;a=blob;f=src/main/java/org/apache/geronimo/microprofile/metrics/impl/TimerImpl.java;h=d8ac05ecef4aea726fe8d8b948e0d067ad35f455;hb=HEAD

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>


Le lun. 11 juin 2018 à 20:35, Otto Fowler <ottobackwards@xxxxxxxxx> a
écrit :

> Thanks to everyone who took that time to review.
>
> Although my preference was to contribute this utility back to commons, it
> seems like it has kind
> of spiraled into something much more, and there doesn’t seem to be a clear
> consensus.
>
> So if you think it was useful :
> you grab it now from
> https://bintray.com/palindromicity/stackwatch/stackwatch/0.0.1
> https://github.com/palindromicity/stackwatch
>
>
>
> On April 23, 2018 at 08:16:46, Gilles (gilles@xxxxxxxxxxxxxxxxxxxxx)
> wrote:
>
> On Mon, 23 Apr 2018 04:54:21 -0700, Otto Fowler wrote:
> > Bump
>
> More than a vote, you need someone to take on the tasks to
> create the new component.
>
> I feel that no argument were made against bringing ex-Sirona
> back to "Commons" (or contributing your code to Romain's
> Sirona fork), and I'm afraid that nothing else will be
> added to that component (or: where is the plan?).
>
> Best,
> Gilles
>
> > On April 9, 2018 at 08:53:13, Otto Fowler (ottobackwards@xxxxxxxxx)
> > wrote:
> >
> > There has been no comment, do we need an explicit vote?
> >
> >
> > On April 3, 2018 at 09:27:56, Otto Fowler (ottobackwards@xxxxxxxxx)
> > wrote:
> >
> > So do we need a vote? What is next to move this forward?
> >
> >
> > On March 28, 2018 at 14:51:55, Otto Fowler (ottobackwards@xxxxxxxxx)
> > wrote:
> >
> > OK, sounds fine to me. Hopefully we’ll get some buy in and can move
> > forward.
> > I’m not sure what is next though ;)
> >
> >
> >
> > On March 28, 2018 at 13:17:22, Gary Gregory (garydgregory@xxxxxxxxx)
> > wrote:
> >
> > On Wed, Mar 28, 2018 at 11:14 AM, Otto Fowler
> > <ottobackwards@xxxxxxxxx>
> > wrote:
> >
> >> How about commons-timing, having StopWatch, StackWatch and other
> >> classes
> >> that
> >> we can find?
> >>
> >
> > I think we start small with only what we need and have today, namely
> > these
> > two classes.
> >
> > Gary
> >
> >
> >>
> >>
> >>
> >> On March 20, 2018 at 18:40:05, Romain Manni-Bucau
> >> (rmannibucau@xxxxxxxxx)
> >> wrote:
> >>
> >> I would be happy to revive sirona @asf but dont think [monitoring]
> >> as just
> >> a few classes would bring enough value compare to a lambda not
> >> worthing
> > any
> >> lib/dep in apps - just my opinion indeed.
> >>
> >> For circuit breaker: geronimo safeguard can be interested in hosting
> >> that
> >> utility part and drop failsafe dependency. Maybe something to
> >> discuss in
> >> another thread.
> >>
> >> Le 20 mars 2018 23:27, "Otto Fowler" <ottobackwards@xxxxxxxxx> a
> >> écrit :
> >>
> >> > Sirona is gone, it is a closed incubator project. Romain has
> >> forked it
> > to
> >> > his own repo.
> >> >
> >> >
> >> >
> >> > On March 20, 2018 at 18:24:06, Gilles
> >> (gilles@xxxxxxxxxxxxxxxxxxxxx)
> >> > wrote:
> >> >
> >> > On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> >> > > If monitoring was started a new, and not re-viving the old
> >> > > monitoring?
> >> >
> >> > Can the feature be contributed to "Sirona"? Otto, are you
> >> > interested in this?
> >> > Does it make sense to have "Commons Monitoring" revived based
> >> > on part/all of "Sirona"?
> >> > Romain, are you interested in this?
> >> > What would be the scope/description of "Commons Monitoring"?
> >> >
> >> > Noting Romain's experience that the original "Commons" project
> >> > evolved into "Sirona", it would be strange to start from scratch
> >> > without a plan to not follow the same route again...
> >> >
> >> > Gilles
> >> >
> >> > > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> >> > > brunodepaulak@xxxxxxxxxxxx.invalid) wrote:
> >> > >
> >> > > I think StopWatch and CircuitBreakers could be moved together to
> >> the
> >> > > same
> >> > > component. However, a circuit breaker can be time-related, or
> >> not
> >> > > (e.g. a
> >> > > circuit breaker for memory size). So probably commons-timing
> >> could be
> >> > > a
> >> > > good place for StopWatch, but maybe not for circuit-breaker. But
> >> I
> >> > > think
> >> > > both could be under commons-monitoring perhaps?
> >> > >
> >> > > From: Otto Fowler <ottobackwards@xxxxxxxxx>
> >> > > To: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>; Commons
> >> Developers
> >> > > List <
> >> > > dev@xxxxxxxxxxxxxxxxxx>
> >> > > Sent: Wednesday, 21 March 2018 10:30 AM
> >> > > Subject: Re: [DISCUSS] new component for timing?
> >> > >
> >> > > I would love to get this on track. I apologize if I have made it
> >> > > more
> >> > > confusing than it needs to be,
> >> > > I’m trying to be open to all the suggestions.
> >> > >
> >> > > If we assume that stack watch is worth ‘having’, then the
> >> question is
> >> > > where
> >> > > to put it.
> >> > > commons-monitoring / sirota seems to me to be a ‘complete’
> >> solution
> >> > > as
> >> > > opposed to
> >> > > a set of or collection of like classes.
> >> > >
> >> > > Setting the community support / project aspect of sirota aside,
> >> it
> >> > > seems
> >> > > strange to put
> >> > > a separate class into a more complete and uniform system. Unless
> >> > > there is
> >> > > some generically
> >> > > useful set of timing utility classes that could be taken out of
> >> > > sirota to
> >> > > go into commons-????,
> >> > > along with things identified ( StopWatch?) out of commons lang
> >> and
> >> > > possibly
> >> > > other commons projects.
> >> > >
> >> > > commons-timing seems reasonable. Thoughts?
> >> > >
> >> > >
> >> > >
> >> > > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> >> > > (rmannibucau@xxxxxxxxx)
> >> > > wrote:
> >> > >
> >> > > Yes but consequence was a lack of community increase which is a
> >> > > killer for
> >> > > an incubator project on the long run.
> >> > >
> >> > > Le 17 mars 2018 15:19, "Gilles" <gilles@xxxxxxxxxxxxxxxxxxxxx> a
> >> > > écrit :
> >> > >
> >> > >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >> > >>
> >> > >>> Le 17 mars 2018 11:49, "Gilles" <gilles@xxxxxxxxxxxxxxxxxxxxx>
> >> a
> >> > >>> écrit :
> >> > >>>
> >> > >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> >> > >>>
> >> > >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler
> >> <ottobackwards@xxxxxxxxx>:
> >> > >>>>
> >> > >>>> If we can come to consensus on the way forward, I’ll be happy
> >> to
> >> > >>>> do the
> >> > >>>>
> >> > >>>>> work ( although I’ll need help of course ).
> >> > >>>>> I guess I’m the straw that broke the camel’s back then? ;)
> >> > >>>>>
> >> > >>>>>
> >> > >>>>>
> >> > >>>>>
> >> > >>>>> On March 15, 2018 at 08:09:45, Gilles
> >> > >>>>> (gilles@xxxxxxxxxxxxxxxxxxxxx)
> >> > >>>>> wrote:
> >> > >>>>>
> >> > >>>>> Hi.
> >> > >>>>>
> >> > >>>>> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> >> > >>>>> > I think bringing back commons-monitoring/sirota would only
> >> be
> >> > >>>>> > possible if
> >> > >>>>> > it were to be modular enough that you could bring in the
> >> ‘core’
> >> > >>>>> > classes
> >> > >>>>> > without needing to bring in all of what sirota ended up
> >> being,
> >> > >>>>> which
> >> > >>>>> > was an
> >> > >>>>> > end to end solution.
> >> > >>>>>
> >> > >>>>> Isn't it possible? [I didn't look; Romain should tell
> >> whether he
> >> > >>>>> would be interested in taking that route.]
> >> > >>>>>
> >> > >>>>>
> >> > >>>>> Sirona was done modular, just the API, the in memory part,
> >> etc...
> >> > >>>> But this kind of impl needs way more just after so not sure
> >> it
> >> > >>>> does
> >> > > worth
> >> > >>>> splitting it to put it back altogether after.
> >> > >>>>
> >> > >>>> What is the rational to try to push a very small part
> >> @commons
> >> > >>>> instead
> >> > > of
> >> > >>>> creating a community @incubator with an E2E solution? This is
> >> what
> >> > >>>> I
> >> > > fail
> >> > >>>> to see.
> >> > >>>> My experience - coming exactly from here - tends to make me
> >> think
> >> > > commons
> >> > >>>> will not fit very long or will not bring enough value pretty
> >> > >>>> quickly
> >> > > but
> >> > >>>> that's just my opinion.
> >> > >>>>
> >> > >>>>
> >> > >>> Not "just" an opinion since you evoke Sirona's precursor as
> >> being
> >> > >>> the kind of component we'd reinstate. Unless we learn
> >> > >>> 1. why the precursor needed to become TLP, and
> >> > >>> 2. why the TLP didn't succeed,
> >> > >>> we'd go in circles.
> >> > >>>
> >> > >>>
> >> > >>> We failed at community@asf and pby communication/promotion
> >> levels I
> >> > >>> think.
> >> > >>> Other parts were successful (prod etc).
> >> > >>>
> >> > >>>
> >> > >> [It seems that part of your message went missing.]
> >> > >>
> >> > >> Lack of marketing skills should not entail failure, especially
> >> > >> not since communication is a transverse concern.
> >> > >>
> >> > >> Gilles
> >> > >>
> >> > >> Would it make sense that Sirona becomes (again?) "Commons
> >> > >> Monitoring"?
> >> > >>> Does the "StackWatck" (Otto's contribution that started this
> >> > >>> discussion)
> >> > >>> already exist in a Sirona module? If not, can it be done, so
> >> that
> >> > >>> usage
> >> > >>> is similar to what Otto had in mind?
> >> > >>>
> >> > >>> Regards,
> >> > >>> Gilles
> >> > >>>
> >> > >>>
> >> > >>> commons-monitoring or commons-timing seem to be the correct
> >> thing
> >> > >>>>
> >> > >>>>> > however,
> >> > >>>>> > but I would like to think that there would be more impetus
> >> > >>>>>
> >> > >>>>> I'm afraid that it's rather the lack of manpower.
> >> > >>>>> [And my inner conviction is that that state of things often
> >> > >>>>> led to rush to cramming more code into existing components,
> >> > >>>>> rather than "distribute" more uniformly according to subject
> >> > >>>>> matters. When scarce human resources ("community")
> >> disappear,
> >> > >>>>> cruft accumulates, sometimes up to stifle clean-up,
> >> maintenance,
> >> > >>>>> improvement, and even development.]
> >> > >>>>>
> >> > >>>>> > to do this than
> >> > >>>>> > thinking StackWatch is ‘too big’ for lang.time.
> >> > >>>>>
> >> > >>>>> It isn't any more than many other functionalities that were
> >> > >>>>> introduced but shouldn't have been.
> >> > >>>>> Depending on what the "Commons" PMC wants to favour ("code"
> >> > >>>>> *or* "community"?), the choice is between continuing with
> >> the
> >> > >>>>> accumulation, or back-pedaling through the creation of as
> >> > >>>>> many *real* components as they are developers willing to
> >> > >>>>> maintain them.
> >> > >>>>>
> >> > >>>>> > It really isn’t that complicated a thing.
> >> > >>>>>
> >> > >>>>> Sure.
> >> > >>>>> The issue is somewhere else.
> >> > >>>>> Note that, personally, I hadn't imagined that there would
> >> > >>>>> be an issue for regular developers of [Lang] (or I wouldn't
> >> > >>>>> have spent time reviewing the "details" ;-).
> >> > >>>>> But I of course agree that the question should be asked; the
> >> > >>>>> more so that, with [Math], we've a striking example of what
> >> > >>>>> awaits a library that lacks boundary checks and explicit
> >> > >>>>> road map.
> >> > >>>>>
> >> > >>>>> Regards,
> >> > >>>>> Gilles
> >> > >>>>>
> >> > >>>>> > On March 8, 2018 at 11:50:17, Gilles
> >> > >>>>> (gilles@xxxxxxxxxxxxxxxxxxxxx)
> >> > >>>>> > wrote:
> >> > >>>>> >
> >> > >>>>> > On Thu, 08 Mar 2018 16:03:24 +0000, Gary Gregory wrote:
> >> > >>>>> >> -1 to "commons-misc". It feels to me like a copout and
> >> > >>>>> unfocused
> >> > >>>>> >> like
> >> > >>>>> >> SomethingUtils.
> >> > >>>>> >> We need a proper home.
> >> > >>>>> >
> >> > >>>>> > +1
> >> > >>>>> >
> >> > >>>>> >> How about the idea of commons-measure.
> >> > >>>>> >
> >> > >>>>> > Just because the first feature would happen to be a timer?
> >> > >>>>> > What other content do you foresee?
> >> > >>>>> >
> >> > >>>>> >> Then there
> >> > >>>>> >> still the idea of resurrecting other Apache projects.
> >> Kind of
> >> > >>>>> going
> >> > >>>>> >> in
> >> > >>>>> >> circles...
> >> > >>>>> >
> >> > >>>>> > Indeed, IIRC the questions were asked (whether the feature
> >> > >>>>> could
> >> > >>>>> > be contributed to ex-Sirona and whether that project would
> >> be
> >> > >>>>> > repatriated to "Commons") but not answered (unless I'm
> >> > >>>>> mistaken)...
> >> > >>>>> >
> >> > >>>>> > Best,
> >> > >>>>> > Gilles
> >> > >>>>> >
> >> > >>>>> >
> >> > >>>>> >> Gary
> >> > >>>>> >>
> >> > >>>>> >> On Mar 8, 2018 08:58, "Otto Fowler"
> >> <ottobackwards@xxxxxxxxx>
> >> > > wrote:
> >> > >>>>> >>
> >> > >>>>> >> So, could think about commons-misc or something?
> >> > >>>>> >> I don’t think we are going to come up with a perfect
> >> module
> >> > >>>>> for
> >> > >>>>> >> these
> >> > >>>>> >> things.
> >> > >>>>> >>
> >> > >>>>> >> Maybe the way it can work is:
> >> > >>>>> >>
> >> > >>>>> >> commons-misc exists.
> >> > >>>>> >>
> >> > >>>>> >> It is the landing place for things that seem to be
> >> outside the
> >> > > scope
> >> > >>>>> >> of
> >> > >>>>> >> commons-xxxx, but don’t justify
> >> > >>>>> >> a new module or sandbox effort.
> >> > >>>>> >>
> >> > >>>>> >> Things in misc can be reevaluated for inclusion in new
> >> modules
> >> > >>>>> at
> >> > >>>>> >> things
> >> > >>>>> >> go, and at that point @Depricated
> >> > >>>>> >> out of misc.
> >> > >>>>> >>
> >> > >>>>> >> ?
> >> > >>>>> >>
> >> > >>>>> >>
> >> > >>>>> >>
> >> > >>>>> >> On March 3, 2018 at 00:42:12, Matt Sicker
> >> (boards@xxxxxxxxx)
> >> > >>>>> wrote:
> >> > >>>>> >>
> >> > >>>>> >> On 2 March 2018 at 13:31, Oliver Heger
> >> > >>>>> >> <oliver.heger@xxxxxxxxxxxxxxx>
> >> > >>>>> >> wrote:
> >> > >>>>> >>>
> >> > >>>>> >>> One other suggestion: It was stated in the past that the
> >> > > concurrent
> >> > >>>>> >>> classes are also a bit out of scope for [lang],
> >> especially
> >> > >>>>> the
> >> > >>>>> >>> circuit
> >> > >>>>> >>> breaker implementations. Would it make sense to move
> >> those
> >> > >>>>> into a
> >> > >>>>> >>> new
> >> > >>>>> >>> module, and could this be a home for the watch classes,
> >> too?
> >> > >>>>> >>>
> >> > >>>>> >>
> >> > >>>>> >> Considering the amount of retry libraries there are out
> >> there,
> >> > >>>>> I
> >> > >>>>> >> think it
> >> > >>>>> >> makes perfect sense for circuit breaker libraries to be
> >> their
> >> > >>>>> own
> >> > >>>>> >> thing,
> >> > >>>>> >> too. See Hysterix for example.
> >> > >>>>> >>
> >> > >>>>> >> --
> >> > >>>>> >> Matt Sicker <boards@xxxxxxxxx>
> >> > >>>>>
> >> > >>>>>
> >> >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> >> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
>
>