> if the "clientB" tries to connect to another acceptor (not the same one
used by the "clientA"): it won't be able to connect, regardless of the
stealing link configuration
That is not correct. If "clientB" tries to connect to another acceptor (not
the same one used by the "clientA") then the link-stealing semantics will
be enforced according to the configuration of that acceptor. Clients are
not isolated from each other based on the acceptor they use.
Everything else you stated is correct.
Justin
On Tue, Aug 29, 2023 at 3:36 AM andrea bisogno <bisoma...@hotmail.it> wrote:
> Hi Justin,
> thanks for your reply.
>
> If I got it right, the stealing link configuration will remain at acceptor
> level. Then, given an MQTT client "clientA" connected to the broker with
> the clientId "testClientId", and another MQTT client "clientB" wanting to
> connect to the broker with the same clientId ("testClientId"), we would
> expect a behavior like this:
>
> * if the "clientB" tries to connect to the same acceptor used by the
> "clientA"
> * in case allowLinkStealing on the acceptor is set to true: it will
> be able to connect, stealing the connection to the "clientA" (that will be
> disconnected)
> * in case allowLinkStealing on the acceptor is set to false: it
> won't be able to connect ("clientA" will remain connected)
> * if the "clientB" tries to connect to another acceptor (not the same
> one used by the "clientA"): it won't be able to connect, regardless of the
> stealing link configuration
>
> Can yuo confirm this?
>
> Thanks,
>
> Andrea
> ________________________________
> Da: Justin Bertram <jbert...@apache.org>
> Inviato: venerdì 25 agosto 2023 21:36
> A: users@activemq.apache.org <users@activemq.apache.org>
> Oggetto: Re: Messages balance between two MQTT connections open with same
> clientId on different acceptors
>
> This should be resolved as a corollary change in the next release via
> ARTEMIS-966 [1].
>
> The solution is close to the second option you proposed. Clients using
> different acceptors will *not* be able to connect concurrently. However,
> the link-stealing behavior will be based on whatever is configured on the
> acceptor which the client used.
>
>
> Justin
>
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FARTEMIS-966&data=05%7C01%7C%7C3265c1f2fa064f2e910d08dba5b3d0d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638285963947195876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dLqZfSV7kHH6fAWL%2BR2CnXxNdzPKzeRubSeWKF0TRAs%3D&reserved=0
> <https://issues.apache.org/jira/browse/ARTEMIS-966>
>
> On Fri, Aug 25, 2023 at 3:20 AM andrea bisogno <bisoma...@hotmail.it>
> wrote:
>
> > Hi support,
> >
> > I observed an unexpected behavior while testing the Artemis Broker (v
> > 2.29.0):
> >
> > if we have two MQTT connections with the same clientId open at the same
> > time (possible only with two clients opening two different connections
> with
> > same clientId to different MQTT acceptors/ports, regardless of the
> stealing
> > link configuration that is on acceptor base), messages are balanced among
> > the two subscribers: this means each subscriber receives half of the
> data.
> >
> > In my opinion, the expected behavior should be one of these two:
> >
> > * if it is possible to keep open different MQTT connections with the
> > same clientId on different acceptors, all the subscribers should receive
> > all the data. This because there is no way to prevent a second MQTT
> client
> > opens a connection to a different acceptor with a clientId already used,
> > and in that case it is not correct to prevent the first client to receive
> > all the messages
> > * on the other side, probably it should not be possible to have two
> > MQTT connections with the same clientId open at the same time (regardless
> > of the target acceptor), and the stealing link configuration should
> became
> > a global setting, and not a setting on acceptor base. In fact, in case we
> > can only have a single connection with a given clientId for all the
> > acceptors, the user should be free to choose which connection to keep
> open
> > (the first one or the second one), regardless the target acceptor
> >
> > What do you think?
> >
> > Have a nice weekend,
> >
> > Andrea
> >
> >
>
