[jcifs] threaded network crawler code examples (transport problem)

[Dan Dumont]

>This is not correct but
>after the first negotiation the client will handle requests concurrently.
Yes, you have said this before, however what you said is not happening.


I waited for 8 hours for mpxcount to increase, it never did.  Left the 
indexer running over night and it was still going when i woke up.
I understand what you are saying.  I'm trying to tell you that it's not 
working like what you say.




"Michael B Allen" <mba2000 at ioplex.com>
07/28/2003 04:44 PM
 
        To:     "Christopher R. Hertel" <crh at ubiqx.mn.org>
        cc:     Dan Dumont/Westford/IBM at IBMUS, jcifs at samba.org
        Subject:        Re: [jcifs] threaded network crawler code examples 
(transport      problem)


> On Mon, Jul 28, 2003 at 01:50:36PM -0400, Dan Dumont wrote:
>> It is not clear to me that my workaround is the "correct" solution to
>> this
>> problem.
>>
>> However in my mind there should not be one global maxmpxcount, but a 
map
>> of server->maxmpxcounts
>
> The SMB MaxMpxCount value is negotiated between the client and server on 
a
> per-transport-connection basis, so (from a strictly theory standpoint) 
I'd
> agree with you.  I would also say, though, that with regard to SMB/CIFS
> practice often trumps theory.

As I have explained on at least two occations the maxMpxCount is *static*.
It is initialized to 1 and it is not increased until the client
successfully negotiates with the first server. This is not correct but
after the first negotiation the client will handle requests concurrently.
So the net effect after a long crawling operation is  ... well nothing.
What Dan is doing with his modified version of jCIFS is removing the
maxMpxCount constraint altogether. This violates the CIFS spec and it will
permit the creation of an unlimited number of threads which would likely
result in doing little more than wasting large amounts of resources
because when you add more threads at some point performance *decreases*.

Again I have explained this to Dan multiple times. I have nothing more to
add to the topic. I will eventually fix the static maxMpxCount but even
after doing so it would not satisfy Dan's desire to disable it
alltogether.

Mike