I got Camel (actually servicemix) running on a 512 mega(!)bytes Raspberry Pi 
and you say you cannot spare 512 MB for a JVM? Maybe you should go with Cobol & 
JCL. That ran on 8 megs of RAM as far as I can remember.
I got servicemix running on a 64 gig memory 16 cpu 2 node cluster as well. But 
you can also have much much more if you need (fabric, whatever).
Are you talking enterprise or toy shop? You can have both with Camel. It scales 
beautifully from 0 (when you stop it) to whatever you can afford.
I know one particular serious enterprise running Camel. They transfer 10,000 
orders per day worth >1 million USD (4 cpus 4 gig). So wtf are you talking 
about Camel not being enterprise ready?

I did not read the jbatch spec. But from 30,000 feet I can see nothing that 
can´t be done with Camel/EIPs (which Robert+Claus already pointed out). 
Maybe jbatch is great. Maybe it goes the JBI route.

Good luck.

Am 16.12.2013 um 18:53 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:

> 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
>>> 
>>> 
>> 

Reply via email to