commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/
Date Tue, 24 Jun 2014 09:17:31 GMT
Hi Sebb,

saw you reverted few parts,

can you give us a status and say me if I can help cleaning up what remains?

Thanks,



Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-06-19 22:35 GMT+02:00 Romain Manni-Bucau <rmannibucau@gmail.com>:

> Currently far from a computer (holidays) so if you cant wait go for it
> otherwise it is on my todo list for the beginning of next month
>
> Le jeudi 19 juin 2014, sebb <sebbaz@gmail.com> a écrit :
>
> > On 3 June 2014 23:29, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
> >> Hmm, any advice to revert it without loosing next changes and passing
> too
> >> long to reapply them (some are important)?
> >
> > Please can you revert the change now?
> > This has been outstanding far too long.
> >
> > If you want me to do it, just let me know.
> >
> >> Actually it was not combining different things, both were related to
> >> scalability and performances.
> >
> > Those are both general concepts and can be applied to lots of different
> changes.
> >
> >>
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >> 2014-06-04 0:23 GMT+02:00 sebb <sebbaz@gmail.com>:
> >>
> >>> Apart from the unresolved issue of logging, I still think the commit
> >>> should be reverted because it combines two completely different
> >>> changes.
> >>>
> >>> Please can you revert the commit ASAP?
> >>>
> >>> On 2 June 2014 18:09, sebb <sebbaz@gmail.com> wrote:
> >>> > On 2 June 2014 16:11, Romain Manni-Bucau <rmannibucau@gmail.com>
> wrote:
> >>> >> First about immutabilit thread safety etc: we can use final if
it
> ends
> >>> the
> >>> >> topic, it was not cause first version was a field and not a
> constant and
> >>> >> serializable but now it can be final.
> >>> >>
> >>> >> Then about isDebugEnabled: overhead is quite important compared
to a
> >>> simple
> >>> >> boolean test. Most of the time it is not important but for a caching
> >>> >> solution (in particular in memory mode) it is impacting since it
is
> done
> >>> >> very often.
> >>> >>
> >>> >> To be convinced of it just debug log4j (1.2) impl for instance.
> Really
> >>> >> depends the config too but basically you'll end up checking
> repository
> >>> >> level + potentially browse all logger categories. If config is
well
> >>> done no
> >>> >> by overhead by if not that's really too much. If you take JUL that's
> >>> worse.
> >>> >> isDebugEnabled is fast but then log invocation has more check
> (record,
> >>> >> filter, handlers at least). Actually I think we can do further
> >>> proposing a
> >>> >> JCS property "verbose" and get rid of logger level for these cases.
> We
> >>> can
> >>> >> add a shared MBean to on/off it then.
> >>> >>
> >>> >>
> >>> >> wdyt?
> >>> >
> >>> > I think we need more proof that some kind of caching really is
> needed.
> >>> >
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> Romain Manni-Bucau
> >>> >> Twitter: @rmannibucau
> >>> >> Blog: http://rmannibucau.wordpress.com/
> >>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>> >> Github: https://github.com/rmannibucau
> >>> >>
> >>> >>
> >>> >> 2014-06-02 16:27 GMT+02:00 Phil Steitz <phil.steitz@gmail.com>:
> >>> >>
> >>> >>> On 6/1/14, 6:01 PM, Bernd Eckenfels wrote:
> >>> >>> > Am Sun, 1 Jun 2014 23:43:10 +0100
> >>> >>> > schrieb sebb <sebbaz@gmail.com>:
> >>> >>> >
> >>> >>> >> On 1 June 2014 20:19, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> >>> >>> >> wrote:
> >>> >>> >>> well it is for sure thread safe. Not sure I get
why final and
> synch
> >>> >>> >>> would be mandatory in this particular case (field
will maybe be
> >>> >>> >>> cached by thread but that's not an issue since
the value will
> be
> >>> >>> >>> unique).
> >>> >>> >> non-final fields are not guaranteed to be published
across
> threads
> >>> in
> >>> >>> >> the absence of sync.
> >>> >>> > The two fields wont change, so there is no need for publishing
> >>> changes.
> >>> >>> > So they dont need to be volatile. They could be made however
> final to
> >>> >>> > make it clearer that they will not change (but IMHO this
does not
> >>> make
> >>> >>> > them more or less thread safe).
> >>> >>>
> >>> >>> Right, except that the logger is itself mutable and it looks
like
> >>> >>> clients hold onto references to it.   What I don't get is why
it is
> >>> >>> so much faster to add the overhead of the helper just to avoid
a
> >>> >>> call to logger.isDebugEnabled().  I would expect that to return
> just
> >>> >>> as fast as the LOG_HELPER inspecting its (even cached) boolean.
> >>> >>> What am I missing?
> >>> >>>
> >>> >>> Phil
> >>> >>> >
> >>> >>> > I feel indifferent about beeing able to turn off trace/debug
by
> >>> >>> > overwriting the underlying logger. If we are really so
logger
> >>> >>> > agnostic it is probably a good idea. At least when
> commons-logging is
> >>> >>> > not able to abstract this shortcoming away.
> >>> >>> >
> >>> >>> > Gruss
> >>> >>> > Bernd
> >>> >>> >
> >>> >>> >
> ---------------------------------------------------------------------
> >>> >>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> >>> > For additional commands, e-mail: dev-help@commons.apache.org
> >>> >>> >
> >>> >>> >
> >>> >>>
> >>> >>>
> >>> >>>
> ---------------------------------------------------------------------
> >>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>> >>>
> >>> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> --
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>

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