+1 Great feature, it reminds me an issue years ago where I found a management context with tons of file endpoint mbeans. It makes me wonder if the file component would be a good candidate for this optimisation ?
Alex On Tue, Apr 24, 2018 at 12:30 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Tue, Apr 24, 2018 at 11:43 AM, Bilgin Ibryam <bibr...@gmail.com> wrote: > > + 1 for this improvement from me. > > > > toD is very commonly used expression, and while it is an improvement > > over recipientList, it has a serious drawback - creating new endpoints > > for every changed option... > > > > Only last week I had to use toD for querying Cassandra, and it quickly > > became obvious it is not practical as it was creating a new endpoint > > and a new connection to a Cassandra cluster of 5 even for a small > > query parameter change. You change would allow to reuse the connection > > (I understand this has to be added to Cassandra component first as > > well) and dynamically build queries..gr8. > > > > Yes it would needed to be added specially per component that can > support such kind of optimisation. > For cassandra that would mean having a way of providing the dynamic > queries in headers. > > > > Bilgin > > > > > > On Mon, Apr 23, 2018 at 11:50 AM, Claus Ibsen <claus.ib...@gmail.com> > wrote: > >> Hi > >> > >> We have ticket > >> https://issues.apache.org/jira/browse/CAMEL-12462 > >> > >> Its an idea I had though about in the past, even before we had toD. > >> However I do think that the simplification toD gives Camel end users, > >> can warrant that we attempted to look at this again. > >> > >> In particular when you have HTTP endpoints that are dynamic (different > >> query parameters, context-path, etc) but calling to the same HTTP > >> server, then toD should ideally be optimised to deal with this > >> out-of-the-box. Today you end up with unique Camel endpoints per > >> unique combo computed from toD. > >> > >> So CAMEL-12462 optimised and resolved this. However it does this with > >> a little bit of complexity of parsing the computed endpoint uri to > >> resolve it into 3 parts > >> > >> - static base uri > >> - dynamic context-path > >> - dynamic query parameters > >> > >> Then it will use the static base url, as the Camel endpoint, and > >> therefore resolve into a single endpoint and Camel http producer. And > >> the dynamic parts are automatic provided in Camel headers that the > >> HTTP producer supports (HTTP_PATH and HTTP_QUERY). > >> > >> Anyway the PR has some docs and examples and more details in the > >> updated adoc file for toD, so take a look at that file. > >> > >> I implemented this with a way for components to support this by > >> providing a service locator file in the send-dynamic folder of > >> META-INF, eg same way we discover components. This way other > >> components can provide their own optimisation implementation in the > >> future. For example to other kinds of components like JMS, Kafka and > >> others. > >> > >> I wanted to give the community and other Camel committers a chance to > >> provide feedback, review, improve, etc - before we merged this into > >> the master branch. > >> > >> There is a GitHub PR that makes it easier to browse the code changes > >> https://github.com/apache/camel/pull/2302 > >> > >> > >> > >> > >> -- > >> Claus Ibsen > >> ----------------- > >> http://davsclaus.com @davsclaus > >> Camel in Action 2: https://www.manning.com/ibsen2 > > > > > > > > -- > > Bilgin Ibryam > > ASF Member | Architect at Red Hat > > http://ofbizian.com | @bibryam > > > > Kubernetes Patterns http://leanpub.com/k8spatterns (in progress) > > Camel Design Patterns https://leanpub.com/camel-design-patterns > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
