Noted Ruwan. Biruntha
Associate Software Engineer WSO2 Email : [email protected] Linkedin : https://lk.linkedin.com/in/biruntha Mobile : +94773718986 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
