[infinispan-dev] [hibernate-dev] HSEARCH-1296

[Ales Justin]

Nice, great job guys!

@Sanne: are you gonna apply all Dan's suggestions to that branch?
e.g. the exclusion list, etc

-Ales

On Apr 15, 2013, at 8:27 PM, Dan Berindei <dan.berindei at gmail.com> wrote:

> Sorry for missing your message, Ales!
> 
> Anyway, good news, we found out why the test was taking so long: the Message instance passed to dispatcher.cast() already had a destination address set, and JGroups only sent the message to that address, even though the dispatcher was waiting for a reply from the local node as well. 
> 
> Sanne has verified that setting the destination in the message to null fixes things, and I have been able to verify this by modifying Bela's test.
> 
> Sanne, a few notes:
> 1) The cast() call doesn't throw a TimeoutException if one of the targets didn't reply - if you want to throw an exception, you need to check wasReceived() on each element of the responses list.
> 2) For ChannelMessageSender as well, channel.send() may throw a TimeoutException or not - depending on the value of RSVP.throw_exception_on_timeout. Because of this and the potential conflict with Infinispan on RSVP.ack_on_delivery, I would strongly recommend using the DispatcherMessageSender all the time.
> 3) Because Infinispan calls channel.setDiscardOwnMessages(false) in 5.3.0.Alpha1, and channel.setDiscardOwnMessages(true) in all previous versions, whether the local node receives a broadcast message depends on the Infinispan version running on the same channel. If you don't actually need the local node to process the message, you should use options.setExclusionList(dispatcher.getChannel().getAddress()) to make it obvious. If you do need the local node to process the message, you may need to process the message yourself when channel.getDiscardOwnMessages() returns true.
> 
> 
> 
> 
> On Mon, Apr 15, 2013 at 3:44 PM, Ales Justin <ales.justin at gmail.com> wrote:
>> Looking at your workaround, I think you actually set the response mode to GET_NONE (because that's the default value in RequestOptions), so you're back to sending an asynchronous request.
> 
> That was my question as well:
> 
>> Shouldn't this "synchronous" flag still be used?
>> 
>> https://github.com/Sanne/hibernate-search/blob/077f29c245d2d6e960cd6ab59ff58752320d5658/hibernate-search-engine/src/main/java/org/hibernate/search/backend/impl/jgroups/DispatcherMessageSender.java#L57
>> 
>> e.g.
>> if (synchronous) {
>> 		int size = dispatcher.getChannel().getView().getMembers().size();
>> 		RequestOptions options = RequestOptions.SYNC();
>> 		options.setRspFilter( new WaitAllFilter( size ) );
>> } else {
>> 	options = RequestOptions.ASYNC();
>> }
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130415/85856dd6/attachment.html