For instance the run method in TcpTransport doesn't check for isInterrupted on the thead. I tried added it myself but I think readCommand is blocking and the threadgroup interrupt has no affect in blocking I/O so it's not getting back to the while to check whether the thread was interrupted. I wish one of the maintainers would take some interest in this issue because with a little effort some nasty memory leaks could be cleaned up.
On 3/23/07, Ted X Toth <[EMAIL PROTECTED]> wrote:
Well I thought I was on to something. I created a threadgroup and put my thread in it and sure enough the activemq created threads as part of my spring context creation get created in my thread group, great. Then when I close my spring context I get the threadgroup and call interrupt and my thread catches the interrupt exception and completes. The only problem is that now I've got threadgroups hanging around with only activemq related threads in them. It would appear that these threads aren't quiting when they receive the interrupt exception :( Xavier Toth wrote: > On further inspection I see that there are a number of threads started > on behalf of ActiveMQ and I'm wondering if and how these ever get > cleaned up? I've included a super simplified example of a standalone > broker and client along with build and run scripts (the classpath will > have to be changed for these to work on another system). The run > script will generate a hprof dump on exit (Ctrl-C) that can be > inspected with 'hat'. > > On 3/20/07, Xavier Toth <[EMAIL PROTECTED]> wrote: >> I'm using Spring, Lingo and ActiveMQ. My processes routinely create >> new queues use them for awhile and then hopefully destroy them. But >> it's the last part that's got me concerned. I close the Spring context >> from which were created beans of class ActiveMQConnectionFactory, >> ActiveMQQueue, LingoRemoteInvocationFactory and a few others but >> despite my efforts to cleanup I'm getting OutOfMemory exceptions. I've >> run jmap and seen the number of instances of some of these classes >> growing >> overtime and through use. I've run hat on the hprof dumps and see >> that these >> objects are accessible from the rootset but it's unclear to me who is >> hanging on the their references. Is there anything I should be >> explicitly doing in my code when I close the context to make sure >> ActiveMQ cleans up it's objects? Are there any know memory leaks in >> ActiveMQ? I've experience similar results on 3.2.2 and 4.1.0. >> >> Ted >>