Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When the NATS server is unavailable and the number of reconnection times is set to infinite, memory leakage occurs on the NATS client. #1135

Open
hjk235456 opened this issue May 11, 2024 · 1 comment
Labels
needs info Additional info is needed

Comments

@hjk235456
Copy link

Observed behavior

When the number of reconnection times is set to -1 and the server is down, messages are stacked in the queue and will not be consumed.

1715410907127-c9l

optionBuilder
.connectionName(connectName)
.connectionTimeout(Duration.ofMillis(2 * CONNECTING_TIMEOUT))
.reconnectWait(Duration.ofMillis(reconnectWaitTime))
.maxReconnects(-1)
.executor(es)
.servers(servers)
.userInfo(natsUser, natsPassword);

When the connection fails, the reconnection function is invoked. The _poison message is placed in the outgoing and reconnectOutgoing queues of NatsConnectionWriter.

1715411296188-qlm

1715411316195-i5y

Expected behavior

The number of reconnection times is set to -1, and the NATS server is not started. In this case, memory leakage does not occur.

Server and client version

jnats-2.15.6-htrunk2.jar

Host environment

No response

Steps to reproduce

  1. Set maxReconnects in the connection parameters to -1.
  2. The NATS server is not started.
@hjk235456 hjk235456 added the defect Suspected defect such as a bug or regression label May 11, 2024
@scottf
Copy link
Contributor

scottf commented May 19, 2024

@hjk235456 You said:

When the number of reconnection times is set to -1 and the server is down, messages are stacked in the queue and will not be consumed.

Yes message are kept in the queue based on maxMessagesInOutgoingQueue. Messages consume memory. Does the memory usage stay up after reconnect? Remember it will take some amount of time to empty the queue.

@scottf scottf added needs info Additional info is needed and removed defect Suspected defect such as a bug or regression labels May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs info Additional info is needed
Projects
None yet
Development

No branches or pull requests

2 participants