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.
