You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Soumya Pal (JIRA)" <ji...@apache.org> on 2009/02/17 13:02:59 UTC
[jira] Created: (SM-1807) Classes, Objects and Threads still alive
after Undeploying a servicemix component
Classes, Objects and Threads still alive after Undeploying a servicemix component
---------------------------------------------------------------------------------
Key: SM-1807
URL: https://issues.apache.org/activemq/browse/SM-1807
Project: ServiceMix
Issue Type: Bug
Components: servicemix-lwcontainer
Affects Versions: 3.2.1
Environment: Windows XP , Fedora 10
Reporter: Soumya Pal
Hi,
I noticed that after I undeploy a servicemix component (i.e. say delete the zip from teh hotdeploy folder) the component is no longer available as a Service over AMQ. However the classes that were loaded by it are not unloaded.
In my LWC component I had a Timer Thread running (java.util.Timer) which refreshes an in memory Hashmap object. Now all the objects were created when the component was deployed as a service.
Now when I undeploy the service, this Thread still continues running. The HasMap object it refers to, also continues to reside in-memory, as I can see from the logs. Though it won't cause any harm even if I re-deploy the zip again(which in turn instatiates it's own set of objects again), should servicemix not kill all references to objects or unload classes when the component service is un-deployed?
or is it a bug in smix 3.2.1 ? Or am I missing soem configuration which can help me get rid of this. Only issue is if I continue hotdeploying or updating the component zips, the classes loaded and objects in JVM keep on increasing.
Any help will be greatly appreciated
Thanks
Soumya
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1807) Classes, Objects and Threads still
alive after Undeploying a servicemix component
Posted by "Soumya Pal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49713#action_49713 ]
Soumya Pal commented on SM-1807:
--------------------------------
Btw the Timer thread was created to run a daemon.
Here is the code snippets.
The class BufferTimer extends TimerTask. And the logic to update the reqBufferMap object is in its run() method.
Here is the snippet of code which creates the Timer and passes on the reqBufferMap object to it.
HashMap<Integer,RequestBuffered> reqBufferMap = new HashMap<Integer,RequestBuffered>();
BufferTimer bufferTimer = new BufferTimer(reqBufferMap);
tm = new Timer(true);
Date currentTime = new Date();
currentTime.setMinutes(currentTime.getMinutes()+1);
int timeDelayInt = 24;
tm.scheduleAtFixedRate(bufferTimer,currentTime, timeDelayInt*60*60*1000);
Regards,
Soumya
> Classes, Objects and Threads still alive after Undeploying a servicemix component
> ---------------------------------------------------------------------------------
>
> Key: SM-1807
> URL: https://issues.apache.org/activemq/browse/SM-1807
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-lwcontainer
> Affects Versions: 3.2.1
> Environment: Windows XP , Fedora 10
> Reporter: Soumya Pal
>
> Hi,
> I noticed that after I undeploy a servicemix component (i.e. say delete the zip from teh hotdeploy folder) the component is no longer available as a Service over AMQ. However the classes that were loaded by it are not unloaded.
> In my LWC component I had a Timer Thread running (java.util.Timer) which refreshes an in memory Hashmap object. Now all the objects were created when the component was deployed as a service.
> Now when I undeploy the service, this Thread still continues running. The HasMap object it refers to, also continues to reside in-memory, as I can see from the logs. Though it won't cause any harm even if I re-deploy the zip again(which in turn instatiates it's own set of objects again), should servicemix not kill all references to objects or unload classes when the component service is un-deployed?
> or is it a bug in smix 3.2.1 ? Or am I missing soem configuration which can help me get rid of this. Only issue is if I continue hotdeploying or updating the component zips, the classes loaded and objects in JVM keep on increasing.
> Any help will be greatly appreciated
> Thanks
> Soumya
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1807) Classes, Objects and Threads still
alive after Undeploying a servicemix component
Posted by "Barrie Treloar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54809#action_54809 ]
Barrie Treloar commented on SM-1807:
------------------------------------
I've noticed a similar problem in 3.3.1, uninstall does not stop running threads created during the install process.
Here is a thread dump
"QueueThread:queue://org.apache.servicemix.jca.{urn:mcp:testing}file:sender" daemon prio=6 tid=0x00a39090 nid=0x172c waiting on condition [0x3088f000..0x3088fa98]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jca.{urn:mcp}incoming:endpoint" daemon prio=6 tid=0x2af22d58 nid=0x11d8 waiting on condition [0x307cf000..0x307cfb18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jms.{urn:mcp}incoming:endpoint" daemon prio=6 tid=0x28fbfc18 nid=0xce4 waiting on condition [0x3078f000..0x3078fd98]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jms.{urn:mcp:testing}file:sender" daemon prio=6 tid=0x2b898db0 nid=0x1420 waiting on condition [0x3068f000..0x3068fb18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jms.{http://activemq.apache.org/camel/schema/jbi}provider:camel:mcp-eip-su-controlBus" daemon prio=6 tid=0x28b90638 nid=0xb50 waiting on condition [0x304cf000..0x304cfb18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jca.{http://activemq.apache.org/camel/schema/jbi}provider:camel:mcp-eip-su-controlBus" daemon prio=6 tid=0x28f6d408 nid=0x7e0 waiting on condition [0x3040f000..0x3040fc18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jca.{urn:mcp}outgoing:endpoint" daemon prio=6 tid=0x2878b390 nid=0x828 waiting on condition [0x3038f000..0x3038fb18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
"QueueThread:queue://org.apache.servicemix.jms.{urn:mcp}outgoing:endpoint" daemon prio=6 tid=0x2bc35408 nid=0x14e4 waiting on condition [0x300df000..0x300dfa18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:470)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:674)
at java.lang.Thread.run(Thread.java:595)
> Classes, Objects and Threads still alive after Undeploying a servicemix component
> ---------------------------------------------------------------------------------
>
> Key: SM-1807
> URL: https://issues.apache.org/activemq/browse/SM-1807
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-lwcontainer
> Affects Versions: 3.2.1
> Environment: Windows XP , Fedora 10
> Reporter: Soumya Pal
>
> Hi,
> I noticed that after I undeploy a servicemix component (i.e. say delete the zip from teh hotdeploy folder) the component is no longer available as a Service over AMQ. However the classes that were loaded by it are not unloaded.
> In my LWC component I had a Timer Thread running (java.util.Timer) which refreshes an in memory Hashmap object. Now all the objects were created when the component was deployed as a service.
> Now when I undeploy the service, this Thread still continues running. The HasMap object it refers to, also continues to reside in-memory, as I can see from the logs. Though it won't cause any harm even if I re-deploy the zip again(which in turn instatiates it's own set of objects again), should servicemix not kill all references to objects or unload classes when the component service is un-deployed?
> or is it a bug in smix 3.2.1 ? Or am I missing soem configuration which can help me get rid of this. Only issue is if I continue hotdeploying or updating the component zips, the classes loaded and objects in JVM keep on increasing.
> Any help will be greatly appreciated
> Thanks
> Soumya
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.