You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "atiaomar1978-hub (via GitHub)" <gi...@apache.org> on 2026/08/18 18:02:49 UTC
[PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
atiaomar1978-hub opened a new pull request, #25531:
URL: https://github.com/apache/camel/pull/25531
## Summary
_AI-generated on behalf of atiaomar1978-hub_
Fixes [CAMEL-24401](https://issues.apache.org/jira/browse/CAMEL-24401): camel-jms InOut producers using temporary reply queues could enter a permanent `Failed to resolve replyTo destination` loop after JMS connection faults.
### Root cause
`TemporaryQueueReplyManager` used a one-shot `refreshWanted` flag that was cleared **before** a replacement temporary queue was published (Scenario B), and could remain armed with no consumer left to call the destination resolver (Scenario A).
### Fix
- Replace `refreshWanted` with a monotonic **refresh generation** counter and only publish `replyTo` after a successful queue creation for the handled generation (prevents Scenarios B and C).
- When a refresh is scheduled, **defer** listener-container recovery until after the endpoint recovery interval and skip while Spring is already recovering, forcing a resolver call for Scenario A without racing Spring recovery.
- Add `DefaultJmsMessageListenerContainer.recoverReplyDestinationAfterRefresh()` as a guarded hook into Spring recovery.
### Tests
- `TemporaryQueueReplyManagerRefreshTest` — failed create retry, latest generation publish, permanent failure, generation change during resolve
- `JmsTemporaryReplyToRequestReplyIT` — consecutive InOut request-reply sanity check
### References
- JIRA: https://issues.apache.org/jira/browse/CAMEL-24401
- Reproducer/analysis: https://github.com/vdobos-trask/Reproducer_Camel_Jms_Failed_ReplyTo_Destination_2026
### Review notes
Grok + Bugbot review feedback addressed: publish ordering, lock scope, deferred recovery, shutdown ordering.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #25531:
URL: https://github.com/apache/camel/pull/25531#issuecomment-5399045312
:star2: Thank you for your contribution to the Apache Camel project! :star2:
:robot: CI automation will test this PR automatically.
:camel: Apache Camel Committers, please review the following items:
* First-time contributors **require MANUAL approval** for the GitHub Actions to run
* You can use the command `/component-test (camel-)component-name1 (camel-)component-name2..` to request a test from the test bot although they are normally detected and executed by CI.
* You can label PRs using `skip-tests` and `test-dependents` to fine-tune the checks executed by this PR.
* Build and test logs are available in the summary page. **Only** [Apache Camel committers](https://camel.apache.org/community/team/#committers) have access to the summary.
:warning: Be careful when sharing logs. Review their contents before sharing them publicly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "atiaomar1978-hub (via GitHub)" <gi...@apache.org>.
atiaomar1978-hub commented on PR #25531:
URL: https://github.com/apache/camel/pull/25531#issuecomment-5399214111
## CI / uncommitted changes fixed
_AI-generated on behalf of atiaomar1978-hub_
CI failed on the **uncommitted changes** check: after build, `core/camel-core-model/.../model.properties` picked up the `ubl` entry from latest `main` while the branch still had a stale version (from the earlier revert commit).
**Fix (commit `ac4fa659`):**
- Rebased onto latest `upstream/main`
- Synced `model.properties` with `main` so the PR diff contains only the 4 `camel-jms` files
- Verified locally: `./mvnw -pl components/camel-jms -am install -DskipTests` leaves a clean working tree
**Tests:**
```
./mvnw -pl components/camel-jms -am test \
-Dtest=TemporaryQueueReplyManagerRefreshTest,JmsTemporaryReplyToRequestReplyIT
```
6 tests, 0 failures.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #25531:
URL: https://github.com/apache/camel/pull/25531#issuecomment-5399672528
<!-- ci-tested-modules -->
:test_tube: **CI tested the following changed modules:**
- `components/camel-jms`
---
<details><summary>:microscope: Scalpel shadow comparison — Scalpel: 12 tested, 29 compile-only — current: 12 all tested</summary>
[Maveniverse Scalpel](https://github.com/maveniverse/scalpel) detected **41 affected modules** (current approach: 12).
<details><summary>:warning: Modules only in Scalpel (29)</summary>
- `apache-camel`
- `camel-allcomponents`
- `camel-catalog`
- `camel-catalog-console`
- `camel-catalog-lucene`
- `camel-catalog-maven`
- `camel-catalog-suggest`
- `camel-componentdsl`
- `camel-csimple-maven-plugin`
- `camel-endpointdsl`
- `camel-endpointdsl-support`
- `camel-itest`
- `camel-jbang-core`
- `camel-jbang-it`
- `camel-jbang-main`
- `camel-jbang-plugin-edit`
- `camel-jbang-plugin-generate`
- `camel-jbang-plugin-kubernetes`
- `camel-jbang-plugin-test`
- `camel-kamelet-main`
- `camel-launcher`
- `camel-report-maven-plugin`
- `camel-route-parser`
- `camel-yaml-dsl`
- `camel-yaml-dsl-deserializers`
- `camel-yaml-dsl-maven-plugin`
- `coverage`
- `docs`
- `dummy-component`
</details>
**Skip-tests mode would test 12 modules** (1 direct + 11 downstream), **skip tests for 29** (generated code, meta-modules)
<details><summary>Modules Scalpel would test (12)</summary>
- `camel-activemq`
- `camel-activemq6`
- `camel-amqp`
- `camel-jbang-mcp`
- `camel-jbang-plugin-mcp`
- `camel-jbang-plugin-route-parser`
- `camel-jbang-plugin-tui`
- `camel-jbang-plugin-validate`
- `camel-jms`
- `camel-launcher-container`
- `camel-yaml-dsl-validator`
- `camel-yaml-dsl-validator-maven-plugin`
</details>
<details><summary>Modules with tests skipped (29)</summary>
- `apache-camel`
- `camel-allcomponents`
- `camel-catalog`
- `camel-catalog-console`
- `camel-catalog-lucene`
- `camel-catalog-maven`
- `camel-catalog-suggest`
- `camel-componentdsl`
- `camel-csimple-maven-plugin`
- `camel-endpointdsl`
- `camel-endpointdsl-support`
- `camel-itest`
- `camel-jbang-core`
- `camel-jbang-it`
- `camel-jbang-main`
- `camel-jbang-plugin-edit`
- `camel-jbang-plugin-generate`
- `camel-jbang-plugin-kubernetes`
- `camel-jbang-plugin-test`
- `camel-kamelet-main`
- `camel-launcher`
- `camel-report-maven-plugin`
- `camel-route-parser`
- `camel-yaml-dsl`
- `camel-yaml-dsl-deserializers`
- `camel-yaml-dsl-maven-plugin`
- `coverage`
- `docs`
- `dummy-component`
</details>
> :information_source: Shadow mode — Scalpel observes but does not affect test execution. [Learn more](https://github.com/maveniverse/scalpel)
</details>
:warning: **Some tests are disabled on GitHub Actions** (`@DisabledIfSystemProperty(named = "ci.env.name")`) and require manual verification:
- `components/camel-jms`: 1 test(s) disabled on GitHub Actions
<details><summary>All tested modules (41 modules)</summary>
- Camel :: AMQP
- Camel :: ActiveMQ 5.x
- Camel :: ActiveMQ 6.x
- Camel :: All Components Sync point
- Camel :: Assembly
- Camel :: Catalog :: CSimple Maven Plugin (deprecated)
- Camel :: Catalog :: Camel Catalog
- Camel :: Catalog :: Camel Report Maven Plugin
- Camel :: Catalog :: Camel Route Parser
- Camel :: Catalog :: Console
- Camel :: Catalog :: Dummy Component
- Camel :: Catalog :: Lucene (deprecated)
- Camel :: Catalog :: Maven
- Camel :: Catalog :: Suggest
- Camel :: Component DSL
- Camel :: Coverage
- Camel :: Docs
- Camel :: Endpoint DSL
- Camel :: Endpoint DSL :: Support
- Camel :: Integration Tests
- Camel :: JBang :: Core
- Camel :: JBang :: Integration tests
- Camel :: JBang :: MCP
- Camel :: JBang :: Main
- Camel :: JBang :: Plugin :: Edit
- Camel :: JBang :: Plugin :: Generate
- Camel :: JBang :: Plugin :: Kubernetes
- Camel :: JBang :: Plugin :: MCP
- Camel :: JBang :: Plugin :: Route Parser
- Camel :: JBang :: Plugin :: TUI
- Camel :: JBang :: Plugin :: Testing
- Camel :: JBang :: Plugin :: Validate
- Camel :: JMS
- Camel :: Kamelet Main
- Camel :: Launcher
- Camel :: Launcher :: Container
- Camel :: YAML DSL
- Camel :: YAML DSL :: Deserializers
- Camel :: YAML DSL :: Maven Plugins
- Camel :: YAML DSL :: Validator
- Camel :: YAML DSL :: Validator Maven Plugin
</details>
---
:gear: [View full build and test results](https://github.com/apache/camel/actions/runs/32759405406)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "davsclaus (via GitHub)" <gi...@apache.org>.
davsclaus merged PR #25531:
URL: https://github.com/apache/camel/pull/25531
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "atiaomar1978-hub (via GitHub)" <gi...@apache.org>.
atiaomar1978-hub commented on PR #25531:
URL: https://github.com/apache/camel/pull/25531#issuecomment-5398943721
## Review feedback addressed
_AI-generated on behalf of atiaomar1978-hub_
Thanks @davsclaus for the review. Both blocking items are addressed in commit `13f774f`:
### 1. Unrelated `model.properties` change removed
Reverted `core/camel-core-model/src/generated/resources/META-INF/services/org/apache/camel/model.properties` to match `main` (same class of spurious generated drift called out in `ba216589e5ee`).
### 2. Scenario A recovery-path test coverage
Added `shouldRecoverReplyDestinationAfterRefreshWithRunningListenerContainer` to `TemporaryQueueReplyManagerRefreshTest`:
- Creates a real `JmsEndpoint` with Artemis and starts the reply manager (so `listenerContainer` is a running `DefaultJmsMessageListenerContainer`)
- Waits for the initial `replyTo` destination
- Calls `scheduleRefresh()` to arm recovery while consumers remain cached
- Asserts deferred recovery completes (`isRefreshPending()` clears, new `replyTo` published, container still running)
This exercises `triggerReplyDestinationRecovery()` → `runReplyDestinationRecovery()` → `DefaultJmsMessageListenerContainer.recoverReplyDestinationAfterRefresh()`.
### Tests run locally
```
./mvnw -pl components/camel-jms -am test \
-Dtest=TemporaryQueueReplyManagerRefreshTest,JmsTemporaryReplyToRequestReplyIT
```
**Result:** 6 tests, 0 failures (5 unit + 1 IT).
### Non-blocking blast-radius question
Reusing Spring's `recoverAfterListenerSetupFailure()` is scoped to the reply-manager DMLC instance only (not the main route consumer). With `replyToConcurrentConsumers > 1` or a shared connection factory, recovery recreates consumers on that container; it does not stop/start the producer-side connection or other endpoints. Happy to add a note in the PR description or JIRA if you'd like that documented explicitly.
Ready for another look when CI is green.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "atiaomar1978-hub (via GitHub)" <gi...@apache.org>.
atiaomar1978-hub commented on PR #25531:
URL: https://github.com/apache/camel/pull/25531#issuecomment-5332250748
## AI Review Summary (Bugbot + Grok)
_AI-generated on behalf of atiaomar1978-hub_
Both reviews were run against this changeset. Findings below, with status after follow-up commits in this PR.
---
### Bugbot findings
| Severity | Finding | Status |
|----------|---------|--------|
| **High** | `setReplyTo` was called before generation confirmation; a concurrent `scheduleRefresh()` could publish then delete a queue, or return a deleted queue | **Addressed** — `setReplyTo` now runs only after `refreshGeneration == generationToHandle`; stale attempts return `null` |
| **High** | Lock-free fast path could return a cached queue after a concurrent arm | **Addressed** — resolver logic is fully under `destinationLock`; no unsynchronized fast path |
| **Medium** | Recovery task could stop re-scheduling if container is not running after failed stop/start | **Partially addressed** — `finally` re-schedules when still pending; Simple-container stop/start path remains less exercised in tests |
---
### Grok review (cursor-grok-4.6-high-fast)
**Verdict:** request changes → several items addressed in latest commit; a few gaps remain for human review.
#### What looks correct
- Generation-based refresh (`refreshGeneration` / `publishedGeneration`) is the right fix for **Scenario B** (flag cleared before queue published) and **Scenario C** (lost update on naive reorder-only fix).
- Builds on CAMEL-24074 locking without reverting it.
- Unit tests with failing `TemporaryQueueResolver` cover the B-shaped retry path well.
#### Addressed in this PR
1. **Recovery races Spring DMLC** — recovery is deferred by `recoveryInterval`, skips while `isRecovering()`, and `recoverReplyDestinationAfterRefresh()` guards with `!isRecovering()`.
2. **Publish ordering** — `replyTo` published only after generation match.
3. **Shutdown** — listener stopped first (`super.doStop()`), then `shutdownNow` on recovery executor; loop checks `isStopping()`.
4. **Generation discard during resolve** — covered by `shouldDiscardPublishWhenRefreshGenerationChangesDuringResolve`.
#### Remaining gaps / human review items
1. **Scenario A not fully reproduced in tests** — the DMLC invoker-pool late-arm path (CACHE_CONSUMER + collapsed pool) is not covered by unit/IT tests here; the external reproducer lab remains the authoritative proof. Consider follow-up IT or acceptance note in JIRA.
2. **`JmsTemporaryReplyToRequestReplyIT`** — sanity test for consecutive InOut only; Artemis VM `restart()` is a no-op, so this does not prove post-broker-fault recovery.
3. **Unrelated generated file in diff** — `core/camel-core-model/.../model.properties` appears unrelated to CAMEL-24401 and should be dropped from this PR before merge.
4. **Simple `replyToConsumerType`** — stop/start recovery path for `SimpleMessageListenerContainer` is untested.
5. **`camel-sjms`** — same defect family noted in JIRA/reproducer; out of scope here but worth a separate ticket.
#### Style / conventions
- Production `Thread.sleep` in recovery loop uses endpoint `recoveryInterval` (acceptable for background recovery, but worth committer opinion).
- New public method `recoverReplyDestinationAfterRefresh()` on `DefaultJmsMessageListenerContainer` — thin hook, but it is public API on a released type.
---
### Recommendation
Approach is sound for B/C and a reasonable mitigation for A. Before merge:
- Remove unrelated `model.properties` change
- Human reviewer to confirm deferred recovery timing is acceptable vs. always triggering immediately on arm
- Acknowledge Scenario A validation relies on reporter reproducer + unit coverage of generation protocol
Backport: https://github.com/apache/camel/pull/25530
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] CAMEL-24401: Fix permanent temporary replyTo strand in camel-jms [camel]
Posted by "davsclaus (via GitHub)" <gi...@apache.org>.
davsclaus commented on code in PR #25531:
URL: https://github.com/apache/camel/pull/25531#discussion_r3843289939
##########
components/camel-jms/src/test/java/org/apache/camel/component/jms/reply/TemporaryQueueReplyManagerRefreshTest.java:
##########
@@ -0,0 +1,256 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.camel.component.jms.reply;
+
+import java.util.concurrent.atomic.AtomicInteger;
+
+import jakarta.jms.Connection;
+import jakarta.jms.JMSException;
+import jakarta.jms.Session;
+import jakarta.jms.TemporaryQueue;
+
+import org.apache.camel.CamelContext;
+import org.apache.camel.component.jms.JmsConfiguration;
+import org.apache.camel.component.jms.JmsEndpoint;
+import org.apache.camel.component.jms.TemporaryQueueResolver;
+import org.apache.camel.test.infra.artemis.common.ConnectionFactoryHelper;
+import org.apache.camel.test.infra.artemis.services.ArtemisService;
+import org.apache.camel.test.infra.artemis.services.ArtemisServiceFactory;
+import org.apache.camel.test.infra.core.DefaultCamelContextExtension;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+import org.junit.jupiter.api.extension.RegisterExtension;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatThrownBy;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
+
+class TemporaryQueueReplyManagerRefreshTest {
+
+ @RegisterExtension
+ static DefaultCamelContextExtension contextExtension = new DefaultCamelContextExtension();
+
+ @RegisterExtension
+ static ArtemisService service = ArtemisServiceFactory.createVMService();
+
+ private TemporaryQueueReplyManager replyManager;
+
+ @BeforeEach
+ void setUp() {
Review Comment:
None of the tests in this class start the `TemporaryQueueReplyManager` (no call to `.start()`/`doStart()`), so `listenerContainer` stays `null` throughout. That means `triggerReplyDestinationRecovery()` always hits its early `listenerContainer == null` guard, and `runReplyDestinationRecovery()` / `DefaultJmsMessageListenerContainer.recoverReplyDestinationAfterRefresh()` are never actually exercised by this test class.
That background-recovery path is specifically what fixes Scenario A from the PR description ("cached consumer, no one left to call the destination resolver") — arguably the trickiest part of this fix — and it currently has no test coverage. The generation-counter tests here are valuable for Scenarios B/C, but could you add a test (or extend `JmsTemporaryReplyToRequestReplyIT`) that starts a real listener container, forces an `onException`/`scheduleRefresh()` while a consumer is already cached, and asserts recovery actually happens end-to-end?
##########
components/camel-jms/src/main/java/org/apache/camel/component/jms/reply/TemporaryQueueReplyManager.java:
##########
@@ -57,9 +63,95 @@ public TemporaryQueueReplyManager(CamelContext camelContext, TemporaryQueueResol
@Override
protected void doStop() throws Exception {
super.doStop();
+ if (refreshRecoveryExecutor != null) {
+ camelContext.getExecutorServiceManager().shutdownNow(refreshRecoveryExecutor);
+ refreshRecoveryExecutor = null;
+ }
ServiceHelper.stopService(destinationResolver);
}
+ private void triggerReplyDestinationRecovery() {
+ if (listenerContainer == null || isStopping() || isStopped()) {
+ return;
+ }
+ if (!destinationResolver.isRefreshPending()) {
+ return;
+ }
+ if (!refreshRecoveryScheduled.compareAndSet(false, true)) {
+ return;
+ }
+ try {
+ getRefreshRecoveryExecutor().execute(this::runReplyDestinationRecovery);
+ } catch (RejectedExecutionException e) {
+ refreshRecoveryScheduled.set(false);
+ }
+ }
+
+ private void runReplyDestinationRecovery() {
+ try {
+ long delay = endpoint.getRecoveryInterval() >= 0 ? endpoint.getRecoveryInterval() : 5000L;
+ if (!sleepQuietly(delay)) {
+ return;
+ }
+ int attempts = 0;
+ while (destinationResolver.isRefreshPending() && !isStopping() && !isStopped()
+ && listenerContainer != null && listenerContainer.isRunning() && attempts < 20) {
+ try {
+ if (listenerContainer instanceof DefaultJmsMessageListenerContainer dmlc) {
+ if (dmlc.isRecovering()) {
+ if (!sleepQuietly(delay)) {
+ return;
+ }
+ attempts++;
+ continue;
+ }
+ dmlc.recoverReplyDestinationAfterRefresh();
Review Comment:
Question/assumption for the author to confirm rather than a blocking issue: `TemporaryQueueReplyManager` uses a single shared `listenerContainer` (one temp queue) for *all* in-flight InOut exchanges on this endpoint. `DefaultMessageListenerContainer.recoverAfterListenerSetupFailure()` calls `refreshConnectionUntilSuccessful()`, which for a shared connection tears down and recreates the entire underlying JMS `Connection` (`refreshSharedConnection()` in Spring's `AbstractJmsListeningContainer`) — not just the one consumer whose replyTo needs refreshing.
Since `triggerReplyDestinationRecovery()` is only invoked from the JMS `ExceptionListener` (i.e. after a genuine connection-level fault, which already affects every consumer on the shared connection), this is probably the right call — but could you confirm this blast radius was considered, particularly for `replyToConcurrentConsumers > 1` where multiple concurrent in-flight replies would be sharing this container?
##########
core/camel-core-model/src/generated/resources/META-INF/services/org/apache/camel/model.properties:
##########
@@ -13,11 +13,16 @@ beanFactory
beanio
bearerToken
bindy
+blacklistServiceFilter
Review Comment:
This generated file picks up ~23 unrelated entries (`blacklistServiceFilter`, `consulServiceDiscovery`, `kubernetesServiceDiscovery`, `zookeeperServiceDiscovery`, `serviceCall`, load-balancer configs, etc.) that have nothing to do with the JMS replyTo fix. This looks like a stale/partial local build state (e.g. a full reactor build picking up modules that weren't part of a scoped build) that leaked into the commit.
`git log` on this file shows the same class of issue was reverted before in `ba216589e5ee` ("revert spurious generated file changes"). Please drop this file from the diff — it should regenerate to match `main` once the branch is rebased and only the affected module is rebuilt.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org