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 <rmannibu...@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 <seb...@gmail.com> a écrit : > > > On 3 June 2014 23:29, Romain Manni-Bucau <rmannibu...@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 <seb...@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 <seb...@gmail.com> wrote: > >>> > On 2 June 2014 16:11, Romain Manni-Bucau <rmannibu...@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.ste...@gmail.com>: > >>> >> > >>> >>> On 6/1/14, 6:01 PM, Bernd Eckenfels wrote: > >>> >>> > Am Sun, 1 Jun 2014 23:43:10 +0100 > >>> >>> > schrieb sebb <seb...@gmail.com>: > >>> >>> > > >>> >>> >> On 1 June 2014 20:19, Romain Manni-Bucau <rmannibu...@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-unsubscr...@commons.apache.org > >>> >>> > For additional commands, e-mail: dev-h...@commons.apache.org > >>> >>> > > >>> >>> > > >>> >>> > >>> >>> > >>> >>> > --------------------------------------------------------------------- > >>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> >>> > >>> >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@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 > >
