shashank created CAMEL-26681:
--------------------------------
Summary: camel-xmpp - the consumer's connection monitor reconnects
outside the account's lock, and a consumer and a group chat producer of one
room both re-enter it after a reconnect
Key: CAMEL-26681
URL: https://issues.apache.org/jira/browse/CAMEL-26681
Project: Camel
Issue Type: Improvement
Components: camel-xmpp
Reporter: shashank
Assignee: shashank
Follow-up of CAMEL-25961 (apache/camel#29293), which made the private chat and
group chat producers log in again and the group chat producer enter its room
again after a lost connection. Two items of CAMEL-25961 were left out of that
PR, and one note from its review is for the docs.
h3. 1. The consumer's connection monitor reconnects outside the account's lock
The third bullet of CAMEL-25961. Since CAMEL-25841 the consumers and producers
of one account share one connection, and the producers connect and log it in
again through {{XmppEndpoint.reconnect(connection)}}, under the account's lock.
The consumer's connection monitor ({{XmppConsumer.checkConnection}}) still
calls {{connection.connect()}} and {{endpoint.login(connection)}} itself,
without that lock.
This is safe today: Smack's {{connect}} and {{login}} are synchronized, and the
monitor treats {{AlreadyConnectedException}} and {{AlreadyLoggedInException}}
(from a producer or Smack's {{ReconnectionManager}} that got there first) as
done. Moving the monitor onto {{XmppEndpoint.reconnect(connection)}} makes all
users of an account reconnect the same way and in one place. It must keep the
room re-entry of the consumer, the handling of a connection that needs no login
({{login=false}} with a user), and what {{XmppConsumerConnectionRaceTest}}
checks.
h3. 2. A consumer and a group chat producer of the same account and room share
one MultiUserChat
Smack keeps one {{MultiUserChat}} per connection and room
({{MultiUserChatManager.getMultiUserChat}}), so a consumer and a group chat
producer of the same account and room use the same object, and each of them
enters the room again after a reconnect. The second one to do so leaves and
enters again ({{MultiUserChat.join}} leaves first when Smack thinks the room is
joined). For a moment the consumer is not in the room and can miss room
messages, and a send of the producer in that moment can be dropped by the room,
once per reconnect.
{code:java}
from("xmpp://[email protected][email protected]&password=secret").to("log:room");
from("direct:say").to("xmpp://[email protected][email protected]&password=secret");
// after a reconnect both enter dev@conference again on the same MultiUserChat:
the second leaves first
{code}
Avoiding it needs state shared by all users of the room on that connection, for
example the session (login) on which the room was last entered, so that whoever
comes second sees the room as entered already. Routes that use one account per
consumer or producer of a room, or one room endpoint per account, are not
affected.
h3. 3. Docs: first group chat message after a reconnect
Add a sentence to the reconnect notes of the component docs (the Connections
section): after a reconnect, Smack still considers the old session joined to
the room, so {{MultiUserChat.join}} first sends a leave and waits for its
answer, up to the reply timeout (5 s by default). The first group chat message
after a reconnect can therefore wait up to that long, under the producer's
lock, and other senders of the same producer wait with it. The consumer behaves
the same when it enters its room again.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
