Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of christian.mueller@gmail.com
 designates 209.85.219.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1364178381645-5729737.post@n5.nabble.com>
References: <1364178381645-5729737.post@n5.nabble.com>
Date: Wed, 27 Mar 2013 12:27:04 +0100
Message-ID: 
 <CALvzYd9aQ-86hoL=1fiQPNudRM+43v7oNMALCS0F+A2iXMrHHQ@mail.gmail.com>
Subject: Re: [DISCUSS] another camel 3.0 ideas
From: =?ISO-8859-1?Q?Christian_M=FCller?= <christian.mueller@gmail.com>
To: dev@camel.apache.org
Content-Type: multipart/alternative; boundary=f46d044281a04ea30804d8e651b1

--f46d044281a04ea30804d8e651b1
Content-Type: text/plain; charset=ISO-8859-1

Hello Koseki!

Hope you are well. And thanks for participating in this discussion!

Regarding 1)
This is already on the road map for Camel 2.x / 3.x. As you told me in
Portland, we have to check whether we can improve how we handle batch
submission (If we have a batch with 100 individual messages, we should only
issue one commit at the end instead of 100 commits.).

Regarding 2)
I think one part of your idea is already addressed with the topic "Schedule
in DSL" at [1]. I don't think (I don't know how) we can handle component
specific errors in or onException() definition. Let's assume you poll a JMS
queue and you cannot access the queue (for whatever reason). It doesn't
make sense for me to create an empty exchange with the exception attached
which is send to the next processor or the onException() definition if it
exists. We should eager check (if possible) whether the provided
configuration works or not.

Regarding 3)
Interesting idea. I think it's useful. I will add it to our Camel 3.0 idea
page [2]. We will see whether we can find enough supporter and a champion
for it.

[1] http://camel.apache.org/camel-30-ideas.html#Camel3.0-Ideas-ScheduleinDSL
[2] http://camel.apache.org/camel-30-ideas.html

Best,
Christian

On Mon, Mar 25, 2013 at 3:26 AM, koseki nonuyuki
<koseki.nobuyuki@gmail.com>wrote:

> Hi
>
> I have some ideas I want to see in Camel 3.0
>
> 1)Batched Transaction
> As discussed in [1], I'm glad to see this feature in Camel 3.0 or 2.X, if
> possible.
> When we have to deal with a huge number of data without losing any data,
> batched transaction mechanism or similar feature is required.
>
> 2)Introduce 'Timer + Consumer' instead of PollingConsumer
> When we define a route that contains pollingConsumer, such as File
> consumer,
> we have to define two exception logic, one is onException and the other is
> component specific error handling.
>
> How about the idea that we divide pollingConsumer into two part, timer part
> and consumer part.
>
> If the timer component instantiate the Exchange periodically, then next
> consumer can handle errors by onException logic, that means we can handle
> all errors by onException logic, not using component specific error
> handling.
>
> 3)Print route information when error occured
> Like printStackTrace() in Java, Camel can print routeTrace(), that make us
> much easier to trace route when we encounter exception.
>
>
> [1]
>
> http://camel.465427.n5.nabble.com/SJMS-and-batched-transactions-td5716910.html
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/DISCUSS-another-camel-3-0-ideas-tp5729737.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

--f46d044281a04ea30804d8e651b1--