trace vs log.isTraceEnabled
by Mircea Markus
Hi,
I'm not aware of any convention on using trace vs log.isTraceEnabled() to guard the trace statements.
if (trace) log.trace("some request related stuff")
vs
if (log.isTraceEnabled()) log.trace("some request related stuff");
The former is more efficient, but cannot be managed at runtime. It seems to be the preferred form, so shall we stick with it?
Cheers,
Mircea
13 years, 11 months
Time measurement and expiry
by Elias Ross
Rather than a heap, I recall Netty had a hash wheel timer[1]. Which should
be better performing than a heap. You could get clever by having
multiple heaps, segmented by orders of magnitude. For example wheel 1
could have < 1 minute, 2 < 1 hour etc. Netty uses a lot of short lived
timers and performs well.
[1] http://docs.jboss.org/netty/3.1/api/org/jboss/netty/util/HashedWheelTimer...
Obviously this uses some memory, but you could probably optimize it
somewhat to only work with Node instances.
14 years
user concerned about lack of "high performance" CacheLoaders
by Sanne Grinovero
Via twitter and Hibernate forums, @astralbodies seems to be doing some
interesting high performance *writing* stuff with Hibernate Search,
but in his experience Hibernate Search on disk is pretty fast, not so
the Search + Infinispan combination.
http://twitter.com/#!/practicallyUX/statuses/126774913884360704
In my own tests, we are quite faster than Lucene's FSDirectory even
while this uses MMap and NIO tricks, but indeed writing to a sync
CacheLoader will slow it down significantly, and since the performance
battle was won by a small margin only (close to 3X); I never recommend
a cacheloader in sync, but async introduces some limitations too (most
notably ISPN-1174, which can lead to critical errors with Lucene).
background, actually an interesting read:
https://forum.hibernate.org/viewtopic.php?f=9&t=1013032
Besides pointing out the Cassandra CacheLoader, I think that at some
point we should spend some time tuning & testing the FS CacheLoader to
remove it's "experimental" flag and actually suggest using it.
Sanne
14 years
Time measurement and expiry
by Sanne Grinovero
Hi all,
I'm looking at some performance details, and noticed the current code
is using System.currentTimeMillis() to estimate performance for short
lived operations.
For the purpose of CacheMgmtInterceptor we should use System.nanoTime() instead:
http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks
Searching for "currentTimeMillis()" in the code base reveals it's
being used for expiry of entries as well. If someone messes with
system clocks data will expire; is it expected that entries expire at
calendar time and not at a set lifetime?
I understand we need to use the absolute time to be able to transmit
the value to other nodes, where the nanoTime of different nodes might
not be comparable, but we could store one and use both: transmit the
absolute value only to other nodes and refer to the other for accurate
expiries.
Other nodes receiving the absolute value will check for the remaining
lifespane and store the corresponding nanoTime.
ExpiryHelper itself will invoke the currentTimeMillis() operation
internally, that means that it's going to be invoked at least once for
each entry being accessed and might result in a lot of invocations
when traversing several entries; I'm wondering if it shouldn't take a
millisecond parameter to consider as current, so that this relatively
expensive method can be invoked only once at the beginning of a batch
of operations.
Also reading this time information is a high overhead in some
configurations, I'm wondering if we should make it possible to
configure Infinispan to not track performance on each cache operation?
Someone might prefer to estimate an average from multiple calls; I'm
going to remove CacheMgmtInterceptor for my tests.
Sanne
14 years
Refactoring API and Commons
by Tristan Tarrant
Hi all,
I've been looking into refactoring certain interfaces and common classes
as part of https://issues.jboss.org/browse/ISPN-1490
I have come across a couple of snags (more will come I'm sure).
Firstly all modules use org.infinispan.util.logging.LoggingFactory to
get a logger. Unfortunately the logger in question implements the
org.infinispan.util.logging.Log interface which contains a ton of
logging methods mostly related to core functionality, and therefore
irrelevant for things such as the remote APIs. My suggestion here is
that each module either uses a specialized LoggingFactory or create a
common one which returns implementations of BasicLogger (which is the
root interface of our Logs).
Another one is related to org.infinispan.util.FileLookupFactory which
references OSGi classes, even though the org.osgi dependency is marked
as optional in the infinispan-core POM. In my opinion the OsgiFileLookup
should be put in an external class and loaded via reflection so that we
don't get NoClassDefFoundErrors.
I've also introduced at the API level a BasicCache<K,V> which now
Cache<K,V> extends. BasicCache<K,V> knows nothing about Lifecycle,
Listenable, AdvancedCache, Configuration, eviction, batching and is
intended to be the base for the RemoteCache<K,V> interface.
Suggestions, recommendations, etc.
Tristan
14 years
Infinispan 5.1.0.BETA4 plan
by Galder Zamarreño
We ain't finished yet with the BETA releases for the 5.1 series.
Pete's new XML configuration, Manik's versioned API, and Mircea's further locking improvements are still to come.
We have planned for BETA4 to be out on 7th of November, so please bear that in mind.
Also, a few of us will be presenting next week in JUDCon (http://www.jboss.org/events/JUDCon/2011/london/agenda), so we're likely to be busy preparing for that.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years
Reminders about GIT
by Sanne Grinovero
1) If you have warnings about "Merge made by recursive" you have to
fix it rebasing.
2) If you have warnings about "non-fast-forward" you have to rebase.
3) If you see "non-fast-forward updates were rejected" you shall never
use "force" on upstream! It means that another patch was merged before
you and you have to update your master again, and rebase again.
4) "force" is allowed only in special maintenance circumstances. If
you find you're needing it to handle a pull request, then you're doing
it wrong, and the mistake might be a dangerous one. It's like the good
rule of never commit when you're drunk (coding is allowed).
14 years
Abstracting javax.cache.annotation.CacheKey away from the user?
by Galder Zamarreño
Pete/Kevin,
Looking at the Infinispan CDI quickstart, I see:
@GreetingCache
private Cache<CacheKey, String> cache;
The key that the user really uses here is String. So, could that be defined like this?
@GreetingCache
private Cache<String, String> cache;
Btw, I've just tried this and when using the key I get:
Caused by: java.lang.ClassCastException: org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to java.lang.String
Are we forcing the user to dephicer what's in CacheKey? Related to this, looking at org.infinispan.cdi.interceptor.DefaultCacheKey I see no way to retrieve individual elements of a key.
My point here is whether we can avoid leaking javax.cache.annotation.CacheKey to the user cos it can do little with it without being able to get its contents.
I see there;s a way to define a custom key, but that should not be necessary for a simple key based on a String for example.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years
