You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Hadrian Zbarcea (JIRA)" <ji...@apache.org> on 2010/01/08 04:43:13 UTC
[jira] Created: (CXF-2606) ThreadGroup in the default workqueue
gets prematurely destroyed
ThreadGroup in the default workqueue gets prematurely destroyed
---------------------------------------------------------------
Key: CXF-2606
URL: https://issues.apache.org/jira/browse/CXF-2606
Project: CXF
Issue Type: Improvement
Components: Core
Affects Versions: 2.2.2
Environment: IBM JDK6
Reporter: Hadrian Zbarcea
An IllegalThreadStateException gets thrown as shown in the stack below when a new Thread is added to the default workqueue. This does not happen with the Sun JDK and it was not encountered with the IBM JDK5 either.
The Exception gets thrown because the ThreadGroup is destroyed by the time we add the new thread because the core pool size (low watermark) is 0, the number of threads is 0 and is a daemon thread.
{code}
Throwable occurred: java.lang.IllegalThreadStateException
at java.lang.ThreadGroup.checkNewThread(ThreadGroup.java:147)
at java.lang.Thread.initialize(Thread.java:332)
at java.lang.Thread.<init>(Thread.java:267)
at java.lang.Thread.<init>(Thread.java:225)
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory.newThread(AutomaticWorkQueueImpl.java:162)
at java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652)
at org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueueImpl.java:249)
at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:83)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
{code}
A workaround is to set the lowWaterMark to something >=1 so that the ThreadGroup never gets destroyed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2606) ThreadGroup in the default workqueue
gets prematurely destroyed
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp updated CXF-2606:
-----------------------------
Fix Version/s: (was: 2.3)
2.1.9
Assignee: Daniel Kulp
> ThreadGroup in the default workqueue gets prematurely destroyed
> ---------------------------------------------------------------
>
> Key: CXF-2606
> URL: https://issues.apache.org/jira/browse/CXF-2606
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.2.2
> Environment: IBM JDK6
> Reporter: Hadrian Zbarcea
> Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
>
> An IllegalThreadStateException gets thrown as shown in the stack below when a new Thread is added to the default workqueue. This does not happen with the Sun JDK and it was not encountered with the IBM JDK5 either.
> The Exception gets thrown because the ThreadGroup is destroyed by the time we add the new thread because the core pool size (low watermark) is 0, the number of threads is 0 and is a daemon thread.
> {code}
> Throwable occurred: java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.checkNewThread(ThreadGroup.java:147)
> at java.lang.Thread.initialize(Thread.java:332)
> at java.lang.Thread.<init>(Thread.java:267)
> at java.lang.Thread.<init>(Thread.java:225)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory.newThread(AutomaticWorkQueueImpl.java:162)
> at java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672)
> at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueueImpl.java:249)
> at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:83)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
> {code}
> A workaround is to set the lowWaterMark to something >=1 so that the ThreadGroup never gets destroyed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2606) ThreadGroup in the default workqueue
gets prematurely destroyed
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hadrian Zbarcea resolved CXF-2606.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.3
2.2.6
Fixed by dkulp in r896888,896994. Thanks.
> ThreadGroup in the default workqueue gets prematurely destroyed
> ---------------------------------------------------------------
>
> Key: CXF-2606
> URL: https://issues.apache.org/jira/browse/CXF-2606
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.2.2
> Environment: IBM JDK6
> Reporter: Hadrian Zbarcea
> Fix For: 2.2.6, 2.3
>
>
> An IllegalThreadStateException gets thrown as shown in the stack below when a new Thread is added to the default workqueue. This does not happen with the Sun JDK and it was not encountered with the IBM JDK5 either.
> The Exception gets thrown because the ThreadGroup is destroyed by the time we add the new thread because the core pool size (low watermark) is 0, the number of threads is 0 and is a daemon thread.
> {code}
> Throwable occurred: java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.checkNewThread(ThreadGroup.java:147)
> at java.lang.Thread.initialize(Thread.java:332)
> at java.lang.Thread.<init>(Thread.java:267)
> at java.lang.Thread.<init>(Thread.java:225)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory.newThread(AutomaticWorkQueueImpl.java:162)
> at java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672)
> at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652)
> at org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueueImpl.java:249)
> at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:83)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
> {code}
> A workaround is to set the lowWaterMark to something >=1 so that the ThreadGroup never gets destroyed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.