On 3 May 2013 10:47, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
I did not think of that but an "implicit" or
"auto" setting makes some
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
Correct, this was released as 4.3.0.Alpha1 :
BUT I didn't realize it would effectively change interpretation of
existing configurations; my bad, updating the migration guide now..
BTW, did you guys even found out why using sync was taking so much time?
Yes, although it was a painfully long debug session (week+): the way
we where using the JGroups API was "unexpected" and would trigged
faulty behaviour. This is way our backend ended up to be mostly
rewritten, to better match JGroups typical usage. Also JGroups issues
where opened to avoid the pitfall.
In short, the operation would complete quickly (<5 milliseconds) on
the master node, but then the client thread would be stuck waiting for
one more reply than what it would receive in practice, waiting for the
timeout: so that added 10 seconds for each RPC. After the timeout
would trigger, the client thread would actually realize the ACK *was*
received, so wouldn't throw an error as all was processed fine. Added
very strict test for this ;-)
On Mon 2013-04-15 18:00, 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 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 behaviour are two different
> things; so I just separated this into a new configuration property
> "block_waiting_ack" (boolean)
> which of course applies only to the JGroups backends.
> I agree it's important to keep the two separate, but also if the user
> is configuring an ASYNC worker, he should set this option to false as
> there is no benefit in waiting for the delivery.
> Likewise, if SYNC is required, you would probably want to set this to true.
> So I'm suggesting we make the default value ot "block_waiting_ack"
> dependant on the worker execution, exposing the property as an
> I guess it's much easier to understand the default behaviour if we
> keep them separate, still I don't see much use for configuring the two
> hibernate-dev mailing list