You're making me think ... :-) and that's a good thing.
I would have kept the same handler, just switched the codec. Creating
a new NioConnector is quite expensive.
Hmmm, the (someone else's) code I started from doesn't lend itself well
to that... The handler, codec factory, encoders, and decoders are all
tightly linked functionally with a single discoverable device family
(protocol). And it's working fairly well... ( at least with
2.0.0-M4 ) except for the unbound thread growth on the discovery
failures.
If I run a test with twice our normal expected number of devices
attached and discoverable, everything runs through a few discovery
cycles and eventually each lands on the right port and everyone's fat &
happy for days. There's some number of threads stuck in WAIT states,
but it's been a relatively constant number since the last device was
discovered. [ IOW, the problem hides well ]
But, run the same code configured for continual discovery (ie turn an
external device off, or configure with no valid pairing) and the unbound
thread growth becomes a real issue. My most recent test died after the
thread count hit the 870-880 range after about 7 hours of continual
discovery on a single port.
The symptom was originally seen in the many-device tests, when the
external device powered down, causing continual discovery. I've been
replicating it in a smaller, easier to manage one-port situation where
several drivers are attempted on the same serial port repeatedly. [
None of the activated drivers match the actual device. ]
IOW, I *think* we can live with the creation being expensive, if we can
clean up the destruction.
boB
PS. BTW, except for this thread growth, Mina is handling this very
well, with both serial and Ethernet ports (and protocols that can be
attached to either). I've even watched the same protocol discover and
work properly alternately on serial and Ethernet ports.
Thanks for a great tool!!
Emmanuel Lecharny wrote:
boB Gage wrote:
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 would have kept the same handler, just switched the codec. Creating
a new NioConnector is quite expensive.
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 ]
Hmmmm... Without the code, it's difficult to say. Also, it's now 3
weeks I didn't looked at the code, so I can't give you an decent
advice atm...
--
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.
