[jcifs] Possible deadlock?

[Jake Goulding]

Thanks for the good information!

However, I happen to be running this particular implementation  
through the JVM invocation interface. The crawler itself is written  
in C, and I call through to the Java code. I'm fairly certain that  
the CTRL-\ will not work through that layer. Could this possibly  
cause my problems?

Using jSwat, I can see that of the 50 threads, only this one is  
currently running.

Note that I seem to be able to crawl all sorts of setups fine, it's  
just when I start crawling a handful of servers (18 I think), I'll  
get this lock.

The crawler also reports that the last status update from that thread  
was 29895 seconds ago (8+ hours, far beyond any jCIFS default timeouts).

I will definitely check the list for good properties to use.

Thanks!


On Aug 19, 2006, at 11:36 AM, Michael B Allen wrote:

> I doubt this is a deadlock. A deadlock is when two threads are waiting
> for each other to complete but can't because they're trying to access
> the same resource. To determine if a deadlock has occured, wait for
> your program to hang and then invoke a thread dump (Ctrl-\ on UNIX,
> don't recall what the trigger is on Windows). If threads are  
> deadlocked
> the thread dump will indicate so.
>
> It is not uncommon for a host to be unresponsive such that the client
> will hang. For example, if there is no reply to an initial SYN packet
> it takes about 1 min 15 sec to timeout. But everything should  
> eventually
> timeout somewhere and continue.
>
> Finally, for efficient crawling there is a cocktail of properties to
> set. You can find them by searching the list archives. Otherwise, if
> you're just testing then be patient or fix the broken host.
>
> Mike
>
> On Sat, 19 Aug 2006 09:54:16 -0400
> Jake Goulding <goulding at vivisimo.com> wrote:
>
>> Hey all,
>>
>> I am using jCIFS do do a crawl of a bunch of local computers (via the
>> C$ share). Basically it is just a test to push it to the limit.
>>
>> However, I seem to consistently get a thread (or a few) stuck on a
>> particular host. The host is not constant between runs, but if there
>> are a few threads, they all are stuck on the same host.
>>
>> This time I have jSwat connected to it, so I can actually figure out
>> what is happening where.
>>
>> It is currently stuck in TransactNamedPipeInputStream.read, line 71
>>
>> This line has a lock.wait() call, and while I'm not particularly  
>> well-
>> versed with how jCIFS does its locking, but I cannot find a notify
>> call that corresponds to it.
>>
>> Any help is appreciated, and I plan on just leaving the debugger
>> connected until I figure this out :-)
>>
>> Thanks!