Async Notification API
by Manik Surtani
While the new async API has been getting rave reviews, someone did
bring up async notifications. E.g.,
Future f = cache.putAsync(k, v);
f.get();
But what if I don't want to wait on f.get(), I'd rather be told when
the future is done so I can do an f.get()?
Sounds pretty useful to me. But just wanted to sound you guys on the
API choices for notifications.
My immediate thought was to use the existing notification API. You
register a cache listener, annotate a method with @RpcCallMade,
receive an RpcCallMadeEvent. But this is probably pretty useless,
since you couldn't associate the notification with the specific put
you've just done. Even if you have the key in the event (which is
unlikely - since we need to use the same event for all cache
operations, some which take > 1 key such as putAll()), multiple
threads could be working on the same key.
Another approach is to design a sub-interface to Future.
NotifyingFuture.
public interface NotifyingFuture extends Future {
void addListener(NotifyingFutureListener l);
}
public interface NotifyingFutureListener {
void futureDone(Future f);
}
WDYT?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
Re: [infinispan-dev] config migration scripts
by Manik Surtani
On 18 May 2009, at 21:01, Christophe Hivert wrote:
> Just curious, do you guys have any code review process?
Yes - nothing formal, but before we grant commit access to new
committers I usually ask for patch files for the first few
contributions.
And on an ongoing basis, we usually "request" code reviews especially
on complex features by emailing this list.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
config migration scripts
by Mircea Markus
Hi,
I've just added /src/resources/xslt/jbc3x2infinispan4x.xslt for
migrating config files from JBossCache to Infinispan.
I'll also add the .bat and .sh shortly + a java class to instantiate the
transformer.
Cheers,
Mircea
17 years
Management interface
by Manik Surtani
This is related to
https://jira.jboss.org/jira/browse/ISPN-71
and I'm starting this thread to discuss how we should approach this,
given that Heiko Rupp from the JOPR team's just joined the mail
list. :-)
So here is what I see as a need: a GUI console (probably based on
JOPR) that would:
* provide info on the state of the cluster
* be able to locate entries via some interface
* visualise key statistics of each cluster node - memory consumption,
cache hit/miss ratio, transaction success rate, network-level metrics
such as throughput, etc
* perform management of the cluster - shut down, start nodes
* manage configuration?
The last one is probably optional. The thing to keep in mind is that
cache instances may not run in the same environment as an app server
so even if the console requires an app server, the individual cache
nodes should not. Of course, if the cache is used within an app
server, any advantages that come from that could be made use of, such
as communication of common management information in an app server
cluster for the embedded console.
For starters, Heiko, how does JOPR manage remote instances? Does it
require its own agent to be loaded in each remote VM with its own
communication channel?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
CacheLoader.prepare/commit/rollback
by Mircea Markus
Hi,
Currently the interface of these classes use a
javax.transaction.Transaction parameter:
void prepare(List<? extends Modification> modifications, Transaction tx,
boolean isOnePhase) throws CacheLoaderException;
The problem with this is that Transaction will not exist if this is a
remotely originated call (we only propagate the GlobalTransaction on the
remote nodes).
I've took a look at the CacheStore impls, they do not use any specific
javax.transaction.Transaction logic/methods, but rather use the param as
a key in their internal caches.
Do you see any issues with changing the signature of CacheStore to
replace Transaction param with GlobalTransaction?
Cheers,
Mircea
17 years
Re: JProfiler snapshots for Infinispan+JBMAR
by Galder Zamarreno
Hi David,
Please find attach graphs belonging to two runs that compare:
infinispan-4.0.0(repl-sync) - home grown marshalling layer
infinispan-4.0.0(repl-sync-jbmar) - infinispan + jbmar 1.1.2
infinispan-4.0.0(repl-sync-jbmar)-rXYZ - infinispan + jbmar with revision
Not sure what's the conclusion here tbh. The results of 1.1.2 almost
look opposite in each test.
I've also attached some information from previously run profiling
sessions with a couple of local machines we have in Neuchatel. I
profiled the faster of the two machines.
Actually, looking at this profiled data, these tests are for synchronous
replicated caches but I see no traces of actually reading the stream,
only writing to it, hmmmm.
I'm adding Externalizers to class table and implementing
marshaller/unmarshaller pooling as my next tasks.
Regards,
David M. Lloyd wrote:
> OK, I tried out a few things. You might want to try introducing these
> one at a time (i.e. update up to rev 173, then 174, then 175 and see how
> each one does). In particular, I think 175 has just as much chance of
> slowing things down as speeding them up - either you're getting tons of
> collisions in the hash table or the profiler is skewing the results
> there (maybe try filtering out org.jboss.marshalling.util.IdentityIntMap
> and java.lang.System to see if that gives a different picture).
>
> I feel pretty good about 173 and 174 though I think the profiler will
> skew 173 unless you have that UTFUtils filter installed. If 175 slows
> things down (outside of the profiler), let me know and I'll revert it.
> None of my tests showed much difference but I don't have any good
> benchmarks that really exercise that code right now.
>
> There's a couple things left to try yet, like looking at replacing
> ConcurrentReferenceHashMap (assuming that isn't the profiler again).
>
> ------------------------------------------------------------------------
> r175 | david.lloyd(a)jboss.com | 2009-05-08 00:17:46 -0500 (Fri, 08 May
> 2009) | 1 line
>
> Try a trick to decrease the liklihood of collisions
> ------------------------------------------------------------------------
> r174 | david.lloyd(a)jboss.com | 2009-05-08 00:04:39 -0500 (Fri, 08 May
> 2009) | 1 line
>
> Replacement caching is not economical; the cost is one extra hash table
> get for non-replaced objects, two hash table gets (total) for replaced
> objects. Removing the cache gets rid of the cost for non-replaced
> objects, while replaced objects now have to be replaced again before the
> single hash table hit.
> ------------------------------------------------------------------------
> r173 | david.lloyd(a)jboss.com | 2009-05-07 23:44:52 -0500 (Thu, 07 May
> 2009) | 1 line
>
> JBMAR-52 - Avoid extra copy of char array (1.5 of 2)
> ------------------------------------------------------------------------
>
> - DML
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years
OwnableReentrantLock.currentRequestor
by Mircea Markus
Hi,
this method obtains the lock requestor associated with the current
thread, which ultimately performs an ThreadLocal.get(key).
Can't we pass the lock owner to the lock before acquiring locks to avoid
this lookup map lookup? This would mean some code changes, but I think
we'll gain some performance.
Cheers,
Mircea
17 years
