camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller <>
Subject Re: SmppConsumer: Deliver SM Error Handling
Date Thu, 26 May 2011 07:17:29 GMT
Hello Tolga!

I will have a look in it.
If you can share your route with us, it would be very helpful. And we love
contributions (which also include unit tests)... :-)


On Wed, May 25, 2011 at 3:09 AM, Tolga Tarhan <> wrote:

> All,
> The SMPP protocol allows a ESME to reject a message temporarily if
> it's having trouble processing it (by responding with ESME_RX_T_APPN -
> ESME Receiver temporary error). This seems to be the most logical
> thing to do when an exception occurs during
> onAcceptDeliverSm(DeliverSm) so that the SMSC will try to deliver the
> message again later.
> However, the behavior currently in SmppConsumer is to use the default
> exception handler, which is LoggingExceptionHandler, and still return
> from onAcceptDeliverSm as normal (thus, JSMPP returns a success to the
> SMSC). Further, the SmppConsumer ignores any faults (it's an InOnly
> endpoint). As a result, the SMSC believes the message was delivered
> when there's an exception or fault.
> The fix is trivial, and I'm happy to submit a patch. Being that I'm
> new to Camel, however, I wanted to ask if this was a reasonable thing
> to do. Specifically, I propose changing SmppConsumer so that in the
> event of an exception during getProcessor().process(exchange) inside
> onAcceptDeliverSm(DeliverSm), we would throw a ProcessRequestException
> back to JSMPP, which causes it respond with a failure to the SMSC,
> rather than a success as it currently does.
> If that change make sense, then I'd also like to ask if changing the
> MEP to InOut makes sense, so that we can capture faults from the
> processor. Obviously, an actual out message never make sense, but we
> could use a fault message to specify an error code to use in the
> ProcessRequestException. Do other components which can report faults,
> but not have any real out messages, work as InOut components or as
> InOnly components?
> Thanks for your advice,
> Tolga

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message