Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

The performance problem that this trick is meant to resolve is really a problem in the logging backend. It *should* be faster inside of WildFly, where JBoss LogManager is used, because that project just checks a single volatile field for the level check... and the path to that code *should*

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

this discussion appears on this mailing list approximately every 2 years :) On 30 September 2016 at 13:41, Dan Berindei wrote: > I should stress that we only cache `isTraceEnabled()` in a static > field. Debug logging can still be enabled or disabled on the fly. > > >

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

I should stress that we only cache `isTraceEnabled()` in a static field. Debug logging can still be enabled or disabled on the fly. Cheers Dan On Fri, Sep 30, 2016 at 3:14 PM, Wolf Fink wrote: > Ok, > > thanks for clarifying it. > > So there is a factor of 3 for the test if

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

Hey David! It's Java Util Logging (so the JDKLogger implementation). Thanks Sebastian On Fri, Sep 30, 2016 at 1:53 PM, David M. Lloyd wrote: > On 09/30/2016 01:53 AM, Sebastian Laskawiec wrote: > > Hey! > > > > A while ago I asked Radim and Dan about these kind of

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

Ok, thanks for clarifying it. So there is a factor of 3 for the test if no trace is enabled, just for checking. It makes sense to use it. But my concern is still that it is sometimes good to have the possibility to enable debug for some important information in production just on the fly and

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

On 09/30/2016 01:53 AM, Sebastian Laskawiec wrote: > Hey! > > A while ago I asked Radim and Dan about these kind of constructs [1]: > > private boolean trace = logger.isTraceEnabled(); //stored in a field > > ... called in some method ... > if(trace) > logger.tracef(...); > ... > > At

Re: [infinispan-dev] Hot Rod testing

> > > > I wonder if something like Haxe [1] could help here in defining a language > agnostic > TCK (maybe an skeleton?) that gets compiled to several platforms. Each > platform's > testsuite would them "implement" the spec and of course would be free to > add > 'native' tests as well. There's

Re: [infinispan-dev] Hot Rod testing

Hi all, > - for each Hot Rod operation and variant (e.g. flags, metadata) the > client is sending the correct request. > - the client should also be able to correctly process the response, > again with different variations (result, not found, errors, metadata) > - for the different client

Re: [infinispan-dev] Hot Rod testing

On Fri, Sep 30, 2016 at 9:40 AM, Tristan Tarrant wrote: > On 23/09/16 17:33, Galder Zamarreño wrote: > > ^ I thought about all of this when working on the JS client, and > although like you, I thought this was the biggest hurdle, eventually I > realised that there are bigger

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

Yes, exactly - Radim is correct. I added also one test - "if(logger.isTraceEnabled()) logger.trace(...)". The results look like the following: Benchmark Mode Cnt Score Error Units MyBenchmark.noVariable thrpt 20 725265655.062 ± 1777607.124

Re: [infinispan-dev] Hot Rod testing

On 23/09/16 17:33, Galder Zamarreño wrote: > ^ I thought about all of this when working on the JS client, and although > like you, I thought this was the biggest hurdle, eventually I realised that > there are bigger issues than that: > > 1. How do you verify that a Javascript client works the

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

Wolf, the isTraceEnabled() is called only once during class initialization (if that's a static field) or instance creation, but it is usually stored as final field and therefore the JVM is likely to optimize the calls. It's possible to change final fields, and in this case it's not as unsafe

Re: [infinispan-dev] Hot Rod testing

On Fri 2016-09-23 17:33, Galder Zamarreño wrote: >Maybe some day we'll have a Java-based testsuite that more easily allows >continous testing. Scala, through SBT, do have something along this lines, so >I don't think it's necessarily impossible, but we're not there yet. And, as I >said above,

Re: [infinispan-dev] Hot Rod testing

>> 1. How do you verify that a Javascript client works the way a Javascript >> program would use it? >> IOW, even if you could call JS from Java, what you'd be verifying is that >> whichever contorsionate way of calling JS from Java works, which might not >> necessarily mean it works when a real

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

I understand the impact of this, but we should keep in mind that there are some important points where it is worse if you can't change the logging on the fly for a few moments to check something and switch back. For the test my understanding is that you use - the logger.tracef direct - check

[infinispan-dev] if (trace) logger.tracef - it makes sense

Hey! A while ago I asked Radim and Dan about these kind of constructs [1]: private boolean trace = logger.isTraceEnabled(); //stored in a field ... called in some method ... if(trace) logger.tracef(...); ... At first they seemed wrong to me, because if one changes logging level