We worked with the Free Public MQTT Broker by HiveMQ for about 2 years now. It was reliable, fast and sufficient for the few development use cases we had. Since about 2-3 weeks we cannot connect anymore - if at all, late in the evening (Germany time) when the MQTT Dashboard shows a client count between 100-150k. During day it’s much higher ~250-350k. Did anyone else experience the same?
I have observed the same since late last week. When I try to connect using the hivemq websocket webpage, I am consistently getting connection timeouts.
Connect failed: AMQJSC0001E Connect timed out.
Yet, the broker.hivemq.com webpage shows connections, subscriptions, and activity.
yes we are currently seeing unusual high traffic patterns on the open MQTT Broker. It is in fact frequently overloaded and using load shedding (denying new connections) to remain stable.
I would suggest to move these test cases towards HiveMQ Cloud Serverless or HiveMQ Cloud Starter.
All the best
Georg
Thanks @sauroter, that’s what I already did - moving to “cloud serverless” for now. Nevertheless, a reliable broker.hivemq.com was much appreciated in the past and would be in the future. It’s a pity if people spam it and make it unusable for others.
Thanks for the response, @sauroter. Quite a while ago, I created a cloud instance. At the time, I was fighting connection issues via the cell modem equipped esp32. Until core connectivity was understood better, I chose to eliminate the complexity and cellular data burden of passing a certificate as required by TLS and cloud connections. There is nothing being sent that would be of interest/value to other mqtt clients, so TLS was/is not a high priority. The iot device has retry/recovery logic built in that will tolerate the broker being down - at the cost of more data through the cell connection. In the past few days, my cell traffic has increased by a factor of 3 over the mean daily rate over the past couple years. I can prioritize moving to the non-public broker option, which will likely increase data requirements on each connection due to TLS.. So, there is a tradeoff.
The device is three hours away from here, and I don’t have the capability to reconfigure it without being there. So, until I can be there, I guess we’re just going to be testing the existing recovery logic. If other clients are retrying, that is only compounding the issues on your end. My retry logic does extend the delay between each successive connection attempt, which probably doesn’t help that much in the scenario you describe.
This does seem to be a problem that has only surfaced in the past week or so. With luck, whatever processes that are causing the increased load will decide to move elsewhere or demand less resources.
As a suggestion, you might add/highlight an indicator to broker.hivemq.com that displays the extent of load shedding that is happening. Some sort of admin message on the site might also be appropriate. I think I saw something along those lines over last weekend.
Thanks again,
John
I am in Bhutan teaching for several months. I had planned to use HiveMQ in several demonstrations I prepared in Canada, but was almost never able to connect. At first I thought it might be blocked ports or firewalls but no interventions worked. I emailed HiveMQ twice for advice but after three weeks still have had no reply. I did not know about the possibility of load shedding, so it was very frustrating. I did consider using a serverless cluster but this does not work well when you want an audience to experience an MQTT interaction without signing in. Finally I was forced to change to a different MQTT broker
As an update, the ability to connect to broker.hivemq.com continues to be flakey at best. This is whether using a pubsubclient on an esp32 or the HiveMQ websocket client on Windows and Linux browsers. What this translates to when using a cellular connection is retries that consume MB trying to connect to the broker. Eventually, the cellular consumption exceeds the assigned upper limit and the provider blocks the SIM card (after running up some $ recharges). I will be changing my broker (and it will probably be a competitor’s cloud based solution).