You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "boB Gage (JIRA)" <ji...@apache.org> on 2009/05/04 17:47:30 UTC
[jira] Created: (DIRMINA-708) Unbound thread growth on discovery
attempts
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
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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711353#action_12711353 ]
Emmanuel Lecharny commented on DIRMINA-708:
-------------------------------------------
Hi,
I have looked at the traces, but as you can imagine, it's far from being easy to analyze what's going on. Since you attached it, a major bug has been fixed, which took me 3 full days (DIRMINA-712).
I understand that it's a major issue for you, but you may also consider that as volunteers, we have a limited amount of time to work on the project.
As a side effect, yes, sure, if you want to dig into the code, and find a fix, that would be greatly appreciated ! Anyone can help, this is basically how it works...
> 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.
[jira] Updated: (DIRMINA-708) Unbound thread growth on discovery
attempts : Improve documentation
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-708:
--------------------------------------
Fix Version/s: (was: 2.0.0-RC2)
2.0.0
moved to 2.0.0
> Unbound thread growth on discovery attempts : Improve documentation
> -------------------------------------------------------------------
>
> Key: DIRMINA-708
> URL: https://issues.apache.org/jira/browse/DIRMINA-708
> Project: MINA
> Issue Type: Task
> Affects Versions: 2.0.0-M5
> Reporter: boB Gage
> Fix For: 2.0.0
>
> 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.
[jira] Updated: (DIRMINA-708) Unbound thread growth on discovery
attempts : Improve documentation
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-708:
--------------------------------------
Affects Version/s: 2.0.0-M5
Fix Version/s: 2.0.0-RC1
Issue Type: Task (was: Bug)
Summary: Unbound thread growth on discovery attempts : Improve documentation (was: Unbound thread growth on discovery attempts)
Affected to 2.0.0-RC1
> Unbound thread growth on discovery attempts : Improve documentation
> -------------------------------------------------------------------
>
> Key: DIRMINA-708
> URL: https://issues.apache.org/jira/browse/DIRMINA-708
> Project: MINA
> Issue Type: Task
> Affects Versions: 2.0.0-M5
> Reporter: boB Gage
> Fix For: 2.0.0-RC1
>
> 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.
[jira] Updated: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "boB Gage (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
boB Gage updated DIRMINA-708:
-----------------------------
Attachment: profile-mina.txt.gz
JIP output from short execution.
Four different discovery cycles appear in the run, at time deltas: 0:27, 0:55, 2:06, and 2:42.
Manually halted before fourth discovery attempt timed out. ( Each protocol defines different time out rates, that last one was going to take several minutes )
> 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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711687#action_12711687 ]
Emmanuel Lecharny commented on DIRMINA-708:
-------------------------------------------
Great !
I suggest then we lower the issue to 'Task' with a 'major' level, changing the title to 'Improve documentation on the session removal'.
> 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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711393#action_12711393 ]
Emmanuel Lecharny commented on DIRMINA-708:
-------------------------------------------
A quick look at the code shows that if the thread is locked, it's because the flush() method is not called. Let's walk the code :
We have a writeMonitor which is used in two places ; the WriteWorker and the SerialIoProcessor.
- In the WriteWorker :
...
// wait for more data
synchronized (writeMonitor) {
try {
writeMonitor.wait();
} catch (InterruptedException e) {
log.error("InterruptedException", e);
}
}
...
- in the SerialIoProcessor :
...
public void flush(SerialSessionImpl session) {
if (writeWorker == null) {
writeWorker = new WriteWorker();
writeWorker.start();
} else {
synchronized (writeMonitor) {
writeMonitor.notifyAll();
}
}
}
...
This flush method is called by the SerialIoProcessor.remove() method, and the flush method is the only place the WriterWorker is created.
Now note the sequence :
1) we start the SerialSessionImpl
2) It creates everything, and the remove() method is called when there is an exception
3) The remove() method do some cleaning, and call the flush() method (this is the only place this method is called)
4) The flush method create a new WriteWorker, as this is the only place we create it in the code
5) The WriteWorker is started, calls flushWrites()
6) When this methods returns, the WriteMonitor wait for notification
7) As soon as the SerialIoProcessor.remove() method will be called, the flush(à method will be called and it will notify the WriteMonitor, releasing the thread, if it were blocked on a wait().
The remove() is invoked when the session is closed. I don't have the code of your application, so I can't tell if you close the session, and when. Also there is something strange I see in the traces : if you check the thread 30, you can see that the SerialSessionImpl.flushWrites() method is called, and end with a call to PdrProtocolEngine.messageSent() method, which does not return. I'm wondering if this method is not supposed to timeout at some point, and then close the session, if it can't write to the client.
This is a bit difficult to say what'ss really going in in your app, as I don't see the code, so consider those elements as semi blind guesses ...
> 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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711645#action_12711645 ]
Emmanuel Lecharny commented on DIRMINA-708:
-------------------------------------------
Seems that the app is not blocked in the PdrProtocolEngine.messageSent() method, but more likely on the WriterMonitor wait then. Which makes sense ...
So I guess that this call to the remove() method is mandatory at some point, in order to get the flush() method to be called. This part of the code is not one I'm comfortable with, as I never used it. I guess that closing the session should either call the remove() method before or do it inside the close() handling at some point.
> 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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "boB Gage (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DIRMINA-708) Unbound thread growth on discovery
attempts : Improve documentation
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-708:
--------------------------------------
Fix Version/s: (was: 2.0.0-RC1)
2.0.0-RC2
> Unbound thread growth on discovery attempts : Improve documentation
> -------------------------------------------------------------------
>
> Key: DIRMINA-708
> URL: https://issues.apache.org/jira/browse/DIRMINA-708
> Project: MINA
> Issue Type: Task
> Affects Versions: 2.0.0-M5
> Reporter: boB Gage
> Fix For: 2.0.0-RC2
>
> 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.
[jira] Resolved: (DIRMINA-708) Unbound thread growth on discovery
attempts : Improve documentation
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRMINA-708.
---------------------------------------
Resolution: Fixed
Added some info in the IoSession.close( immediately ) method's Javadoc.
> Unbound thread growth on discovery attempts : Improve documentation
> -------------------------------------------------------------------
>
> Key: DIRMINA-708
> URL: https://issues.apache.org/jira/browse/DIRMINA-708
> Project: MINA
> Issue Type: Task
> Affects Versions: 2.0.0-M5
> Reporter: boB Gage
> Fix For: 2.0.0
>
> 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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "boB Gage (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711638#action_12711638 ]
boB Gage commented on DIRMINA-708:
----------------------------------
I'm unsure as to how anything could get stuck inside PdrProtocolEngine.messageSent(), the entire method is reproduced here:
public abstract class PdrProtocolEngine extends IoHandlerAdapter {
...
@Override
public final void messageSent(IoSession session, Object message) {
logger.debug("messageSent(session, " + message + ")");
}
...
}
Is there some step I've missed that I should be doing in the overridden method?? This particular one was a placeholder we never went anywhere with; I'll try simply removing it to see if the problem disappears.
----
I do recall one of the changes we had to do when updating to M4 (I think we were at M2 before that?) -- we had been using IoSession.closeOnFlush() which got removed so we had to drop back to a straight close() method.
Since then our code has called close methods, but there is no flush anywhere that we use or that I am aware of.
Matter of fact, a search for flush through our project uncovers only my notes from that upgrade and from chasing this bug -- we have zero specific flush calls in our code.
Is this a problem?? I assumed Mina will flush the sessions it is closing -- or at least trigger whatever threads it may have launched to control that session. Is there something more I should do beyond calling the IoSesison.close() method to bring down a session that fails discovery??
----
Digging now... more later
> 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.
[jira] Commented: (DIRMINA-708) Unbound thread growth on discovery
attempts
Posted by "boB Gage (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711347#action_12711347 ]
boB Gage commented on DIRMINA-708:
----------------------------------
It has been over two weeks since I collected profile data and attached it to this ticket as requested.
Is anything going to be done about this or should I be digging into the Mina code trying to fix it myself???
> 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.
[jira] Issue Comment Edited: (DIRMINA-708) Unbound thread growth on
discovery attempts
Posted by "boB Gage (JIRA)" <ji...@apache.org>.
[ 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.