is onAcceptSubmitSm multithreaded on the server?

[javadevmtl]

Hi I want to confirm if the client sends 2 submit_sm requests at the same then onAcceptSubmitSm will be fired 2 separate times in it's own thread?

[pmoerenhout]

Yes, each onAcceptSubmitSm will be handled by a seperate thread. If you sent the deliver_sm with failure from that thread, that thread will wait for the async answer. The handling and sending of the deliver_sm should be handled from the called async code. Normally, the onAcceptSubmitSm should return asap, to not block the messaging. If all threads are just waiting for the async response, the no threads are available for handling new requests.

[javadevmtl]

Ok so can you confirm if the processing below make sense?

Blocking easier to handle but less throughput. This will only be as fast as the downstream.

public MessageId onAcceptSubmitSm(SubmitSm submitSm, SMPPServerSession source) throws ProcessRequestException {
    HttpRequest request = new HttpRequest();

    HttpResponse response = request.send(...);

    if(response.success())
        return messageId;
    else
        throw new ProcessRequestException("Failed...", SMPPConstant.STAT_ESME_RSUBMITFAIL); 
}

Async more throughput but a bit more logic to handle failure. submit_sm will always succeed as message id is returned immediately. If we need to indicate further if there was success or failure, use deliver_sm in async task to indicate the status success or fail.

public MessageId onAcceptSubmitSm(SubmitSm submitSm, SMPPServerSession source) throws ProcessRequestException {
    final MessageId messageId = idGenerator.newMessageId();

    HttpRequest request = new HttpRequest();

    request.sendAsync(response -> {
        // This canot be used here as the exception will be caught inside the closure.
        // Instead of returning submit_sm_resp with faillure w
        //if(response.success())
        //    return messageId;
        //else
        //    throw new ProcessRequestException("Failed...", SMPPConstant.STAT_ESME_RSUBMITFAIL);

        // Instead with have to create an async task to send DELIVER_SM with either a success or faillure...

    });

    // This is returned immediately
    return messageId;
}

[pmoerenhout]

Yes, that makes sense. In the blocking example, when your client receives the messageId, it's guaranteed forwarded to the http. In the async, the error is returned indeed later with the deliver_sm. It's more a design decision what your prefer.