Bug 70771 - Problem with Sync + Network Enabled.
Summary: Problem with Sync + Network Enabled.
Status: RESOLVED FIXED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: PIM Manager (show other bugs)
Version: 1.3.99.3
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-22 17:47 UTC by Eugenio Parodi
Modified: 2013-11-19 16:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Logfiles (87.79 KB, text/plain)
2013-10-22 17:47 UTC, Eugenio Parodi
Details

Description Eugenio Parodi 2013-10-22 17:47:32 UTC
Created attachment 88012 [details]
Logfiles

There is a hostname request in the Logging routine that may slowdown the Sync if The network is not available or lead to some kind of timeout service.


This is log from sync with network enabled:
	[2013-10-17 15:14:48.189] ---- Hardcoded Product name: SySync SyncML Library OpenSource Linux
	[2013-10-17 15:14:48.189] ---- Configured Model/Manufacturer: SyncEvolution / Patrick Ohly
	[2013-10-17 15:14:58.000] ---- Running on Linux, URI/deviceID='linux:localhost.localdomain'
	[2013-10-17 15:14:58.000] ---- Process ID = 2262, Thread ID = 3034576592 It’s perfect 10 seconds stall after which deviceID is displayed and it’s contains device network name.

Here is the same fragment from log with network disabled:
	[2013-10-18 10:52:54.035] ---- Hardcoded Product name: SySync SyncML Library OpenSource Linux
	[2013-10-18 10:52:54.035] ---- Configured Model/Manufacturer: SyncEvolution / Patrick Ohly
	[2013-10-18 10:52:54.038] ---- Running on Linux, URI/deviceID='linux:localhost.localdomain'
	[2013-10-18 10:52:54.038] ---- Process ID = 19327, Thread ID = 3034973904 No stall at all (interestingly deviceID is the same as with network enabled).

Also there is second 10 seconds stall shortly after first one when network is enabled (log is not saying much about this, but I’m thinking that reason is the same as for the first one):
	[2013-10-17 15:14:58.001] Created command 'Status' (outgoing)
	–[2013-10-17 15:14:58.001] 'DSStateChange' - Datastore changes state, datastore=remote, oldstate=idle, newstate=client_initialized [--][++] [->end]
	–[2013-10-17 15:14:58.001] End of 'DSStateChange' [->top]
	[2013-10-17 15:15:08.000]  
	[2013-10-17 15:15:08.000] =================> Starting new client session

And again log without network:
	[2013-10-18 10:52:54.039] Created command 'Status' (outgoing)
	–[2013-10-18 10:52:54.039] 'DSStateChange' - Datastore changes state, datastore=remote, oldstate=idle, newstate=client_initialized [--][++] [->end]
	–[2013-10-18 10:52:54.039] End of 'DSStateChange' [->top]
	[2013-10-18 10:52:54.040]  
	[2013-10-18 10:52:54.040] =================> Starting new client session Again no stall at all.
Comment 1 Patrick Ohly 2013-10-22 18:52:42 UTC
The root cause is gethostbyname() in the following libsynthesis code:

src/platform_adapters/linux/configfiles.cpp

bool getLocalDeviceID(string &aURI)
...
  if (gethostname(szHostname, sizeof(szHostname))!=0) {
    hostName="_unknown_";
  }
  else {
    // get host entry
    pHostEnt = gethostbyname(szHostname);
    // return fully qualified name of machine as ID
    if (pHostEnt)
      hostName=pHostEnt->h_name; // DNS name of machine
    else
      hostName=szHostname; // just name of machine
  }
...

I suppose the code above tries to resolve the canonical host name. I am not sure whether that is really useful, so perhaps the call can simply be removed without any ill effects. It certainly doesn't matter for PBAP syncing.
Comment 2 Patrick Ohly 2013-10-27 19:15:02 UTC
> I suppose the code above tries to resolve the canonical host name. I am not
> sure whether that is really useful, so perhaps the call can simply be
> removed without any ill effects. It certainly doesn't matter for PBAP
> syncing.

I've removed the code and will try whether that has any unexpected side effects.
Comment 3 Patrick Ohly 2013-11-19 16:08:38 UTC
Passed testing without issues, patch now in libsynthesis master branch and included in 1.3.99.6.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.