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
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've installed RabbitMQ (latest version downloadable from RabbitMQ website) on my Windows 10 machine. It installed with ERlang 19.1.
I'm trying to install RabbitMQ Web UI Management Tools using the following command (using RabbitMQ Command Prompt):
rabbitmq-plugins enable rabbitmq_management
I'm getting the following error:
The directory name is invalid.
The filename, directory name, or volume label syntax is incorrect.
The filename, directory name, or volume label syntax is incorrect.
Plugin configuration unchanged.
Applying plugin configuration to rabbit#[0x7FF9A8527044]... failed.
* Could not contact node rabbit#[0x7FF9A8527044].
Changes will take effect at broker restart.
* Options: --online - fail if broker cannot be contacted.
--offline - do not try to contact broker.
I've looked up on SO and tried stopping and restarting, overriding erlang cookie, but nothing helps.
I think there's a problem with RabbitMQ itself. The service itself is marked as started, but if I try to telnet the default port (5672) then it fails (it's not a firewall issue - I've disabled it).
Also I don't see an log files created for RabbitMQ or any related Event Logs messages. So it's hard to diagnose exactly the problem.
I also tried uninstalling and re-install both erlang and RabbitMQ. Still didn't help.
How do I further diagnose the problem?
Found a solution to the problem (downgrading Erlang did not work in my case, but just in case I left it on Erlang 18 in case there were other issues with ver 19).
What puzzled my eye was this line: Applying plugin configuration to rabbit#[0x7FF9A8527044]... failed.. Seems like it's trying to connect to rabbit instance at a wrong machine name.
I then ran rabbitmqctl.bat status which failed but again showed that it's trying to connect to [0x7FF9A8527044] while the node name was rabbit#my-mchine-name. So I started reading the configuration section at RabbitMQ website and the solution was simple - setting the node name manually.
All I had to do is add an environment variable named RABBITMQ_NODENAME with the node name being rabbit#localhost. And that's it. Problem solved!
you may be running into issues with Erlang 19 incompatibility. there has been some history of Erlang 19 support problems with RMQ. Try installing Erlang 18 instead.
If that fails, I would recommend using Docker for Windows and installing / running RabbitMQ in that. I've moved all my services like RabbitMQ, MongoDB, etc. into Docker containers and it's made my life as a dev so much simpler.
In my case I had to trash the local account config located at : %APPDATA%\RabbitMQ\.
Deleting the entire folder and reinstalling the service did the trick.
Rabbitmq 3.6.14
Erlang 20.1 OTP
In our production environment we use ActiveMQ 5.4.3
We encouter a problem since we added the option schedulerSupport="true" in the broker. The problem encountered is : javax.jms.JMSException: PageFile is not loaded
I recently discovered that this problem is fixed in the version 5.8
Would it be a problem to use the jar activemq-all-5.8.0.jar with that broker or do I have to upgrade the broker from 5.4.3 to 5.8 too ?
Thanks
It's recommend that client and Broker use the same versions. In theory you can mix versions as the underlying Openwire protocol is backwards compatible however it's not something we test heavily. The usual case if that people can upgrade their Broker and need to leave client's behind and that is known to work better. The problem with mixing versions is that there may be bug fixes in one that are necessary for the other to function correctly so you might still see bad behaviour even though you think it should improve things.
We have an issue with a windows service which uses nServiceBus. At some random moment, the nServiceBus stops processing messages and direct them directly to Error queue, and I have to restart the service. After the restart, the messages arrived in the input message queue are handled, and everything gets back to normal. If we re-drop the messages which were went to error queue, it is processing it successfully without any issue.
We are using log4net logs to audit the message flow and storing in DB. The NServiceBus Handler stops to log in log4net. After we restart the windows service (NServiceBus) then it start to log again. We are NOT able to redproduce this issue in development environment. We are suspecting this could be a NService Bus Memory Leak issue. But we don't know how to confirm this issue and resolve the same.
We are planning to move this Windows Service (NServiceBus) to different server as a trial and error basis. Did anyone face this issue ever and resolved it? Please help us to resolve this issue as it is causing more troubles in Production environment.
NServiceBus Version that we are using : 2.0.0.1329
Message queue and windows service are in the same machine.
I believe you're running on a version of NServiceBus that is about 5 years old and is no longer supported. While I could give you the standard recommendation of upgrading to a more current release, it could very well be that some of the configuration APIs that you're using have been made obsolete so you may need to make some modifications there and/or in the app.configs.
I'm sorry to say that there probably isn't a better solution for you at this time.
In general, I'd suggest trying to track the NServiceBus releases somewhat more closely. If you're within 6-12 months of the current release, you should generally be in good shape.