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
>>


Reply via email to