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.berin...@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.jus...@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@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
