Re: Sending email - possible bug?
James Green wrote
To be honest the documentation at
http://camel.apache.org/dead-letter-channel.html is a little contradictory
and could use some touch-ups:
1. Under Redelivery default values the service is turned off and has 0
maximumRedeliveries, yet later it says By default Camel will try to
process the exchange 1 + 5 times.
2. There is no example of how one might log the Exception + stacktrace
that
caused the DLC to be invoked. This must be a common requirement?
On 13 April 2015 at 16:19, Claus Ibsen lt;
claus.ibsen@
gt; wrote:
The DLC do not magically include stacktraces. It sends the message
as-is. If you want to include stacktraces / exception message or
whatever you need to enrich the message before sending to the DLQ to
include that.
On Mon, Apr 13, 2015 at 5:12 PM, James Green lt;
james.mk.green@
gt;
wrote:
An update: the email is sent just fine (I received it eventually). The
trouble is later on - the deadLetterChannel does not appear to log a
stack
trace.
An engineer here is currently scratching his head over this one -
unable
to
see what the route cause is. Any ideas?
On 10 April 2015 at 17:32, Reji Mathews lt;
contactreji@
gt; wrote:
Can u make your Q a little more clear. I assume u got this exception
as
there is no smtp server on ur local host at Port 25.
Obviously it will be caught by ur error handler and since u have used
a
dead letter handler , after specified retry attempts it will get
persisted
to the dead letter uri viz in ur case a jms queue
What's the issue exactly.?
If you are searching for the stack trace it won't be there as its
caught by
ur error handler and message managed .
If u remove ur handlers , u will get the connection refused exception
and
stack traces.
Cheers
Reji
On 10 Apr 2015 16:51, James Green lt;
james.mk.green@
gt; wrote:
We just saw this in the log:
10/Apr/2015 10:56:04,683- DefaultJavaMailSender: Connecting to
localhost:25
10/Apr/2015 10:56:04,701- DefaultJavaMailSender: Sending MimMessage:
javax.mail.internet.MimeMessage@385158f4 using host: localhost
10/Apr/2015 10:56:04,715- DeadLetterChannel: Failed delivery for
(MessageId: ID-ngw-audit-01-39856-1428654916549-0-69 on ExchangeId:
ID-ngw-audit-01-39
856-1428654916549-0-66). On delivery attempt: 0 caught:
java.lang.NullPointerException
The endpoint concerned is smtp://localhost and we're sending a
MimeMessage
down it. Sadly there's nothing more to go on - should we not expect
a
stack
trace somewhere?
Error handler:
errorHandler(deadLetterChannel(activemq:queue:DeliveryReportByEmail.DQL).useOriginalMessage());
The logStackTrace should be on by default looking at the camel
sources?
Thanks,
James
--
Claus Ibsen
-
Red Hat, Inc.
Email:
cibsen@
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
This works for me:
onException
exceptionnet.sf.saxon.trans.XPathException/exception
exceptionorg.apache.camel.language.bean.RuntimeBeanExpressionException/exception
exceptionorg.apache.camel.builder.xml.InvalidXPathExpression/exception
exceptionjava.net.SocketTimeoutException/exception
handled
constanttrue/constant
/handled
pipeline
setHeader headerName=goingToJMSQ
simple${routeId}/simple
/setHeader
setHeader headerName=Exception
simple${exception.message}/simple
/setHeader
setHeader headerName=Exception.Stacktrace
simple${exception.stacktrace}/simple
/setHeader
log message=exception handled from [${routeId}] with error
${header.message} loggingLevel=INFO/
to uri=activemq:queue:dlqQ?disableReplyTo=true/
/pipeline
/onException
--
View this message in context:
http://camel.465427.n5.nabble.com/Sending-email-possible-bug-tp5765589p5765968.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Jetty as a producer for a Rest Call
Using camel 2.12 w/o the doTry block (and using a loop) I get a non
fluctuating '1' in flight message. when stopping the route after deploying
as a .war into eap6, it would take the full 5 minutes for a graceful
shutdown.
I also relearned how to use the Timer. limiting the period to 1s allows the
route to complete w/o violating the REST contract.
from
uri=timer://jettyTimer?fixedRate=trueamp;period=1000amp;repeatCount=0/
doTry
to
uri=jetty:http://api.application.com/v1/pull?httpClient.timeout=3amp;enableJmx=trueamp;throwExceptionOnFailure=falseamp;id={{streamId}}amp;api_key={{api_key}}amp;username={{username}}/
doCatch
exceptionjava.net.ConnectException/exception
log message=*** inside Exception :: ${exception.message}
loggingLevel=ERROR/
/doCatch
/doTry
--
View this message in context:
http://camel.465427.n5.nabble.com/Jetty-as-a-producer-for-a-Rest-Call-tp5762262p5762284.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Jetty as a producer for a Rest Call
A follow up to my previous post:
I use the controlbus to pause and resume this Rest/pull which will throw
exceptions until the message inflight has cleared. This lasts for 5 minutes
until it's forced to by the timeout.
timer 1 time
loop a billion times
to
uri=jetty:http://api.application.com:80/v1/pull?throwExceptionOnFailure=falseamp;id={{stream.id}}amp;api_key={{api_key}}amp;username={{username}}/
I've noticed in Hawtio that Jetty maintains a state of 1 message inflight
at all times.
Is this the nature of Async Jetty?
Is there a way to prevent this?
and/or Is there a way to reduce the amount of time it takes for Jetty to
pause (currently 5 minutes)
Thanks
Rob
--
View this message in context:
http://camel.465427.n5.nabble.com/Jetty-as-a-producer-for-a-Rest-Call-tp5762262.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: HTTP consumer - Terminology confusing
thank you. Glad to know the config is good.
The polling consumer is what we intended.
camel 2.12/activemq 5.9 (we love the Hawtio), war file deployed onto EAP6.3
The original reason for this post is because the client will stall w/o
warnings. No polling activity. no warnings or errors. Sometimes the route
can be stopped/restarted (which we do with a separate route that uses the
controllbus) and sometimes we have to undeploy/deploy. I know, it sounds
like memory issues or too many threads, but the JVM stats show this is not
the case. We're still investigating.
So the warnings in the docs had me concerned. (maybe they should be removed
for us w/limited experience to camel and are basically rule followers)
Code snippet:
from
uri=http://api.application.com/v1/pull?id={{stream}}amp;api_key={{api_key}}amp;username={{username}}/
choice
when
simple${header.CamelHttpResponseCode} == 200/simple
convertBodyTo type=java.lang.String/
to uri=activemq:queue:preQ/
...
But why does the camel doc. say not to use HTTP as consumer to the route? I
understand Clause's suggestion of the Timer to manage the poll. But w/the
timer it is invoked whether the route is complete or not. In our situation,
we suppress this multi threaded behaviour.
Thanks
Rob
--
View this message in context:
http://camel.465427.n5.nabble.com/HTTP-consumer-Terminology-confusing-tp5762190p5762234.html
Sent from the Camel - Users mailing list archive at Nabble.com.
HTTP consumer - Terminology confusing
I use the following as a REST consumer from an external service. I know the
warning in the Camel docs... but am I using this a webservice consumer or as
a Rest Client.
Is this form proper? If not what would I replace it with?
Would someone explain what the ramifications are in using HTTP as a
consumer. (I know the warnings are dire, but why?)
from
uri=http://api.application.com/v1/pull?id={{streamId}}amp;api_key={{api_key}}amp;username={{username}}/
Rob
--
View this message in context:
http://camel.465427.n5.nabble.com/HTTP-consumer-Terminology-confusing-tp5762190.html
Sent from the Camel - Users mailing list archive at Nabble.com.
