Re: [hibernate-dev] multiple/single JGroups channels in Hibernate Search

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.

> 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?