Alright, understood. Thanks!
Em ter., 10 de jun. de 2025, 10:51, Claus Ibsen <claus.ib...@gmail.com>
escreveu:
> 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
>
