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 <saas...@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 <saas...@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 <saas...@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 >>> >>> >>> >> >
_______________________________________________ Csync2 mailing list Csync2@lists.linbit.com http://lists.linbit.com/mailman/listinfo/csync2
