Apache OpenOffice (AOO) Bugzilla – Issue 105283
Extreme slow down of Openoffice.org when accessing files from Windows Shares, on either UNC paths or mapped drives
Last modified: 2017-05-20 10:55:37 UTC
Open office is *extremely* slow when opening, saving, or closing documents on a windows network drive. This issue occurs for sure on Windows 7 64bit, but there are reports or it occuring on Vista 64bit as well. (See here: http://user.services.openoffice.org/en/forum/viewtopic.php?f=15&t=18862) In my tests, it happens every single time, so it is easy to duplicate. Copy any odf file (or other open office compatible file) onto a network location in Windows 7 ie \\fileserver\share\document.odf Open the document. It will be very slow but will eventually open after a minute or so. Edit the document. Save. Again it will be very very slow. Close the document. Again it will be very very slow. This issue is pretty much a showstopper for anyone using Openoffice.org in a 64bit corporate/business/enterprise environment.
*** Issue 110878 has been marked as a duplicate of this issue. ***
Using 3.2.0 OOO320m12(build:9483) on WinXP SP 3 This is all 32 bit. Can confirm that open /close/save is very slow with UNC path file. A mapped drive is quick - this is the work around for me at the moment. My network drive is provided by samba on ubuntu server 8.10 fwiw.
I have this issue on two computers: W7 Home Premium x64 and x86 both, for files stored on a Windows Home Server (HP MediaSmart version). Using a mapped drive is a work around but not one I prefer.
Should have mentioned: OO v3.2.0
We have this issue, too. Windows XP SP3 x86; OOo 3.2.1; Server is Windows Server 2003 R2. Opening/Saving shows a delay of 20+ seconds before actually doing the action. After that, for about 1 minute, it opens/saves to this share OK, but after this time it starts to delay again. After reading Issue 110878 I installed a webserver on our file server, and it instantly solved the problem. After that I removed the webserver and simply turned the Windows Firewall off, and the problem didn't appear again. But if I turn the firewall on, the problem reappears. I suppose that having a firewall rule that wouldn't silently ignore the requests to port 80 but reply error to sender would be enough.
Same problem here, since servers have been upgraded to windows 2008 64bits. Clients are Win XP, OOo 3.2.1, 32bits
.
I can imagine what the problem is, but I can't reproduce. (And if I imagine correctly, it won't be easy to fix) I tried different firewall settings on my W2008R2 server, and connected from W7 box. I tried adding a blocking rule for tcp/udp ports 80/445 (always only 1 rule the time, I didn't introduce many rules for all combinations). Is it safe to assume the the new rule should be active instantly? I didn't wait very long after changing the rule.... Will a blocking rule overrule an other non-blocking rule, in case I have two rules for the same protocol/port combination? I configured that firewall to use the default settings. I assume my "problem" is that I am in a domain network. Any idea which rule(s) exactly to change after configuring default rules, to reproduce the issue?
@mt: I think the idea is precisely not to block the ports but to have them in "stealth mode" i.e. that they drop the packets and not reject them. I'll try to get more details from the admins tomorrow.
Created attachment 72044 [details] wireshark capture of closing an .odt file (long)
Created attachment 72045 [details] wireshark capture of closing an .odt file (quick)
I have attached two captures made with Wireshark. The first (close_ooo_file_long.pcap) was made with the firewall on; the second (close_ooo_file_quick.pcap) with firewall off. The local ip address is 192.168.0.10; the remote share is on a host with ip address 192.168.1.4. You may notice the attempts to communicate to port 80 of the remote host: packets 171, 210 and 211 in the first file (timestamps 0.04s, 3.05s, and 9.17s) (all unanswered), and packets 206 (timestamp 0.07s, answered by 208), 223 (ts. 0.61s, a. 224), and 225 (ts. 1.16s, a. 226). And those unanswered packets to port 80 in the first case were the ones that delayed the further communications. Hope this helps. Best regards, Mike.
Created attachment 72046 [details] Another capture with a webserver listening on the port 80 on the remote server. Here only one port 80 conversation can be seen (packets 221-224, 228, 229, 231, 232)
I was able to reproduce it this way: 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, then attach the debugger, then use command line again. This way, a break point in "osl_getDirectoryItem" will only be hit for exactly that file, and not for other configuration and UNO stuff. 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: > sal3.dll!osl_getDirectoryItem(_rtl_uString * strFilePath=0x0914b1ec, void * * pItem=0x014ae9b4) Line 3284 C++ sofficeapp.dll!desktop::GetURL_Impl(const String & rName={...}, const boost::optional<rtl::OUString> & cwdUrl={...}) Line 2631 + 0x4c bytes C++ sofficeapp.dll!desktop::DispatchWatcher::executeDispatchRequests(const _STL::vector<desktop::DispatchWatcher::DispatchRequest,_STL::allocator<desktop::DispatchWatcher::DispatchRequest> > & aDispatchRequestsList={...}, bool bNoTerminate=false) Line 198 + 0x2e bytes C++ sofficeapp.dll!desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest & aRequest={...}) Line 989 + 0x1a bytes C++ sofficeapp.dll!desktop::ProcessEventsClass_Impl::ProcessDocumentsEvent(desktop::ProcessEventsClass_Impl * __formal=0x00000000, void * pEvent=0x08435a98) Line 281 + 0x9 bytes C++ > sal3.dll!osl_getDirectoryItem(_rtl_uString * strFilePath=0x08ec15f0, void * * pItem=0x014ad7d8) Line 3284 C++ ucpfile1.dll!fileaccess::shell::getv(long CommandId=929, const rtl::OUString & aUnqPath={...}, const com::sun::star::uno::Sequence<com::sun::star::beans::Property> & properties={...}) Line 1068 + 0x28 bytes C++ ucpfile1.dll!fileaccess::BaseContent::getPropertyValues(long nMyCommandIdentifier=929, const com::sun::star::uno::Sequence<com::sun::star::beans::Property> & PropertySet={...}) Line 878 + 0x1f bytes C++ ucpfile1.dll!fileaccess::BaseContent::execute(const com::sun::star::ucb::Command & aCommand={...}, long CommandId=929, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & Environment={...}) Line 386 + 0x1e bytes C++ ucbhelper4MSC.dll!ucbhelper::Content_Impl::executeCommand(const com::sun::star::ucb::Command & rCommand={...}) Line 1809 + 0x2c bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::getPropertyValuesInterface(const com::sun::star::uno::Sequence<rtl::OUString> & rPropertyNames={...}) Line 686 + 0x53 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::getPropertyValues(const com::sun::star::uno::Sequence<rtl::OUString> & rPropertyNames={...}) Line 623 + 0x13 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::getPropertyValue(const rtl::OUString & rPropertyName={...}) Line 573 + 0x13 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::isDocument() Line 1557 + 0x31 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::openWriteableStream() Line 1240 + 0xb bytes C++ comphelp4MSC.dll!comphelper::MediaDescriptor::impl_openStreamWithURL(const rtl::OUString & sURL={...}, unsigned char bLockFile=' ') Line 820 + 0x10 bytes C++ comphelp4MSC.dll!comphelper::MediaDescriptor::impl_addInputStream(unsigned char bLockFile=' ') Line 569 + 0x14 bytes C++ comphelp4MSC.dll!comphelper::MediaDescriptor::addInputStreamOwnLock() Line 536 C++ filterconfig1.dll!filter::config::TypeDetection::impl_openStream(comphelper::MediaDescriptor & rDescriptor={...}) Line 1149 + 0x9 bytes C++ filterconfig1.dll!filter::config::TypeDetection::impl_askDetectService(const rtl::OUString & sDetectService={...}, comphelper::MediaDescriptor & rDescriptor={...}) Line 1003 C++ filterconfig1.dll!filter::config::TypeDetection::impl_detectTypeFlatAndDeep(comphelper::MediaDescriptor & rDescriptor={...}, const _STL::list<filter::config::FlatDetectionInfo,_STL::allocator<filter::config::FlatDetectionInfo> > & lFlatTypes={...}, unsigned char bAllowDeep=' ', comphelper::SequenceAsVector<rtl::OUString> & rUsedDetectors={...}, rtl::OUString & rLastChance={...}) Line 819 + 0x17 bytes C++ filterconfig1.dll!filter::config::TypeDetection::queryTypeByDescriptor(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lDescriptor={...}, unsigned char bAllowDeep=' ') Line 185 + 0x27 bytes C++ fwkmi.dll!framework::LoadEnv::impl_detectTypeAndFilter() + 0x147 bytes C++ fwkmi.dll!framework::LoadEnv::startLoading() + 0x69 bytes C++ fwkmi.dll!framework::LoadDispatcher::impl_dispatch() + 0x16d bytes C++ fwkmi.dll!framework::LoadDispatcher::dispatchWithReturnValue() + 0x32 bytes C++ comphelp4MSC.dll!comphelper::SynchronousDispatch::dispatch(const com::sun::star::uno::Reference<com::sun::star::uno::XInterface> & xStartPoint={...}, const rtl::OUString & sURL={...}, const rtl::OUString & sTarget={...}, const long nFlags=0, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArguments={...}) Line 88 + 0x29 bytes C++ sofficeapp.dll!desktop::DispatchWatcher::executeDispatchRequests(const _STL::vector<desktop::DispatchWatcher::DispatchRequest,_STL::allocator<desktop::DispatchWatcher::DispatchRequest> > & aDispatchRequestsList={...}, bool bNoTerminate=false) Line 340 + 0x36 bytes C++ sofficeapp.dll!desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest & aRequest={...}) Line 989 + 0x1a bytes C++ > sal3.dll!osl_getDirectoryItem(_rtl_uString * strFilePath=0x08ec15f0, void * * pItem=0x014ad224) Line 3284 C++ ucpfile1.dll!`anonymous namespace'::generateErrorArguments(const rtl::OUString & rPhysicalUrl={...}) Line 98 + 0x28 bytes C++ ucpfile1.dll!fileaccess::throw_handler(long errorCode=11, long minorCode=2, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & xEnv={...}, const rtl::OUString & aUncPath={...}, fileaccess::BaseContent * pContent=0x08ecb648, bool isHandled=true) Line 395 + 0x6c bytes C++ ucpfile1.dll!fileaccess::TaskManager::endTask(long CommandId=929, const rtl::OUString & aUncPath={...}, fileaccess::BaseContent * pContent=0x08ecb648) Line 105 + 0x1e bytes C++ ucpfile1.dll!fileaccess::BaseContent::endTask(long CommandId=929) Line 1312 + 0x29 bytes C++ ucpfile1.dll!fileaccess::BaseContent::execute(const com::sun::star::ucb::Command & aCommand={...}, long CommandId=929, const com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> & Environment={...}) Line 446 + 0x10 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content_Impl::executeCommand(const com::sun::star::ucb::Command & rCommand={...}) Line 1809 + 0x2c bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::getPropertyValuesInterface(const com::sun::star::uno::Sequence<rtl::OUString> & rPropertyNames={...}) Line 686 + 0x53 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::getPropertyValues(const com::sun::star::uno::Sequence<rtl::OUString> & rPropertyNames={...}) Line 623 + 0x13 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::getPropertyValue(const rtl::OUString & rPropertyName={...}) Line 573 + 0x13 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::isDocument() Line 1557 + 0x31 bytes C++ ucbhelper4MSC.dll!ucbhelper::Content::openWriteableStream() Line 1240 + 0xb bytes C++ comphelp4MSC.dll!comphelper::MediaDescriptor::impl_openStreamWithURL(const rtl::OUString & sURL={...}, unsigned char bLockFile=' ') Line 820 + 0x10 bytes C++ comphelp4MSC.dll!comphelper::MediaDescriptor::impl_addInputStream(unsigned char bLockFile=' ') Line 569 + 0x14 bytes C++ comphelp4MSC.dll!comphelper::MediaDescriptor::addInputStreamOwnLock() Line 536 C++ filterconfig1.dll!filter::config::TypeDetection::impl_openStream(comphelper::MediaDescriptor & rDescriptor={...}) Line 1149 + 0x9 bytes C++ filterconfig1.dll!filter::config::TypeDetection::impl_askDetectService(const rtl::OUString & sDetectService={...}, comphelper::MediaDescriptor & rDescriptor={...}) Line 1003 C++ filterconfig1.dll!filter::config::TypeDetection::impl_detectTypeFlatAndDeep(comphelper::MediaDescriptor & rDescriptor={...}, const _STL::list<filter::config::FlatDetectionInfo,_STL::allocator<filter::config::FlatDetectionInfo> > & lFlatTypes={...}, unsigned char bAllowDeep=' ', comphelper::SequenceAsVector<rtl::OUString> & rUsedDetectors={...}, rtl::OUString & rLastChance={...}) Line 819 + 0x17 bytes C++ filterconfig1.dll!filter::config::TypeDetection::queryTypeByDescriptor(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lDescriptor={...}, unsigned char bAllowDeep=' ') Line 185 + 0x27 bytes C++ fwkmi.dll!framework::LoadEnv::impl_detectTypeAndFilter() + 0x147 bytes C++ fwkmi.dll!framework::LoadEnv::startLoading() + 0x69 bytes C++ fwkmi.dll!framework::LoadDispatcher::impl_dispatch() + 0x16d bytes C++ fwkmi.dll!framework::LoadDispatcher::dispatchWithReturnValue() + 0x32 bytes C++ comphelp4MSC.dll!comphelper::SynchronousDispatch::dispatch(const com::sun::star::uno::Reference<com::sun::star::uno::XInterface> & xStartPoint={...}, const rtl::OUString & sURL={...}, const rtl::OUString & sTarget={...}, const long nFlags=0, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArguments={...}) Line 88 + 0x29 bytes C++ sofficeapp.dll!desktop::DispatchWatcher::executeDispatchRequests(const _STL::vector<desktop::DispatchWatcher::DispatchRequest,_STL::allocator<desktop::DispatchWatcher::DispatchRequest> > & aDispatchRequestsList={...}, bool bNoTerminate=false) Line 340 + 0x36 bytes C++ sofficeapp.dll!desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest & aRequest={...}) Line 989 + 0x1a bytes C++ So someone should try to figure out if we can reduce it to one call, which would save a lot of time. That one call will still take a while, but changing that would be more complicated - loading the document would need to be done from an other thread, to not block the main thread. Something we would like to have anyway, but I guess we still don't have it because it's not that easy. Some time, we really should start making use of the threading framework that we have introduced some time ago...
Changing owner to cd (framework team)
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).
cd->mav: Please take a look. You are the expert for low-level file access.
Setting the target to OOo 3.x for now.
This days i spent time to verify logs on us linux server. I found flood records on smbd logs says same trouble as 90065 and i mean too this issue 105283. FindFirstFile implementation or other code cut from service name last character and use it to connect on network = 30s wait on win shares and = log and mini wait on samba shares. Error is only logged if opened file is UNC. I dont test 3.3 but oldies ver have this issue long time ago. Jan 27 09:50:30 boss smbd[5801]: [2011/01/27 09:50:30, 0] smbd/service.c:make_connection(1366) Jan 27 09:50:30 boss smbd[5801]: max (192.168.1.42) couldn't find service dokument opened file \\boss\dokumenty\....xls
Reset assigne to the default "issues@openoffice.apache.org".