[
https://issues.apache.org/jira/browse/CAMEL-25842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashank updated CAMEL-25842:
-----------------------------
Description:
{{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._
was:
{{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._
> 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
>
> {{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
(v8.20.10#820010)
