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

[Sanne Grinovero]

On 23 March 2012 12:41, Emmanuel Bernard <emmanuel at 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