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
