Duplicate Message Queue in RabbitMQ - 3.8.14 version

[Mahesh935525]

Describe the bug

Hi,

We have installed the RabbitMQ-3.8.14 version in Azure cloud and to process the message we have used consumers added in the RabbitMQ. After installing we are getting duplicate messages added to the RabbitMQ.

Please let me know if is there any issue with the RabbitMQ-3.8.14 version.

Reproduction steps

we are using the below dependency version

python==2.7
numpy==1.16.0
pandas==0.22
psycopg2==2.7.3.1
amqp<2.0,>=1.4.9
anyjson==0.3.3
beautifulsoup4==4.3.2
billiard<3.4,>=3.3.0.23
celery==3.1.23
dj-database-url==0.2.1
django-celery==3.0.11
Django==1.4.3
gdata==2.0.17
geopy==0.94.2
gspread==0.3.0
gunicorn==0.17.2
imageio==1.3
kombu<3.1,>=3.0.34
lxml==3.4.4
mock==1.0.1
newrelic==2.56.0.42
rsa==4.5
oauth2client==1.5.0
pyactiveresource==1.0.2
pyOpenSSL==18.0.0
python-dateutil==1.5
pytz==2012j
PyYAML==3.10
ShopifyAPI==1.0.6
wsgiref==0.1.2
coverage==4.5.1
nose>=1.0
xmltodict==0.8.3
django-db-pool==0.0.10
pprintpp==0.4.0
psutil==5.7.0

Expected behavior

The Duplicate Message should not be added into the RabbitMQ

Additional context

No response

[mkuratczyk]

3.8.x has been out of support for well over a year. Do not use it.
Either way it's almost certainly not a bug in RabbitMQ but either a behaviour you didn't expect, a matter of how you configured bindings or something like that. If you want some assistance, start a dissuasion and share a simple executable example that shows the behaviour.

[michaelklishin]

@Mahesh935525 you haven't provided any evidence that this is an issue with RabbitMQ. If you may using a routing topology that routes a message to multiple queues. Your applications may be requeueing messages, publishing them twice in certain conditions, et cetera.

We are not aware of any scenarios where RabbitMQ itself would duplicate a message in a queue (like I said above, a routed message can and will be routed to N queues, each getting a copy, with certain exchange types or exchange/routing key combinations).

We will not accept a claim of a bug without evidence. Start with putting together an executable example that reproduces the issue with 3.12.8, put it up on GitHub in a repo we can clone and inspect, and see what your clients actually do (not what you believe they should be doing).