[Csync2] [SOLVED] Database backend is exceedingly busy => Terminating (requesting retry)

[Samba]

Hi,


A few more details on this front...

Although this issue is no more occurring after setting the lock-timeout to
60 seconds [very very bad network with ping response times of the order 1-2
seconds],  i did notice error messages like :

[16:34:23] While syncing file /opt/conf/messages/card_en.properties:


[16:34:23] ERROR from peer /opt/conf/messages/card_en.properties):
slave.server Connection closed.


[16:34:23] ERROR from peer(<no file>): slave.server Connection closed.


[16:34:23] Finished with 2 errors.


I guess that even though above message has been logged as error but the
exit code after running the command "csync2 -C abc -G xyz -xt >>
/var/log/csync2.log 2>&1"  is ZERO and hence my script continued with other
csync-config-files and did not fail at that point.

I'm not sure if the above error is a cause of concern and needs to be fixed
or it may be just a warning and can be ignored.

Anyway, this issue can be treated as SOLVED and the solution is setting
appropriate "lock-timeout" for your network characteristics.

Thanks and Regards,
Samba


=========================================================================

On Tue, Aug 7, 2012 at 3:48 PM, Samba <saasira at gmail.com> wrote:

> Hi Lars,
>
> Good news is that i worked around the issue by setting the "lock-timeout
> 60;" in each of the csync configuration files.
>
> When I set it for 30 the issue was still occuring on an average 1 in 7 so
> i have set it up as 60 seconds, and after that i could not see this issue,
> at least in dozen plus tests with a very bad (simulated) network.
>
> So, this issue can be attributed to slower networks ( "-B" option did not
> help) and the workaround or may be a solution is to set appropriate
> lock-timeout in csync configuration file.
>
> I'm still curious to know as to how would network strength (or rather
> weakness of it) affect the transaction time since csync accesses SQLite
> database on the same host and not remotely.
>
> Thanks and Regards,
> Samba
>
> ===================================================================================
>
> On Mon, Aug 6, 2012 at 4:28 PM, Samba <saasira at gmail.com> wrote:
>
>> Hi,
>> I could reproduce this issue with the code checked out from the trunk as
>> well.
>>
>> Issue seems to be occurring when we have slow network [reproducbe at
>> least once in 5 times over a WAN ping response-times 300 ms; if i increase
>> delay to 1000 ms, then almost always reproducible].
>>
>> I'm not sure why network speed (or rather slowness of it) would have any
>> impact on SQLite database transactions, since the database is accessed
>> locally within the same host.
>>
>> I tried the option "-B" which is suggested over slow networks but that
>> also could not completely resolve the issue although occasionally it did
>> reduce the frequency of occurrence.
>>
>> It would be great if any workaround [or if possible, a workable solution]
>> is  suggested.
>>
>> Thanks and Regards,
>> Samba
>>
>> ===========================================================
>>
>> On Tue, Jul 31, 2012 at 6:48 PM, Samba <saasira at gmail.com> wrote:
>>
>>> Lars,
>>>
>>> I'm getting the error "Database backend is exceedingly busy =>
>>> Terminating (requesting retry)" occasionally; not sure if it has to do with
>>> the patch I provided for "subdir_deletion" though. I'm  sure that i did not
>>> play with SQL queries in my first version of the patch and even with that I
>>> see this error coming up occasionally, perhaps when the network is slow.
>>> I'm planning to run a few more tests to confirm whether this issue exists
>>> in the trunk version or introduced with my patch.
>>>
>>> Could you throw some light on what can be going wrong to get that error?
>>>
>>> Thanks and Regards,
>>> Samba
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/csync2/attachments/20120807/2f7f6b2a/attachment.htm>