CacheLoaderManagerImpl.preload() put calls
by Galder Zamarreno
Hi,
Re: http://community.jboss.org/message/521810#521810
I'm looking at this and thinking, do we want preloading put calls to go
remote? Shouldn't put calls in CacheLoaderManagerImpl.preload() be
putForExternalRead() or similar?
I know that this happens during cache startup and that hence the cache
shouldn't be dealing with requests as it's not yet started, so there
shouldn't be lock timeouts on the local machine at least.
However, not sure about going remote with this call.
Something that's odd here as well is this:
2010-01-22 12:53:13,596 TRACE {main} [o.i.r.t.j.JGroupsTransport:12]
dests=null, command=SingleRpcCommand{cacheName='isd-source',
command=PutKeyValueCommand{key=cle03, value=value03, putIfAbsent=false,
lifespanMillis=-1, maxIdleTimeMillis=-1}}, mode=ASYNCHRONOUS, timeout=15000
2010-01-22 12:54:13,605 ERROR {main} [o.i.r.r.RpcManagerImpl:111]
unexpected error while replicating
java.util.concurrent.TimeoutException: Timed out waiting for a
cluster-wide sync to be released. (timeout = 60 seconds)
at
org.infinispan.remoting.transport.jgroups.JGroupsDistSync.blockUntilReleased(JGroupsDistSync.java:51)
[infinispan-core-4.0.0-SNAPSHOT.jar:4.0.0-SNAPSHOT]
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:397)
[infinispan-core-4.0.0-SNAPSHOT.jar:4.0.0-SNAPSHOT]
The call is clearly syncrhonous but the mode printed says ASYNCHRONOUS?
I'll see if I can create a test for the ASYNCHRONOUS bit.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 8 months
Implementing Hot Rod using Google Protocol Buffers?
by Galder Zamarreno
Hi,
In a previous email, Bela suggested having a look at Google Protocol
Buffers for implementing Hot Rod.
I had a brief look at Google Protocol Buffers and at first glance, the
most obvious advantage is that it abstract the lower level protocol
details and generate higher level code in different languages: Java,
C++, Python.
Another thing I've noted is that it does seem to handle different
versions of the protocol in a transparent way, as indicated in "A bit of
history" section in
http://code.google.com/apis/protocolbuffers/docs/overview.html
Once we're all happy with the protocol itself, I think it might be worth
doing a small prototype for example with a put operation and an a
cluster formation event and see how it works.
What do people think? Anyone with Google Protocol Buffers experience
that could provide us with 1st hand advice?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 8 months
Expiration does not work for Initially loaded Entries
by Amin Abbaspour
Hi,
Those keys loaded initially from CacheLoader via loadAll method do not
obey expiration rules unless they are modified. Just after first
change they expire following lifespan and maxIdle values.
Regards,
Amin
15 years, 8 months
Cache Entry is Loaded two times from CacheLoader
by Amin Abbaspour
Hi All,
I put some log in my CacheLoader and noticed that when some key
expires, the load(key) method (in the case of LockSupportCacheStore
loadLockSafe method) in CacheLoader is called two times
consequentially for the same key.
Of course this creates no logical issues but is not much welcomed from
performance point of view.
Regards,
Amin
15 years, 8 months
Rethinking asynchronism in Infinispan
by Manik Surtani
So I've been spending some time thinking about how we deal with async tasks in Infinispan, both from an API perspective as well as an implementation detail, and wanted to throw a few ideas out there.
First, lets understand the 4 most expensive things that happen in Infinispan, either simply expensive or things that could block under high contention (in descending order): RPC calls, marshalling, CacheStore and locking.
We deal with asynchronism in a somewhat haphazard way at the moment, each of these functions receiving a somewhat different treatment:
1) RPC: Using JGroups' ResponseMode of waiting for none.
2) Marshalling: using an async repl executor to take this offline
3) Use an AsyncStore wrapper which places tasks in an executor
4) Nothing
and to add to it,
5) READs are never asynchronous. E.g., no such thing as an async GET - even if it entails RPC or a CacheStore lookup (which may be a remote call like S3!)
The impact of this approach is that end users never really get to benefit from the general asynchronism in place, and still needs to configure stuff in several different places. And internally, it makes dealing with internal APIs hard.
Externally, this is quite well encapsulated in the Cache interface, by offering async methods such as putAsync(), etc. so there would be little to change here. They return Futures, parameterized to the actual method return type, e.g., putAsync returns Future<V> in a parameterized Cache<K, V>. (More precisely, they return a NotifyingFuture, a sub-interface of Future that allows attaching listeners, but that's a detail.)
So I think we should start with that. The user receives a Future. This Future is an aggregate Future, which should aggregate and block based on several sub-Futures, one for each of the tasks (1 ~ 4) outlined above. Now what is the impact of this? Designing such a Future is easy enough, but how would this change internal components?
1) RPC. Async RPC is, IMO, broken at the moment. It is unsafe in that it offers no guarantees that the calls are received by the recipient, and you have no way of knowing. So RPC should always be synchronous, but wrapped in a Future so that it is taken offline and the Future can be checked for success.
2) Marshalling happens offline at the moment and a Future is returned as it stands, but this could probably be combined with RPC to a single Future since this step is logically before RPC, and RPC relies on marshalling to complete.
3) The CacheStore interface should only return parameterized Futures. Implementations that do not offer any async support may simply return a wrapped value. Calls to this interface that require immediate results would simply poll the Future. But in all other cases - ranging from the AsyncStore wrapper to more sophisticated async backends such as JClouds, we get to harness the async nature offered by the impl.
4) Locking could be async, but understanding context is important here. We currently use 2 different types of Locks: JDK reentrant locks for non-transactional calls, or OwnableReentrantLock for transactional calls where the lock owner is not the thread but instead the GlobalTransaction. For this to work, any invocation context should have reference to the original invoking thread, OwnableReentrantLocks should always be used, and the owner set accordingly, to ensure an Executor thread doesn't gain ownership of a lock instead.
The end result of all this, is that async API calls will be truly non-blocking, and will be able t harness as much parallelism as possible in the system. Another effect is that we'd have a cleaner internal API which is specifically designed with async operations in mind, and converting any of the async calls to sync calls is trivial (Future.get()) anywhere along the invocation chain. Also, I think once we have this in place, any async transport modes (REPL_ASYNC, DIST_ASYNC) should be deprecated in favour of an async API, since you get the ability to check that a call completes even though it happens offline.
And a disclaimer: I have no plans to implement anything like this soon, I was just throwing this out for comment and distillation. :)
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 8 months
Error building Infinispan distribution
by Galder Zamarreno
Hi,
I'm trying to build the Infinispan distribution (-Pdistribution) but I'm
getting the following error:
[WARNING] Removing: aggregate from forked lifecycle, to prevent
recursive invocation.
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [javadoc:aggregate {execution: javadoc}]
[WARNING] POM for 'org.slf4j:slf4j-simple:pom:1.5.8:compile' is invalid.
Its dependencies (if any) will NOT be available to the current build.
[WARNING] POM for 'org.apache.httpcomponents:httpclient:pom:4.0:compile'
is invalid.
Its dependencies (if any) will NOT be available to the current build.
2 errors
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] An error has occurred in JavaDocs report generation:Exit code: 1
- error: error reading
/home/g/.m2/repository/org/apache/httpcomponents/httpclient/4.0/httpclient-4.0.jar;
error in opening zip file
error: error reading
/home/g/.m2/repository/org/slf4j/slf4j-simple/1.5.8/slf4j-simple-1.5.8.jar;
error in opening zip file
Command line
was:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/../bin/javadoc @options
@packages
I've tried to wipe out /home/g/.m2/repository/org/apache/httpcomponents
and /home/g/.m2/repository/org/slf4j/ but I still get same issue. I'm
trying with a different JDK just in case...
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 8 months
