routingSlip and async destinations
Camel riders,
I've got a route that makes use of the Routing Slip EIP. Right now, a
processor is used to create the header to be used with the routingSlip
processor. Once that is done, the routingSlip then passes the messages
on to one or more ActiveMQ queues as targets.
It was my understanding that the Routing Slip EIP is supposed to take
a message and send it to each destination synchronously (i.e. go to
destination "A", then destination "B", and so on until all of the
destinations in the routing slip header are visited, or an exception
occurs). However, during my experimentation, I've seen that the
routing slip processor seems to happily "fulfill" its duties by
sending to all of the destinations near simultaneously if the
destinations are ActiveMQ queues.
Here's my RouteBuilder:
/*..*/
getContext().addInterceptStrategy(new Tracer());
from("activemq:results")
.unmarshal(bufFormatter)
.bean(RoutingSlipCreator.class) /* adds "activemq:foo,
etc. as needed"
.routingSlip("routingSlip");
from("activemq:foo")
.bean(Foo.class);
from("activemq:bar")
.bean(Bar.class);
from("activemq:baz")
.bean(Baz.class);
from("activemq:quux")
.bean(Quux.class);
And here's an example of the tracer tracing this interaction (I've
deleted the contents of the body for brevity):
DefaultMessageListenerContainer-1 INFO
[org.apache.camel.processor.interceptor.Tracer] -
ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1 >>> (route1) -->
com.ateb.dataproc.obc_processor.processor.postcontact.routingslipcrea...@407e75d2
<<< Pattern:InOnly, Headers:{JMSPriority=4, JMSDeliveryMode=2,
JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1,
JMSCorrelationID=null, JMSRedelivered=false,
JMSTimestamp=1273613390576, JMSType=null, JMSReplyTo=null,
underTest=true, JMSDestination=queue://results, JMSXGroupID=null,
JMSExpiration=0}, BodyType:java.util.HashMap, Body:{ ... }
DefaultMessageListenerContainer-1 INFO
[org.apache.camel.processor.interceptor.Tracer] -
ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1 >>> (route1)
com.ateb.dataproc.obc_processor.processor.postcontact.routingslipcrea...@407e75d2
--> routingSlip[routingSlip] <<< Pattern:InOnly,
Headers:{JMSDeliveryMode=2,
routingSlip=activemq:foo,activemq:bar,activemq:baz,activemq:quux,
JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1,
JMSDestination=queue://results, JMSRedelivered=false, underTest=true,
JMSPriority=4, JMSTimestamp=1273613390576, JMSCorrelationID=null,
JMSType=null, JMSReplyTo=null, JMSXGroupID=null, JMSExpiration=0},
BodyType:java.util.HashMap, Body:{ ... }
DefaultMessageListenerContainer-1 INFO
[org.apache.camel.processor.interceptor.Tracer] -
ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:2:1 >>> (route3)
from(activemq://bar) -->
com.ateb.dataproc.obc_processor.processor.postcontact@1ee2433b <<<
Pattern:InOnly, Headers:{JMSCorrelationID=null,
CamelJmsDeliveryMode=2, underTest=true, JMSType=null,
JMSXGroupID=null, JMSTimestamp=1273613391428, JMSExpiration=0,
JMSDestination=queue://bar, JMSReplyTo=null, JMSRedelivered=false,
JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:2:1,
JMSPriority=4, JMSDeliveryMode=2,
routingSlip=activemq:baz,activemq:quux}, BodyType:java.util.HashMap,
Body:{ ... }
DefaultMessageListenerContainer-1 INFO
[org.apache.camel.processor.interceptor.Tracer] -
ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:3:1 >>> (route4)
from(activemq://baz) -->
com.ateb.dataproc.obc_processor.processor.postcontact@5809fdee <<<
Pattern:InOnly, Headers:{JMSTimestamp=1273613391434, JMSXGroupID=null,
CamelJmsDeliveryMode=2,
JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:3:1,
JMSPriority=4, routingSlip=activemq:quux, JMSDeliveryMode=2,
JMSExpiration=0, JMSReplyTo=null, JMSType=null, JMSRedelivered=false,
JMSDestination=queue://baz, JMSCorrelationID=null, underTest=true},
BodyType:java.util.HashMap, Body:{ ... }
DefaultMessageListenerContainer-1 INFO
[org.apache.camel.processor.interceptor.Tracer] -
ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:1:1 >>> (route2)
from(activemq://foo) -->
com.ateb.dataproc.obc_processor.processor.postcontact@43ce663c <<<
Pattern:InOnly, Headers:{JMSXGroupID=null, JMSPriority=4,
JMSDeliveryMode=2, CamelJmsDeliveryMode=2, JMSTimestamp=1273613391410,
JMSExpiration=0, JMSType=null, JMSCorrelationID=null, underTest=true,
JMSReplyTo=null, JMSDestination=queue://foo,
routingSlip=activemq:bar,activemq:baz,activemq:quux,
JMSRedelivered=false,
JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:1:1},
BodyType:java.util.HashMap, Body:{...}
DefaultMessageListenerContainer-1 INFO
[org.apache.camel.processor.interceptor.Tracer] -
ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:4:1 >>> (route5)
from(activemq://quux) -->
com.ateb.dataproc.obc_processor.processor.postcontact.q...@34cef6f1
<<< Pattern:InOnly, Headers:{underTest=true,
JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:
Re: routingSlip and async destinations
On Tue, May 11, 2010 at 7:21 PM, Jon Anstey wrote:
> In RoutingSlipCreator maybe add a slip like
> "jms:foo?exchangePattern=InOut,jms:bar?exchangePattern=InOut" instead of
> just the plain endpoint URIs.
I tried setting my routingSlips to look like this:
activemq:foo?exchangePattern=InOut
and the odd thing is that the tracer doesn't show any difference on
the consuming side; i.e. the MEP is still InOnly, and things are still
handled out of order.
Any other ideas?
--sgp
> On Tue, May 11, 2010 at 7:12 PM, Scott Parkerson
> wrote:
>
>> Camel riders,
>>
>> I've got a route that makes use of the Routing Slip EIP. Right now, a
>> processor is used to create the header to be used with the routingSlip
>> processor. Once that is done, the routingSlip then passes the messages
>> on to one or more ActiveMQ queues as targets.
>>
>> It was my understanding that the Routing Slip EIP is supposed to take
>> a message and send it to each destination synchronously (i.e. go to
>> destination "A", then destination "B", and so on until all of the
>> destinations in the routing slip header are visited, or an exception
>> occurs). However, during my experimentation, I've seen that the
>> routing slip processor seems to happily "fulfill" its duties by
>> sending to all of the destinations near simultaneously if the
>> destinations are ActiveMQ queues.
>>
>> Here's my RouteBuilder:
>>
>> /*..*/
>> getContext().addInterceptStrategy(new Tracer());
>>
>> from("activemq:results")
>> .unmarshal(bufFormatter)
>> .bean(RoutingSlipCreator.class) /* adds "activemq:foo,
>> etc. as needed"
>> .routingSlip("routingSlip");
>>
>> from("activemq:foo")
>> .bean(Foo.class);
>>
>> from("activemq:bar")
>> .bean(Bar.class);
>>
>> from("activemq:baz")
>> .bean(Baz.class);
>>
>> from("activemq:quux")
>> .bean(Quux.class);
>>
>> And here's an example of the tracer tracing this interaction (I've
>> deleted the contents of the body for brevity):
>>
>> DefaultMessageListenerContainer-1 INFO
>> [org.apache.camel.processor.interceptor.Tracer] -
>> ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1 >>> (route1) -->
>>
>> com.ateb.dataproc.obc_processor.processor.postcontact.routingslipcrea...@407e75d2
>> <<< Pattern:InOnly, Headers:{JMSPriority=4, JMSDeliveryMode=2,
>> JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1,
>> JMSCorrelationID=null, JMSRedelivered=false,
>> JMSTimestamp=1273613390576, JMSType=null, JMSReplyTo=null,
>> underTest=true, JMSDestination=queue://results, JMSXGroupID=null,
>> JMSExpiration=0}, BodyType:java.util.HashMap, Body:{ ... }
>>
>> DefaultMessageListenerContainer-1 INFO
>> [org.apache.camel.processor.interceptor.Tracer] -
>> ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1 >>> (route1)
>>
>> com.ateb.dataproc.obc_processor.processor.postcontact.routingslipcrea...@407e75d2
>> --> routingSlip[routingSlip] <<< Pattern:InOnly,
>> Headers:{JMSDeliveryMode=2,
>> routingSlip=activemq:foo,activemq:bar,activemq:baz,activemq:quux,
>> JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:5:1:1:1,
>> JMSDestination=queue://results, JMSRedelivered=false, underTest=true,
>> JMSPriority=4, JMSTimestamp=1273613390576, JMSCorrelationID=null,
>> JMSType=null, JMSReplyTo=null, JMSXGroupID=null, JMSExpiration=0},
>> BodyType:java.util.HashMap, Body:{ ... }
>>
>> DefaultMessageListenerContainer-1 INFO
>> [org.apache.camel.processor.interceptor.Tracer] -
>> ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:2:1 >>> (route3)
>> from(activemq://bar) -->
>> com.ateb.dataproc.obc_processor.processor.postcontact@1ee2433b <<<
>> Pattern:InOnly, Headers:{JMSCorrelationID=null,
>> CamelJmsDeliveryMode=2, underTest=true, JMSType=null,
>> JMSXGroupID=null, JMSTimestamp=1273613391428, JMSExpiration=0,
>> JMSDestination=queue://bar, JMSReplyTo=null, JMSRedelivered=false,
>> JMSMessageID=ID:xyzzy.ateb.com-52179-1273613387168-2:7:1:2:1,
>> JMSPriority=4, JMSDeliveryMode=2,
>> routingSlip=activemq:baz,activemq:quux}, BodyType:java.util.HashMap,
>> Body:{ ... }
>>
>> DefaultMessageListenerContainer-1 INFO
>> [org.apache.camel.processor.interceptor.Tracer] -
>> ID:xyzzy.ateb.com-52179-1273613387
Re: routingSlip and async destinations
On Wed, May 12, 2010 at 12:35 AM, Claus Ibsen wrote: > On Wed, May 12, 2010 at 1:21 AM, Jon Anstey wrote: >> In RoutingSlipCreator maybe add a slip like >> "jms:foo?exchangePattern=InOut,jms:bar?exchangePattern=InOut" instead of >> just the plain endpoint URIs. >> > > Yeah the MEP impacts how the messages gets routed in the Routing Slip EIP. I understand how that makes sense, but it still seems that it violates the principle of least surprise. > You use InOnly which causes the JmsProducer just to send the message > to the JMS queue and then continue immediately. > If you want it to wait for a reply, then you must use InOut Will try to get this working. (See my convo with janstey.) --sgp
Re: routingSlip and async destinations
Well, setting up the consumer side
(from('activemq:foo?exchangePattern=InOut')) seems to work, although
my test is failing because I have a mock endpoint at the end of the
route who is receiving the message almost instantaneously. This tells
me that the routing slip doesn't quite work as I intended.
For the time being, I'm going to hardcode my route using the DSL, but
I'd really like to work in the Routing Slip EIP for the future.
--sgp
Re: routingSlip and async destinations
There's now a JIRA open for this, with a test case attached.
https://issues.apache.org/activemq/browse/CAMEL-2715
--sgp
On Wed, May 12, 2010 at 11:44 AM, Scott Parkerson
wrote:
> Well, setting up the consumer side
> (from('activemq:foo?exchangePattern=InOut')) seems to work, although
> my test is failing because I have a mock endpoint at the end of the
> route who is receiving the message almost instantaneously. This tells
> me that the routing slip doesn't quite work as I intended.
>
> For the time being, I'm going to hardcode my route using the DSL, but
> I'd really like to work in the Routing Slip EIP for the future.
>
> --sgp
>
Rumors of Flatpack's Death Were Quite Exaggerated
I wanted to pass this along to both the Camel and Servicemix groups because I've been seeing a few things in the archives and in JIRA noting that it appeared that Flatpack[1] was dead. On the contrary, it looks quite alive, as they (finally) released version 3.2.0 in March 2010, about two and a half years after the last release (3.1.1, dated November 2007). Furthermore, Flatpack isn't quite "unfriendly" to OSGi, per se -- it actually works quite well, if you can work around the current ServiceMix bundle problem where the fpconvert.properties file didn't make it into the wrapped bundle[2]. Finally, since the SMX bundle is old-ish, I've filed another JIRA[3] to get 3.2.0 in Apache Servicemix (since it could be done around the same time as the other bundling fix). Cheers! --sgp [1]http://sourceforge.net/projects/flatpack/ [2]https://issues.apache.org/activemq/browse/SMX4-561 [3]https://issues.apache.org/activemq/browse/SMX4-562
Re: Rumors of Flatpack's Death Were Quite Exaggerated
Chris, I'm trying to get in touch with the developers of Flatpack to answer those questions. --sgp On Mon, Jul 19, 2010 at 12:12 PM, Chris Custine wrote: > We'll get this fixed ASAP and add a bundle for the new release. Do you know > of any major changes to the API causing incompatibilities? If not, we can > bump the default version to the new one. > > Chris > -- > Chris Custine > FUSESource :: http://fusesource.com > My Blog :: http://blog.organicelement.com > Apache ServiceMix :: http://servicemix.apache.org > Apache Felix :: http://felix.apache.org > Apache Directory Server :: http://directory.apache.org > > > On Mon, Jul 19, 2010 at 09:57, Scott Parkerson > wrote: > >> I wanted to pass this along to both the Camel and Servicemix groups >> because I've been seeing a few things in the archives and in JIRA >> noting that it appeared that Flatpack[1] was dead. On the contrary, it >> looks quite alive, as they (finally) released version 3.2.0 in March >> 2010, about two and a half years after the last release (3.1.1, dated >> November 2007). >> >> Furthermore, Flatpack isn't quite "unfriendly" to OSGi, per se -- it >> actually works quite well, if you can work around the current >> ServiceMix bundle problem where the fpconvert.properties file didn't >> make it into the wrapped bundle[2]. >> >> Finally, since the SMX bundle is old-ish, I've filed another JIRA[3] >> to get 3.2.0 in Apache Servicemix (since it could be done around the >> same time as the other bundling fix). >> >> Cheers! >> --sgp >> >> [1]http://sourceforge.net/projects/flatpack/ >> [2]https://issues.apache.org/activemq/browse/SMX4-561 >> [3]https://issues.apache.org/activemq/browse/SMX4-562 >> >
[Subjective] Which is best? Bean Binding or Explicit Processors?
Camel riders, I've been working on various approaches to a message-driven solution here at $WORK for quite some time, and I must say first of all that I totally love Camel. That said, sometimes I find myself constantly refactoring my solution, because Camel offers so many different approaches to solve a problem. One particular thing that I'm struggling with is whether or not to refactor a set of subclasses I've written that extend Processor explicitly into something that's more flexible (and even more unit-testable) using Camel's POJO Bean Binding. For those who have written solutions: which do you find yourself using? Camel's bean binding, or explicit Exchange handling? --sgp
Re: Using @Produce / @Consume -- What am I missing?
On Mon, 2009-09-14 at 16:07 +0100, James Strachan wrote: > Are you creating your OutboundFooRequestHandlerImpl class by > configuring it in Spring XML? Or are you using the Spring 3 component > scan stuff? Well, that question made me realize that I need to instantiate the bean via Spring. Turns out two things were missing: 1. I needed to configure the Impl class in my bean, thusly: 2. I needed to configure the Apache Maven plugin to add the package "com.ateb.dataproc.obc_processor.internal" to in my POM. Now, I have a new issue: Upon each message consumed, this is spewed to SMX's console: com.ateb.dataproc.obc_processor.internal 11:26:11,796 | WARN | nerContainer-240 | DefaultMessageListenerContainer | AbstractMessageListenerContainer 646 | Execution of JMS message listener failed org.apache.camel.RuntimeCamelException: org.apache.camel.component.jms.RuntimeJmsException: Failed to extract body due to: javax.jms.JMSException: Failed to build body from content. Serializable class not available to broker. Reason: java.lang.ClassNotFoundException: org.apache.camel.component.bean.BeanInvocation. So, evidently, something needs to be added to my bundle's classpath via the pom.xml? Or am I missing the component? --sgp
Using @Produce / @Consume -- What am I missing?
Hello,
I'm trying to use Camel 1.6.1 in SMX 4.1.0.2 (FUSE) and the POJO
Producing / Consuming annotations as described in the online
documentation.
In one class (a CXF-based RESTful webservice), I have the following set
up:
// OutboundFooRequestHandler is an interface (see below)
@Produce(uri="activemq:queue:outbound_foo_req")
private OutboundFooRequestHandler outboundFooRequestHandler;
@POST
@Path("/sendfoo")
public Response sendFoo(OutboundFooRequest sendFooRequest)
{
// (a bunch of web-specific code deleted)
// send this sendFooReqest object on the queue
outboundFooRequestHandler.handle(sendFooRequest);
// Return HTTP response 202 Accepted
return Response.status(202).build();
}
The interface that is annotated with Produce is shown below:
@InOnly
public interface OutboundFooRequestHandler
{
public void handle(OutboundFooRequest outboundFooRequest);
}
Here is the implementation of the interface:
public class OutboundFooRequestHandlerImpl implements
OutboundFooRequestHandler, InitializingBean, DisposableBean
{
private static final Logger logger =
LoggerFactory.getLogger(OutboundFooRequestHandlerImpl.class);
@Override
@Consume(uri="activemq:queue:outbound_foo_req")
public void handle(@Body OutboundFooRequest outboundFooRequest)
{
logger.debug("got it");
// TODO: actually *do* something
}
The producer and the consumer's bundle-context.xml has this:
http://activemq.apache.org/camel/schema/spring"; />
I can send a message, but the consumer doesn't wake up and pick up the
message.
It's worth noting that the producer and the consumer are in two
different bundles.
What am I missing?
--sgp
Using HTTPS in camel-http when remote side has self-signed cert
I'm trying to use Camel's HTTP component to send a POST request to a web service using HTTPS. When I attempt to connect, I get the following exception: org.apache.camel.RuntimeCamelException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:850) at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:138) at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:101) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:105) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:121) at org.apache.camel.impl.DefaultProducerTemplate.requestBody(DefaultProducerTemplate.java:201) [etc.] I'm pretty sure that this is because the remote side is using a self-signed certificate. The question is: is there a good way to replace the behavior SSL factory used by the Commons HTTPClient inside of the camel-http component to make it accept self-signed certificates? I see that the docs mention that you can provide a class that extends CamelHttpClientConfigurer and configure the endpoint to use a reference to that bean. Ideas? --sgp cf. http://www.smerpology.org/
Unit of Work Scope and direct/SEDA/vm components
Hi, fellow Camel riders. I was wondering where Camel's notion of UnitOfWork begins and ends with respect to processing a route or set of routes. For example, I have a route that starts with a SFTP poller that consumes files off of a server. The contents of these files are then handed to another route via the direct component, which is responsible for filtering and routing the data to other processors that are on multiple camel contexts. As such, I have been using the vm component to pass that data to the appropriate processing route. What's strange is that it seems like the files are not marked as processed (i.e. the original SFTP component does not move the files to the processed directory until the message is completely handled by the second route. This is a problem because the second route actually splits and aggregates data in the file, and, as such, the data may not be released from the aggregator until later. Furthermore, the SFTP connection in the body may not be valid anymore, and even if it is, it seems like splitting the data also splits the notion that that data came from a SFTP consumer, which makes lots of stack traces. What I want to know is: how can I make sure that the file on the SFTP server is marked processed before it goes off to the handling route? Do I need to send the data to a file or an JMS/ActiveMQ queue first? Thanks, Scott Parkerson
Re: Unit of Work Scope and direct/SEDA/vm components
Bilgin, Thank you -- that's what I expected, so I'll give using a JMS queue a try. --sgp On Mon, Aug 5, 2013 at 2:45 PM, Bilgin Ibryam wrote: > Hi, > The file component uses onCompletion for moving files after the exchange > has completed. As long as the completions are passed with the exchange the > files wont move. The VM component passes the completions to the next camel > context so the files are not moved... You have to use a queue or something > like wiretap to stop completions. > > HTH > Bilgin > > Sent from mobile > On 5 Aug 2013 18:07, "Scott Parkerson" wrote: > > > Hi, fellow Camel riders. > > > > I was wondering where Camel's notion of UnitOfWork begins and ends with > > respect to processing a route or set of routes. > > > > For example, I have a route that starts with a SFTP poller that consumes > > files off of a server. The contents of these files are then handed to > > another route via the direct component, which is responsible for > filtering > > and routing the data to other processors that are on multiple camel > > contexts. As such, I have been using the vm component to pass that data > to > > the appropriate processing route. > > > > What's strange is that it seems like the files are not marked as > processed > > (i.e. the original SFTP component does not move the files to the > processed > > directory until the message is completely handled by the second route. > This > > is a problem because the second route actually splits and aggregates data > > in the file, and, as such, the data may not be released from the > aggregator > > until later. Furthermore, the SFTP connection in the body may not be > valid > > anymore, and even if it is, it seems like splitting the data also splits > > the notion that that data came from a SFTP consumer, which makes lots of > > stack traces. > > > > What I want to know is: how can I make sure that the file on the SFTP > > server is marked processed before it goes off to the handling route? Do I > > need to send the data to a file or an JMS/ActiveMQ queue first? > > > > Thanks, > > Scott Parkerson > > >
Property Placeholder for Aggregation Completion Timeout Value in Blueprint
I'm using Camel 2.10.4 with my routes defined in Blueprint. I'm trying to
use a property placeholder to configure the completionTimeout for my
aggregator, and it's complaining:
Camel (postingResultsCamelContext) thread #6 - seda://start ERROR
[org.apache.camel.processor.DefaultErrorHandler] - Failed delivery for
(MessageId: ID-elysium-local-64760-1376927985149-0-1 on ExchangeId:
ID-elysium-local-64760-1376927985149-0-6). Exhausted after delivery
attempt: 1 caught: org.apache.camel.TypeConversionException: Error during
type conversion from type: java.lang.String to the required type:
java.lang.Long with value {{processor.posting.aggregation_timeout_millis}}
due java.lang.NumberFormatException: For input string:
"{{processor.posting.aggregation_timeout_millis}}"
org.apache.camel.TypeConversionException: Error during type conversion from
type: java.lang.String to the required type: java.lang.Long with value
{{processor.posting.aggregation_timeout_millis}} due
java.lang.NumberFormatException: For input string:
"{{processor.posting.aggregation_timeout_millis}}"
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
at
org.apache.camel.core.osgi.OsgiTypeConverter.convertTo(OsgiTypeConverter.java:102)
at
org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:37)
at
org.apache.camel.builder.SimpleBuilder.evaluate(SimpleBuilder.java:82)
at
org.apache.camel.processor.aggregate.AggregateProcessor.isCompleted(AggregateProcessor.java:333)
at
org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:258)
at
org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:201)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:571)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:504)
at
org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:213)
at org.apache.camel.processor.Splitter.process(Splitter.java:98)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
at
org.apache.camel.util.AsyncProces
Re: Property Placeholder for Aggregation Completion Timeout Value in Blueprint
Babak,
I'm not sure this will help, as the value I'm trying to replace is not an
attribute, but a child element (see element below:
${in.header.ATEB_CLIENT_ID}-${body.clientStoreId}-${body.rxNumber}-${in.header.ATEB_FILENAME_DATESTAMP}
${in.body.isComplete}
{{processor.posting.aggregation_timeout_millis}}
${in.header.CamelAggregatedCompletedBy} ==
'timeout'
--sgp
On Mon, Aug 19, 2013 at 12:53 PM, Babak Vahdat
wrote:
> Hi
>
> Can you try upgrading to 2.10.5, see the blue box here about the xs:int
> type
> attribute when OSGi Blueprint is in use:
>
>
> http://camel.apache.org/using-propertyplaceholder.html#UsingPropertyPlaceholder-UsingpropertyplaceholdersforanykindofattributeintheXMLDSL
>
> Babak
>
>
> Scott Parkerson-4 wrote
> > I'm using Camel 2.10.4 with my routes defined in Blueprint. I'm trying to
> > use a property placeholder to configure the completionTimeout for my
> > aggregator, and it's complaining:
> >
> > Camel (postingResultsCamelContext) thread #6 - seda://start ERROR
> > [org.apache.camel.processor.DefaultErrorHandler] - Failed delivery for
> > (MessageId: ID-elysium-local-64760-1376927985149-0-1 on ExchangeId:
> > ID-elysium-local-64760-1376927985149-0-6). Exhausted after delivery
> > attempt: 1 caught: org.apache.camel.TypeConversionException: Error during
> > type conversion from type: java.lang.String to the required type:
> > java.lang.Long with value
> {{processor.posting.aggregation_timeout_millis}}
> > due java.lang.NumberFormatException: For input string:
> > "{{processor.posting.aggregation_timeout_millis}}"
> > org.apache.camel.TypeConversionException: Error during type conversion
> > from
> > type: java.lang.String to the required type: java.lang.Long with value
> > {{processor.posting.aggregation_timeout_millis}} due
> > java.lang.NumberFormatException: For input string:
> > "{{processor.posting.aggregation_timeout_millis}}"
> > at
> >
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
> > at
> >
> org.apache.camel.core.osgi.OsgiTypeConverter.convertTo(OsgiTypeConverter.java:102)
> > at
> >
> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:37)
> > at
> > org.apache.camel.builder.SimpleBuilder.evaluate(SimpleBuilder.java:82)
> > at
> >
> org.apache.camel.processor.aggregate.AggregateProcessor.isCompleted(AggregateProcessor.java:333)
> > at
> >
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:258)
> > at
> >
> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:201)
> > at
> >
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> > at
> >
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
> > at
> >
> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
> > at
> >
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
> > at
> >
> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
> > at
> >
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
> > at
> >
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
> > at
> >
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:220)
> > at
> >
> org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
> > at
> >
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
> > at
> >
> org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
> > at
> >
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
> > at
> >
> org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:334)
> > at
> >
> org.apache.camel.processor.RedeliveryErrorHandler.process(Re
Re: Property Placeholder for Aggregation Completion Timeout Value in Blueprint
Ah, but I see that I can use the completionTimeout as an attribute; I've
tried it using the special namespace with 2.10.5 and it worked.
Thanks!
--sgp
On Mon, Aug 19, 2013 at 1:32 PM, Scott Parkerson wrote:
> Babak,
>
> I'm not sure this will help, as the value I'm trying to replace is not an
> attribute, but a child element (see element below:
>
>
>
> strategyRef="postingRequestResultAggregationStrategy">
>
>
> ${in.header.ATEB_CLIENT_ID}-${body.clientStoreId}-${body.rxNumber}-${in.header.ATEB_FILENAME_DATESTAMP}
>
>
> ${in.body.isComplete}
>
>
>
> {{processor.posting.aggregation_timeout_millis}}
>
>
> ${in.header.CamelAggregatedCompletedBy} ==
> 'timeout'
> logName="com.ateb.messaging.myx.posting_results.CamelRoutes"
> loggingLevel="WARN" message="${in.header.CamelFileNameOnly}:
> ${in.header.ATEB_CLIENT_ID}-${body.clientStoreId}-${body.rxNumber}-${in.header.ATEB_FILENAME_DATESTAMP}]
> Timed out waiting for aggregation"/>
>
>
>
>
>
> --sgp
>
>
> On Mon, Aug 19, 2013 at 12:53 PM, Babak Vahdat <
> babak.vah...@swissonline.ch> wrote:
>
>> Hi
>>
>> Can you try upgrading to 2.10.5, see the blue box here about the xs:int
>> type
>> attribute when OSGi Blueprint is in use:
>>
>>
>> http://camel.apache.org/using-propertyplaceholder.html#UsingPropertyPlaceholder-UsingpropertyplaceholdersforanykindofattributeintheXMLDSL
>>
>> Babak
>>
>>
>> Scott Parkerson-4 wrote
>> > I'm using Camel 2.10.4 with my routes defined in Blueprint. I'm trying
>> to
>> > use a property placeholder to configure the completionTimeout for my
>> > aggregator, and it's complaining:
>> >
>> > Camel (postingResultsCamelContext) thread #6 - seda://start ERROR
>> > [org.apache.camel.processor.DefaultErrorHandler] - Failed delivery for
>> > (MessageId: ID-elysium-local-64760-1376927985149-0-1 on ExchangeId:
>> > ID-elysium-local-64760-1376927985149-0-6). Exhausted after delivery
>> > attempt: 1 caught: org.apache.camel.TypeConversionException: Error
>> during
>> > type conversion from type: java.lang.String to the required type:
>> > java.lang.Long with value
>> {{processor.posting.aggregation_timeout_millis}}
>> > due java.lang.NumberFormatException: For input string:
>> > "{{processor.posting.aggregation_timeout_millis}}"
>> > org.apache.camel.TypeConversionException: Error during type conversion
>> > from
>> > type: java.lang.String to the required type: java.lang.Long with value
>> > {{processor.posting.aggregation_timeout_millis}} due
>> > java.lang.NumberFormatException: For input string:
>> > "{{processor.posting.aggregation_timeout_millis}}"
>> > at
>> >
>> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>> > at
>> >
>> org.apache.camel.core.osgi.OsgiTypeConverter.convertTo(OsgiTypeConverter.java:102)
>> > at
>> >
>> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:37)
>> > at
>> > org.apache.camel.builder.SimpleBuilder.evaluate(SimpleBuilder.java:82)
>> > at
>> >
>> org.apache.camel.processor.aggregate.AggregateProcessor.isCompleted(AggregateProcessor.java:333)
>> > at
>> >
>> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:258)
>> > at
>> >
>> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:201)
>> > at
>> >
>> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
>> > at
>> >
>> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
>> > at
>> >
>> org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
>> > at
>> >
>> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
>> > at
>> >
>> org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.j
Re: Property Placeholder for Aggregation Completion Timeout Value in Blueprint
Also, for what it's worth, I can stay at the currently supported version of
Camel we are using and do this:
${properties:processor.posting.aggregation_timeout_millis}
--sgp
On Mon, Aug 19, 2013 at 1:39 PM, Scott Parkerson wrote:
> Ah, but I see that I can use the completionTimeout as an attribute; I've
> tried it using the special namespace with 2.10.5 and it worked.
>
> Thanks!
>
> --sgp
>
>
> On Mon, Aug 19, 2013 at 1:32 PM, Scott Parkerson wrote:
>
>> Babak,
>>
>> I'm not sure this will help, as the value I'm trying to replace is not an
>> attribute, but a child element (see element below:
>>
>>
>> >
>> strategyRef="postingRequestResultAggregationStrategy">
>>
>>
>> ${in.header.ATEB_CLIENT_ID}-${body.clientStoreId}-${body.rxNumber}-${in.header.ATEB_FILENAME_DATESTAMP}
>>
>>
>> ${in.body.isComplete}
>>
>>
>>
>> {{processor.posting.aggregation_timeout_millis}}
>>
>>
>> ${in.header.CamelAggregatedCompletedBy}
>> == 'timeout'
>> > logName="com.ateb.messaging.myx.posting_results.CamelRoutes"
>> loggingLevel="WARN" message="${in.header.CamelFileNameOnly}:
>> ${in.header.ATEB_CLIENT_ID}-${body.clientStoreId}-${body.rxNumber}-${in.header.ATEB_FILENAME_DATESTAMP}]
>> Timed out waiting for aggregation"/>
>>
>>
>>
>>
>>
>> --sgp
>>
>>
>> On Mon, Aug 19, 2013 at 12:53 PM, Babak Vahdat <
>> babak.vah...@swissonline.ch> wrote:
>>
>>> Hi
>>>
>>> Can you try upgrading to 2.10.5, see the blue box here about the xs:int
>>> type
>>> attribute when OSGi Blueprint is in use:
>>>
>>>
>>> http://camel.apache.org/using-propertyplaceholder.html#UsingPropertyPlaceholder-UsingpropertyplaceholdersforanykindofattributeintheXMLDSL
>>>
>>> Babak
>>>
>>>
>>> Scott Parkerson-4 wrote
>>> > I'm using Camel 2.10.4 with my routes defined in Blueprint. I'm trying
>>> to
>>> > use a property placeholder to configure the completionTimeout for my
>>> > aggregator, and it's complaining:
>>> >
>>> > Camel (postingResultsCamelContext) thread #6 - seda://start ERROR
>>> > [org.apache.camel.processor.DefaultErrorHandler] - Failed delivery for
>>> > (MessageId: ID-elysium-local-64760-1376927985149-0-1 on ExchangeId:
>>> > ID-elysium-local-64760-1376927985149-0-6). Exhausted after delivery
>>> > attempt: 1 caught: org.apache.camel.TypeConversionException: Error
>>> during
>>> > type conversion from type: java.lang.String to the required type:
>>> > java.lang.Long with value
>>> {{processor.posting.aggregation_timeout_millis}}
>>> > due java.lang.NumberFormatException: For input string:
>>> > "{{processor.posting.aggregation_timeout_millis}}"
>>> > org.apache.camel.TypeConversionException: Error during type conversion
>>> > from
>>> > type: java.lang.String to the required type: java.lang.Long with value
>>> > {{processor.posting.aggregation_timeout_millis}} due
>>> > java.lang.NumberFormatException: For input string:
>>> > "{{processor.posting.aggregation_timeout_millis}}"
>>> > at
>>> >
>>> org.apache.camel.impl.converter.BaseTypeConverterRegistry.convertTo(BaseTypeConverterRegistry.java:126)
>>> > at
>>> >
>>> org.apache.camel.core.osgi.OsgiTypeConverter.convertTo(OsgiTypeConverter.java:102)
>>> > at
>>> >
>>> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:37)
>>> > at
>>> > org.apache.camel.builder.SimpleBuilder.evaluate(SimpleBuilder.java:82)
>>> > at
>>> >
>>> org.apache.camel.processor.aggregate.AggregateProcessor.isCompleted(AggregateProcessor.java:333)
>>> > at
>>> >
>>> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:258)
>>> > at
>>> >
>>> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor
Ignoring permissions errors on File (FTP/SFTP) consumers
Supposing I had a route that consumed from a remote directory via SFTP. When files are dropped into this directory, they are usually the wrong permission until a cron job comes by to "fix" the permissions so that they are readable by the Camel file consumer. However, until the permissions are set correctly, the file consumer generates a nasty stacktrace in the logs that looks like this when it attempts to read a file it has no permission to read: org.apache.camel.component.file.GenericFileOperationFailedException: Cannot retrieve file: somefile.txt at org.apache.camel.component.file.remote.SftpOperations.retrieveFileToStreamInBody(SftpOperations.java:532)[214:org.apache.camel.camel-ftp:2.10.0.redhat-60024] at org.apache.camel.component.file.remote.SftpOperations.retrieveFile(SftpOperations.java:494)[214:org.apache.camel.camel-ftp:2.10.0.redhat-60024] at org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:317)[106:org.apache.camel.camel-core:2.10.0.redhat-60024] at org.apache.camel.component.file.remote.RemoteFileConsumer.processExchange(RemoteFileConsumer.java:92)[214:org.apache.camel.camel-ftp:2.10.0.redhat-60024] at org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:189)[106:org.apache.camel.camel-core:2.10.0.redhat-60024] at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:155)[106:org.apache.camel.camel-core:2.10.0.redhat-60024] at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:142)[106:org.apache.camel.camel-core:2.10.0.redhat-60024] at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:92)[106:org.apache.camel.camel-core:2.10.0.redhat-60024] at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)[:1.6.0_30] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)[:1.6.0_30] at java.util.concurrent.FutureTask.runAndReset(Unknown Source)[:1.6.0_30] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)[:1.6.0_30] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)[:1.6.0_30] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)[:1.6.0_30] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)[:1.6.0_30] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)[:1.6.0_30] at java.lang.Thread.run(Unknown Source)[:1.6.0_30] Caused by: 3: Permission denied at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2569)[60:org.apache.servicemix.bundles.jsch:0.1.48.1] at com.jcraft.jsch.ChannelSftp.get(ChannelSftp.java:1205)[60:org.apache.servicemix.bundles.jsch:0.1.48.1] at com.jcraft.jsch.ChannelSftp.get(ChannelSftp.java:1158)[60:org.apache.servicemix.bundles.jsch:0.1.48.1] at org.apache.camel.component.file.remote.SftpOperations.retrieveFileToStreamInBody(SftpOperations.java:525)[214:org.apache.camel.camel-ftp:2.10.0.redhat-60024] ... 16 more Is there a way to neuter this particular warning either by some routing magic or policy changes? --sgp
Using Camel to process files and associated metadata files
I have an interesting integration problem:
One of our business units drops report files in a directory. Each report is
a PDF, and has an associated text metadata file that describes the report.
I'd like to have Camel poll the directory for the metadata files, and then,
upon reading the metadata file, load the associated report. The end result
would be that
* the report would be moved to its appropriate location
* the metadata would be stored in a database
* the metadata file would be deleted.
I thought about using the file component to match the metadata files; for
each metadata file, unmarshal the data, and store that data into a header.
Then use pollEnrich to attempt to load the associated report. Once that's
loaded, move it to its final location.
The questions I have are:
1. How does one store the body as an object using the Spring/Blueprint
specification? I know there's the specification, but I'm not
sure just using ${body} is going to work the way I expect
for an object (i.e. not a string).
2. Is this the best way to do this? Something tells me I'm trying to fit a
square peg into a round hole here...
--sgp
Semantics of JMSReplyTo between Camel 2.2 and 2.8
Folks, Somewhere along the way, the semantics of setting the "reply to" in a message header has changed. Background: In 2.2.0, I used to be able to send a message to a queue (specifically, the ActiveMQ.Statistics.Destination.> wildcard queue), which would trigger n responses, n being the number of configured destinations. Using the In-Out MEP didn't work, as it seemed to assume that there would be only one response from the request, grab the first reply, and ignore the next n-1 replies. Thus, I came up with using the In-Only MEP, sending to the queue and setting the JMSReplyTo header to have the responses sent to a topic. The consumer on that topic would use the Aggregator to aggregate the responses, correlating them using the JMSCorrelationId, and using a custom aggregation strategy to create a list of the JMSMapMessages from the statistics query. This worked fine in 2.2.0, where I set the JMSReplyTo header to "topic://qstats". In 2.8.0, setting JMSReplyTo to "topic://qstats" creates a _queue_ called "qstats" rather than a topic. What changed? Are headers which are considered queues being mangled differently by the JMS/ActiveMQ component? Any help would be appreciated! --sgp
