On Wed, Apr 25, 2018 at 7:29 PM, Alex Dettinger <aldettin...@gmail.com> wrote:
> +1
>
> Great feature, it reminds me an issue years ago where I found a management
> context with tons of file endpoint mbeans.
The file component provides the fileName uri option using simple
expression today that is evaluated per exchange.
So the optimisation does not apply as much here. But it may be a bit
how you use the file component and how the file endpoint is defined.
For many JMX mbeans then Camel should only register mbeans for "static
endpoints" that are defined in routes during startup.
However you can configure Camel to always register, and therefore also
endpoints created dynamically later on.
Many many years ago it would create mbeans always.
But the starting directory is not a simple expression so if you have
from file:foo
to file:bar
Then its 2 different endpoints.
> It makes me wonder if the file component would be a good candidate for this
> optimisation ?
>
Not as much. Also sometimes you may want to have more endpoints you
can see in JMX and others, eg
to file:bar?fileName=backup/${xxxx}
to file:bar?fileName=important/${yyyy}
Would be 2 different endpoints. But if the optimisation is done, then
it would be
setHeader name=backup/${xxxx}
to file:bar
setHeader name=important/${yyyy}
to file:bar
And there would be 1 endpoint file:bar and you would not have
separated stats between the backup vs important endpoint.
The optimisation makes the most sense when its producer take up
resources such as a HTTP client / database connection / JMS connection
etc.
For light-weight java.io.File APIs then there is less gained.
But since its explicit only in use with toD then its a deliberate
choice by the Camel developer and it can make sense to have as many
optimisations as possible.
But for starters we should log a parent JIRA about optimisations for
other components. And then create sub JIRAs for each component we
would work on.
> 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
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
