You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are running in a Kubernetes environment and when applications run up, the first thing they do is to try building an Environment using the builder. If RabbitMQ is not reachable at that moment (could happen for many reasons), the call throws an exception.
We then now periodically retry building the environment and when the broker becomes available, it connects to it and runs perfectly.
However, it seems like for every unsuccessful build() call, there is a multiThreadIoEventLoopGroup thread remaining in the runnable state, which, for longer downtimes may potentially cause resource problems.
What is the proper way to handle a non-reachable broker when build() is called?
Using 1.1 with RabbitMQ 4.1.
Here's a quick unit test, calling build() 100 times and showing 100 multiThreadIoEventLoopGroup threads remaining afterwards, just run it with no broker available:
importcom.rabbitmq.stream.Environment;
importorg.junit.jupiter.api.Test;
importstaticorg.junit.jupiter.api.Assertions.assertNull;
publicclassEnvironmentThreadsTest {
privatevoidcountThreads() {
ThreadGrouprootGroup = Thread.currentThread().getThreadGroup();
ThreadGroupparentGroup;
while ((parentGroup = rootGroup.getParent()) != null) {
rootGroup = parentGroup;
}
Thread[] threads = newThread[rootGroup.activeCount() * 2]; // Double to ensure we have enough spaceintactualCount = rootGroup.enumerate(threads, true);
inteventLoopGroupThreadCount = 0;
for (inti = 0; i < actualCount; i++) {
Threadthread = threads[i];
if (thread.getName().contains("multiThreadIoEventLoopGroup")) {
eventLoopGroupThreadCount++;
}
}
System.out.println("multiThreadIoEventLoopGroup thread count: " + eventLoopGroupThreadCount);
}
@TestpublicvoidtestEnvironmentThreads() throwsInterruptedException {
Environmentenvironment = null;
for (inti = 0; i < 100; i++) {
try {
environment = Environment.builder().build();
System.out.println("Environment created successfully.");
break;
} catch (Exceptione) {
assertNull(environment);
System.out.println("Environment creation failed as expected since no RabbitMQ server is running");
};
Thread.sleep(100);
countThreads();
}
Thread.sleep(1000);
countThreads();
}
@TestpublicvoidtestEnvironmentThreadsAutoClosable() throwsInterruptedException {
for (inti = 0; i < 100; i++) {
try (Environmentenvironment = Environment.builder().build()) {
System.out.println("Environment created successfully.");
break;
} catch (Exceptione) {
System.out.println("Environment creation failed as expected since no RabbitMQ server is running");
};
Thread.sleep(100);
countThreads();
}
Thread.sleep(1000);
countThreads();
}
}
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
We are running in a Kubernetes environment and when applications run up, the first thing they do is to try building an Environment using the builder. If RabbitMQ is not reachable at that moment (could happen for many reasons), the call throws an exception.
We then now periodically retry building the environment and when the broker becomes available, it connects to it and runs perfectly.
However, it seems like for every unsuccessful build() call, there is a multiThreadIoEventLoopGroup thread remaining in the runnable state, which, for longer downtimes may potentially cause resource problems.
What is the proper way to handle a non-reachable broker when build() is called?
Using 1.1 with RabbitMQ 4.1.
Here's a quick unit test, calling build() 100 times and showing 100 multiThreadIoEventLoopGroup threads remaining afterwards, just run it with no broker available:
Beta Was this translation helpful? Give feedback.
All reactions