Andrea Cosentino created CAMEL-24624:
----------------------------------------
Summary: camel-infinispan: catalog, lifecycle and efficiency
cleanups
Key: CAMEL-24624
URL: https://issues.apache.org/jira/browse/CAMEL-24624
Project: Camel
Issue Type: Task
Components: camel-infinispan
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
h3. Summary
A batch of small consistency, metadata and lifecycle issues found while
auditing {{components/camel-infinispan}} at 10f750a2d61f. Grouped into one
issue because each is a couple of lines.
h3. 1. Phantom {{CamelInfinispanOperationResult}} header
{{InfinispanConstants}} line 51 declares:
{code:java}
@Metadata(label = "producer", description = "The name of the header whose value
is the result", javaType = "String")
String RESULT = "CamelInfinispanOperationResult";
{code}
The constant has zero references in main or test sources, yet it is published
in both {{infinispan.json}} and {{infinispan-embedded.json}} and rendered
throughout the component documentation. Its description is also a copy of the
one on {{RESULT_HEADER}} ({{CamelInfinispanOperationResultHeader}}), which is
the option that actually names the result header - so the docs advertise two
headers for one job and the more obvious-looking one does nothing.
h3. 2. {{CamelInfinispanIgnoreReturnValues}} is labelled as a consumer header
{{InfinispanConstants}} line 72 marks it {{label = "consumer"}}, but it is read
on the producer path, in {{InfinispanEmbeddedManager.getCache(Message,
String)}} line 140, and its description ("a write operation's return value") is
producer semantics. It lands in the wrong group in the catalog and docs.
h3. 3. Consumer stop order
{{InfinispanRemoteConsumer}} line 71 and {{InfinispanEmbeddedConsumer}} line 65
both call {{super.doStop()}} before stopping the handler that owns the cache
listener, the reverse of {{doStart()}}. Between the two calls the consumer is
stopped while the listener is still registered, so an event arriving in that
window is processed against a stopped consumer.
h3. 4. Idempotent repository does two round trips per check
{{InfinispanIdempotentRepository.add}} line 47 does {{containsKey}} followed by
{{put}}. The result is correct (the decision is taken on {{put}}'s return
value), but {{putIfAbsent(key, true) == null}} is a single atomic call that
also satisfies the existing comment's intent of not resetting the lifespan of
an existing entry. On the Hot Rod repository the current form doubles the
network cost of every idempotency check.
h3. 5. Typos
* {{InfinispanRemoteConsumer}} line 153: "Cannot remote the listener" should be
"remove".
* {{InfinispanConstants}} line 76: "InifinispanConfiguration" in the
{{QUERY_BUILDER}} metadata description.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
