[jcifs] OutOfMemoryError unable to create new native thread

[Michael B Allen]

On Mon, Mar 8, 2010 at 5:20 PM, Peter <peter_zavadsky at symantec.com> wrote:
> Michael B Allen <ioplex <at> gmail.com> writes:
>
>> In particular the broadcasting is refered to as the 'BCAST' method. So
>> again, set netbios.resolveOrder=DNS. If your customer is really
>> actually using WINS then use netbios.resolveOrder=WINS,DNS. Whatever
>> the case, just leave BCAST out of it.
>>
>> Basically you just have a name service problem.
>
> Mike,
>
> Thanks for the explanation.
> It seems that your suggestion would be an ideal solution. However it seems that
> in our case only the BCAST option resolves the (server) name. If I leave it out
> I get UnknownHostException.
> While I could adjust our network configuration to by pass that, I can't force
> our customers to do so. It seems that BCAST is a viable feature of JCIFS, and
> it would be a pity to not support it.

Then you should be setting jcifs.netbios.wins and use WINS and not BCAST.

BCAST and NetBIOS in general is largely obsolete. BCAST broadcasts
name lookups on the local subnet so it is also largely useless. If
your customer is really still using NetBIOS, you should be setting
jcifs.netbios.wins and use the WINS method and not BCAST. Again, this
is all explained in fairly great detail on the Setting Name Resolution
Properties page.

>> I think if you read the above link carefully, you should be able to
>> solve your problem. Interrupting those QueryThreads is a very ugly
>> solution to what is effectively a configuration issue. You just need
>> to understand better what name service lookups are timing out and
>> adjust the configuration to stop them.
>>
>> Mike
>
> I am only trying to point out that there is temporarily a thread leak. Each
> request leaves one thread around doing job which will be wasted.
> That left-behind-thread leads to the OutOfMemoryError in a performance heavy
> app like ours. If that is fixed, the BCAST option would work without
> problems.

There is no thread leak or anything to be fixed. I believe I have
explained this as well as I can.

If you insist on doing it your way, then just replace the body of
UniAddress.lookupServerOrWorkgroup with a straight call to
NbtAddress.getByName so that it just looks up the server and not the
workgroup or vise versa. That will completely eliminate the
QueryThread business altogether.

Good luck,
Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/