Ok great, thank you then
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-06-24 12:15 GMT+02:00 sebb <seb...@gmail.com>: > On 24 June 2014 10:17, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Hi Sebb, > > > > saw you reverted few parts, > > > > can you give us a status and say me if I can help cleaning up what > remains? > > AFAIK it has all now been reverted apart from the locking changes that > were documented in the original log message. > > I don't think there is anything left to do on this. > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
