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 Thu, 19 Jun 2014 20:35:14 GMT
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