[ 
https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711685#action_12711685
 ] 

boB Gage commented on DIRMINA-708:
----------------------------------

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.

Reply via email to