mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From boB Gage <bg...@ekosystems.com>
Subject Re: Unbound thread growth...
Date Thu, 30 Apr 2009 17:37:30 GMT
Emmanuel,

That's kind of how the original C++ code that I'm porting worked...

The various devices we use each have their own serial parameters (baud, 
stop/start/partity bits et al) so all have their own SerialAddress 
objects to open & close.    Each device handler (ie our code) has it's 
own codec factory -- so there's not a single shared one for all the 
devices to be discovered (that would be way too unwieldy for words).

I've tried re-using IoConnector objects and just change handlers, but 
the IoConnector.setHandler() method (IoService.java) complains bitterly 
if I assign a new handler to an existing connection.

I have eliminated the synchronized clauses as a source, and had my Java 
understanding expanded in the process.  :-)   One of the two unbound 
threads *is* caught in that quoted wait() call however.    Perhaps 
because we failed to flush a failed session before closing it???  [ the 
notify is in a flush ]

Thanks again!
boB

Emmanuel Lecharny wrote:
> boB Gage wrote:
>> Hi again...
>>
>> I am working on an application that has to discover serial devices 
>> from a large set of known devices (each represented by their own 
>> collection of ProtocolHandler, CodecFactory, Encoders, and Decoders).
>>
>> In the process of doing this, I am running through a list of known 
>> protocols, for each I:
>>   Create an IoConnector and a SerialAddress
>>   Attempt to connect -- which eventually fails because this is the 
>> wrong protocol
>>   Cycle to the next & try it...
>>
>> Eventually (assuming it's there to be found) the right combination is 
>> attempted and all is good.
>>
>> BUT....   turn off that device (or attach something that doesn't 
>> match any of the known protocols) and you can see an unbound thread 
>> growth.
>>
>> Each cycle through the discovery process above generates several 
>> (six-ish) threads, most of which die.    Two don't, and remain in a 
>> WAITING state forevermore.
>>
>> According to JProfiler, they are:
>>   SerialConnector-#-idleStatusChecker created from 
>> org.apache.mina.transport.serial.SerialConnector.<init>()
>> and
>>   Thread-# created from 
>> org.apache.mina.core.session.IoSession.write(java.lang.Object)
>>
>> The various numbers in the Thread-# names increment by 4 in the 
>> threads that are left behind after each cycle (ie 4 get created, 3 
>> die -- the same 3 by creation order) -- The SerialConnector numbers 
>> increment by one. (ie. none of the idleStatusChecker threads ever 
>> goes away)
>>
>> So far I have seen no bound in the thread creation.  In the execution 
>> I am currently profilling, my baseline was way back at time =0:50 
>> with a thread count of 10.   I'm now at time=243:33 with a thread 
>> count of 463.
>>
>> Any clues would be greatly appreciated!!!
>
> Hi boB,
>
> sorry for the latency...
>
> Why are you trying to connect each time to test the protocol for the 
> device ? You should be able to connect only once, and deal with the 
> different protocols in the Codec filter, switching from one codec to 
> the other until you get the right one, or ended without any match.
>
> Doing so, you should be able to avoid creating useless connectors...
>
>

-- 
boB Gage
Software Engineer
Merge Healthcare


This message is a PRIVATE communication. This message and all
attachments are a private communication and may be confidential or
protected by privilege. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of the
information contained in or attached to this message is strictly
prohibited. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.


Mime
View raw message