You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christian Müller <ch...@gmail.com> on 2013/01/03 22:08:43 UTC
Re: camel-smpp in trx mode
It doesn't make sense for me to support the TRX mode.
Could you provide some pseudo code how your route will looks like?
Best,
Christian
On Mon, Dec 31, 2012 at 5:32 AM, Srinivas <ja...@gmail.com> wrote:
> Hi Christian,
>
> Thank you for replying.
>
> Operator given only one smpp connectivity that is in trx mode and
> operator not allowed two smpp(tx and rx) connections. In my application
> receive delivery sm ,delivery recipients and submit sm. Please help me how
> to solve my problem using apache camel.
>
> Regards,
>
> Srinivas
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Re: camel-smpp in trx mode
Posted by Johanes Soetanto <j...@otnateos.com>.
On Sunday, 13 January 2013, Christian Müller 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.
Would it be possible to share SMPP session?
> 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?
If there is no consumer and bind TRX would it be acceptable to simply dump
the message somewhere. Like slf4j nop?
>
> Best,
> Christian
>
> On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson <alex@frontlinesms.com<javascript:;>
> >wrote:
>
> > On 4 January 2013 17:26, Christian Müller <christian.mueller@gmail.com<javascript:;>
> >
> > 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
> >
>
>
>
> --
>
--
Johanes
Re: camel-smpp in trx mode
Posted by Christian Müller <ch...@gmail.com>.
There was no progress on this issue until now. We use to separate
connections (tx and rx).
And we love contributions. If you want to take a stab on it, let us know.
Best,
Christian
-----------------
Software Integration Specialist
Apache Member
V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer
Apache Incubator PMC Member
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Mon, Mar 17, 2014 at 8:53 AM, tkvarenes <tk...@hotmail.com> wrote:
> Are there any progress on this issue. I see that there hasn't been mutch
> activity on the CAMEL-5963 issue.
> This must be something that is crucial for many camel users using smpp?
> Are there any possible workarrounds to support smpp TRX with camel? Any
> other components that can serve as the smpp TRX endpoint in some way?
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5748908.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: camel-smpp in trx mode
Posted by tkvarenes <tk...@hotmail.com>.
Are there any progress on this issue. I see that there hasn't been mutch
activity on the CAMEL-5963 issue.
This must be something that is crucial for many camel users using smpp?
Are there any possible workarrounds to support smpp TRX with camel? Any
other components that can serve as the smpp TRX endpoint in some way?
--
View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5748908.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
Posted by "sash_dce@yahoo.com" <sa...@yahoo.com>.
In that case the endpoint will hold the session. What I am not sure is what
type of listener does one register with the Producer ? The listener does
require the processor .
-----
~Sandeep
--
View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734973.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
Posted by "sash_dce@yahoo.com" <sa...@yahoo.com>.
Hadrian - I am eagerly waiting for the release of the SMPP component with TRX
support. And I guess , this conversational state pattern is a better
solutions. I am not sure how the listener at the producer side get handle to
the "processor" ?
-----
~Sandeep
--
View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5735017.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
Posted by Hadrian Zbarcea <hz...@gmail.com>.
The thorny issue with the TRX mode is that it uses a conversational
pattern, not really quite supported/modeled well.
Since the Endpoint is the one creating the Producers and Consumers, it
could be used to share the conversation state. I believe a cleaner
solution would be to model a Conversation and have consumers and
producers join it. But a quick and dirty solution would do too.
Cheers,
Hadrian
On 06/27/2013 05:28 PM, Christian Müller wrote:
> From the spec:
>
> 5.2.3
> The system_type parameter is used to categorize the type of ESME that is
> binding to the SMSC.
> Examples include “VMS” (voice mail system) and “OTA” (over-the-air
> activation system).
> Specification of the system_type is optional - some SMSC’s may not require
> ESME’s to provide
> this detail. In this case, the ESME can set the system_type to NULL.
>
> Best,
> Christian
> -----------------
>
> Software Integration Specialist
>
> Apache Camel committer: https://camel.apache.org/team
> V.P. Apache Camel: https://www.apache.org/foundation/
> Apache Member: https://www.apache.org/foundation/members.html
>
> https://www.linkedin.com/pub/christian-mueller/11/551/642
>
>
> On Wed, Jun 26, 2013 at 8:08 AM, sash_dce@yahoo.com <sa...@yahoo.com>wrote:
>
>> What is the use of "systemType" paramter ? I don't see any differentiation
>> in the code based on this parameter . Am I missing something ?
>> The possible values are "producer" , "consumer"
>>
>>
>>
>> -----
>> ~Sandeep
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734784.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
Re: camel-smpp in trx mode
Posted by Christian Müller <ch...@gmail.com>.
>From the spec:
5.2.3
The system_type parameter is used to categorize the type of ESME that is
binding to the SMSC.
Examples include “VMS” (voice mail system) and “OTA” (over-the-air
activation system).
Specification of the system_type is optional - some SMSC’s may not require
ESME’s to provide
this detail. In this case, the ESME can set the system_type to NULL.
Best,
Christian
-----------------
Software Integration Specialist
Apache Camel committer: https://camel.apache.org/team
V.P. Apache Camel: https://www.apache.org/foundation/
Apache Member: https://www.apache.org/foundation/members.html
https://www.linkedin.com/pub/christian-mueller/11/551/642
On Wed, Jun 26, 2013 at 8:08 AM, sash_dce@yahoo.com <sa...@yahoo.com>wrote:
> What is the use of "systemType" paramter ? I don't see any differentiation
> in the code based on this parameter . Am I missing something ?
> The possible values are "producer" , "consumer"
>
>
>
> -----
> ~Sandeep
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734784.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: camel-smpp in trx mode
Posted by "sash_dce@yahoo.com" <sa...@yahoo.com>.
What is the use of "systemType" paramter ? I don't see any differentiation
in the code based on this parameter . Am I missing something ?
The possible values are "producer" , "consumer"
-----
~Sandeep
--
View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734784.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
Posted by Christian Müller <ch...@gmail.com>.
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 <ul...@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
> <ch...@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 <ul...@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 <ul...@gmail.com>
> >> wrote:
> >> > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller
> >> > <ch...@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 <
> alex@frontlinesms.com
> >> >wrote:
> >> >>
> >> >>> On 4 January 2013 17:26, Christian Müller <
> christian.mueller@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
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >>
> >
> >
> >
> > --
>
--
Re: camel-smpp in trx mode
Posted by Pontus Ullgren <ul...@gmail.com>.
Agree, log and reject would be the best solution.
// Pontus
On Sun, Jan 13, 2013 at 12:01 PM, Christian Müller
<ch...@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 <ul...@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 <ul...@gmail.com>
>> wrote:
>> > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller
>> > <ch...@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 <alex@frontlinesms.com
>> >wrote:
>> >>
>> >>> On 4 January 2013 17:26, Christian Müller <christian.mueller@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
>> >>>
>> >>
>> >>
>> >>
>> >> --
>>
>
>
>
> --
Re: camel-smpp in trx mode
Posted by Christian Müller <ch...@gmail.com>.
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 <ul...@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 <ul...@gmail.com>
> wrote:
> > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller
> > <ch...@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 <alex@frontlinesms.com
> >wrote:
> >>
> >>> On 4 January 2013 17:26, Christian Müller <christian.mueller@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
> >>>
> >>
> >>
> >>
> >> --
>
--
Re: camel-smpp in trx mode
Posted by Pontus Ullgren <ul...@gmail.com>.
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 <ul...@gmail.com> wrote:
> On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller
> <ch...@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 <al...@frontlinesms.com>wrote:
>>
>>> On 4 January 2013 17:26, Christian Müller <ch...@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
>>>
>>
>>
>>
>> --
Re: camel-smpp in trx mode
Posted by Pontus Ullgren <ul...@gmail.com>.
On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller
<ch...@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 <al...@frontlinesms.com>wrote:
>
>> On 4 January 2013 17:26, Christian Müller <ch...@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
>>
>
>
>
> --
Re: camel-smpp in trx mode
Posted by Christian Müller <ch...@gmail.com>.
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?
Best,
Christian
On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson <al...@frontlinesms.com>wrote:
> On 4 January 2013 17:26, Christian Müller <ch...@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
>
--
Re: camel-smpp in trx mode
Posted by Alex Anderson <al...@frontlinesms.com>.
On 4 January 2013 17:26, Christian Müller <ch...@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
Re: camel-smpp in trx mode
Posted by Christian Müller <ch...@gmail.com>.
That's the problem from my point of view. If you can suggest a good design
how to handle it, I will implement it.
Assume your route to send short messages looks like the following:
from("bean://")
.to("smpp://...");
By using TRX mode your smpp session will also receive:
- sync. response from the SMSC
- async. requests for the delivery notification
- async requests for received short messages
How would you like to model your route to catch all this use cases?
Something like
from("bean://")
.to("smpp://...")
.choice()
.when(header("CamelSmppMessageType").isEqual("DeliveryReceipt"))
.to("bean://....") // async. requests for the delivery notification
.when(header("CamelSmppMessageType").isEqual("DeliverSm"))
.to("bean://....") // async. requests for the delivery notification
.otherwise()
.to("bean://....") // sync. response from the SMSC
.end();
?
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, ...).
Best,
Christian
On Thu, Jan 3, 2013 at 11:41 PM, Johanes Soetanto <ot...@gmail.com>wrote:
> On Friday, 4 January 2013, Christian Müller wrote:
>
> > It doesn't make sense for me to support the TRX mode.
> > Could you provide some pseudo code how your route will looks like?
> >
> > Best,
> > Christian
> >
> > On Mon, Dec 31, 2012 at 5:32 AM, Srinivas <javvadi.sreenu@gmail.com
> <javascript:;>>
> > wrote:
> >
> > > Hi Christian,
> > >
> > > Thank you for replying.
> > >
> > > Operator given only one smpp connectivity that is in trx mode
> > and
> > > operator not allowed two smpp(tx and rx) connections. In my application
> > > receive delivery sm ,delivery recipients and submit sm. Please help me
> > how
> > > to solve my problem using apache camel.
> > >
> > > Regards,
> > >
> > > Srinivas
>
>
> From my experience, some SMSC only allow single connection using TRX.
> I can't remember whether i have established TRX connection during my tests,
> but I remember that sometimes my outbound route also receive incoming sms
> if i add additional "to" destination
>
>
> >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html
> > > Sent from the Camel - Users mailing list archive at Nabble.com.
> > >
> >
> >
> >
> > --
> >
>
>
> --
> Johanes
>
--
Re: camel-smpp in trx mode
Posted by Johanes Soetanto <ot...@gmail.com>.
On Friday, 4 January 2013, Christian Müller wrote:
> It doesn't make sense for me to support the TRX mode.
> Could you provide some pseudo code how your route will looks like?
>
> Best,
> Christian
>
> On Mon, Dec 31, 2012 at 5:32 AM, Srinivas <javvadi.sreenu@gmail.com<javascript:;>>
> wrote:
>
> > Hi Christian,
> >
> > Thank you for replying.
> >
> > Operator given only one smpp connectivity that is in trx mode
> and
> > operator not allowed two smpp(tx and rx) connections. In my application
> > receive delivery sm ,delivery recipients and submit sm. Please help me
> how
> > to solve my problem using apache camel.
> >
> > Regards,
> >
> > Srinivas
>From my experience, some SMSC only allow single connection using TRX.
I can't remember whether i have established TRX connection during my tests,
but I remember that sometimes my outbound route also receive incoming sms
if i add additional "to" destination
>
> >
> >
> > --
> > View this message in context:
> >
> http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
>
>
> --
>
--
Johanes