[jira] [Commented] (CAMEL-25842) 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

["Claus Ibsen (Jira)" <ji...@apache.org>]

    [ 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)