Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of christian.mueller@gmail.com
 designates 209.85.216.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Fu6kT7OOMsXPN0JM9yIY+I8sI8n4keZzWxYZhLsavtDerwpgJg8+4J8dVrmyJjl1MB
         +MwfgOfveEQ8H5D0htVXkiGaPmQtZoEeV8Uj+sXWMvh7pQDp+IKAOezFUCZo+4MH+vj2
         u4sMo5y2ZDPoOoF+q0mCDPNEOISw1e4qkVkXg=
MIME-Version: 1.0
In-Reply-To: <BANLkTin3ohGZ=kB2Si5yKAM7dLxPCNN=Ww@mail.gmail.com>
References: <BANLkTin3ohGZ=kB2Si5yKAM7dLxPCNN=Ww@mail.gmail.com>
Date: Thu, 26 May 2011 09:17:29 +0200
Message-ID: <BANLkTik+mPXtYDn2BUhW_gnXOd2FLr3kxQ@mail.gmail.com>
Subject: Re: SmppConsumer: Deliver SM Error Handling
From: =?ISO-8859-1?Q?Christian_M=FCller?= <christian.mueller@gmail.com>
To: dev@camel.apache.org
Content-Type: multipart/alternative; boundary=00163630f5853032eb04a4289d30

--00163630f5853032eb04a4289d30
Content-Type: text/plain; charset=ISO-8859-1

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 <tolga@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
>

--00163630f5853032eb04a4289d30--