[jcifs] Re: jcifs-1.1.9 ArrayIndexOutOfBoundsException: -2146866174

[Michael B Allen]

On Thu, 03 Mar 2005 16:51:56 +0100
<madlg3 at vodafone.es> wrote:

> Hi,
> 
> The ArrayIndexOutOfBoundException occurred in Windows, Solaris and HP-
> UX. But today I do not get the same exception, it is vanished!, I got 
> a different exception for Linux, Windows, solaris and HP-Ux against 2 
> different servers, one W2003 and one XP:
> socket closed: euk/10.11.21.219
> java.net.SocketException: Socket closed
> smb://euk;euk:stinker@euk/euk-archive/docs/
> jcifs.smb.SmbException: Timeout waiting for response from server: 
> euk/10.11.21.219
<snip>
> I also try setting the new SmbFile(argv).exists before the loop, but 
> the result is the same, I got time-out for all plattforms.

Ok, so it's something else. It's probably a concurrency issue. Note I
haven't ruled out the possibility that your modified T2Crawler isn't
inadvertantly operating on the same file using multple threads. But
JCIFS has been a little sensitive to senarios such as a session logging
off at the same instant the session is being established. It's probably
a bug in the jCIFS transport. This is one of the reasons I'm re-writing
the transport layer. At some point I'll probably have the stable branch
working with the new transport and no other changes. Perhaps you can
try that.

Otherwise, in general I doubt this problem will occur under normal
conditions. I assume your running 50 threads to test the stability of
jCIFS but in practice this number of threads for the application being
used (crawling) is not recommended for a variety of reasons.

> In relation to the fix in 1.1.9, The reason to believe that HP has 
> poblems is that the machines running Linux, Windows and Solaris do not 
> have any high-load problem(this was fixed in 1.1.9). However, the HP-Ux 
> pa-risc and true 64 do have the problem, having better Processors and 
> much better memory. The last fix seems to solve the problem, although 
> the HP-UX should not need this fix for just 50 users querying an smb 
> server when the small Linux monoprocessor based on PIII does not have 
> any problem. Do you usually test against HP-ux?If not, from now on I 
> will help you with this task.

Your conclusion is incorrect. There is no "high-load problem" with HP-UX.

> The test simulates 50 users browsing at same time and fetching some 
> files, do you think this is an unrealistic scenario for machines like 
> the HP-ux or Solaris?

For this particular application of crawling a single directory, 50 threads
is far too many. What happends is the server is ultimately slower because
it's tring to multiplex so many requests at the same time and there is
more overhead on the JCIFS host because of context switching and lock
contention. You should trying different numbers of threads and see where
the crest in performace is. I think you'll find that between 3 and 5 is
optimal. With workstation class machines it's probably more like 3 [1].

Mike

[1] Note, more threads does not equal faster. There is a fixed amount of
CPU cycles to go around and using multiple threads just allows you to
use clock cycles that would otherwise go unused because another thread
is blocked waiting for a network response.

-- 
IRC - where men are men, women are men, and the boys are FBI agents.