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
10 years, 8 months
Indexing deadlock (solution suggestion)
by Radim Vansa
Hi,
what I was suggesting in the call in order to get rid of the indexing:
Currently we're doing this:
1. thread on primary owner executes the write and sends indexing request
(synchronous RPC) to index master, waits for the response
2. remote/OOB thread on indexing master enqueues the indexing request
and waits
3. indexing thread (on indexing master) retrieves the request, processes
it and wakes up the waiting remote/OOB thread
4. remote/OOB thread sends RPC response
5. primary owner receives the RPC response (in OOB thread, inside
JGroups) and wakes up the thread sending the RPC
What I suggest is that:
1. thread on primary owner executes the write and sends indexing request
as asynchronous RPC (single message) to index master, and waits on a
custom synchronization primitive
2. remote/OOB thread on indexing master enqueues the indexing request
and returns back to the threadpool
3. indexing thread (on indexing master) retrieves the request, processes
it and sends asynchronouse RPC (again single message) to the primary owner
4. primary owner (in OOB thread) receives the message and wakes up
thread waiting on the custom synchronization primitive (in Infinispan)
My 2c
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
10 years, 9 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...
10 years, 10 months
Dan's wiki page on cache consistency
by Radim Vansa
Hi guys,
since not everyone is watching ISPN-5016, I wanted to spread the
audience for $SUBJECT [1]. A few details need more attention yet, but
this is really the most comprehensive information on Infinispan Cache
API guarantees and I'd recommend anyone to spend the time to read this
carefully (although it's not an one-coffee article).
Thanks a lot, Dan, for compiling this.
Radim
[1]
https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-I...
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
10 years, 10 months
Re: [infinispan-dev] JIRAs for a 7.0.3 release
by Erik Salter
Hi all,
I have a few more that might be candidates for the 7.0.x branch. The
critical ones (for me) have to do with state transfer and locks. Some of
these are still pending, though.
ISPN-5076
ISPN-5030
ISPN-5000
ISPN-4546
There are a few optimizations. ISPN-5042, in particular, seems like a
quick win. For ISPN-5037 and ISPN-5032, I'll probably implement on my own.
Also under the heading of optimizations -- one thing that's a real problem
with my cache configuration is the verbose nature of
OutdatedTopologyExceptions. They're thrown as RemoteExceptions, which
cause stack traces all over the place when a NonTx cache retries its
operation. (These actually crashed an indexer on my analytics engine
during a performance state transfer test.) Also, if the key ownership
hasn't changed, why throw them at all?
ISPN-4695
ISPN-4586
(If I'm on Santa's naughty list, I may have a crack at implementing them.)
There are a few minor cosmetic things that are easily ported.
ISPN-4989
ISPN-5040
ISPN-5052
Thanks all,
Erik
On 12/4/14, 10:22 AM, "Erik Salter" <an1310(a)hotmail.com> wrote:
>Hi all,
>
>I was asked to vote on a list of JIRAs for 7.0.3 and send it to the
>mailing list. The next iteration of my application is migrating from
>5.2.x to 7.0.x, so I'm really focused on hardening and stability,
>especially WRT state transfer. Here are the ones I was looking at, mostly
>related to state transfer:
>
>- ISPN-5000
>
>- ISPN-4949 (and related ISPN-5030)
>- ISPN-4975
>- ISPN-5027
>
>Notes on a few others I was looking at:
>- ISPN-4444, from the description, looks serious enough to include. I
>haven't looked at the commit in-depth; appears to be limited to keys in
>L1?
>- ISPN-4979 appears to be a substantial change. I would defer to the team
>about how risky of a change it is.
>
>And if ISPN-3561 makes it into a 7.0.3, I'd consider it a personal favor.
>
>Regards,
>
>Erik
>
>
>_______________________________________________
>infinispan-dev mailing list
>infinispan-dev(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/infinispan-dev
10 years, 10 months
Performance gap between different value sizes and between key loactions
by linjunru
Hi, all:
I have tested infinispan in distributed mode in terms of latency of put(k,v) operation. The own_num is 1 and the key we put/write locates in the same node as the put operation occurs(In the table,“1+0” represents this scenario), the results indicates that the latency increases as the size of the value increases. However the increments seem to be a little “unreasonable” to me, because the bandwidth of the memory system is quite huge, and the number of keys (10000) remains the same during the experiment. So, here is the questions: which operations inside infinspan have strong relatives with the size of value, and why they costs so much as the size increases?
We have also tested infinispan in the scenario which the key and the put/write(key,value) operation reside in different nodes(we noted it as “0+1”). Compared with “1+0”, “0+1” triggers network communications, however, the network latency is much smaller compared to the performance gas between the two scenarios. Why this situation happens? For example, with a 25K bytes ping packet, the RTT is about 0.713ms while performance gas between the two scenarios is about 8.4ms，what operations inside infinispan used the other 7.6ms?
UDP is utilized as the transport protocol, the infinispan version we used is 7.0 and there are 4 nodes in the cluster, each has 10000 keys, all of them have memory bigger than 32G, and all of them have xeon cpu e5-2407 x2.
Value size
250B( us)
2.5K( us)
25k(us)
250k(us)
2.5M(us)
25M(us)
1+0
463
726
3 236
26 560
354 454
3 979 830
0+1
1 807
2 829
11 635
87 540
1 035 133
11 653 389
Thanks!
Best Regards,
JR
10 years, 10 months
Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net
by Rory O'Donnell
Hi Galder,
Now that JDK 9 Early Access build images are modular [1], there is a fresh
Early Access build for JDK 9 b42 <https://jdk9.java.net/download/>
available on java.net. The summary of
changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b42.html>
In addition, there are new Early Access builds for the ongoing update
releases.
The Early Access build for JDK 8u40 b18
<http://jdk8.java.net/download.html> is available on java.net, with the
summary of changes listed here.
<http://www.java.net/download/jdk8u40/changes/jdk8u40-b18.html>
Finally, the Early Access build for JDK 7u80 b03
<https://jdk7.java.net/download.html>is available on java.net,
with the summary of changes listed here.
<http://download.java.net/jdk7u80/changes/jdk7u80-b03.html>
As we enter the later phases of development for JDK 7u80 & JDK 8u40,
please log any show stoppers as soon as possible.
Rgds,Rory
[1] http://mreinhold.org/blog/jigsaw-modular-images
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 10 months
