transaction/query/mapreduce over hotrod
by Mircea Markus
Hi,
As there is a high community demand for having these operations in place, and most of these are targeted for post 5.1 releases, I thought about a workaround for having this functionality in place.
I hijacked Hotrod's put operation and added a custom interceptor, so that if a certain object is being "put" into remote cache, the server side interceptor jumps in and runs transactions.
This doesn't look too bad for the user, e.g. for supporting transactions:
RemoteCache rc = getRemoteCache();//from somewhere...
//this is what we'll use for running remote transactions over hotrod
BatchEnabledRemoteCache berc = new BatchEnabledRemoteCache(rc);
berc.startBatch(); //everything from here to endBatch call is a single transaction
berc.put("k", "v1");
berc.put("k2", "v2");
berc.put("k3", "v3");
berc.endBatch(true); // all or nothing!
Of course this won't work with other clients than the java client, but I think most of our users are using that one ATM.
Currently there's only support for transactions but this approach (and the code) can be easily extended to mapreduce and querying.
I added s short description on how this can be used [1], also the source code is available here[2].
What do you think about it? Is it worth suggesting to the users this approach(and possibly the code as well)?
Cheers,
Mircea
[1] https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide
[2]https://github.com/mmarkus/ops_over_hotrod
15 years
Too late for an 5.0 API change?
by Galder Zamarreño
Hi all,
What do people think of changing the addListener() APIs to be more fluent?
We could either:
1. Change Listenable to be Listenable<T> and then have:
<T> addListener(Object listener);
So, implementers such as EmbeddedCacheManager would implement Listenable<EmbeddedCacheManager> and so would implement:
EmbeddedCacheManager addListener(Object listener);
2. Or, more simply, have Listenable define:
Object addListener(Object listener);
and EmbeddedCacheManager using covariants to implement:
EmbeddedCacheManager addListener(Object listener);
Btw, the same would apply to removeListener.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
IllegalStateException when receiving invalidation messages on a stopped/stopping cache
by Sanne Grinovero
Hello,
I was looking into the many stacktraces being thrown from the
testsuite, this one caught my attention (see below).
Can't we just discard such errors? if the cache is stopping, or
stopped already, we shouldn't really care for invalidations -
especially stacktraces and exceptions being returned to the caller.
This doesn't solve all the EOF exceptions I'm still experiencing, but
it seems to make things a bit better.. I've hacked a solution which
implies adding a method:
boolean ignoreCommandOnStatus(ComponentStatus status);
to the VisitableCommand interface, seems to work fine. Shall I open a
JIRA and send a pull request?
Details:
https://github.com/Sanne/infinispan/commit/ed962ed72bc68765078b6a0f172b95...
Cheers,
Sanne
2011-07-14 15:16:20,940 ERROR [RebalanceTask]
(Rehasher,Infinispan-Cluster,NonStringKeyStateTransferTest-NodeC-7649)
ISPN000145: Error during rehash
java.lang.IllegalStateException: Default cache is in 'STOPPING' state
and this is an invocation not belonging to an on-going transaction, so
it does not accept new invocations. Either restart it or recreate the
cache container.
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:83)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:120)
at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:124)
at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:177)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
at org.infinispan.distribution.RebalanceTask.invalidateKeys(RebalanceTask.java:172)
at org.infinispan.distribution.RebalanceTask.performRehash(RebalanceTask.java:145)
at org.infinispan.distribution.RehashTask.call(RehashTask.java:67)
at org.infinispan.distribution.RehashTask.call(RehashTask.java:44)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
15 years
CDI support
by Pete Muir
Kevin has completed this up a pretty good standard, so I think it's ready to merge. Do we want to try to slip this into Infinispan 5? It's a separate module so should have no impact on the rest of the code base. I would label it a tech preview, moving to final status in 5.1 but it will give people a taster.
WDYT?
15 years
Workarounds for 'duplicate class...' issues after activation of IntelliJ annotation processing
by Galder Zamarreño
Hi,
Since I enabled annotation processing in IntelliJ and got it working, if I build core/ from command line (i.e. to run the testsuite), when I go back to the IDE and try to run a test, I get messages like:
Duplicate class ....$Logger
Now, the eclipse Maven plugin allows to configure a different build output folder for the IDE:
<buildOutputDirectory>${basedir}/eclipse-output</buildOutputDirectory>
I've looked around the idea mvn plugin but found nothing. If build output was configurable for the IDE, we'd avoid clashes like this.
Any other ideas?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
For Eclipse users: setup the annotation processors
by Sanne Grinovero
Yesterday during one of the changes I made about dependencies I
removed the committed eclipse project file which setup the annotation
processors for Eclipse,
mainly because it was not valid anymore with the current dependencies.
Fred Bricon from the JBoss Tools team is working on
https://issues.jboss.org/browse/JBIDE-8208, I've tested his work
yesterday on both Infinispan and Hibernate projects: it's awesome, and
the project will not need anything more than a standard maven project
import to be setup properly.
The integration is very nice, for example if you now make a mistake in
the logger annotations (like a duplicate logging ID) Eclipse will
immediately highlight it as compile error - again without needing to
configure anything in the IDE; as soon as [LOGTOOL-20] will be
included in the next version of the annotation processor we'll even
get errors of mismatching parameters with the message placeholders as
"%s".
There's one side note: this update of the plugin was not released yet,
so please be patient and for the time being configure the annotation
processors manually and avoid committing that in the project as it
will conflict with the plugin work.
The main difficulty in configuring the APs is gone (duplicate
conflicting classes on classpath), so you only have to tick the
annotation processors checkbox to "enabled", if it's not already.
Cheers,
Sanne
15 years
Duplicate classes on classpath
by Sanne Grinovero
Hi all,
Fred Bricon is working on m2eclipse support to detect and properly
setup the annotation processors, and testing it on Infinispan (as I've
been bugging him to make this..)
He had an hard time make the project work because it seems that
org.jboss.logging.Logger
is defined twice on the classpath, and usually it all works fine
because of the specific order of our dependencies; one of these
implementations seems to come via dependencies like org.jboss.naming,
and
org.jboss:jboss-common-core
these are all in test scope, still could we remove them or update them
so that we all use the same logger implementations?
Ideally we should have a tattletale CI task verifying we never have duplicates.
Cheers,
Sanne
15 years
