Well that's just my feedback. I don't use camel anymore ATM so I'm not that concerned and I asked only to try to get something better in batchee.
BTW I saw a lot of ugly code to stop camel cause camel was not handling it itself and I'm pretty sure if I propose camel in my current job it will even not be studied cause of it. Compare to spring integration (which you woudn't use if you used camel) it seems a missing "feature". It is ok to close this thread is camel doesn't aim to solve it. Thks btw Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/12/16 kraythe . <kray...@gmail.com>: > Hmm, ok, well I will stop trying to convince people that cant be convinced. > Useless tasks are not very productive. Instead I will wish you the best of > luck in your solution. I guess the millions of installs of camel and the > billions of exchanges processed daily will just have to own up to not being > enterprise ready. ;-) > > *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 11:53 AM, Romain Manni-Bucau > <rmannibu...@gmail.com>wrote: > >> I dont agree, it is a common need (at least the 2 cies i did) and if the >> answzr is keep process running it is really disappointing...ig you have too >> much mem and cpu please share ;)...and being open/extensible (api) doesnt >> mean being enterprise ready. >> >> Another thing is it makes camel not really well usable in jbatch readers >> (not a big deal)...but same applies in spring-batch (released and worse in >> fact since timeout is not handled). So camel should drop this code instead >> of keeping it IMHO. >> Le 16 déc. 2013 18:40, "kraythe ." <kray...@gmail.com> a écrit : >> >> > 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.wal...@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 < >> rmannibu...@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.ib...@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 >> > > >> <rmannibu...@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.am...@gmail.com>: >> > > >>>> Romain, >> > > >>>> >> > > >>>> What do you mean? >> > > >>>> >> > > >>>> On Sat, Dec 14, 2013 at 4:00 PM, Romain Manni-Bucau >> > > >>>> <rmannibu...@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 ." <kray...@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.am...@gmail.com >> > > >>>>>>> wrote: >> > > >>>>>> >> > > >>>>>>> Why not use a polling consumer? >> > > >>>>>>> >> > > >>>>>>> On Sat, Dec 14, 2013 at 6:25 AM, Romain Manni-Bucau >> > > >>>>>>> <rmannibu...@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: cib...@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 >> > > >> > > >> > >>
