Hi
Its either
a)
Do not use all those HTTP_XXX headers with toD.
Instead put dynamic parts in the toD uri with {{xxx}} placeholders for
headers / variables etc.
b)
Or use a single static to and only HTTP_XXX headers
On Tue, Jun 10, 2025 at 2:27 PM Gabriel Souza <
gabrielaraujodesouz...@gmail.com> wrote:
> 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
> >
>
--
Claus Ibsen
