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