HiveMQ Clients Opening And Closing Connections

I’m new to HiveMQ and I’m planning to use it for one of my projects and I woukld like to know if the client connections to HiveMQ are similiar to database connections where you have a fixed number of connections and you pool them. Is a HiveMQ client connection the same way to be handled or can I open and close them for each and every single message that my application will be sending. Could someone point me to some documentation on this please?

Hello @Joesan ,

Thank you for the outreach!

Each client that connects to the HiveMQ broker maintains a connection to the broker until the connection is terminated, whether that be via communication termination, a client-initiated disconnect, or a broker-initiated disconnect. Typically, there is a limitation to the number of unique clients connected at any single time to one broker, as each connection utilizes a number of resources to maintain connectivity and client persistence.

With that said, there is no issue with connecting a client, publishing a message, and then disconnecting the client, so long as the client session persistence is properly configured to meet the deployment’s needs.

For more information, I highly recommend reviewing our MQTT essentials series. This part in particular covers client connections with MQTT.

Aaron from the HiveMQ Team

1 Like

Thanks for the reply. I have one other question:

  .thenCompose(_ => client.publishWith().topic(topic).qos(mqttQos).send)
  .thenAccept(publishResult => println(s"publishedResult $publishResult"))
  .thenCompose(_ => client.disconnect())
  .thenAccept(_ => println(s"disconnected"))

In that code, the client connects, publishes and then disconnects, so let us assume that there is an error that happens during the publish, would the disconnect still run? Is that a recipie for a connection leak?

I modified it like this. Is thie safe way to say that in case of errors during publish the disconnect will happen for sure without any connection leak?

sealed trait PublishResult
case class SuccessfulPublish(mqttPublishResult: Mqtt5PublishResult) extends PublishResult
case class FailedPublish(error: Throwable) extends PublishResult

  .thenCompose(_ => client.publishWith().topic(topic).qos(mqttQos).send()
    .handle { (result, throwable) =>
      // Handle the result or exception and wrap it in the custom type
      if (throwable != null) FailedPublish(throwable)
      else SuccessfulPublish(result)
  .thenAccept {
    case SuccessfulPublish(message) =>
      println(s"publishedResult: $message")
    case FailedPublish(error) =>
      println(s"Failed to publish: ${error.getMessage}")
  .thenCompose(_ => client.disconnect())
  .thenAccept(_ => println("disconnected"))

Any help to my questions here?

Hello @Joesan ,

Thank you for the follow up and the additional details here. While we cannot guarantee the functionality of custom client implementations, as the use case and implementation details can vary widely, based on what has been provided it does appear that this fulfills the needs you have previously specified. With that in mind, we do also highly recommend performing some client testing to ensure proper functionality, even in edge cases, before migrating to a production environment.

Namely, this client implementation looks to perform its activities as such :

  • Attempt a client connection, and on success, compose a publish and submit the publish request.
  • Wrap an error, if the publish failed.
  • If there is a successful publish, log the published result.
  • If there is a failed publish, log the error.
  • Compose a disconnect request, and submit the request.
  • Print disconnection.

My notes here would be to potentially include some additional handling for a connection failure - i.e., reason for disconnect or any throwables, and include handling prior to the publish request in the event of a connection failure.

Aaron from the HiveMQ Team