camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kraythe ." <kray...@gmail.com>
Subject Re: camel for "short" programs
Date Mon, 16 Dec 2013 17:39:49 GMT
There is nothing that you are trying to do that camel wont do. You simply
don't seem want to do it. So why waste our time? You can start it up and
shut it down if thats your flavor. You dont really need to do such a thing,
but if you want, go for it. You can leave it running as most of us do and
use quartz triggers, events on files showing up, AMQ events and so on. The
only limit is your imagination. If you care looking for camel-ruby that is
weird (and Ruby is ENTIRELY unmaintainable anyway). If you want to do it in
something else then we all wish you good fortune but there is NOTHING
preventing you from reaching your goals with camel.

Always try to think "Is my problem unique to my company or domain?" if not
then the odds are its solved already, you jsut have to learn the provided
APIs.

*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*


On Mon, Dec 16, 2013 at 8:34 AM, Walzer, Thomas <
thomas.walzer@integratix.net> wrote:

> Why not keep the context+routes running?
> If nothing´s there nothing gets processed.
> We transfer a gazillion files and poll like crazy (5 sec) even when
> nothing is expected. Who cares on a corporate network?
>
> Am 15.12.2013 um 20:11 schrieb Romain Manni-Bucau <rmannibucau@gmail.com>:
>
> > Not really true since it prevents from using camel consumers which
> > doesn't support it so it makes camel not as useful as it could.
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> >
> > 2013/12/15 Claus Ibsen <claus.ibsen@gmail.com>:
> >> You can use route policy / event notifier or what not to know when
> >> there is nothing more to process and then signal to the main thread to
> >> stop camel and terminate the jvm.
> >>
> >> No hacks is needed just use the API there is already there.
> >>
> >> On Sun, Dec 15, 2013 at 6:57 PM, Romain Manni-Bucau
> >> <rmannibucau@gmail.com> wrote:
> >>> If you look camel architecture it is great but not usable for batches
> >>> *out of the box*. What I find "sad" is the code needed to support this
> >>> (common) use case shouldn't be that important:
> >>>
> >>> CamelContext ctx = new ...();
> >>> ctx.setSingleShort(true); // or singleExecution(); maybe
> >>>
> >>> This would set the same boolean on the consumers which would not wait
> >>> to get data if nothing is available anymore and would stop the route.
> >>> Once all routes are stopped the context would be stopped too.
> >>>
> >>> This way it would be easy to write cron-ned mains with camel without
> app hacks.
> >>>
> >>> Romain Manni-Bucau
> >>> Twitter: @rmannibucau
> >>> Blog: http://rmannibucau.wordpress.com/
> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>> Github: https://github.com/rmannibucau
> >>>
> >>>
> >>>
> >>> 2013/12/15 John D. Ament <john.d.ament@gmail.com>:
> >>>> Romain,
> >>>>
> >>>> What do you mean?
> >>>>
> >>>> On Sat, Dec 14, 2013 at 4:00 PM, Romain Manni-Bucau
> >>>> <rmannibucau@gmail.com> wrote:
> >>>>> Hmm, so if I understand you camel will not solve it. I find it sad
> cause
> >>>>> camel pipeline and the numerous components are 2 tempting things
for
> >>>>> batches but the fact to be able to process what is here when
> starting and
> >>>>> dont wait another messge is no more is present is mandatory to be
> usable.
> >>>>>
> >>>>> I know it is hackable but I dont think it is clean if not in camel
> itself.
> >>>>> Context should get an option propagated to consumer for it imo.
> >>>>> Le 14 déc. 2013 16:32, "kraythe ." <kraythe@gmail.com> a
écrit :
> >>>>>
> >>>>>> Indeed. Though you could use it to start up and shut down, nothing
> stopping
> >>>>>> you. I would not opt for that choice if I had some sort of
> deployment
> >>>>>> system where I could keep the routes running.
> >>>>>>
> >>>>>> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> >>>>>> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> >>>>>> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> >>>>>> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
> >>>>>>
> >>>>>>
> >>>>>> On Sat, Dec 14, 2013 at 9:09 AM, John D. Ament <
> john.d.ament@gmail.com
> >>>>>>> wrote:
> >>>>>>
> >>>>>>> Why not use a polling consumer?
> >>>>>>>
> >>>>>>> On Sat, Dec 14, 2013 at 6:25 AM, Romain Manni-Bucau
> >>>>>>> <rmannibucau@gmail.com> wrote:
> >>>>>>>> Hi
> >>>>>>>>
> >>>>>>>> any opinion on how to make consumers consume all what
is possible
> when
> >>>>>>>> program is running then shutdown the route once processed?
> >>>>>>>>
> >>>>>>>> It is basically needed for BatchEE camel extension (
> >>>>>>>>
> >>>>>>>
> >>>>>>
> https://git-wip-us.apache.org/repos/asf?p=incubator-batchee.git;a=blob;f=extensions/camel/src/main/java/org/apache/batchee/camel/CamelItemReader.java;h=bf4d289a8fea4a18f783353c3cb25d1aa9050018;hb=HEAD
> >>>>>>>> ) + I wondered it for some batches I wrote some months
ago without
> >>>>>>>> camel because the infra needed for it was too heavy
(route policy
> +
> >>>>>>>> few other things) compared to the gain.
> >>>>>>>>
> >>>>>>>> ATM batchee relies on timeout but surely not the best
way to do.
> >>>>>>>>
> >>>>>>>> Romain Manni-Bucau
> >>>>>>>> Twitter: @rmannibucau
> >>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>
> >>>>>>
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> Red Hat, Inc.
> >> Email: cibsen@redhat.com
> >> Twitter: davsclaus
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >> Make your Camel applications look hawt, try: http://hawt.io
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message