H, the links seem to imply that the answer to my question is that
you were talking to me and code at my level should be calling
IoConnector.dispose() as part of my clean up for each discovery.
So I put that code in.But it had no visible impact.
So I added debug logging to ensure I had
you are right.
On Tue, May 5, 2009 at 5:59 PM, Maarten Bosteels
mbosteels@gmail.com wrote:
The dispose method is analogous to the close method on java.io.OutputStream
http://java.sun.com/j2se/1.5.0/docs/api/java/io/OutputStream.html#close()
On Wed, May 6, 2009 at 4:13 PM, boB Gage bg...@ekosystems.com wrote:
H, the links seem to imply that the answer to my question is that you
were talking to me and code at my level should be calling
IoConnector.dispose() as part of my clean up for each discovery.
yep.
So I put that code
Got one already - DIRMINA-708. I attached a JIP file before this code
mod (the dispose() call). Do I need to do another one to prove I made
the mod?? :-)
boB
Maarten Bosteels wrote:
On Wed, May 6, 2009 at 4:13 PM, boB Gage bg...@ekosystems.com wrote:
H, the links seem to imply
Le Thu, 30 Apr 2009 22:03:46 +0200,
Emmanuel Lecharny elecha...@apache.org a écrit :
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)
The dispose method is analogous to the close method on java.io.OutputStream
http://java.sun.com/j2se/1.5.0/docs/api/java/io/OutputStream.html#close()
http://java.sun.com/j2se/1.5.0/docs/api/java/io/Closeable.html
see also http://www.javapractices.com/topic/TopicAction.do?Id=24
regards,
Maarten
On Mon, May 4, 2009 at 5:23 PM, boB Gage bg...@ekosystems.com wrote:
I think it was maintenance; and I didn't get back to it until just now.
The site's there now, but I don't see an Add Issue button and do not have a
log in to use So I'm still not sure what to do with this trace file.
(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
). 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
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
.
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
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
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
13 matches
Mail list logo
