> I did not think of that but an "implicit" or "auto" setting makes some
> sense.
> Just to be sure, the new immplicit setting / behavior will break the
> semantic of what's going on so it should at least but a minor version
> bump. Correct?
>
> BTW, did you guys even found out why using sync was
On 3 May 2013 10:47, Emmanuel Bernard wrote:
> I did not think of that but an "implicit" or "auto" setting makes some
> sense.
> Just to be sure, the new immplicit setting / behavior will break the
> semantic of what's going on so it should at least but a minor version
> bump. Correct?
Correct, t
I did not think of that but an "implicit" or "auto" setting makes some
sense.
Just to be sure, the new immplicit setting / behavior will break the
semantic of what's going on so it should at least but a minor version
bump. Correct?
BTW, did you guys even found out why using sync was taking so much
Applies to all backends:
"hibernate.search.default.worker.execution" "async"
Then override the above per specific index which needs to be sync :
"hibernate.search.books.worker.execution" "sync"
On 15 April 2013 22:37, Ales Justin wrote:
> What's (again) the magic property to set all indexes bac
What's (again) the magic property to set all indexes backends in a cache to
async?
-Ales
On Apr 15, 2013, at 7:00 PM, Sanne Grinovero wrote:
> In my first draft for HSEARCH-1296 I was automatically enabling the
> blocking behaviour on JGroups if the worker backend was configured to
> be synchr
In my first draft for HSEARCH-1296 I was automatically enabling the
blocking behaviour on JGroups if the worker backend was configured to
be synchronous (which is the default for workers),
but Emmanuel didn't like that and I think he has a good point:
The JGroups behaviour and the workers behaviou
