Hi
This is expected behaviour as toD needs to know the component in use before
it can do optimizations. And that is why it works correctly when you start
with "http:..." then Camel knows its the http component and can do pre-
optimizations.
On Fri, May 23, 2025 at 2:17 PM Gabriel Souza <
gabrielaraujodesouz...@gmail.com> wrote:
> Hello, I want to ask a question about the usage of the .toD EIP. Recently,
> we had a memory leak problem due to a misuse of .toD. Our URL had a path
> parameter that was dynamically computed, and we found that each request was
> kept forever inside camelContext's attribute "routesToStop".
>
> The URL is in the form " myhost/v1/mypath/{id}"
>
> Inspecting CamelContext, the "routesToStop" attribute kept growing with
> entries like this:
> Producer[myhost/v1/mypath/14254]
> Producer[myhost/v1/mypath/28623]
> Producer[myhost/v1/mypath/98854]
> Producer[myhost/v1/mypath/45352]
> Producer[myhost/v1/mypath/76374]
>
> We read the documentation and applied the suggestions. We tried setting the
> cache to -1, and setting the cache to 10, which didn't solve the problem.
> We also tried setting the header HTTP_PATH with the dynamic part and using
> the static part in toD, which didn't work either.
>
> Finally, we did a simple change in the way we construct the URL.
>
> The problematic way was using this code:
> .toD(${exchangeProperty.endpointUri})
> where the property endpointUri was setted a few lines earlier, and the
> property contained an the full mounted URL like "myhost/v1/mypath/76374".
>
> We changed to this code, which seemed to solve the memory leak:
> .toD(
>
> https://sboot-scmb-rpcb-atom-configuracao.appuat.bvnet.bv/v1/provider/lock-code/${exchangeProperty.lockCodeForSearch}
> )
> where the beginning of the URL is static and just the path variable is
> computed with the ${exchangeProperty.lockCodeForSearch).
>
> Could you help me understand better what causes this difference in the
> behaviour? Right now I don't have sample code because it was something that
> happened in my job, but I probably can recreate it.
>
> The documentation also states that when using "camel-http" this should be
> solved out-of-the- box. We have this dependency in the classpath, and the
> problem still occurs.
>
> Best regards,
> Gabriel
>
--
Claus Ibsen
