Currently running version RabbitMQ: 3.6.16 Erlang 20.3.4,
Since yesterday night we're seeing this issue in RabbitMQ Webui that some of the queues are showing NaN, Also I attached the screenshot of the issue.
This is a very old issue. I'd suggest updating rabbitmq to the last version.
Currently, we are on 3.9.11. Your version is ~2 years old.
Related
erlang version = 1:24.0.2-1
rabbitmq-server version = 3.8.16-1
Recently installed latest rabbitmq on Ubuntu20.
I verified that all was working fine and consumer was consuming the notification from messaging queue as required.
After approximately a day, rabbbitmq crashed as there was 0 disk space left.
After analysis found that around 10G was consumed by msg_store_transient, to which restarting rabbitmq solved the issue.
But after a day, it happens again.
Can someone help me further?
most likely you are consuming messages without sending back the basic_ack, see for example here the ch.basic_ack
What to do:
check the unacked messages see:
check if you are using too many not persistent messages
check if you are using too many not persistent queues
Issue is Fixed:
We had high number of Ready messages because of which rdq files was taking huge space
There was a bug in code, that was listening to only one queue not all.
Since RabbitMq version 3.8.0 queues are create with x-queue-type: classic by default, this seems to be causing an error on EasyNetQ.
Running the following snippet will trigger an error
this.bus.Receive(queueName, onMessage);
Error
The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=406, text='PRECONDITION_FAILED - inequivalent arg 'x-queue-type' for queue 'TheQueue' in vhost '/': received none but current is the value 'classic' of type 'longstr'', classId=50, methodId=10
I did some tests and I know for a fact that the problem is the queue type, I would like to be able to connect EasyNetQ to this kind of queue but I couldn find any reference in the documentation on how to do this.
Thanks for reporting this. It is in fact a bug in RabbitMQ. I created an issue report here if you would like to follow along. The fix will ship in version 3.8.2.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.
Faced same issue in 3.8.0.
I verified in 3.8.23 - The issue is resolved.
I was following this tutorial.
https://medium.com/swlh/guide-to-nest-js-rabbitmq-microservices-e1e8655d2853
It does clearly mention to use 3.8.2. I still tired 3.8.0 and hit the issue.
I have three redis nodes being watched by 3 sentinels. I've searched around and the documentation seems to be unclear as to how best to upgrade a configuration of this type. I'm currently on version 3.0.6 and I want to upgrade to the latest 5.0.5. I have a few questions on the procedure around this.
Is it ok to upgrade two major versions? I did this in our staging environment and it seemed to be fine. We use pretty basic redis functionality and there are no breaking changes between the versions.
Does order matter? Should I upgrade say all the sentinels first and then the redis nodes, or should the sentinel plane be last after verifying the redis plane? Should I do one sentinel/redis node at a time?
Any advice or experience on this would be appreciated.
I am surprised by the lack of response to this, but I understand that the subject kind of straddles something like stackoverflow and something like stack exchange. I'm also surprised at the lack of documentation I was able to find on the subject.
I did some extensive testing in a staging environment and then proceeded to our production and the procedure I followed seemed to work for the most part:
Upgrading from 3.0.6 to 5.0.5 in our case seems to be working without a hitch. As I said in the original post, we use the basics in redis and there hasn't been much changed from the client perspective.
I went forward upgrading in this order:
The first two sentinel peers and then the sentinel currently in the leader status.
Each of the redis nodes listed as slaves (now known as replicas).
After each node is upgraded, it will want to copy its dump.rdb from the master
A sync can be done to a 5 node from a 3 node, but once a 5 node is the master, a 3 node cannot sync, so once you've failed over to an upgraded node, you can't go back to the earlier version.
Finally use the sentinels to failover to an upgraded node as master and upgrade the former master
Hopefully someone might find this useful going forward.
There is a mention of ActiveMQ real time on the apache ActiveMQ site. But, I am unable to locate any builds for download.
Is it in alpha stage? Is there any way I can try it out?
I did see the activeblaze in the apache SVN repo. Is it expected that we check out the code, build and try?
http://activemq.apache.org/activemq-real-time.html
According to this thread on the ActiveMQ user mailing list the project is "mothballed" (i.e. no longer maintained). That thread was back in 2014.
I joined the ActiveMQ project a few years ago, and I've never seen any development on or questions about any "real time" broker variant.
Recently upgraded to RabbitMQ version 3.2.0 from 2.x previously. The version of pika being used is 0.9.13. Previously when sending "large" messages (20k - 40k bytes...so maybe not that large) it would send the message without any problems. Now with the new RabbitMQ server the message will not send and instead hangs at basic_publish and will not send the message to the server; small messages do not seem to be an issue.
This is causing some frustration because the only thing that has changed is effectively upgrading the server to a newer version.
I noticed that RabbitMQ states on their site that a limit to frame_max size is now set by default. I tried changing my /etc/rabbitmq/rabbit.config file to eliminate the frame_max:
[{rabbit, [{frame_max ,0 }]}].
Then of course restart the service:
service rabbitmq-server restart
I was able to verify this change by using:
rabbitmqctl environment
This did not solve my issue however as the same problem still persists; I can't send large messages to my rabbitmq server. Any ideas on what might be wrong?
The problem, found by the OP himself, was solved by upgrading to pika 0.9.14.
I noticed that my answer in my question was deleted so here is the resolution:
I had to upgrade to pika 0.9.14 ; this solved my problem. There were some issues of compatibility with pika 0.9.13 and a recent upgrade to rabbitmq version 3+
This version of pika can be found here