-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Share MQTT connection between inbound & outbound IntegrationFlow
s
#3685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This request is not OK in the context of those channel adapters.
And that So, it is probably OK to have the same client for publishing an subscribing logic in the same place: https://stackoverflow.com/questions/49484629/mqtt-publish-subscribe-in-the-same-client. How about having a client id as prefixed: |
Hi @artembilan, thanks for your fast response :) Thanks, I checked that StackOverflow answer but I'd like to achieve it using the APIs of Spring Integration, as we have other integrations implemented with it on that project! Having client id prefixed... well then it means 2 MQTT connections for each client, which is a waste of resources, isn't it? |
As I said: it was designed like that to keep the proper track of
So, for every new subscriber we can have its own listening context while keeping the rest of So, yeah: let's see what we can do so far in the next version! For now you only have a choice or use different clients or implement a logic manually. |
Hello, I would like to ask if there is any solution to this, is it? MQTT allows only one connection per clientId, so my client gets disconnected. Thank you. |
we definitely are looking into this, but since there are expected some breaking changes, the fix is likely would make it only to the next As a workaround consider to do such an MQTT logic manually:
|
Fixes spring-projects#3685 Introduce some initial design. Add a new interface `MqttClientManager` which will manage clients and connections. Use this manager in v3 topic adapter and message handler.
Fixes spring-projects#3685 Introduce some initial design. Add a new interface `ClientManager` which will manage clients and connections. Use this manager in v3 topic adapter and message handler.
Fixes spring-projects#3685 Add a new interface `ClientManager` which will manage clients and connections. Add different implementations for v3 and v5 MQTT clients. Use this manager in v3/v5 topic adapters and message handlers.
Fixes spring-projects#3685 Add a couple of unit/integration tests to cover client manager usage. Several small code improvements after the code review: * Improve client manager usage via providing several mutual exclusive constructors, whether the users provides `url` or `connectionOptions` or `clientFactory` for v3. * Move the logger to `AbstractMqttClientManager` * Do not inject TaskScheduler in constructor for v3 client manager but use lazy init via `BeanFactory` and `IntegrationContextUtils` * Other smaller code readability improvements
Fixes spring-projects#3685 Introduce some initial design. Add a new interface `ClientManager` which will manage clients and connections. Use this manager in v3 topic adapter and message handler.
Fixes spring-projects#3685 Add a new interface `ClientManager` which will manage clients and connections. Add different implementations for v3 and v5 MQTT clients. Use this manager in v3/v5 topic adapters and message handlers.
Fixes spring-projects#3685 Add a couple of unit/integration tests to cover client manager usage. Several small code improvements after the code review: * Improve client manager usage via providing several mutual exclusive constructors, whether the users provides `url` or `connectionOptions` or `clientFactory` for v3. * Move the logger to `AbstractMqttClientManager` * Do not inject TaskScheduler in constructor for v3 client manager but use lazy init via `BeanFactory` and `IntegrationContextUtils` * Other smaller code readability improvements
Fixes spring-projects#3685 Add new tests with reconnect cases. Other code improvements after the code review: * Adjust javadocs according to standards * Remove `setClientManager` and use exclusive ctors * Make automatic reconnects using the v3 client instead of manually using task scheduler
Fixes spring-projects#3685 Some fixes and improvements after another code review iteration: * Rearrange the code according to the code style guides * Move client instance to `AbstractClientManager` with `isRunning` method * Fix abstract adapter/handler fields visibility and `final`ize them where we can * Send application event if automatic reconnect is not enabled for the client manager
Fixes spring-projects#3685 Other fixes and improvements after code review: * Changes around fields, methods, ctors visibility * Removed contradictory ctors * Reduce amount of unnecessary `getClientManager() != null` checks in logic and make it as similar as possible for client manager and the old approach * Use auto-reconnect where possible * Remove manual reconnect trigger and rely on events instead to know where to subscribe * Do not close the connection in adapter to be able to use reconnect logic without lose of subscriptions * Make `ClientManager` extend `MqttComponent` so that it knows about connection options as part of its contract * Remove not relevant auto test cases (relying on connection close or manual reconnect) * Other code style smaller changes
Fixes spring-projects#3685 Other fixes and improvements after code review: * Get manual `reconnect` invocation back for v3/v5 adapters and client managers (see bug spring-projectsGH-3822 for a reasoning) * Remove unnecessary getters/setter for a listener and use adapter class as listener instead * Optimize MessageListener: remove redundant inner class and use a single method reference instead of N instances per each subscribe * Javadocs improvements
Related to #3685 * Add documentation for a new MQTT shared client feature Add an overview with reason for the feature as well as basic capabilities listing. Give an example with Java DSL usage for several adapters. * Fill `whats-new.adoc` with MQTT changes Add a reference to MQTT documentation with info about shared MQTT client * Couple of code review changes
Hello, How can I solve it in spring-integration 5.5.14? |
In that version you can do that only implementing your own channel adapters. |
Expected Behavior
If there are two
IntegrationFlow
s that use the same ClientFactory, to be able to share the same MQTT connection, hence being able to publish and subscribe with the same client idCurrent Behavior
When I create two
IntegartionFlow
s to publish & subscribe to an MQTT Broker, first the subscribe (inbound) flow connects and subscribes successfully to the given topic. Then when a message is published to a topic, the previous connection drops so the publishing (outbound) flow connects!Relevant logs:
So basically they ping-pong with each other as MQTT allows only one connection per client id
Context
My use-case is that I have to use the same client id both for subscribing and publishing messages to the MQTT broker
Sample project: https://github.com/durimkryeziu/mqtt-shared-connection
The text was updated successfully, but these errors were encountered: