[jcifs] threading

[Dan Dumont]

I tried T2Crawler and messed around, broke it, then tried it again.

I observed some interesting behavior that would seem to indicate that
Christopher Hertel might have been right on the ball.

When I tell the threads to start on many hosts that I know to be up, the
threads go, and the output mixes in my console (desired effect).

However, when I stick in a host that does I know will not respond....
instant blocking...

It seems that a lookup is in progress and is blocking up the whole mess.

Is there an easy way that I can disable lookups in the package?
I really don't need them.  I am using ip addresses as it is to connect
to smb hosts, so I do not need the added feature of name lookups.
 

-----Original Message-----
From: Michael B. Allen [mailto:miallen at eskimo.com] 
Sent: Wednesday, February 19, 2003 4:26 PM
To: Dan Dumont
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] threading

On Wed, 19 Feb 2003 12:11:18 -0500
Dan Dumont <dan at canofsleep.com> wrote:

> 
> Well I have a working threading program.  When I tell the threads to
do
> something obnoxious like count to 4 billion, they exit like normal.
Bur
> when I tell them each to open a SmbFile and list contents, they block
> until the scanning is complete or there is a connection time out.
Then
> the next thread tries.

Try the T2Crawler or ThreadedSmbCrawler examples (in the examples
directory). If they don't work then you have a more fundamental
problem. If they do work, compare the code.

The jCIFS client will create a thread for every socket it opens. So when
you call some method it uses that thread to write the request but then
calls wait(). The socket thread will notify() the caller thread when
a message is received (or a timeout occurs). I'm not suggesting this
is related to your problem (you haven't provided 1/10th the necessary
information to properly diagnose your problem) but it might help you to
understand how things work internally.

Finally, if you are trying to "scan" or "crawl" over many hosts it
is highly likely that you will get a wide variety of exceptions and
timeouts. In particular if you try to connect to a machine that was
recently turned off (but it's name was still registered with WINS)
it will hang for ~1min15sec. There is *nothing* that you can do about
this. You cannot kill the thread. If you run the ThreadedSmbCrawler for
example on a big WAN with dozens of workgroups and thousands of hosts
there will be periods where all of the threads are waiting for this "No
route to host" timeout. Also, if you are scanning/crawling you will want
to remove BCAST from the resolveOrder property or every lookup failure
will take an extra 6 seconds.

Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.