Ales, good point your Channel might be configured with fire-and-forget messages ? Can you share the JGroups configuration of the Channel you are injecting in Search ?
The backend implementation delegates to the IndexManager at the receiver side in the same thread processing the incoming Message; that is unless the IM itself is configured to process the index updates asynchronously, the backend from the client side should block until the index is updated. Sanne On 10 April 2013 13:38, Ales Justin <[email protected]> wrote: > @Bela: is there a config way to make this JGroups backend wait for ACK? > > -Ales > > Begin forwarded message: > > From: Emmanuel Bernard <[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]> > Reply-To: infinispan -Dev List <[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] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
