shashank created CAMEL-25842:
--------------------------------
Summary: 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
{{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 would, is off by default and Camel
does not enable it). 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 the first lost
connection:
* 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;
* for a room consumer, the room no longer has the consumer as an occupant
either.
{{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 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) and the consumer enters its room again with the same nickname and
room password. 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 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. 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). With the fix both pass. camel-xmpp unit tests with the
fix: 11 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
(v8.20.10#820010)
