[
https://issues.apache.org/jira/browse/CAMEL-26716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141845#comment-18141845
]
Claus Ibsen commented on CAMEL-26716:
-------------------------------------
More hints from the chaos explorations of CAMEL-26760 on the chaos example
(apache/camel-jbang-examples#134). Two can come straight from a table that
camel-chaos already has: the chaos facts as Good to know hints, as in the
comments above.
*When it fails: an input that does not keep a failed message*
* A Kafka input without {{breakOnFirstError=true}}: a message whose exchange
fails is logged, the consumer commits and goes on, so it is gone. In the
example, route {{refunds}} reads Kafka with the default error handler; refunds
failed on a 503 from payment in runs 3 and 4, while route {{orders}} recovered
from the same fault with its dead letter channel. Hint: "a refund that fails is
logged and skipped: {{breakOnFirstError=true}} reads it again, or a dead letter
channel keeps it".
* The same table covers JMS (kept with {{transacted=true}}, or with
{{acknowledgementModeName=CLIENT_ACKNOWLEDGE}} and {{asyncConsumer=false}}) and
file inputs. It is {{ChaosConsumers}} in camel-chaos, which decides whether the
chaos report counts a failure as "kept by the consumer".
*What is read again: a poison file*
* A file (or ftp, sftp) input without {{moveFailed}}: the rollback leaves a
failed file where it is, so it is read again on every poll, for ever. It is the
opposite of the hint above: a message that never goes away, instead of one that
is lost. Same table.
*When a service is slow* (a new group)
* A route started by a timer that calls out and waits does not start the next
exchange until the call is done. In run 6, route {{orders}} (a timer every
second, then an HTTP call to payment) made 44 orders in 46 s, and 31 in the
same time while payment timed out after 5 s. For a timer that may be fine; for
a Kafka or JMS input it is lag. It pairs with the fact "an HTTP call without a
circuit breaker" that {{chaos-suggest}} already uses.
*Already in the list, now with evidence*
* *Twice or out of order*: {{refunds}} reads Kafka (at least once) and calls
payment without an idempotent consumer. In run 3 a {{duplicate}} rule sent 8
payments twice, and all went through. CAMEL-26791 (an expectation for
duplicates) is the chaos side of the same gap.
* *When it fails*, for an HTTP server: route {{payment}} is {{platform-http}}
with {{noErrorHandler}}, so a failure goes back to the HTTP caller as an error
(run 5, experiment 9).
_Claude Code on behalf of Claus Ibsen_
> camel-jbang - Good to know: hints about an integration from one shared rule
> set (About screen, security scan, Doctor)
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26716
> URL: https://issues.apache.org/jira/browse/CAMEL-26716
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
> Reporter: Claus Ibsen
> Priority: Minor
> Fix For: 4.24.0
>
>
> The About screen of the TUI (CAMEL-26700) should end with *Good to know*: a
> few lines, each answering one question a newcomer to an integration has, from
> the route model, saying what happens (a hint, not a fix):
> * *When it fails*: per entry point, retried N times then the dead letter
> channel, returned to the HTTP caller as 500, or logged and gone.
> * *What is dropped*: a filter, a choice without otherwise, the duplicates an
> idempotent consumer skips.
> * *What does not wait*: a wire tap, a seda: hand-off, inOnly; a failure there
> is not seen by the caller.
> * *What a restart forgets*: an idempotent or aggregation repository in memory.
> * *Twice or out of order*: an input that redelivers (Kafka, JMS) before a
> call out without an idempotent consumer; parallel processing or concurrent
> consumers.
> * *What is exposed or insecure*: a call to another host over a plain
> transport (http:, ftp:, smtp:, Kafka PLAINTEXT) where a secure one exists; an
> option the catalog marks insecure set to its insecure value (security =
> "insecure:ssl", "insecure:serialization", "insecure:dev", such as
> trustAllCertificates=true); an option marked secret written as plain text
> instead of a {{placeholder}} or a vault; an HTTP server without
> authentication on all interfaces. A plain transport to localhost is no hint.
> The hints should not be a set picked while building the screen. They belong
> to one curated set of rules that more tools share, kept in camel-jbang-core:
> * today's ProjectOverview findings,
> * the camel_security_scan and harden tools of camel-jbang-mcp (their rules
> move from camel-jbang-mcp to camel-jbang-core, so the screen and the tools
> agree),
> * the Doctor,
> * the option metadata of the catalog (secret, security = "insecure:*").
> Then the same hints are in the About screen, in camel get about (CAMEL-26700,
> stage 5) and for an AI over MCP.
> To be talked over before it is built (decided on the walk of the About
> screen, 7 Nov 2026). Design:
> https://claude.ai/artifact/2H927wodRp3FAy1BbDbw3P (section "For you to
> decide").
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
