Alright... thank you for the reply! Really appreciate it.
Do you think this is clear enough in the current documentation? To me, this
part is rather confusing:
IMPORTANT: this will only reduce the endpoint cache of the toD that has a
chance of being reused in case a message is routed with the same
userName header.
Therefore, reducing the cache size will not solve the *endless dynamic
endpoint* problem. Instead, you should use static endpoints with to and
provide the dynamic parts in Camel message headers (if possible).
It states we should use static endpoint with "to", but then the example
right after uses "toD".
from("direct:login") .setHeader(Exchange.HTTP_PATH, constant("/login"))
.setHeader(Exchange.HTTP_QUERY, simple("userid=${header.userName}")) .toD(
"http:myloginserver:8080");
This confused me a little, I had another question. If I used "to" and set
some headers HTTP_PATH or HTTP_QUERY, would these headers be considered at
runtime even with ".to" or only with ".toD"?
And, the problem is, I tried this solution above and it didn't work either.
We still got a memory leak. The example is using a constant HTTP_PATH, and
a dynamic HTTP_QUERY. My case was something like:
from("direct:login") .setHeader(Exchange.HTTP_PATH, simple ("/
${exchangeProperty.lockCodeForSearch)"))
.toD("http:myloginserver:8080");
I don't know, maybe I was the only one to have problems with this section,
but I would like to state more clearly an example or "IMPORT" saying:
"If you're computing dynamic URLs, don't do this:
.toD(${exchangeProperty.endpointUri})
And follow with your explanation,
"toD needs to know the component in use before it can do
optimizations. Instead,
consider building the URL like:
.toD( http:myloginserver:8080/my-path/${exchangeProperty.pathParam}
<https://sboot-scmb-rpcb-atom-configuracao.appuat.bvnet.bv/v1/provider/lock-code/$%7BexchangeProperty.lockCodeForSearch%7D>
)"
It's just a suggestion, if you think it's pertinent I would even volunteer
to make a contribution.
Best regards,
Gabriel
On Mon, Jun 9, 2025 at 11:08 AM Claus Ibsen <claus.ib...@gmail.com> wrote:
> 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
>
