SmppConsumer: Deliver SM Error Handling

[Tolga Tarhan <to...@netbrains.com>]

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

Re: SmppConsumer: Deliver SM Error Handling

[Christian Müller <ch...@gmail.com>]

Tracked with https://issues.apache.org/jira/browse/CAMEL-4136

Re: SmppConsumer: Deliver SM Error Handling

[Christian Müller <ch...@gmail.com>]

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 <to...@netbrains.com> 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 <
> christian.mueller@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
> > >
> >
>

Re: SmppConsumer: Deliver SM Error Handling

[Tolga Tarhan <to...@netbrains.com>]

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.mueller@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
> >
>

Re: SmppConsumer: Deliver SM Error Handling

[Christian Müller <ch...@gmail.com>]

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
>

Re: SmppConsumer: Deliver SM Error Handling

[Christian Müller <ch...@gmail.com>]

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
>