[
https://issues.apache.org/jira/browse/CAMEL-25908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shashank updated CAMEL-25908:
-----------------------------
Description:
{{KnativeHttpConsumer}} (main 74ee085f7d64) registers a Vert.x route on the
shared platform HTTP router in {{doStart}}, only when it has none yet, and
removes it in {{doStop}} without clearing the field:
{code:java}
protected void doStart() throws Exception {
if (route == null) {
...
route = router.get().route(HttpMethod.POST, path);
... handlers ...
}
super.doStart();
}
protected void doStop() throws Exception {
if (route != null) {
route.remove();
}
super.doStop();
}
{code}
So when the same consumer instance is stopped and started again, the start
skips the registration: the consumer and its route report Started, but no
handler serves its path, and every event POSTed to it is answered with 404 (the
Knative broker or channel retries and then drops or dead-letters the events).
It lasts until the route is restarted through the route controller (which
creates a new consumer) or the application restarts.
The consumer is not {{Suspendable}}, so the route policies that suspend and
resume a route stop and start this same instance
({{RoutePolicySupport.suspendOrStopConsumer}} / {{resumeOrStartConsumer}}): the
circuit breaker {{ThrottlingExceptionRoutePolicy}} (half open after
{{halfOpenAfter}}), {{ThrottlingInflightRoutePolicy}}, and, with CAMEL-25848,
the suspend/resume of the scheduled route policies. With the circuit breaker
the circuit never closes again, since no request reaches the route. A route
stop/start through the route controller is not affected (a new consumer is
created), nor is a CamelContext suspend/resume. The sibling
{{VertxPlatformHttpConsumer}} clears its routes in {{doStop}}.
*Fix*: clear {{route}} after removing it in {{doStop}}, so a start registers a
new route. The new route is added at the end of the router, so when another
route of the router can take the same request (a second consumer of the same
path without a filter, or a platform-http consumer on {{/*}} added later), the
restarted consumer now comes after it. Keeping the route with
{{disable()}}/{{enable()}} would keep its place, but a route stop and start
through the route controller creates a new consumer without shutting the old
one down, which would leave the old consumer's disabled route in the router.
*Tests*: two new parameterized tests in {{KnativeHttpTest}} (3 CloudEvents
versions each, the module's platform HTTP server and two filtered sources).
{{testConsumerStartedAgainByCircuitBreakerRoutePolicy}} (route with
{{ThrottlingExceptionRoutePolicy(1, 60000, 1000, null)}}, one failing request
opens the circuit and stops the consumer, the half-open task starts it again)
and {{testConsumerStoppedAndStartedAgain}} (consumer stopped and started with
{{ServiceHelper}}, as the policies do) fail on main:
{{HttpOperationFailedException ... statusCode: 404}} on the request after the
start; they pass with the fix. camel-knative-http unit tests with the fix: 200
run, 0 failures.
*How it was found*: variant analysis of CAMEL-25872 and CAMEL-25848 (a consumer
that is not Suspendable, started again through a path that assumes a first
start), then the JUnit tests above.
*Affected*: main, camel-4.23.x, camel-4.22.x and camel-4.18.x (the same
{{doStart}} guard and {{doStop}}; read, not run).
_Filed with Claude Code on behalf of allthingssecurity._
was:
{{KnativeHttpConsumer}} (main 74ee085f7d64) registers a Vert.x route on the
shared platform HTTP router in {{doStart}}, only when it has none yet, and
removes it in {{doStop}} without clearing the field:
{code:java}
protected void doStart() throws Exception {
if (route == null) {
...
route = router.get().route(HttpMethod.POST, path);
... handlers ...
}
super.doStart();
}
protected void doStop() throws Exception {
if (route != null) {
route.remove();
}
super.doStop();
}
{code}
So when the same consumer instance is stopped and started again, the start
skips the registration: the consumer and its route report Started, but no
handler serves its path, and every event POSTed to it is answered with 404 (the
Knative broker or channel retries and then drops or dead-letters the events).
It lasts until the route is restarted through the route controller (which
creates a new consumer) or the application restarts.
The consumer is not {{Suspendable}}, so the route policies that suspend and
resume a route stop and start this same instance
({{RoutePolicySupport.suspendOrStopConsumer}} / {{resumeOrStartConsumer}}): the
circuit breaker {{ThrottlingExceptionRoutePolicy}} (half open after
{{halfOpenAfter}}), {{ThrottlingInflightRoutePolicy}}, and, with CAMEL-25848,
the suspend/resume of the scheduled route policies. With the circuit breaker
the circuit never closes again, since no request reaches the route. A route
stop/start through the route controller is not affected (a new consumer is
created), nor is a CamelContext suspend/resume. The sibling
{{VertxPlatformHttpConsumer}} clears its routes in {{doStop}}.
*Fix*: clear {{route}} after removing it in {{doStop}}, so a start registers a
new route.
*Tests*: two new parameterized tests in {{KnativeHttpTest}} (3 CloudEvents
versions each, the module's platform HTTP server and two filtered sources).
{{testConsumerStartedAgainByCircuitBreakerRoutePolicy}} (route with
{{ThrottlingExceptionRoutePolicy(1, 60000, 1000, null)}}, one failing request
opens the circuit and stops the consumer, the half-open task starts it again)
and {{testConsumerStoppedAndStartedAgain}} (consumer stopped and started with
{{ServiceHelper}}, as the policies do) fail on main:
{{HttpOperationFailedException ... statusCode: 404}} on the request after the
start; they pass with the fix. camel-knative-http unit tests with the fix: 200
run, 0 failures.
*How it was found*: variant analysis of CAMEL-25872 and CAMEL-25848 (a consumer
that is not Suspendable, started again through a path that assumes a first
start), then the JUnit tests above.
*Affected*: main, camel-4.23.x, camel-4.22.x and camel-4.18.x (the same
{{doStart}} guard and {{doStop}}; read, not run).
_Filed with Claude Code on behalf of allthingssecurity._
> camel-knative-http - a consumer stopped and started again by a route policy
> (circuit breaker, throttling) answers 404 for good
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25908
> URL: https://issues.apache.org/jira/browse/CAMEL-25908
> Project: Camel
> Issue Type: Bug
> Components: camel-knative-http
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> {{KnativeHttpConsumer}} (main 74ee085f7d64) registers a Vert.x route on the
> shared platform HTTP router in {{doStart}}, only when it has none yet, and
> removes it in {{doStop}} without clearing the field:
> {code:java}
> protected void doStart() throws Exception {
> if (route == null) {
> ...
> route = router.get().route(HttpMethod.POST, path);
> ... handlers ...
> }
> super.doStart();
> }
> protected void doStop() throws Exception {
> if (route != null) {
> route.remove();
> }
> super.doStop();
> }
> {code}
> So when the same consumer instance is stopped and started again, the start
> skips the registration: the consumer and its route report Started, but no
> handler serves its path, and every event POSTed to it is answered with 404
> (the Knative broker or channel retries and then drops or dead-letters the
> events). It lasts until the route is restarted through the route controller
> (which creates a new consumer) or the application restarts.
> The consumer is not {{Suspendable}}, so the route policies that suspend and
> resume a route stop and start this same instance
> ({{RoutePolicySupport.suspendOrStopConsumer}} / {{resumeOrStartConsumer}}):
> the circuit breaker {{ThrottlingExceptionRoutePolicy}} (half open after
> {{halfOpenAfter}}), {{ThrottlingInflightRoutePolicy}}, and, with CAMEL-25848,
> the suspend/resume of the scheduled route policies. With the circuit breaker
> the circuit never closes again, since no request reaches the route. A route
> stop/start through the route controller is not affected (a new consumer is
> created), nor is a CamelContext suspend/resume. The sibling
> {{VertxPlatformHttpConsumer}} clears its routes in {{doStop}}.
> *Fix*: clear {{route}} after removing it in {{doStop}}, so a start registers
> a new route. The new route is added at the end of the router, so when another
> route of the router can take the same request (a second consumer of the same
> path without a filter, or a platform-http consumer on {{/*}} added later),
> the restarted consumer now comes after it. Keeping the route with
> {{disable()}}/{{enable()}} would keep its place, but a route stop and start
> through the route controller creates a new consumer without shutting the old
> one down, which would leave the old consumer's disabled route in the router.
> *Tests*: two new parameterized tests in {{KnativeHttpTest}} (3 CloudEvents
> versions each, the module's platform HTTP server and two filtered sources).
> {{testConsumerStartedAgainByCircuitBreakerRoutePolicy}} (route with
> {{ThrottlingExceptionRoutePolicy(1, 60000, 1000, null)}}, one failing request
> opens the circuit and stops the consumer, the half-open task starts it again)
> and {{testConsumerStoppedAndStartedAgain}} (consumer stopped and started with
> {{ServiceHelper}}, as the policies do) fail on main:
> {{HttpOperationFailedException ... statusCode: 404}} on the request after the
> start; they pass with the fix. camel-knative-http unit tests with the fix:
> 200 run, 0 failures.
> *How it was found*: variant analysis of CAMEL-25872 and CAMEL-25848 (a
> consumer that is not Suspendable, started again through a path that assumes a
> first start), then the JUnit tests above.
> *Affected*: main, camel-4.23.x, camel-4.22.x and camel-4.18.x (the same
> {{doStart}} guard and {{doStop}}; read, not run).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
