Christian, Sorry for the long delay in responding. I agree that changing the logic only in the case of this SMPP-specific exception, ProcessRequestException, is a relatively straight-forward way to go. I've got the camel-smpp code checked out, if you'd like me to take the first stab at a patch.
The other option is to have a configuration parameter which indicates that we want to send a failure to the SMSC in the event of an exception. In this case, we'd both execute the exception handler AND throw a ProcessRequestException back to jsmpp to notify the SMSC. Both options could be implemented in a complementary manner. -- Tolga On Tue, Jun 21, 2011 at 2:51 PM, Christian Müller < christian.muel...@gmail.com> wrote: > 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 > > >
