Asynchronous cache's "void put()" call expectations changed from 6.0.0 to 6.0.1/7.0
by Galder Zamarreño
Hi all,
@Paul, this might be important for WF if using async repl caches (the same I think applies to distributed async caches too)
Today I’ve been trying to upgrade Infinispan version in Hibernate master from 6.0.0.Final to 7.0.0.Beta1. Overall, it’s all worked fine but there’s one test that has started failing.
Essentialy, this is a clustered test for a repl async cache (w/ cluster cache loader) where a non-owner cache node does put() and immediately, on the same cache, it calls a get(). The test is failing because the get() does not see the effects of the put(), even if both operations are called on the same cache instance.
According to Dan, this should have been happening since [1] was implemented, but it’s really started happening since [2] when lock delegation was enabled for replicated caches (EntryWrappingInterceptor.isUsingLockDelegation is now true whereas in 6.0.0 it was false).
Not sure we set expectations in this regard, but clearly it’s big change in terms of expectations on when “void put()” completes for async repl caches. I’m not sure how we should handle this, but it definitely needs some discussion and adjuts documentation/javadoc if needed. Can we do something differently?
Indepent of how we resolve this, this is the result of once again of trying to shoehole async behaviour into sync APIs. Any async caches (DIST, INV, REPL) should really be accessed exclusively via the AsyncCache API, where you can return quickly and use the future, and any listener to attach to it (a bit ala Java8’s CompletableFuture.map lambda calls) as a way to signal that the operation has completed, and then you have an API and cache mode that make sense and is consistent with how async APIs work.
Right now, when a repl async cache’s “void put()” call is not very well defined. Does it return when message has been put on the network? What impact does it have in the local cache contents?
Also, a very big problem of the change of behaviour is that if left like that, you are forcing users to code differently, using the same “void put()” API depending on the configuration (whether async/sync). As clearly shown by the issue above, this is very confusing. It’s a lot more logical IMO, and I’ve already sent an email on this very same topic [3] back in January, that whether a cache is sync or async should be based purely on the API used and forget about the static configuration flag on whether the cache is async or sync.
Cheers,
[1] https://issues.jboss.org/browse/ISPN-2772
[2] https://issues.jboss.org/browse/ISPN-3354
[3] http://lists.jboss.org/pipermail/infinispan-dev/2014-January/014448.html
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
9 years, 10 months
Infinispan tutorial
by Tristan Tarrant
Hi guys,
I've been working on how to spruce up our website, docs and code samples.
While quickstarts are ok, they come as monolithic blobs which tell you
nothing about how you got there. For this reason I believe a
step-by-step tutorial approach is better and I've been looking at the
AngularJS tutorials [0] as good examples on how to achieve this.
I have created a repo [1] on my GitHub user where each commit is a step
in the tutorial. I have tagged the commits using 'step-n' so that you
can checkout any of the steps and run them:
git checkout step-1
mvn clean package exec:java
The GitHub web interface can be used to show the diff between steps, so
that it can be linked from the docs [2].
Currently I'm not aiming to build a real application (although
suggestions are welcome in this sense), but just going through the
basics, adding features one by one, etc.
Comments are welcome.
Tristan
---
[0] https://docs.angularjs.org/tutorial/step_00
[1] https://github.com/tristantarrant/infinispan-embedded-tutorial
[2]
https://github.com/tristantarrant/infinispan-embedded-tutorial/compare/st...
9 years, 12 months
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, 1 month
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
Taking over Mongo DB Cache Store ?
by Romain Pelisse
Hi all,
I've been looking into a piece of ISPN I could contribute to, and I think I
could help supporting the MognoDB Cache Store[1]. I've checkout and none of
the fork seems to be ahead of this version, and it seems to need to be
ported to ISPN 7.x - which I'm inclined to work on.
However, before doing so, I wanted to check with the community if nobody
has such plan...
[1] https://github.com/infinispan/infinispan-cachestore-mongodb
--
Romain PELISSE,
*"The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it" -- Terry Pratchett*
Belaran ins Prussia (blog) <http://blog.wordpress.belaran.eu/> (...
finally up and running !)
10 years, 2 months
