<p><br>
On Feb 28, 2013 12:59 AM, "Philip Warner" <<a href="mailto:pjw@rhyme.com.au">pjw@rhyme.com.au</a>> wrote:<br>
><br>
> On 28/02/2013 3:45 PM, Michael B Allen wrote:<br>
> > JCIFS should absolutely not be querying DFS during writes and I would be surprised if it actually is. That is something that would<br>
> > require a proper capture to verify.<br>
><br>
> You are probably right about this, but based on 1.3.14 sources:<br>
><br>
>     SmbFileOutputStream.writeDirect(...) calls SmbFile.send(...)<br>
>     SmbFile.send(...) calls resolveDfs(...)<br>
>     resolveDfs(...) calls Dfs.resolve(...)<br>
></p>
<p>Hi Philip,</p>
<p>The those DFS methods should just return immediately after being called once. They cache results.</p>
<p>> Dfs.resolve(...) looks like it does OS-level network stuff unless DFS is disabled, or unless it has succeeded in a call to<br>
> Dfs.resolve(...) recently.<br>
><br>
> My suspicion is that because DFS is enabled, and because DFS is not present, it is retrying for every block it sends. Hence the 400%<br>
> slowdown when DFS is enabled.</p>
<p>I doubt very much that is happening.  But if you can produce a capture that shows a problem I'll fix it (eventually).</p>
<p>> Or it could just the the OS-level calls are really slow.</p>
<p>Jcifs does not call any OS specific functions. It is 100% java.</p>
<p>Mike<br><br></p>
<p>><br>
><br>
><br>
</p>