This boils down to using a sync RPC (versus an async one). I don't know how HS does this (e.g. whether they use RPCs at all)... Sanne might be able to help
On 4/10/13 2:38 PM, Ales Justin wrote: > @Bela: is there a config way to make this JGroups backend wait for ACK? > > -Ales > > Begin forwarded message: > >> *From: *Emmanuel Bernard <[email protected] >> <mailto:[email protected]>> >> *Subject: **Re: [infinispan-dev] query npe* >> *Date: *April 10, 2013 2:06:20 PM GMT+02:00 >> *To: *infinispan -Dev List <[email protected] >> <mailto:[email protected]>> >> *Reply-To: *infinispan -Dev List <[email protected] >> <mailto:[email protected]>> >> >> Dan worked to understand the problem, here is where we stand without >> Sanne's additional knowledge. >> >> The test failing is the following: >> >> tx1.start(); >> cache.remove(key); >> tx1.commit(); >> assert queryDeletedKey.getResults().size() == 0; >> >> Surprisingly, the entity is still found in the query and Infinispan >> Query returns `null`. >> >> The reason we suspect is the following. While pushing the index changes >> is done in sync with the transaction commit (tx sync), the backend is >> JGroups and returns right after it has sent the message to the master >> node without waiting for the index ack. >> This is a good thing as it scales much better but has the nice >> side effect of returning incorrect query results right after a change >> set is applied (indexing window + index propagation). >> >> My recommendation is to make sure Infinispan Query removes entities >> found by the query engine but not present in the grid like we do in >> Hibernate Search for the ORM case. Note that this does not solve the >> case were you add a new entity and expect to query it *right after the >> commit*. There is a similar issue around entity changes. If CapeDwarf >> can live with it it will be better off. >> >> An alternative solution would be to create a JGroups backend that waits >> for an execution ACK before giving back the had to the client but that >> will have scalability problems. >> >> Emmanuel >> >> On Tue 2013-04-09 23:41, Ales Justin wrote: >>> Chasing down today's NPE: http://pastie.org/7382216 >>> >>> I've added this test: >>> * https://github.com/capedwarf/capedwarf-blue/commit/d416d5358 >>> >>> The test fails. ;-) >>> >>> deleteAndQueryInA(org.jboss.test.capedwarf.cluster.test.QueryTest): >>> Should not be here: null >>> >>> This is the "null" that is the cause of top NPE. >>> >>> -Ales >>> >> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
