TopologySafe Map / Reduce
by Emmanuel Bernard
Pedro and I have been having discussions with the LEADS guys on their experience of Map / Reduce especially around stability during topology changes.
This ties to the .size() thread you guys have been exchanging on (I only could read it partially).
On the requirements, theirs is pretty straightforward and expected I think from most users.
They are fine with inconsistencies with entries create/updated/deleted between the M/R start and the end.
They are *not* fine with seeing the same key/value several time for the duration of the M/R execution. This AFAIK can happen when a topology change occurs.
Here is a proposal.
Why not run the M/R job not per node but rather per segment?
The point is that segments are stable across topology changes. The M/R tasks would then be about iterating over the keys in a given segment.
The M/R request would send the task per segments on each node where the segment is primary.
(We can imagine interesting things like sending it to one of the backups for workload optimization purposes or sending it to both primary and backups and to comparisons).
The M/R requester would be in an interesting situation. It could detect that a segment M/R never returns and trigger a new computation on another node than the one initially sent.
One tricky question around that is when the M/R job store data in an intermediary state. We need some sort of way to expose the user indirectly to segments so that we can evict per segment intermediary caches in case of failure or retry.
But before getting ahead of ourselves, what do you thing of the general idea? Even without retry framework, this approach would be more stable than our current per node approach during topology changes and improve dependability.
Emmanuel
10 years
7.0.1.Final tomorrow
by Tristan Tarrant
Hi all,
tomorrow we'll be cutting 7.0.1.Final so please make sure that all the
issues you want fixed have PRs by end-of-day today.
Thanks
Tristan
10 years
Rebalancing flag as part of the CacheStatusResponse
by Erik Salter
Hi all,
This topic came up in a separate discussion with Mircea, and he suggested
I post something on the mailing list for a wider audience.
I have a business case where I need the value of the rebalancing flag read
by the joining nodes. Let's say we have a TACH where we want our keys
striped across machines, racks, etc. Due to how NBST works, if we start a
bunch of nodes on one side of the topology marker, we'rewill end up with
the case where all keys will dog-pile on the first node that joins before
being disseminated to the other nodes. In other words, the first joining
node on the other side of the topology acts as a "pivot." That's bad,
especially if the key is marked as DELTA_WRITE, where the receiving node
must pull the key from the readCH before applying the changelog.
So not only do we have a single choke-point, but it's made worse by the
initial burst of every write requiring numOwner threads for remote reads.
If we disable rebalancing and start up the nodes on the other side of the
topology, we can process this in a single view change. But there's a
catch -- and this is the reason I added the state of the flag. We've run
into a case where the current coordinator changed (crash or a MERGE) as
the other nodes are starting up. And the new coordinator was elected from
the new side of the topology. So we had two separate but balanced CHs on
both sides of the topology. And data integrity went out the window.
Hence the flag. Note also that this deployment requires the
awaitInitialTransfer flag to be false.
In a real production environment, this has saved me more times than I can
count. Node failover/failback is now reasonably deterministic with a
simple operational procedure for our customer(s) to follow.
The question is whether this feature would be useful for the community.
Even with the new partition handling, I think this implementation is still
viable and may warrant inclusion into 7.0 (or 7.1). What does the team
think? I welcome any and all feedback.
Regards,
Erik Salter
Cisco Systems, SPVTG
(404) 317-0693
10 years, 1 month
Infinispan 7 documentation
by Jiri Holusa
Hi guys,
I wanted to share one user experience feedback with you. At university, I had a lecture about NoSQL datastores and Infinispan was also mentioned. The lecturer also showed some code examples. To my surprise, he used Infinispan 6. So after the lecture I asked him why version 6, not 7, and his answer was quite surprising.
He told me that he got angry on Infinispan 7 documentation, because many code snippet examples were from old 6 version and that he was basically unable to configure it in a reasonable time. So he threw it away and switched back to Infinispan 6. I justed wanted to make a little discussion about this, because I think this is quite a big issue.
I noticed that part of this issue was fixed just recently (18 hours ago, nice coincidence :)) by [1] (+10000 Gustavo), but there are still some out-of-date examples.
But the message I want to say, we should pay attention to this (I know, boring) stuff, because we're basically discouraging users/community from using the newest version. Every customer/user will start playing with the community version and if he's not able to set it up in a few moments, he will move on to another product. And we don't want that, right? :)
I also have clap the effort of Tristan with step-by-step tutorial, that's exactly what user wants and I would be happy to help you in anyway (verifying, keeping up-to-date, whatever) with it.
Conclusion: let's pay more attention to documentation, it's the entering point for every newcomer and we want to make as best first impression as possible :)
Thanks,
Jirka
P.S.: I don't see the changes from [1] in Infinispan User Guide [2], am I missing something or will it appear there later?
[1] https://github.com/infinispan/infinispan/pull/3011/
[2] http://infinispan.org/docs/7.0.x/user_guide/user_guide.html
10 years, 1 month
About size()
by Radim Vansa
Hi,
recently we had a discussion about what size() returns, but I've
realized there are more things that users would like to know. My
question is whether you think that they would really appreciate it, or
whether it's just my QA point of view where I sometimes compute the
'checksums' of cache to see if I didn't lost anything.
There are those sizes:
A) number of owned entries
B) number of entries stored locally in memory
C) number of entries stored in each local cache store
D) number of entries stored in each shared cache store
E) total number of entries in cache
So far, we can get
B via withFlags(SKIP_CACHE_LOAD).size()
(passivation ? B : 0) + firstNonZero(C, D) via size()
E via distributed iterators / MR
A via data container iteration + distribution manager query, but only
without cache store
C or D through
getComponentRegistry().getLocalComponent(PersistenceManager.class).getStores()
I think that it would go along with users' expectations if size()
returned E and for the rest we should have special methods on
AdvancedCache. That would of course change the meaning of size(), but
I'd say that finally to something that has firm meaning.
WDYT?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
10 years, 1 month
PHP hot rod client
by Albert Bertram
Hi,
A couple of years ago there were a few messages on this list about a
potential PHP Hot Rod client. I haven't seen any further discussion of it,
but I find myself in the same situation described before: I want to have a
Drupal installation write cache data to Infinispan, and I'd prefer if it
could do it via the Hot Rod protocol rather than the memcached protocol.
I haven't seen any further evidence of the existence of a Hot Rod client
native to PHP out on the open web, so I wrote a small wrapper around the
Hot Rod C++ client which works for my purposes so far. The code is at
https://github.com/bertrama/php-hotrod
I wanted to send a note to the list to ask a couple questions:
Would anyone else be interested in this php extension?
Are there client-oriented benchmarks I should run? I looked around for
some, but didn't find any. Specifically, I want to compare performance of
this PHP Hot Rod client to the PHP memcached client when talking to the
same Infinispan server.
Thanks!
Albert Bertram
10 years, 1 month
JDK 9 Early Access with Project Jigsaw build b36 is available on java.net
by Rory O'Donnell Oracle, Dublin Ireland
Hi Galder,
JDK 9 Early Access with Project Jigsaw build b36 is available on
java.net [1]
The goal of Project Jigsaw [2] is to design and implement a standard
module system for the Java SE Platform,
and to apply that system to the Platform itself and to the JDK.
As described in JEP 220 [3], this build provides a new runtime image
structure. For example, this new runtime
image does not install an rt.jar file or a tools.jar file.
Please refer to Project Jigsaw's updated project pages [2] & [4] and
Mark Reinhold's announcement email [5]
for further details.
We are very interested in your experiences testing this build. Comments,
questions, and suggestions are
welcome on the jigsaw-dev mailing list or else submit bug reports via
bugs.java.com.
Note: If you haven’t already subscribed to that mailing list then please
do so first, otherwise
your message will be discarded as spam.
[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/projects/jigsaw/
[3] http://openjdk.java.net/jeps/220
[4] http://openjdk.java.net/projects/jigsaw/ea
[5]
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/003878.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 1 month
