Skip to content

Automatic recovery can leave auto-delete queues info behind #20

Closed
@budjb

Description

@budjb

We have a long-running application that takes in HTTP requests and proxies those requests to a worker application via messages over a RabbitMQ broker.

I updated the RabbitMQ java client to 3.3.0 so we can utilize the auto recovering functionality. It works, well, however, I've seen memory usage steadily climb. Analyzing the heap, I see quite a few objects associated with the recovery classes hanging around in memory, and they look to be the culprit of the increasing memory usage. For example, I see 53,143 instances of ConsumerDispatcher, AutorecoveringChannel, RecordedQueue, RecoveryAwareChannelN, and 53,140 AMQImpl$Channel$Close and ShutdownSignalException. Skimming over the text of those exceptions, they seem to be clean shutdowns. All of these instances are held in hash maps that all end up in the autorecovering connection object, which in my example is sitting at 247.3MB of usage.

This app uses RPC-style requests. A temporary queue is created, along with a channel. A message is sent to some queue, and the application consumes via that channel until a message is received or a timeout occurs. In both cases, the consuming is canceled and the channel is closed. At the time the heap dump was taken, there were 3 active requests, which account for the difference in the instance counts.

I'm curious why all of those class instances are hanging around. I'm not sure if it's a bug with the client or our own code. There should be some way to clear out these old instances. Any insight would be appreciated.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions