[
https://issues.apache.org/jira/browse/CAMEL-25852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashank updated CAMEL-25852:
-----------------------------
Description:
The {{channel}} option of the JGroups component (a {{JChannel}}, for example a
channel secured with AUTH and encryption, as the consumer start-up guard of
CAMEL-25223 suggests) is given to every endpoint the component creates. Each
{{JGroupsEndpoint}} (main 20cdb309f7d0) counts only its own producers and
consumers in {{connectCount}}, and closes the channel when it stops:
{code:java}
public void disconnect() {
if (connectCount.decrementAndGet() == 0) {
resolvedChannel.disconnect();
}
}
protected void doStop() throws Exception {
if (resolvedChannel != null) {
resolvedChannel.close();
}
...
{code}
With the component channel, two endpoints of the same cluster that differ in
their options (for example a producer to {{jgroups:orders}} and a consumer from
{{jgroups:orders?enableViewMessages=true}}) share the channel but not the
count. When the producer route stops, its endpoint disconnects the channel, and
the consumer route stays started and receives nothing until a producer or
consumer of the other endpoint starts again. When the producer route is
removed, its endpoint is stopped and closes the channel, and the consumer
receives nothing more for good (a closed {{JChannel}} cannot be connected
again). Nothing is logged.
*Fix*: the component counts the producers and consumers of a channel that the
endpoints did not create (the component channel, or a channel given to one
endpoint with {{channel=#bean}}) and disconnects it when the last of them
stops; an endpoint closes only a channel it created, and the component closes
the other channels when it stops (before, the first endpoint that stopped
closed the component channel, and an endpoint closed a channel given to it). A
channel an endpoint creates itself (from {{channelProperties}} or the default)
is unchanged. A producer or consumer disconnects the channel only when it
connected it: Camel stops a service whose start failed, and a consumer that
refuses to start (no {{acceptAllObjects}}, filter or secured channel) would
otherwise disconnect the channel under the producers of the other endpoints. A
stopping consumer removes the channel's receiver only when it is its own.
*Tests*: new {{JGroupsComponentChannelEndpointsTest}} (component channel, a
producer route and a consumer route on two endpoints of the same cluster,
messages sent by a separate channel):
{{stoppingTheProducerKeepsTheConsumerReceiving}} and
{{removingTheProducerRouteKeepsTheConsumerReceiving}} both fail on main with
{{mock://received Received message count. Expected: <1> but was: <0>}}, and
pass with the fix. {{stoppingTheCamelContextClosesTheChannels}} (a third route
with {{channel=#endpointChannel}}) is a control that both channels are still
closed when the CamelContext stops; it passes on main and with the fix.
{{aConsumerThatFailsToStartKeepsTheChannelOfTheProducerConnected}} and
{{aConsumerThatFailsToStartKeepsTheOtherConsumerReceiving}} (a route
{{jgroups:<cluster>?enableViewMessages=true}} that fails to start) fail without
that check ({{expected: <true> but was: <false>}} for the producer's channel,
{{Expected: <1> but was: <0>}} for the running consumer) and pass with it.
camel-jgroups unit tests with the fix: 31 run, 0 failures.
*How it was found*: variant analysis of CAMEL-25849 and CAMEL-25850 (a resource
that belongs to one owner kept where another owner finds and stops it), then
the JUnit test above.
*Affected*: main, camel-4.18.x and camel-4.14.x (the same per-endpoint
{{connectCount}} and {{close}} in {{doStop}}; read, not run). Not changed: two
consumers on one channel still replace each other's receiver ({{setReceiver}}),
a separate limitation. camel-jgroups-raft has the same pattern for the
{{raftHandle}} of {{JGroupsRaftComponent}}: each {{JGroupsRaftEndpoint}} counts
only its own producers and consumers ({{connectCount}}), disconnects the
handle's channel when they stop, and closes the channel and the log in
{{doStop}}. Fixed separately in CAMEL-25883.
_Filed with Claude Code on behalf of allthingssecurity._
was:
The {{channel}} option of the JGroups component (a {{JChannel}}, for example a
channel secured with AUTH and encryption, as the consumer start-up guard of
CAMEL-25223 suggests) is given to every endpoint the component creates. Each
{{JGroupsEndpoint}} (main 20cdb309f7d0) counts only its own producers and
consumers in {{connectCount}}, and closes the channel when it stops:
{code:java}
public void disconnect() {
if (connectCount.decrementAndGet() == 0) {
resolvedChannel.disconnect();
}
}
protected void doStop() throws Exception {
if (resolvedChannel != null) {
resolvedChannel.close();
}
...
{code}
With the component channel, two endpoints of the same cluster that differ in
their options (for example a producer to {{jgroups:orders}} and a consumer from
{{jgroups:orders?enableViewMessages=true}}) share the channel but not the
count. When the producer route stops, its endpoint disconnects the channel, and
the consumer route stays started and receives nothing until a producer or
consumer of the other endpoint starts again. When the producer route is
removed, its endpoint is stopped and closes the channel, and the consumer
receives nothing more for good (a closed {{JChannel}} cannot be connected
again). Nothing is logged.
*Fix*: the component counts the producers and consumers of a channel that the
endpoints did not create (the component channel, or a channel given to one
endpoint with {{channel=#bean}}) and disconnects it when the last of them
stops; an endpoint closes only a channel it created, and the component closes
the other channels when it stops (before, the first endpoint that stopped
closed the component channel, and an endpoint closed a channel given to it). A
channel an endpoint creates itself (from {{channelProperties}} or the default)
is unchanged.
*Tests*: new {{JGroupsComponentChannelEndpointsTest}} (component channel, a
producer route and a consumer route on two endpoints of the same cluster,
messages sent by a separate channel):
{{stoppingTheProducerKeepsTheConsumerReceiving}} and
{{removingTheProducerRouteKeepsTheConsumerReceiving}} both fail on main with
{{mock://received Received message count. Expected: <1> but was: <0>}}, and
pass with the fix. {{stoppingTheCamelContextClosesTheChannels}} (a third route
with {{channel=#endpointChannel}}) is a control that both channels are still
closed when the CamelContext stops; it passes on main and with the fix.
camel-jgroups unit tests with the fix: 29 run, 0 failures.
*How it was found*: variant analysis of CAMEL-25849 and CAMEL-25850 (a resource
that belongs to one owner kept where another owner finds and stops it), then
the JUnit test above.
*Affected*: main, camel-4.18.x and camel-4.14.x (the same per-endpoint
{{connectCount}} and {{close}} in {{doStop}}; read, not run). Not changed: two
consumers on one channel still replace each other's receiver ({{setReceiver}}),
a separate limitation. camel-jgroups-raft has the same pattern for the
{{raftHandle}} of {{JGroupsRaftComponent}}: each {{JGroupsRaftEndpoint}} counts
only its own producers and consumers ({{connectCount}}), disconnects the
handle's channel when they stop, and closes the channel and the log in
{{doStop}}. Fixed separately in CAMEL-25883.
_Filed with Claude Code on behalf of allthingssecurity._
> camel-jgroups - with the channel option of the component, an endpoint whose
> producer stops, or whose route is removed, disconnects or closes the channel
> under the consumers of the other endpoints
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25852
> URL: https://issues.apache.org/jira/browse/CAMEL-25852
> Project: Camel
> Issue Type: Bug
> Components: camel-jgroups
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> The {{channel}} option of the JGroups component (a {{JChannel}}, for example
> a channel secured with AUTH and encryption, as the consumer start-up guard of
> CAMEL-25223 suggests) is given to every endpoint the component creates. Each
> {{JGroupsEndpoint}} (main 20cdb309f7d0) counts only its own producers and
> consumers in {{connectCount}}, and closes the channel when it stops:
> {code:java}
> public void disconnect() {
> if (connectCount.decrementAndGet() == 0) {
> resolvedChannel.disconnect();
> }
> }
> protected void doStop() throws Exception {
> if (resolvedChannel != null) {
> resolvedChannel.close();
> }
> ...
> {code}
> With the component channel, two endpoints of the same cluster that differ in
> their options (for example a producer to {{jgroups:orders}} and a consumer
> from {{jgroups:orders?enableViewMessages=true}}) share the channel but not
> the count. When the producer route stops, its endpoint disconnects the
> channel, and the consumer route stays started and receives nothing until a
> producer or consumer of the other endpoint starts again. When the producer
> route is removed, its endpoint is stopped and closes the channel, and the
> consumer receives nothing more for good (a closed {{JChannel}} cannot be
> connected again). Nothing is logged.
> *Fix*: the component counts the producers and consumers of a channel that the
> endpoints did not create (the component channel, or a channel given to one
> endpoint with {{channel=#bean}}) and disconnects it when the last of them
> stops; an endpoint closes only a channel it created, and the component closes
> the other channels when it stops (before, the first endpoint that stopped
> closed the component channel, and an endpoint closed a channel given to it).
> A channel an endpoint creates itself (from {{channelProperties}} or the
> default) is unchanged. A producer or consumer disconnects the channel only
> when it connected it: Camel stops a service whose start failed, and a
> consumer that refuses to start (no {{acceptAllObjects}}, filter or secured
> channel) would otherwise disconnect the channel under the producers of the
> other endpoints. A stopping consumer removes the channel's receiver only when
> it is its own.
> *Tests*: new {{JGroupsComponentChannelEndpointsTest}} (component channel, a
> producer route and a consumer route on two endpoints of the same cluster,
> messages sent by a separate channel):
> {{stoppingTheProducerKeepsTheConsumerReceiving}} and
> {{removingTheProducerRouteKeepsTheConsumerReceiving}} both fail on main with
> {{mock://received Received message count. Expected: <1> but was: <0>}}, and
> pass with the fix. {{stoppingTheCamelContextClosesTheChannels}} (a third
> route with {{channel=#endpointChannel}}) is a control that both channels are
> still closed when the CamelContext stops; it passes on main and with the fix.
> {{aConsumerThatFailsToStartKeepsTheChannelOfTheProducerConnected}} and
> {{aConsumerThatFailsToStartKeepsTheOtherConsumerReceiving}} (a route
> {{jgroups:<cluster>?enableViewMessages=true}} that fails to start) fail
> without that check ({{expected: <true> but was: <false>}} for the producer's
> channel, {{Expected: <1> but was: <0>}} for the running consumer) and pass
> with it. camel-jgroups unit tests with the fix: 31 run, 0 failures.
> *How it was found*: variant analysis of CAMEL-25849 and CAMEL-25850 (a
> resource that belongs to one owner kept where another owner finds and stops
> it), then the JUnit test above.
> *Affected*: main, camel-4.18.x and camel-4.14.x (the same per-endpoint
> {{connectCount}} and {{close}} in {{doStop}}; read, not run). Not changed:
> two consumers on one channel still replace each other's receiver
> ({{setReceiver}}), a separate limitation. camel-jgroups-raft has the same
> pattern for the {{raftHandle}} of {{JGroupsRaftComponent}}: each
> {{JGroupsRaftEndpoint}} counts only its own producers and consumers
> ({{connectCount}}), disconnects the handle's channel when they stop, and
> closes the channel and the log in {{doStop}}. Fixed separately in CAMEL-25883.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
