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 ?
and
-Ales
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 <ales.justin@gmail.com> wrote:
@Bela: is there a config way to make this JGroups backend wait for ACK?
-Ales
Begin forwarded message:
From: Emmanuel Bernard <emmanuel@hibernate.org>
Subject: Re: [infinispan-dev] query npe
Date: April 10, 2013 2:06:20 PM GMT+02:00
To: infinispan -Dev List <infinispan-dev@lists.jboss.org>
Reply-To: infinispan -Dev List <infinispan-dev@lists.jboss.org>
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
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev