No response after waiting for 2000 millis when executing submit_sm with sessionId

[Imran Raza Khan]

Hi All,

I am getting following error while sending SMS to SMSc, and starnge is that though i got error, SMS was successfully received on mobile

org.jsmpp.extra.ResponseTimeoutException: No response after waiting for 2000 millis when executing submit_sm with sessionId cd12
5cd2 and sequenceNumber 2
        at org.jsmpp.session.AbstractSession.executeSendCommand(AbstractSession.java:261)
        at org.jsmpp.session.SMPPSession.submitShortMessage(SMPPSession.java:318)
        at com.warid.bulk.StressClient.run(StressClient.java:78)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: org.jsmpp.extra.ResponseTimeoutException: No response after 2000 millis
        at org.jsmpp.extra.PendingResponse.waitDone(PendingResponse.java:117)
        at org.jsmpp.session.AbstractSession.executeSendCommand(AbstractSession.java:257)
        ... 5 more


Imran Raza Khan

[uud ashr]

Hi, you have to set transactionTime more thab 2000 millis.

The case is you've done sent message to SMSC. SMSC send response (submit_sm_resp), but the response is still on the way and the total time is more than 2000 millis, so jsmpp said that is already timeout.

The submit_sm_resp may receive after 2000 millis, and jsmpp not gonna recognize it because jsmpp didn't the sequence number already dropped when response timeout occured.

What is the best transaction time? Tips based on my personal opinion:
1. You have to know the SMSC max process time. What is max process time? Maximum process time is an interval between submit_sm receive by SMSC and SMSC sent the response command (submit_sm_resp).
2. You have to know the latency of your network from your server to SMSC
3. transaction time should be > SMSC max process time + (network latency *  2)

The bigger value is the safer.

[Ahsan]

Hi,
I have a suggestion that in asynchronous mode, for every submit
request the process will wait for transaction timer limit to receive
the resp PDU from SMSC which is not efficient for bulk broadcasts
where we have to through large bulks of data. In logica smpp driver we
use the method transmitter.send() for sending message and then if the
mode is not asynchronous the process waits for pdu response otherwise
it doesn't wait for the pdu response and starts processing the next
request.

regards,

On Apr 13, 12:10 pm, uud ashr <uuda...@gmail.com> wrote:
> Hi, you have to set transactionTime more thab 2000 millis.
>
> The case is you've done sent message to SMSC. SMSC send response
> (submit_sm_resp), but the response is still on the way and the total time is
> more than 2000 millis, so jsmpp said that is already timeout.
>
> The submit_sm_resp may receive after 2000 millis, and jsmpp not gonna
> recognize it because jsmpp didn't the sequence number already dropped when
> response timeout occured.
>
> What is the best transaction time? Tips based on my personal opinion:
> 1. You have to know the SMSC max process time. What is max process time?
> Maximum process time is an interval between submit_sm receive by SMSC and
> SMSC sent the response command (submit_sm_resp).
> 2. You have to know the latency of your network from your server to SMSC
> 3. transaction time should be > SMSC max process time + (network latency *
> 2)
>
> The bigger value is the safer.
>

> On Mon, Apr 13, 2009 at 1:51 PM, Imran Raza Khan <imranrazak...@gmail.com>wrote:
>
>
>
> > Hi All,
>
> > I am getting following error while sending SMS to SMSc, and starnge is that
> > though i got error, SMS was successfully received on mobile
>
> > org.jsmpp.extra.ResponseTimeoutException: No response after waiting for
> > 2000 millis when executing submit_sm with sessionId cd12
> > 5cd2 and sequenceNumber 2
> >         at

> > org.jsmpp.session.AbstractSession.executeSendCommand(AbstractSession.java:2­61)

> >         at
> > org.jsmpp.session.SMPPSession.submitShortMessage(SMPPSession.java:318)
> >         at com.warid.bulk.StressClient.run(StressClient.java:78)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> > Source)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> > Source)
> >         at java.lang.Thread.run(Unknown Source)
> > Caused by: org.jsmpp.extra.ResponseTimeoutException: No response after 2000
> > millis
> >         at
> > org.jsmpp.extra.PendingResponse.waitDone(PendingResponse.java:117)
> >         at

> > org.jsmpp.session.AbstractSession.executeSendCommand(AbstractSession.java:2­57)
> >         ... 5 more
>
> > Imran Raza Khan- Hide quoted text -
>
> - Show quoted text -

[Imran Raza Khan]

Hi UUD,

I resolved my problem by setting setTransactionTimer(3000L), but ahsan raised very valid point that applications will wait for resp until transactiontimer, in case of asynchronous and for sending bulk SMS our application should not check for transaction timer. it should keep sending SMS.

Regards,

--
Imran Raza Khan
Assitsan Manager IT-VAS
Warid Telecom, Lahore.

[Shantanu Kumar]

While I second that concern, I think a truly asynchronous implementation will have to buffer all SUBMIT_SM entries until their response arrives. Now that leads us to thinking how long should we actually buffer the SUBMIT_SM entry? There has to be a timeout at some point to that buffering.

JSMPP simplifies the buffering issue by waiting for a response till a timeout, which works well for many cases. However, this also means the thread has to keep waiting during that period, which in turn (hypothetically) means that if we are sending 500 messages per second and every messages take 3 seconds to submit then we need to have 1500 threads running per second !!

Thanks,

Shantanu

[Ahsan]

Hi,

This is definitely a good suggestion. Let me add my suggestions to it.
If we use one thread for just for sending PDU of SubmitSM and the
other thread for keep on receiving PDU of SubmitSM_resp which will
definitely not only increase the performance but also help in making
seggretion of concerns. In this way, threading will be in control and
will not create problem if we open multiple sessions using
multithreading.

regards,

On Apr 13, 1:41 pm, Shantanu Kumar <kumar.shant...@gmail.com> wrote:
> While I second that concern, I think a truly asynchronous implementation
> will have to buffer all SUBMIT_SM entries until their response arrives. Now
> that leads us to thinking how long should we actually buffer the SUBMIT_SM
> entry? There has to be a timeout at some point to that buffering.
> JSMPP simplifies the buffering issue by waiting for a response till a
> timeout, which works well for many cases. However, this also means the
> thread has to keep waiting during that period, which in turn
> (hypothetically) means that if we are sending 500 messages per second and
> every messages take 3 seconds to submit then we need to have 1500 threads
> running per second !!
>
> Thanks,
> Shantanu
>

> On Mon, Apr 13, 2009 at 1:14 PM, Imran Raza Khan <imranrazak...@gmail.com>wrote:
>
>
>
> > Hi UUD,
>
> > I resolved my problem by setting setTransactionTimer(3000L), but ahsan
> > raised very valid point that applications will wait for resp until
> > transactiontimer, in case of asynchronous and for sending bulk SMS our
> > application should not check for transaction timer. it should keep sending
> > SMS.
>
> > Regards,
>

> > Warid Telecom, Lahore.- Hide quoted text -

[chatura sandaruwan]

Hi All,
 
     Flow control (throttling) also taken in to account when bulk dispatching. Personally i experienced throttling error  incidence in bulk dispatching.  Throttle monitor must introduce in case for any mode of transmission.
Open your comments.

Thanks,
Chatura.

[uud ashr]

JSMPP engine already do that for you.

It has single thread that read the response and several threads that process the response (such as raise event onSubmitShortMessage).
The sending thread is the thread where session.submitShortMessage(...) invoked.

[uud ashr]

If the application not clustered it's pretty simple.

Just create Throttle class

long period = TimeConstant.ONE_SECOND;
Throttle throttle = new Throttle(100, period);

if (throttle.acquire()) {
    sendMessage(message);
} else {
    reschedule(message);
}

Share the Throttle instance to each session using the same account.

[Imran Raza Khan]

Hi UUD,

How i can implement throttling in following multiple session code, i will oblige if you update it.

public class StressTestRunner
{
   
    public static void main(String args[])
    {
        Logger logger = Logger.getLogger(

StressTestRunner.class);
        PropertyConfigurator.configure( "log4j.properties" );
        logger.info("Logging Setup Done...");
       
        StressClient sc1 = new StressClient(0, "test msg");
        StressClient sc2 = new StressClient(1, "test msg");
        StressClient sc3 = new StressClient(2, "test msg");
       
        long lTimeAtStart = System.currentTimeMillis();
       
        ExecutorService pool = Executors.newFixedThreadPool( 3 );
        pool.execute( sc1 ); // start task1
        pool.execute( sc2 ); // start task2
        pool.execute( sc3 ); // start task3
       
        pool.shutdown(); // shutdown worker threads
       
       long lTimeAtEnd = System.currentTimeMillis();
        
       long timetakeninsec = (lTimeAtEnd - lTimeAtStart) / 1000;

       long throughput =  (3 * 100)/timetakeninsec;
      
       System.out.println("Time at start = " + lTimeAtStart );
       System.out.println("Time at end = " + lTimeAtEnd);
       System.out.println("Throughput = " + throughput);   
       System.out.println("Quitting ");
       
    }//EO Main

/*********************************************************************************************/

public class StressClient implements Runnable
{
        private static final String DEFAULT_PASSWORD = "test";
        private static final String DEFAULT_SYSID = "test";
        private static final String DEFAULT_SOURCEADDR = "111";
        private static final String DEFAULT_HOST = "xx.xx.xx.xx";
        private static final Integer DEFAULT_PORT = 2775;

        private static final Long DEFAULT_TRANSACTIONTIMER = 2000L;
       

        private static final Integer DEFAULT_PROCESSOR_DEGREE = 3;

       
       
        private SMPPSession smppSession = new SMPPSession();

        private int id;
        private String message;
        private Logger logger = Logger.getLogger(StressClient.class);
       
        public StressClient(int id,String msg)
        {
            this.id = id;
            smppSession.setPduProcessorDegree(DEFAULT_PROCESSOR_DEGREE);
            smppSession.setTransactionTimer(DEFAULT_TRANSACTIONTIMER);
           
            message=msg;
        }
       
        public void run()
        {
            try
            {
               
                smppSession.connectAndBind("xx.xx.xx.xx", 2775,        BindType.BIND_TX, "ITDEV", "ITDEV",               "ITV", TypeOfNumber.UNKNOWN, NumberingPlanIndicator.UNKNOWN, null);

               
                logger.info("Bound to " + DEFAULT_HOST + ":" + DEFAULT_PORT);
                System.out.println("Bound to " + DEFAULT_HOST + ":" + DEFAULT_PORT);
               
                FileInputStream fstream = new FileInputStream("test"+id+".txt");
                DataInputStream in      = new DataInputStream(fstream);

                int counter = 0;
               
                while (in.available() !=0)
                {
                    //System.out.println("In thread "+index+"=="+in.readLine().trim()  );
                    counter ++;
                    smppSession.submitShortMessage("CMT", TypeOfNumber.ALPHANUMERIC, NumberingPlanIndicator.UNKNOWN,           DEFAULT_SOURCEADDR, TypeOfNumber.INTERNATIONAL, NumberingPlanIndicator.ISDN,             "92"+in.readLine().trim(), new ESMClass(),        (byte)0, (byte)1, null, null, new RegisteredDelivery(0),       (byte)0, DataCoding.newInstance((byte)0),(byte)0, message.getBytes());  
                  
                   
                    System.out.println("Message sent");
                   
                    if( counter%500 == 0)
                    {       
                        System.out.println("Thread " + id + " sent " + counter + " messages");
                    }
                   
                }
  
       
            } catch (Exception e) {

               logger.error("Failed submit short message '" + message + "'", e);

               e.printStackTrace(); 

            }
               
          
            logger.info("Done");
            smppSession.unbindAndClose();

        }//EO run

Regards,
imran

[uud ashr]

I've attach simple API for throttle. Feel free to modify.

[uud ashr]

Hmm, for now I'm not gonna give you the code. I'll give you a hints.

You should use some kind of Queue System. JMS would be fine or just create you own simple queue implementation, or use LinkedList or Queue on java 5 or 6.

So the reschedule logic is simply re-putting message to the queue.

Or you can use simple throttle API attached on this thread (throttle-sample.zip). This API will block until thread flow it has turn.

Throttle throttle = new SimpleThrottle(100, TimeConstant.ONE_SECOND); // 100 message / second
...
while (in.available()) {
    throttle.obtainTurn(); // it will block here
    session.submitShortMessage(..., message.getBytes());

[Shantanu Kumar]

I do not agree.

There are N number of ways to throttle / manage / manipulate submissions, which also depends on the SMSC behaviour. One generic throttler cannot be sufficient for all throttling needs. I would suggest that you do throttling in application logic, rather than expecting this from JSMPP.

JSMPP implements SMPP 3.4 protocol (as of now), and that is what it does best. Is throttling a part of SMPP 3.4 protocol specification? In my opinion, seeking solutions to your application-related problems in JSMPP may only lead to very little in the end.

Thanks,

Shantanu

[chatura sandaruwan]

 Hi All,
    Flow control and congestion avoidance are topics in SMPP_v5, but also throttling error behavior in SMSC is familiar to v3.4. That's why i raised the opinion regarding that and as Shantanu suggest its may be not part of protocal handler in this version.

Thanks
Chatura.

[Ashwin Moily]

The basic thing over here is when throttle takes place .Ur sms is not submitted to the smsc just sleep for 10ms and again send it .U actually dont have to put in the queue u just have to wait for a while .Thats how I have implemented and I am able to get maximum throughput here.

jsmpp is the interface it shldnt be changed unless and until the specification chnages .
I guess it should be the app logic where u control throttle error smsc full queue error .
When u shld retry depends upon the error .

No response after waiting for 2000 millis when executing submit_sm with sessionId

During this u shldnt retry the message .There is no error taking place the only thing happened over here is that u didnt get the response but the message may have gone out .I did a test with some smsc where the response was slow and i ended up sending muliple sms.

On Tue, Apr 14, 2009 at 2:21 PM, Shantanu Kumar <kumar.s...@gmail.com> wrote:

--
Thanks & Regards
Ashwin Moily
Tel: +91 (22) 25639261
Mob: +91 9619181096

[uud ashr]

Maybe throttle API comes on JSMPP next version.

[Imran Raza Khan]

Hi UUD,

Following declaration is wrong

Throttle throttle = new SimpleThrottle(100, TimeConstant.ONE_SECOND); //100msg/sec

it should be like following

Throttle throttle = new SimpleThrottle(TimeConstant.ONE_SECOND,100); //100msg/sec

I am considering the value of TimeConstant.ONE_SECOND as 1

Regards,

[Shantanu Kumar]

What is noteworthy here is SimpleThrottle "blocks" for a certain period if the maxCount has reached. That accidentally means you need one thread per session (to deal with multiple sessions concurrently), which may not be desirable if you have many sessions across many accounts. If you are planning to multiplex the submissions across multiple sessions, then you cannot afford to block on a session!

I would suggest to throw NotReadyException whenever the session is out of throttle limit. Or perhaps, obtainTurn(...) can be re-factored to return the number of milliseconds to wait until it will be ready -- public long millisUntilReady().

Thanks,

Shantanu

[Prasad Khatavkar]

Hello,

Do you have a sample code to set the transaction timer.

[Gaurav Singh]

Hello,

You can do like

smppSession.setTransactionTimeer(long).

--
You received this message because you are subscribed to the Google Groups "jsmpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsmpp+un...@googlegroups.com.
To post to this group, send email to js...@googlegroups.com.
Visit this group at http://groups.google.com/group/jsmpp.
For more options, visit https://groups.google.com/groups/opt_out.

[Iman Ebrahimzadeh]

hello there,

im having one small problem could you please kindly guid me how to solve it?

im having a problem with smpp connection and the problem is i connect normaly to smpp i do send keepalive every 30sec and keep the connection live..

sometimes when i send sms at the begining or middle of sending i keep getting an error :

Erorr Message: No response after waiting for 45000 millis when executing submit_sm with sessionId 540259b5 and sequenceNumber 26986 -- at org.jsmpp.session.Abstra 

I keep get this error even if i send one sms, the only way to fix this error is to disconnect and reconnect the smpp connection.

could you please guid me how to solve this issue?

ps. while im getting this error i do can sms to smsc and they do deliver the sms but i dont get the msgid. 

 

regards

[Sateesh Pandey]

sir how i setTransectiontime(3000L) as you done in your project.?

[Praveen Chaudhary]

Hi Imran, 

Are you able to resolve this timeout issue. I am still getting it. Any suggestions or solutions you have.