<p><br>
On Feb 25, 2013 5:54 PM, "Philip Warner" <<a href="mailto:pjw@rhyme.com.au">pjw@rhyme.com.au</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Thanks for the prompt reply. While in some sense sleeping is not a performance issue per-se, if it spends 85% of it's time sleeping<br>
> while the app waits, it's at least a perceived performance issue. But that's just nit-picking.<br>
><br>
> The suggestion:<br>
><br>
> > you should disable DFS with jcifs.smb.client.dfs.disabled<br>
><br>
> had a remarkable effect. The time waiting for peekKey() went down to 20% of total time</p>
<p>Hi Philip,</p>
<p>peekKey is called while waiting for a response to a request. So if you eliminate some request that is just timing out then naturally the "performance" is going to look a lot better.</p>
<p>> , and total time dropped by 75% from 5min30 to<br>
> 1min17m. The total time in SmbWrite dropped from 7secs to 2sec.<br>
><br>
> So...this leads to two more questions:<br>
><br>
> Q3: is there any disadvantage in disabling DFS permanently?</p>
<p>Well if you try to access a dfs volume then it's not going to work. But if your using it in a non-corporate home pc type environment then you could disable dfs no problem.</p>
<p>><br>
> Q4: in general terms, if this were a Windows or Linux setup, how would you go about working out what was wrong with having DFS<br>
> enabled? FWIW, I can run a packet sniffer on a Linux server if that helps.<br>
></p>
<p>You really need a capture from android. And a capture is what you really need to figure out the root of the problem.</p>
<p>To be honest now it sounds like jcifs is doing something wrong. It probably shouldn't hang if the server or env doesn't support dfs. And the only way to really figure out what the problem is is to get a capture.</p>

<p>Note: do not post captures to the list. If you send me a capture directly I'll look at it (eventually).</p>
<p>Mike</p>
<p>><br>
> Thanks again!<br>
><br>
><br>
><br>
> On 26/02/2013 4:24 AM, Michael B Allen wrote:<br>
> > It sounds like there's some kind of networking quirk like a socket<br>
> > option that's wrong for the Android JVM. This almost certainly has<br>
> > little or nothing to do with JCIFS. It's not a "performance" issue.<br>
> > The methods that you reference are just sleeping. Although there could<br>
> > easily be something timing out like a DFS referral that isn't<br>
> > applicable because you're not in a domain environment in which case<br>
> > you should disable DFS with jcifs.smb.client.dfs.disabled = false.<br>
> > Otherwise, I'm not familiar with Android development so I have no idea<br>
> > as to how to go about debugging such a thing.<br>
> ><br>
> > Mike<br>
> ><br>
</p>