Hi Biruntha, Very good finding. So we do not need to handle sending enquire link. But we need to allow the "enquireLinkTimer" value to be configurable. One problem though, the thread count increases per each session in the pool. I guess it would be ok in this case.
The other part of the problem is we need to send response to enqure_link, when SMSC sends it to our side, in timely manner. Cheers, Ruwan On Wed, Nov 30, 2016 at 2:47 PM, Biruntha Gnaneswaran <[email protected]> wrote: > Hi Ruwan, > > To check "enqure_link" at regular intervals, the smpp library [1] itself > has the facility to check that while connecting and binding [2] with > SMSC. I think we don’t need to re implement that. > > Please give your suggestion on this. > > > [1] - https://github.com/opentelecoms-org/jsmpp/blob/dffb4c578b284 > 1ff6b4868feecdbf3cf9ec465fa/jsmpp/src/main/java/org/jsmpp/ > session/AbstractSession.java#L449-#L489 > > [2] - https://github.com/opentelecoms-org/jsmpp/blob/dffb4c578b284 > 1ff6b4868feecdbf3cf9ec465fa/jsmpp/src/main/java/org/jsmpp/ > session/SMPPSession.java#L238 > > > Thanks, > > Biruntha > > Associate Software Engineer > WSO2 > Email : [email protected] > Linkedin : https://lk.linkedin.com/in/biruntha > Mobile : +94773718986 <+94%2077%20371%208986> > > On Fri, Nov 25, 2016 at 2:45 PM, Biruntha Gnaneswaran <[email protected]> > wrote: > >> Noted Ruwan. >> >> Biruntha >> >> Associate Software Engineer >> WSO2 >> Email : [email protected] >> Linkedin : https://lk.linkedin.com/in/biruntha >> Mobile : +94773718986 <+94%2077%20371%208986> >> >> On Fri, Nov 25, 2016 at 2:25 PM, Ruwan Abeykoon <[email protected]> wrote: >> >>> Hi Biruntha, >>> Few improvements, >>> 1. Connection pool should be per "System_ID+SMSC", not per SMSC. >>> 2. Need to have MaxSessions per each "SystemID". max sessions >>> (used+idle) can not exceed the defined value. >>> >>> >>> Cheers, >>> Ruwan >>> >>> On Fri, Nov 25, 2016 at 2:03 PM, Biruntha Gnaneswaran <[email protected] >>> > wrote: >>> >>>> Hi Ruwan, >>>> Thankyou. I will consider your suggestions to manage the idle sessions. >>>> >>>> Diagram for maintain the Session: >>>> >>>> >>>> >>>> >>>> Steps : >>>> >>>> 1. >>>> >>>> Create the cache which contains all the SMPP sessions. >>>> 2. >>>> >>>> Create the connection pool object. It manages multiple SMPP >>>> sessions (with EnquireLinkTimer value) for a single SMSC to support >>>> parallel connections. While receive the request to create the session, >>>> first it will check the connection pool whether session is available. If >>>> there is available session then that session will be used. Otherwise, it >>>> will create the new session. >>>> 3. Send the message using that session. >>>> >>>> Thanks, >>>> >>>> Biruntha >>>> >>>> Associate Software Engineer >>>> WSO2 >>>> Email : [email protected] >>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>> Mobile : +94773718986 >>>> >>>> On Fri, Nov 25, 2016 at 11:48 AM, Ruwan Abeykoon <[email protected]> >>>> wrote: >>>> >>>>> Hi Biruntha, >>>>> I think you need to implement a custom pool implementation by simply >>>>> using Java Collections; due to, >>>>> 1. Telco provider does not allow more than few "Sessions" having same >>>>> "System ID" at a time. So we need to keep a maximum. >>>>> 2. Some telco providers insist the client to send traffic at regular >>>>> interval. They drop the session when it is idle. To prevent this the >>>>> client >>>>> has to send "enqure_link" at regular intervals. >>>>> 3. The SMSC can at any time send "enqure_link", and client has to >>>>> respond fast enough. Otherwise server can "unbind" the session. >>>>> 4. I do not think any existing pool implementation provides the >>>>> support for above(1,2,3) >>>>> >>>>> So I guess, there has to be a "supervisor thread(s)" to manage the >>>>> idle sessions. The "supervisor" will listen to any "enquire" message and >>>>> schedule a response. Also supervisor will schedule "enquire" at regular >>>>> interval, based on some configuration in system or in URL. There needs to >>>>> be few worker threads to perform the real sending of those messages. >>>>> >>>>> Cheers, >>>>> Ruwan >>>>> >>>>> On Wed, Nov 23, 2016 at 12:24 PM, Biruntha Gnaneswaran < >>>>> [email protected]> wrote: >>>>> >>>>>> Thankyou Ruwan, I will check on this. >>>>>> >>>>>> Biruntha >>>>>> >>>>>> Associate Software Engineer >>>>>> WSO2 >>>>>> Email : [email protected] >>>>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>>>> Mobile : +94773718986 >>>>>> >>>>>> On Wed, Nov 23, 2016 at 12:16 PM, Ruwan Abeykoon <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Biruntha, >>>>>>> If I remember correctly, you ned to read the SMS from a client bound >>>>>>> to delivery address. Please see [1][2] for a sample client code. >>>>>>> >>>>>>> The status change only when the client read the message from the >>>>>>> queue. >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/twitter/cloudhopper-smpp/blob/master/ >>>>>>> src/test/java/com/cloudhopper/smpp/demo/ClientMain.java >>>>>>> [2] https://github.com/opentelecoms-org/jsmpp/tree/master/js >>>>>>> mpp-examples/src/main/java/org/jsmpp/examples >>>>>>> >>>>>>> Cheers, >>>>>>> Ruwan >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 23, 2016 at 12:05 PM, Biruntha Gnaneswaran < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi Ruwan, >>>>>>>> >>>>>>>> >>>>>>>> I tested the “query_sm” PDU to query delivery report with logica >>>>>>>> smpp simulator, smpp jar [1]. It gives delivery as “SCHEDULED”. >>>>>>>> Because of >>>>>>>> the Message State as 0 in the response. >>>>>>>> >>>>>>>> What would be the case in real scenario? How to proceed this >>>>>>>> further? >>>>>>>> >>>>>>>> Simulator Output: >>>>>>>> >>>>>>>> 10:27:03 [esb1] server response: (bindresp: (pdu: 0 80000002 0 1) >>>>>>>> Smsc Simulator) >>>>>>>> >>>>>>>> 10:27:03 [esb1] client request: (submit: (pdu: 87 4 0 2) (addr: 0 0 >>>>>>>> 1616) (addr: 0 0 628176504657) (sm: msg: This is message) (opt: ) ) >>>>>>>> >>>>>>>> 10:27:03 [esb1] putting message into message store >>>>>>>> >>>>>>>> 10:27:03 [esb1] server response: (submit_resp: (pdu: 0 80000004 0 >>>>>>>> 2) Smsc2002 ) >>>>>>>> >>>>>>>> 10:27:03 [esb1] client request: (query: (pdu: 32 3 0 3) Smsc2002 >>>>>>>> (addr: 0 0 1616) ) >>>>>>>> >>>>>>>> 10:27:03 [esb1] querying message in message store >>>>>>>> >>>>>>>> 10:27:03 [esb1] server response: (query_resp: (pdu: 0 80000003 0 3) >>>>>>>> Smsc2002 0 0 ) >>>>>>>> >>>>>>>> [1] http://mvnrepository.com/artifact/org.jsmpp/jsmpp/2.3.0 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Biruntha >>>>>>>> >>>>>>>> Associate Software Engineer >>>>>>>> WSO2 >>>>>>>> Email : [email protected] >>>>>>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>>>>>> Mobile : +94773718986 >>>>>>>> >>>>>>>> On Tue, Nov 22, 2016 at 3:48 PM, Ruwan Abeykoon <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Biruntha, >>>>>>>>> >>>>>>>>> 1. What is the reason us to provide the support for "query_sm", >>>>>>>>> most of the SMSC does not provide the support for this. I wonder we >>>>>>>>> ever >>>>>>>>> need to support it. >>>>>>>>> >>>>>>>>> 2. When we maintain the SMPP session in the pool, we have to >>>>>>>>> manage the idle sessions. We need to send "enquire_link" periodically, >>>>>>>>> otherwise the SMSC will terminate the session, after few minutes of >>>>>>>>> idle >>>>>>>>> time. So you may need to implement a custom pool implementation. >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Ruwan >>>>>>>>> >>>>>>>>> On Tue, Nov 22, 2016 at 3:04 PM, Biruntha Gnaneswaran < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> yes Malaka, i'm considering that also. >>>>>>>>>> >>>>>>>>>> Biruntha >>>>>>>>>> >>>>>>>>>> Associate Software Engineer >>>>>>>>>> WSO2 >>>>>>>>>> Email : [email protected] >>>>>>>>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>>>>>>>> Mobile : +94773718986 >>>>>>>>>> >>>>>>>>>> On Tue, Nov 22, 2016 at 2:39 PM, Malaka Silva <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Biruntha, >>>>>>>>>>> >>>>>>>>>>> There can be multiple gateways based on client configuration and >>>>>>>>>>> for multiple tenants. >>>>>>>>>>> We need to reuse only the sessions for the given service >>>>>>>>>>> provider and tenant. >>>>>>>>>>> I guess you are considering those as well? >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 22, 2016 at 12:14 PM, Biruntha Gnaneswaran < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Currently i’m working on the SMPP connector improvement as >>>>>>>>>>>> described below: >>>>>>>>>>>> >>>>>>>>>>>> 1. >>>>>>>>>>>> >>>>>>>>>>>> Query the status of the submitted message :- When message >>>>>>>>>>>> is send using the SMPP protocol, SMSC returns a message >>>>>>>>>>>> reference >>>>>>>>>>>> (messageId). Then we are able to query the SMSC for the >>>>>>>>>>>> delivery status of >>>>>>>>>>>> this message. >>>>>>>>>>>> 2. >>>>>>>>>>>> >>>>>>>>>>>> Maintain the SMPP session between multiple calls of send >>>>>>>>>>>> SMS operation :- Current version of the connector creates new >>>>>>>>>>>> session for >>>>>>>>>>>> each sms. To solve this problem, i create own connection pool >>>>>>>>>>>> to use it in >>>>>>>>>>>> the multithreading environment by creating a >>>>>>>>>>>> ConcurrentLinkedQueue and push >>>>>>>>>>>> the connections to that queue. Each time a thread requests a >>>>>>>>>>>> connection, >>>>>>>>>>>> connection is popped out from queue. Once job is done, threads >>>>>>>>>>>> push >>>>>>>>>>>> connection back to queue. If there are no connection in the >>>>>>>>>>>> queue, it will >>>>>>>>>>>> create a new connection. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This improvement is regarding the jira [1] and [2]. >>>>>>>>>>>> >>>>>>>>>>>> [1] https://wso2.org/jira/browse/ESBCONNECT-120 >>>>>>>>>>>> >>>>>>>>>>>> [2] https://wso2.org/jira/browse/ESBCONNECT-121 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Biruntha >>>>>>>>>>>> >>>>>>>>>>>> Associate Software Engineer >>>>>>>>>>>> WSO2 >>>>>>>>>>>> Email : [email protected] >>>>>>>>>>>> Linkedin : https://lk.linkedin.com/in/biruntha >>>>>>>>>>>> Mobile : +94773718986 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> Malaka Silva >>>>>>>>>>> Senior Technical Lead >>>>>>>>>>> M: +94 777 219 791 >>>>>>>>>>> Tel : 94 11 214 5345 >>>>>>>>>>> Fax :94 11 2145300 >>>>>>>>>>> Skype : malaka.sampath.silva >>>>>>>>>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>>>>>>>>> Blog : http://mrmalakasilva.blogspot.com/ >>>>>>>>>>> >>>>>>>>>>> WSO2, Inc. >>>>>>>>>>> lean . enterprise . middleware >>>>>>>>>>> https://wso2.com/signature >>>>>>>>>>> http://www.wso2.com/about/team/malaka-silva/ >>>>>>>>>>> <http://wso2.com/about/team/malaka-silva/> >>>>>>>>>>> https://store.wso2.com/store/ >>>>>>>>>>> >>>>>>>>>>> Don't make Trees rare, we should keep them with care >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Ruwan Abeykoon* >>>>>>>>> *Associate Director/Architect**,* >>>>>>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>>>>>>>> *lean.enterprise.middleware.* >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> *Ruwan Abeykoon* >>> *Associate Director/Architect**,* >>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>> *lean.enterprise.middleware.* >>> >>> >> > -- *Ruwan Abeykoon* *Associate Director/Architect**,* *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * *lean.enterprise.middleware.*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
