[
https://issues.apache.org/jira/browse/CAMEL-25842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130584#comment-18130584
]
Claus Ibsen commented on CAMEL-25842:
-------------------------------------
Merged to main via https://github.com/apache/camel/pull/28263 (commit
3856bca11562).
> camel-xmpp - after a lost connection the consumer connects again without
> logging in, and consumes nothing again (private chats and rooms) until the
> route restarts
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25842
> URL: https://issues.apache.org/jira/browse/CAMEL-25842
> Project: Camel
> Issue Type: Bug
> Components: camel-xmpp
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> {{XmppConsumer}} watches its connection with a scheduled task
> ({{startRobustConnectionMonitor}}, every {{connectionPollDelay}} seconds,
> main 20cdb309f7d0). When the connection was lost (a network failure, a server
> restart, the server closing an idle stream) {{checkConnection}} calls
> {{connection.connect()}} and nothing else:
> {code:java}
> if (!connection.isConnected()) {
> LOG.info("Attempting to reconnect to: {}", ...);
> connection.connect();
> }
> {code}
> With Smack 4.4 (Camel uses 4.4.8 since 4.22, CAMEL-23562)
> {{AbstractXMPPConnection.connect()}} only opens the stream; it does not log
> in. Smack's own {{ReconnectionManager}}, which {{XmppComponent.doStart}}
> enables for every connection, also reconnects a lost connection (first
> attempt after a random delay of 2 to 14 seconds) and logs in after it
> connected, but it gives up when the connection is already connected, that is
> when the consumer's monitor connected first. An XMPP server delivers no
> stanza to a stream that has not logged in and bound a resource (RFC 6120),
> and it removes an occupant from a multi-user chat room when its connection
> ends. So after a lost connection:
> * when the monitor connects first (with the defaults, often; always with a
> short {{connectionPollDelay}}), the consumer reports a working connection
> ({{isConnected()}} is true, so the monitor does not try again), logs nothing
> more, and receives no private chat message and no room message again, until
> the route is restarted;
> * whoever connected again, a room consumer is no longer an occupant of its
> room and nothing enters it again: it receives no room message again, also
> when the {{ReconnectionManager}} logged in.
> {{XmppRobustConnectionTest}} has been {{@Disabled}} with the note that the
> reconnect does not seem to work since Smack 4.2; this is a likely cause.
> *Fix*: when the connection is connected but not authenticated, the monitor
> logs it in again ({{XmppEndpoint.login}}, split out of {{createConnection}},
> as the configured user or anonymously; {{createAccount}} still only applies
> to the first connection; nothing is done with {{login=false}}). The consumer
> listens for every fresh login of its connection
> ({{ConnectionListener.authenticated}} with {{resumed=false}}), by the monitor
> or by the {{ReconnectionManager}}: it logs "Logged in again" and enters its
> room again with the same nickname and room password, in the monitor thread;
> the monitor tries again if that fails. The producers' reconnect
> ({{XmppGroupChatProducer}}, {{XmppDirectProducer}}) is not changed here; a
> send on a connection that was not logged in again fails loudly there.
> *Tests*: new {{XmppConsumerReconnectTest}} (2 tests) with a small in-process
> XMPP server ({{FakeXmppServer}}, plain TCP, SASL PLAIN and ANONYMOUS,
> resource binding, multi-user chat presence) that, like a real server,
> delivers stanzas only to sessions that logged in and to room occupants of the
> current session; the real Smack 4.4.8 client connects to it. Both tests
> receive a message, drop every connection on the server, and wait for the
> consumer to come back; with {{connectionPollDelay=1}} the monitor connects
> first. On main both fail: {{The consumers did not log in again ==> expected:
> <2> but was: <0> within 20 seconds}} and {{The consumer did not enter the
> room again ==> expected: <1> but was: <0>}} (the log shows "Attempting to
> reconnect" once per consumer, then nothing). New
> {{XmppConsumerSmackReconnectTest}}: the {{ReconnectionManager}} wins (fixed
> delay of 1 s, {{connectionPollDelay=3600}}) and logs in; on main the room is
> not entered again ({{The consumer did not enter the room again ==> expected:
> <1> but was: <0>}}). With the fix all three pass. camel-xmpp unit tests with
> the fix: 12 run, 0 failures, 5 skipped (Google Talk and the disabled robust
> connection test); the container integration tests were not run.
> *How it was found*: variant analysis of CAMEL-25815 (pattern: server-side
> state of a consumer, here the authenticated session and the room occupancy,
> lost on a reconnect and not created again), then the JUnit test.
> *Affected*: main, camel-4.23.x and camel-4.22.x (Smack 4.4.8; read, not run).
> camel-4.18.x and 4.14.x have the same {{checkConnection}} with Smack 4.3.5,
> whose {{connect()}} I did not check.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
