Yes, it's possible to share the jsmpp session, btw. we have to share it in
this case (only one TRX connection is allowed).
We could only log the received message, if no consumer route is defined.
But may be this is not suitable for most of our users.
We could also throw an exception at route/context start up, but this is not
right in my opinion. Assume you do not expect to receive short message (you
only send short message) and you send the messages with the flag that you
are not interested in any delivery received message (part of the SMPP
specification). In this case, you do not need a consumer route.
The best solution I can think for this case (TRX mode connection and no
consumer route) is to log the incomming message at WARN level (delivery
receipt, short message, ...) and reject it. Than the SMSC should try to
redeliver the short message at a later time and the user can fix this
misconfiguration. What do you think?
Best,
Christian
On Sun, Jan 13, 2013 at 11:31 AM, Pontus Ullgren <ullg...@gmail.com> wrote:
> Correction I was wrong on the direct endpoint restriction.
>
> I was thinking about the log message that occurs when a exchange is
> send to a direct endpoint without a consumer. So perhaps there is no
> way to determine if there is a corresponding consuming endpoint at
> start.
>
> On Sun, Jan 13, 2013 at 11:19 AM, Pontus Ullgren <ullg...@gmail.com>
> wrote:
> > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller
> > <christian.muel...@gmail.com> wrote:
> >> The smslib model is a bit different. The smslib camel consumer pull the
> >> short messages for the SMSC. And only if a consumer is defined (
> >> from("smslib://...") ).
> >> In the smpp Camel component, the SMPP library push the short messages
> (and
> >> delivery receipt messages) to the client if the client is connected in
> the
> >> TRX mode.
> >> Assume there is only one producer ( to("smpp://...") ) defined and no
> >> consumer. The SMPP library push the message to the client. Because
> there is
> >> no Camel consumer, there is no route which can
> consume/handle/process/...
> >> this message. What is a good/acceptable behavior in this case?
> >>
> > Not sure what the JSMPP library allows us to do but on a protocol level
> you can
> > reply with a deliver_sm_resp to indicate a failed command_status.
> Perhaps this
> > is a solution if there is no consuming endpoint.
> >
> > Another solution would be to refuse to start the producer endpoint in
> > trx mode if
> > there is no corresponding consuming endpoint defined. If I do not
> > remember incorrectly
> > a similar restriction applies to direct endpoints ?
> >
> > // Pontus
> >
> >
> >> Best,
> >> Christian
> >>
> >> On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson <a...@frontlinesms.com
> >wrote:
> >>
> >>> On 4 January 2013 17:26, Christian Müller <christian.muel...@gmail.com
> >
> >>> wrote:
> >>> > I think we don't have another camel component where the endpoint is a
> >>> > consumer and producer. I'm not sure how/if it works or if we hit
> problems
> >>> > in other areas (exception handling, ...).
> >>>
> >>> We do this for the camel-smslib component. The endpoint represents a
> >>> serial connection to an SMS modem, and therefore must deal with either
> >>> sending or receiving of messages or both. I have no idea if this is a
> >>> recommended approach from camel perspective, but it works for us. My
> >>> interpretation of the camel doc was that returning `true` from
> >>> Endpoint.isSingleton() should allow for one Endpoint per URI, but
> >>> multiple consumers/producers tied to the Endpoint.
> >>>
> >>> You can see example at
> >>>
> >>>
> https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java
> >>>
> >>
> >>
> >>
> >> --
>
--
