http://bugzilla.moblin.org/show_bug.cgi?id=3427
--- Comment #24 from pohly <[email protected]> 2009-09-16 01:13:54 --- (In reply to comment #23) > > Last week on the train I noticed one problem with the implementation: when > > the > > network is down completely, starting a sync via the command line reported > > that > > the initial message was sent three times. It did that quickly without any > > apparent delay between the attempts. However, I cannot reproduce that > > anymore. > > > Yes, when it was caused by network failure, it just resends immediately. Now > add a intentional sleep (this is still responsive for CTRL+C events). I have merged the code to get the adaption to the modified libsynthesis engine included and tested, but this timeout code needs more work. First, calling sleep() for a long duration prevents the syncevo-dbus-server from responding to D-Bus messages. Please introduce a EvolutionSyncClient::sleep() method which calls sleep() by default and in the DBusSyncClient runs the main loop while waiting. EvolutionSyncClient::sleep() should not return prematurely unless the time out expires or CTRL-C was pressed. sleep() could return early when some other signal is received (unlikely, but not impossible). Second, the total duration for which we try to resend messages is not deterministic. This already was a problem before, I just didn't quite realize it. We always wait for the fixed delay between message sends, but we don't know how long the transport was trying to send. It might return quickly (as you said in a comment), but it might also try for a considerable amount of time before giving up, for example in DNS lookups. I think I have seen both happening in practice. I therefore suggest to change the definition of our configuration variables and the implementation: ResendTimeout => RetryDuration (5min) "The total amount of time in which the client\n" "tries to get a response from the server.\n" "During this time, the client will resend messages\n" "in regular intervals (RetryInterval) if no response\n" "is received or the message couldn't be delivered due\n" "to transport problems. When this time is exceeded\n" "without a response, the synchronization aborts without\n" "sending further messages to the server." ResendRetries => RetryInterval (1min) "The time between the start of message sending and\n" "the start of the retransmission. If the interval has\n" "has already passed when a message send returns, the\n" "message is resent immediately.\n" The implementation must be changed so that it records the start of a message send or retransmit and then calculates the sleep duration accordingly. With this definition, it is more deterministic how long the client will try to send (plus a possible timeout in the last resend). Previously, the users had to do some (admittedly simple) math to calculate the duration and there was quite a bit of uncertainty (RetryCount * timeout). -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
