Hi, did someone get to see this?

Em sex., 23 de mai. de 2025, 09:11, Gabriel Souza <
gabrielaraujodesouz...@gmail.com> escreveu:

> 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
>

Reply via email to