[
https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711685#action_12711685
]
boB Gage edited comment on DIRMINA-708 at 5/21/09 9:44 AM:
-----------------------------------------------------------
Uh oh... I think I fixed it. :-)
The documentation for IoSession tells us:
CloseFuture close(boolean immediately)
Closes this session immediately or after all queued write requests are
flushed. This operation is asynchronous. Wait for the returned CloseFuture if
you want to wait for the session actually closed.
Parameters:
immediately - true to close this session immediately (i.e. close()).
false to close this session after all queued write requests are flushed (i.e.
#closeOnFlush()).
----
We want all outgoing data to be flushed, so we had:
CloseFuture cf = session.close(false); // Mina M2->M4 change,
was: session.closeOnFlush();
cf.await(closeTimeout, TimeUnit.SECONDS);
if ( cf.isClosed() ) {
...
}
and observe all of the thread growth behaviour discussed here and in the
listserv.
Changing the false close() parameter to true eliminates the thread growth. [
Actually it limits it -- the *first* cycle through all of the possible
protocols has an upward tilt, but after that the thread graph's a nice flat
line with bumps. ]
Okay, I'll admit it -- I didn't fix it, I just found a way to avoid it. :-)
'sgood enough for me.
was (Author: bgage):
Uh oh... I think I fixed it. :-)
The documentation for IoSession tells us:
CloseFuture close(boolean immediately)
Closes this session immediately or after all queued write requests are
flushed. This operation is asynchronous. Wait for the returned CloseFuture if
you want to wait for the session actually closed.
Parameters:
immediately - true to close this session immediately (i.e. close()).
false to close this session after all queued write requests are flushed (i.e.
#closeOnFlush()).
----
We want all outgoing data to be flushed, so we had:
{code}
CloseFuture cf = session.close(false); // Mina M2->M4 change,
was: session.closeOnFlush();
cf.await(closeTimeout, TimeUnit.SECONDS);
if ( cf.isClosed() ) {
...
}
{code}
and observe all of the thread growth behaviour discussed here and in the
listserv.
Changing the {{false}} close() parameter to {{true}} eliminates the thread
growth. [ Actually it limits it -- the *first* cycle through all of the
possible protocols has an upward tilt, but after that the thread graph's a nice
flat line with bumps. ]
Okay, I'll admit it -- I didn't fix it, I just found a way to avoid it. :-)
'sgood enough for me.
> Unbound thread growth on discovery attempts
> -------------------------------------------
>
> Key: DIRMINA-708
> URL: https://issues.apache.org/jira/browse/DIRMINA-708
> Project: MINA
> Issue Type: Bug
> Reporter: boB Gage
> Attachments: profile-mina.txt.gz
>
>
> Using several different possible protocol handlers (handler, codecs, et al)
> on several potential ports (serial and/or network), our code attempts to
> discover devices on the far end and attach the proper decoders on the proper
> ports.
> Generally, this process is working, however, every failed discovery attempt
> has launched roughly 6 threads, but only destroyed roughly 4 of them. The
> 2 delta threads sit in WAIT states forever.
> More details are available in the "Unbound thread growth" thread of the
> listserv.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
