shashank created CAMEL-26573:
--------------------------------

             Summary: camel-vertx-websocket - a consumer starting while the 
last consumer on its host and port stops keeps being served after its own stop
                 Key: CAMEL-26573
                 URL: https://issues.apache.org/jira/browse/CAMEL-26573
             Project: Camel
          Issue Type: Bug
          Components: camel-vertx-websocket
            Reporter: shashank
            Assignee: shashank


Found with a TLA+ model of the shared host registry of 
{{VertxWebsocketComponent}} (consumers on one host and port, each starting and 
stopping on its own thread), then reproduced on the real classes with embedded 
Vert.x on localhost.

Since CAMEL-24788 the consumers on one host and port share one 
{{VertxWebsocketHost}}, which leaves the registry once it serves no consumer. 
{{connectConsumer}} gets the host ({{computeIfAbsent}}) and connects to it 
afterwards, outside the map; a {{disconnectConsumer}} in between 
({{host.disconnect}}, then {{computeIfPresent}} removing a host that serves no 
consumer) removes the host the consumer is about to connect to. The consumer 
then connects to the removed host and starts its server:

- its own stop finds no host in the registry, so its path stays served after 
the stop (messages reach the route of a stopped consumer) and the server keeps 
the port until the Vert.x instance is closed (when the CamelContext stops, or 
never for a Vert.x instance the application owns);
- the next consumer on that host and port gets a second server on the same port.

Trace: b gets host H (a is still on it); a stops: last route, server closed, H 
removed from the registry; b connects to H and starts a server. The disconnect 
can also be a consumer failing the {{sslContextParameters}} check of 
CAMEL-26109, whose failed start stops it while another consumer has just 
created the host.

Route operations of a CamelContext hold its lock, but 
{{ThrottlingInflightRoutePolicy}} and {{ThrottlingExceptionRoutePolicy}} stop 
and start this consumer (it cannot be suspended) without it, so two routes with 
such a policy on one port, or a policy and a route operation, run both at the 
same time. A stress loop on main (start one consumer while the last other one 
stops) ended with the consumer on a removed host in 295 of 300 runs.

Fix: {{connectConsumer}} and {{disconnectConsumer}} run under a lock per host 
and port.

Affected: main, 4.23.x and 4.22.x (the branches with CAMEL-24788); the failed 
start path needs CAMEL-26109, which is on main only.

_Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to