Hello Tolga! Already done and will be part of Camel 2.8 (see the issue). Thanks for reporting this issue.
Best, Christian On Thu, Jul 7, 2011 at 3:10 AM, Tolga Tarhan <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> > 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 > > > > > >
