I logged a ticket: https://issues.apache.org/jira/browse/CAMEL-5963

Best,
Christian

On Sun, Jan 13, 2013 at 12:19 PM, Pontus Ullgren <ullg...@gmail.com> wrote:

> Agree, log and reject would be the best solution.
>
> // Pontus
>
> On Sun, Jan 13, 2013 at 12:01 PM, Christian Müller
> <christian.muel...@gmail.com> wrote:
> > 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
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >>
> >
> >
> >
> > --
>



--

Reply via email to