infinispan-tree, NodeImpl.getParent() seems to be buggy
by Adrian Nistor
Hi,
I spotted a potential problem in infinispan-tree. Noticed that the
javadoc of org.infinispan.tree.Node.getParent() ("Returns the parent
node. If this is the root node, this method returns <code>null</code>")
does not actually match the implementation. It seems
rootNode.getParent() == rootNode instead of being null.
Can't be sure what was the intention here, but I'm assuming the javadoc
is correct. Can somebody confirm so I can file a bug?
Thanks,
Adrian
12 years
Buildhive
by Galder Zamarreño
I've just registered Infinispan upstream repo to Cloudbees' Buildhive:
https://buildhive.cloudbees.com/job/infinispan/job/infinispan/
What this means now is that it'll listen for pull reqs sent to Infinispan upstream and will build them automatically, posting the results back in the pull request.
No pull reqs have been sent yet, so we need to see whether this works as expected.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years
Hybrid locking scheme in ISPN 5.2.0
by Diego Didona
Hello,
looking at the code of ISPN 5.2 (and 5.1) I have seen that the
LockingIntercetor has been replaced with new ones. I would like to know
if there is the possibility to have ISPN 5.2 (or 5.1) working with the
*same* hybrid locking scheme described in [1], which was the default
till ISPN 5.0 and entailed the encounter-time write-locks acquisition
during the "local" execution of a transaction and then their remote
acquisition on other nodes at prepare time.
Of course I would like to know if this is feasible just by tweaking some
configuration parameters, without having to modify the source code.
Thanks,
Diego
------------------------
[1] https://community.jboss.org/wiki/OptimisticLockingInInfinispan
12 years
state transfer & non-shared CacheStore
by Sanne Grinovero
How is Infinispan dealing with state-transfer of values which are
passivated in a non-shared CacheStore ?
Not only interested about the working in a DIST configuration, but
also with REPL when new (empty) nodes join the grid as they would need
to fetch all the data from peers, including what is currently
passivated.
Cheers,
Sanne
12 years, 1 month
concurrency issue on ServiceLoader::iterator
by Ales Justin
Anyone ever seen this error?
Caused by: java.util.NoSuchElementException
at java.util.AbstractList$Itr.next(AbstractList.java:350) [classes.jar:1.6.0_31]
at java.util.Collections$1.nextElement(Collections.java:3389) [classes.jar:1.6.0_31]
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:332) [classes.jar:1.6.0_31]
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:415) [classes.jar:1.6.0_31]
at org.infinispan.distexec.spi.DistributedTaskLifecycleService.onPreExecute(DistributedTaskLifecycleService.java:50) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
public <T> void onPreExecute(Callable<T> task) {
try {
Iterator<DistributedTaskLifecycle> i = loader.iterator();
while (i.hasNext()) { // <------------------------------------------------- we CHECK before
DistributedTaskLifecycle cl = i.next();
cl.onPreExecute(task);
And I doubt I have multiple thread accessing it at the same time -- running this from serial testsuite.
I can reproduce this, atm, almost every time, where Vladimir (Blagojevic; Infinispan - author of DistributedTaskLifecycleService) cannot.
Any idea?
-Ales
12 years, 1 month
range query in Infinispan !!
by Prabhat Jha
Hi,
In QuickTweet we needed a way to get most recent x tweets for a user or
on a topic. Currently we are implementing it by keeping entries in the
cache and updating a bounded FIFO queue in parallel. However, to get
most recent data or data for a given time range is a very common use
case specially in social media applications. It would be good to see
this range feature available in out of box (not using Query) in upcoming
Infinispan releases. Thoughts?
I can get it started by creating a Jira unless I hear otherwise.
Regards,
Prabhat
12 years, 1 month
Fwd: Backward compatibility and rolling upgrades
by Dan Berindei
Forgot to send to the list :)
---------- Forwarded message ----------
From: Dan Berindei <dan.berindei(a)gmail.com>
Date: Tue, May 15, 2012 at 7:41 PM
Subject: Re: Backward compatibility and rolling upgrades
To: Manik Surtani <manik(a)jboss.org>
On Tue, May 15, 2012 at 4:31 PM, Manik Surtani <manik(a)jboss.org> wrote:
>
> On 15 May 2012, at 10:53, Sanne Grinovero wrote:
>
>> Since I've been long advocating this (thanks Tristan to point it out
>> first) I appreciate the strong push from the project lead.
>> Still as you say in the first half of the mail this wasn't supposed to
>> work in previous releases, so why are your 3 points in the end of the
>> mail asking specific details to migrate from 4.2 ?
>
> Because we (Red Hat services) would need to provide a ramp-up to getting
people already using 4.2 onto JDG (based on 5.1) without any downtime.
Granted, Red Hat services will charge for this, we still need to be able
to help them out with building such a tool.
>
>> It's too late to bridge for existing versions, you can't even patch
>> them as people running them are already running them.. unless you
>> intend to make intermediate releases, such as a "4.2/5.1" specific
>> release.
>
> I was thinking perhaps a 5.1.Compat release which can parse and
participate in a 4.2-style state transfer, etc. It would be a case of then
upgrading half the cluster to 5.1.Compat, then the other half to full 5.1,
and then the first half again to full 5.1.
>
Manik, I doubt that stock JGroups 3.0.x is binary compatible with
JGroups 2.12.x, but we could perhaps copy the protocols from 2.12 to
create a 3.0.compat version. When the entire cluster is running
5.1.compat, we could close the compat-mode channels all at once and
start new JGroups 3.0 channels. We'd need some kind of "disable state
transfer" switch, but it sounds doable.
OTOH, 4.2 state transfer requires partial state transfer support from
JGroups (at least in replicated mode). I'm not sure if Bela can hack
partial state transfer back into 3.0 to support state transfer from
4.2 -> 5.1 in replicated mode. For distributed caches I think it may
be easier, the 4.2 rehashing code should still work with JGroups 3.0.
Even if we do get state transfer working, the nodes then have to
interact: 5.1 nodes have to respond to 4.2 commands, and 4.2 nodes
have to respond to 5.1 commands. I'm pretty sure we have some
incompatibilities, with all the optimization rounds that we had going
on...
>> Did you see the issues we opened back in Lisbon on JIRA? they are
>> supposed to make it possible to perform a rolling upgrade, but need to
>> be included in the project *before* as I had already pointed out, to
>> make it possible to migrate to future versions.
>>
>> All issues are still open, apparently not considered important enough
>> :-( see https://issues.jboss.org/browse/ISPN-1410 and all it's
>> dependencies.
>
> I saw this, but I think there are a few bits missing. From your umbrella
JIRA:
>
> ISPN-1409: why is this necessary? CacheLoaders use
VersionAwareMarshallers which create versioned streams as it is. So from a
serialisation perspective, we should be protected.
>
Looking at the code of VersionAwareMarshaller, it reads the version id
in startObjectInput but it doesn't do anything with it...
Also, how do you register an Externalizer to handle a particular version?
> ISPN-1406: Not sure I understand the purpose of this. If we're writing
through to a cache store then this happens anyway.
>
Assuming VersionAwareMarshaller does pick the right Externalizer based
on the version id...
>> As I see it, even JDG customers won't be able to migrate to newer
>> versions since this wasn't tested and for sure there will be more
>> changes needed: I certainly won't presume our theoretical draft will
>> work flawlessly in practice.
>
> Yes, this definitely needs work, and more than that, as you say, some
real-world migration tests.
>
>> Also the thread we opened on Flags is relevant (active even today)
>
> +1.
>
> But I'm still very curious about the 3 points I raised in my original
email. :)
>
12 years, 1 month
