Hi
You can use route policy to control the route consumer to
suspend/resume, depending on number of in flight exchanges for the
route.
http://camel.apache.org/routepolicy
Then you can suspend when reaching 5, and resume when back to 4 or lower.
There is a ThrottlingInflightRoutePolicy for that.
On Sat, Sep 8, 2012 at 9:44 PM, solimo rob...@budzko.eu wrote:
Hi,
If we stick to examples in term of feedback and gateway configuration as an
optional then I understand if ParamUtils.checkDestination(...) returns false
then default values should still be used. Right now
Hi
I think this is a good idea. When you store data in a RDBMS you may
want to use SQL types that is readable by humans, such as VARCHAR2 (or
what they are called today).
So maybe have some way to make this easier to say if header/body
should be binary or text based.
Yes you can create your own
@Claus I think adding such an option to the existing JDBC
AggregationRepository would be a good idea too. Particularly as the current
JDBC AggregationRepository code is not very friendly for
extending/encapsulating - as everything useful is marked final or private.
I shall work on an
I've got a route that splits a large file into records, using a splitter.
Its basically working but I can't get it to tolerate errors during the
splitting. The route terminates on the first error, but I want that
error to be caught so that the bad record can be logged and processing
continue
Which version of Camel do you use [1]?
Checkout [2] - stopOnException how to continue if an exception occurs (use
a custom AggregationStrategy).
And because it's a custom splitter, you have the full control how to handle
the error...
[1] http://camel.apache.org/how-can-i-get-help.html
[2]
Hi,
I'm using 2.10 version.
Yes, its a custom splitter so I could handle the exception. But not sure
what I would do with it, or whethr that is really a good thing to do.
stopOnException seems to relate to exceptions that occur downstream of
the splitter, not from the splitting itself?
And
I would use
to uri=bean://circService/
instead of
bean ref=circService/
but may be this is not necessary.
Than, in your unit test, use
@Test
public void test() throws Exception {
context.addRoutes(new RouteBuilder() {
@Override
public void configure()
Thanks, here's what I ended up doing.
Changed the bean call to look like this:
to uri={{circ.service}}/
That value is defined in a properties file - in live use it's
bean:circService, but under testing it's mock:circService.
In my test, I added this:
@EndpointInject(uri = {{circ.service}})
