On 23 March 2012 12:41, Emmanuel Bernard <emman...@hibernate.org> wrote: > > On 21 mars 2012, at 18:17, Sanne Grinovero wrote: > >> Context: >> HSEARCH-1070 JGroups channels need to be shared across multiple backends >> >> I think it makes sense for an Hibernate Search instance to share a >> single JGroups channel across multiple backends; there are several >> reasons for this: >> - Not having to change configuration details such as different ports per >> index >> - A Channel is expensive (slow) to start >> - I would very likely want to configure it with a single channel. >> - Sharing channels doesn't prevent us to have different backends, >> with different masters on different nodes >> >> My question is, should I still make sure we allow for multiple >> different channels? Like configuring a different protocol stack / >> network options per index? >> >> I'm not liking that as it makes configuration quite complex and tricky >> - especially worthless as I'm not seeing any practical use for it. > > That would have been my question. If we cannot find any practical use case > (would throughput be impacted?) then let's simply enforce a single channel.
Going that way. >> There is one (annoying) reason to allow that: backwards compatibility. >> It seems since version 4.0 we're dealing with it as one channel per >> index - but this wasn't really intended to work like that imho, I'm >> considering this a bug rather than an API change, but making it unique >> across indexes requires a configuration changes: configuration >> property would not be "scoped" under the index name: >> >> < hibernate.search.default.worker.backend.jgroups.configurationString >> = "jgroups configuration" >>> hibernate.search.services.jgroups.configurationString = "jgroups >>> configuration" > > I think it's fine to break that but let's make sure we fail properly if a > user has an improper configuration. Is it hard to detect incorrect > configuration and raise an exception with a decent explanation? Good idea, that's trivial. thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev