To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=105283
------- Additional comments from mikekagan...@openoffice.org Sun Oct 17 01:49:09 +0000 2010 ------- 2mt >On a W2008R2 server, set all the (in my case existing as "allow" per default >"file and printer sharing" firewall rules to "block". >To ease debugging, run "soffice \\myserver\myshare\myfile.odt" from command >line, which should fail to open the file ... >For PATHTYPE_FILE, there is a Win32 call FindFirstFile(...). This single call >takes more than 30s for me! >Waiting 30s is already bad, but we hit that break point 3 times: I hope that you have found the correct place where the delay happens. But the steps that you suggest don't reproduce the exact problem that the affected systems are suffering from. To be specific: what you effectively do is making the server share unreachable (by making the SMB ports blocked). Thus, all communications to SMB have to time out to proceed with the file open error. You should experience the same delay if you try to enter the "\\myserver\myshare" address into the Windows Explorer address bar, or if you enter "notepad \\myserver\myshare\myfile.odt". But the problem is not with opening an unreachable file. We all try to open a file that is perfectly reachable on the share. And when we open it with another program (for instance, notepad), there's no delay. If you open the last test log I attached to the topic (where the webserver was present on the server), you may notice that the communication on the port 80 of the server is initiated by Microsoft-WebDAV-MiniRedir/5.1.2600. The problem seem to be related to the order in which the network redirectors are initiated on a specific client system. If the WebDAV redirector takes precedence over the usual MS Windows Network provider (SMB), (and the port 80 on the server is blocked) then the delay occurs, otherwise file operations are performed instantly. One can speculate that the problem is with the client machine settings (that may be tuned in Windows Exlporer: go to Control Panel->Network Connections- >meny Advanced->Advanced Settings...->Provider Order tab). That could be the case, but if so, any program that makes use of the "FindForstFile" API (or others that use the network redirectors) would be affected. For example, the Explorer would show contents of the remote shares with such delays on the affected systems. But the reality is that no such things happen (other programs work with the shares/files without delays). Thus, I may conclude that the problem is inside the OpenOffice: either it somehow defines the order of redirectors for itself, or the problem if not inside the FindFirstFile() API. The proposal to reduce the nomber of calls to a function is itself useful (and anyway will lead to overall speed increase, which is great), byt won't solve the root of the problem, nor will the use of the parallel threads, because although the program won't seem to "hang" while opening the file, nonetheless the file will be open with a huge delay. I think that the developers need to find the exact circumstances when the problem shows itself (I mean where the port 80 communications take place, since it seems that not every PC has this problem). --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
