On 06/18/2013 12:35 AM, Mahadevan, Venkat wrote:
I do not know why your environment is prone to trigger db_deadlock
(lot of replica agreements, VM, slow disks...).
I think the best way to progress is that you fill a ticket/bug so that
we may track the issue. Note this bug is possibly
On 06/18/2013 01:51 AM, thierry bordaz wrote:
On 06/18/2013 12:35 AM, Mahadevan, Venkat wrote:
I do not know why your environment is prone to trigger db_deadlock
(lot of replica agreements, VM, slow disks...).
I think the best way to progress is that you fill a ticket/bug so
that we may
Running in a VM should not be an issue if it follows the usual tuning
recommendation. But of course it adds a layer when investigating a RC.
What is weird is to hit so frequent (50) deadlock in a single DB call. In
addition it looks like it always happen when updating the CL so I can think to
Hi Mahadevan,
I think you hit a new bug that I was able to reproduce.
The problem is an incorrect handling of operation return code when
there is an error in SLAPI_PLUGIN_BE_TXN_POST_ADD_FN.
When the operation succeeds in the DB, DS (as a master) updates the
CL and RUV in
I do not know why your environment is prone to trigger db_deadlock (lot of
replica agreements, VM, slow disks...).
I think the best way to progress is that you fill a ticket/bug so that we may
track the issue. Note this bug is possibly affecting all operations
(ADD/MOD/MODRDN/DEL)
-
Hi
I do not know why your environment is prone to trigger db_deadlock (lot of
replica agreements, VM, slow disks...).
I think the best way to progress is that you fill a ticket/bug so that we may
track the issue. Note this bug is possibly affecting all operations
(ADD/MOD/MODRDN/DEL)
---
Hi
If the operation fails to write into the changelog, the operation fails. In
your case, it means that the ldapclient should receive an error.
So it is like if the operation never happened and is not replicated.
Hi Thierry,
That’s what I would expect to, but that does not seem to be the case.
