Tolga, today I had the time to look into it. At present the SmppConsumer catches any Exception in the onAcceptDeliverSm(DeliverSm) and let the exception handler handle it. This is the way Camel handle the exceptions. In a real production system, I would not expect that you will let the logging error handler handle the exception. I think you will use a redelivery error handler or dead letter error handler. The error handler is responsible for a proper handling of the exception.
However, the SMPP protocol gives you (the ESME) the possibility to signal the SMSC to resend the message at a later time in case of an exception. Then the SMSC mas to redeliver the message. Onfortunately, providing your own ExceptionHandler which returns a ProcessRequestException with the proper error code is not a solution, because the ExceptionHandler interface do not define any exceptions on the handleException() method. The only thing I can imagine is to throw new ProcessRequestException(e.getMessage(), 0x00000064, e); // ESME_RX_T_APPN: ESME Receiver Temporary App Error Code for each request which fails. But this doesn't look right for me. We do not know whether a redelivery is useful or not. The "best" solution I have in my mind is that we have a different exception handling for ProcessRequestException and for all other exception. We could only rethrow the ProcessRequestException and the user (you) is responsible to set the proper error code. For all the other Exceptions the behavior is unchanged. What do you think? How would you suggested patch look like? I will raise a JIRA. 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 >
