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/ dffb4c578b2841ff6b4868feecdbf3cf9ec465fa/jsmpp/src/main/ java/org/jsmpp/session/AbstractSession.java#L449-#L489 [2] - https://github.com/opentelecoms-org/jsmpp/blob/ dffb4c578b2841ff6b4868feecdbf3cf9ec465fa/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 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.* >> >> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
