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)... :-)
Best, Christian On Wed, May 25, 2011 at 3:09 AM, Tolga Tarhan <to...@netbrains.com> 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 >
