<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">Ales, good point your Channel might be configured with fire-and-forget<br>messages ?<br>Can you share the JGroups configuration of the Channel you are<br>injecting in Search ?<br></blockquote><div><br></div><div><a href="https://github.com/capedwarf/capedwarf-jboss-as/blob/master/build/src/main/resources/standalone/configuration/standalone-capedwarf.xml">https://github.com/capedwarf/capedwarf-jboss-as/blob/master/build/src/main/resources/standalone/configuration/standalone-capedwarf.xml</a></div><div><br></div><div>and</div><div><br></div><div><a href="https://github.com/capedwarf/capedwarf-jboss-as/blob/master/extension/src/main/java/org/jboss/as/capedwarf/services/IndexableConfigurationCallback.java">https://github.com/capedwarf/capedwarf-jboss-as/blob/master/extension/src/main/java/org/jboss/as/capedwarf/services/IndexableConfigurationCallback.java</a></div><div><br></div><div>-Ales</div><br><blockquote type="cite">The backend implementation delegates to the IndexManager at the<br>receiver side in the same thread processing the incoming Message;<br>that is unless the IM itself is configured to process the index<br>updates asynchronously, the backend from the client side should block<br>until the index is updated.<br><br>Sanne<br><br>On 10 April 2013 13:38, Ales Justin &lt;<a href="mailto:ales.justin@gmail.com">ales.justin@gmail.com</a>&gt; wrote:<br><blockquote type="cite">@Bela: is there a config way to make this JGroups backend wait for ACK?<br><br>-Ales<br><br>Begin forwarded message:<br><br>From: Emmanuel Bernard &lt;<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>&gt;<br>Subject: Re: [infinispan-dev] query npe<br>Date: April 10, 2013 2:06:20 PM GMT+02:00<br>To: infinispan -Dev List &lt;<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>&gt;<br>Reply-To: infinispan -Dev List &lt;<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>&gt;<br><br>Dan worked to understand the problem, here is where we stand without<br>Sanne's additional knowledge.<br><br>The test failing is the following:<br><br> &nbsp;&nbsp;tx1.start();<br> &nbsp;&nbsp;cache.remove(key);<br> &nbsp;&nbsp;tx1.commit();<br> &nbsp;&nbsp;assert queryDeletedKey.getResults().size() == 0;<br><br>Surprisingly, the entity is still found in the query and Infinispan<br>Query returns `null`.<br><br>The reason we suspect is the following. While pushing the index changes<br>is done in sync with the transaction commit (tx sync), the backend is<br>JGroups and returns right after it has sent the message to the master<br>node without waiting for the index ack.<br>This is a good thing as it scales much better but has the nice<br>side effect of returning incorrect query results right after a change<br>set is applied (indexing window + index propagation).<br><br>My recommendation is to make sure Infinispan Query removes entities<br>found by the query engine but not present in the grid like we do in<br>Hibernate Search for the ORM case. Note that this does not solve the<br>case were you add a new entity and expect to query it *right after the<br>commit*. There is a similar issue around entity changes. If CapeDwarf<br>can live with it it will be better off.<br><br>An alternative solution would be to create a JGroups backend that waits<br>for an execution ACK before giving back the had to the client but that<br>will have scalability problems.<br><br>Emmanuel<br><br>On Tue 2013-04-09 23:41, Ales Justin wrote:<br><br>Chasing down today's NPE: <a href="http://pastie.org/7382216">http://pastie.org/7382216</a><br><br>I've added this test:<br>* <a href="https://github.com/capedwarf/capedwarf-blue/commit/d416d5358">https://github.com/capedwarf/capedwarf-blue/commit/d416d5358</a><br><br>The test fails. ;-)<br><br>deleteAndQueryInA(org.jboss.test.capedwarf.cluster.test.QueryTest): Should<br>not be here: null<br><br>This is the "null" that is the cause of top NPE.<br><br>-Ales<br><br><br>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br><br><br>_______________________________________________<br>infinispan-dev mailing list<br>infinispan-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br><br><br><br>_______________________________________________<br>infinispan-dev mailing list<br>infinispan-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></blockquote>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></blockquote></div><br></body></html>