Replies: 2 comments 1 reply
-
You deploy 2 instances of the same application, is that correct? |
Beta Was this translation helpful? Give feedback.
-
|
yes that is correct |
Beta Was this translation helpful? Give feedback.
-
|
I could not reproduce the issue. Can you provide a step-by-step procedure? Here is the procedure I used. We expect something similar from your end to help us diagnose the issue. Start a 3-node cluster. Using the stream Java client Docker setup is convenient: (to stop the cluster later: In another terminal tab, get Stream PerfTest and run it to simulate a super stream consumer (it creates the super stream as well): In yet another terminal tab, run another consumer: List the consumers of the group for the List the Java processes with Kill one of the Stream PerfTest processes: List the consumers on the There is still a consumer, it was inactive before and has been promoted to active. |
Beta Was this translation helpful? Give feedback.
-
Community Support Policy
RabbitMQ version used
4.0.5
Erlang version used
27.2.x
Operating system (distribution) used
Linux version 5.15.153.1-microsoft-standard-WSL2
How is RabbitMQ deployed?
Community Docker image
rabbitmq-diagnostics status output
See https://www.rabbitmq.com/docs/cli to learn how to use rabbitmq-diagnostics
Logs from node 1 (with sensitive values edited out)
See https://www.rabbitmq.com/docs/logging to learn how to collect logs
Logs from node 2 (if applicable, with sensitive values edited out)
See https://www.rabbitmq.com/docs/logging to learn how to collect logs
Logs from node 3 (if applicable, with sensitive values edited out)
See https://www.rabbitmq.com/docs/logging to learn how to collect logs
rabbitmq.conf
See https://www.rabbitmq.com/docs/configure#config-location to learn how to find rabbitmq.conf file location
Steps to deploy RabbitMQ cluster
docker-compose up
glrabbitmq:
restart: always
hostname: acm_rabbit_node_1
image: rabbitmq:4.0.6-management
volumes:
- rabbitmq:/var/lib/rabbitmq
- ./rabbit/enabled_plugins:/etc/rabbitmq/enabled_plugins
- ./rabbit/rabbitmq.conf:/etc/rabbitmq/rabbitmq.conf
ports:
- ${LISTEN_IP}:5672:5672
- ${LISTEN_IP}:5552:5552
- ${LISTEN_IP}:25672:25672
- ${LISTEN_IP}:15672:15672
networks:
- glnet
Steps to reproduce the behavior in question
A super stream 'CmmnEvents' is created with 8 partitions.
On 2 different servers we deploy an application that uses the java stream client 0.22 to create one Environment (connection) with 2 single active consumers (with the same name) on the superstream.
When the clients start up we can see that the 8 partitions of the superstream each get a single active consumer, nicely balanced between the 2 connections. When one server gets shut down nicely, the application calls the close methods on the consumers and we can see that the other connection perfectly takes over all the partitions with a single active consumer. But when we simulate a crash (kill) of one client, the other connection does not take over every partition, but always does it for 2 of them. So 2 others don't get a single active consumer anymore and our application fails to consume messages from those partitions.
When only one consumer is defined per client application, it all works fine.
From the rabbit mq server log it seems that during this crash scenario the server does not send RPC calls about the 2 failing partitions, while it does for the other 6.
advanced.config
See https://www.rabbitmq.com/docs/configure#config-location to learn how to find advanced.config file location
Application code
# PASTE CODE HERE, BETWEEN BACKTICKSKubernetes deployment file
What problem are you trying to solve?
When multiple client applications define multiple single active consumers (with the same name) on the same partitioned superstream, and when one client crashes, we expect the remaining client to take over consuming all the partitions, but this scenario always ends with 2 of the 8 partitions unconsumed.
Beta Was this translation helpful? Give feedback.
All reactions