locked
Issue with concurrent HTTP requests RRS feed

  • Question

  • Hello,

    When I run the following code the first HTTP request is served after 60 seconds, which is what I expect, however subsequent requests emitted during this 60 seconds time frame will block as well and only be served when the first request is completed.

    [ServiceHandler(ServiceHandlerBehavior.Concurrent)]
    public void HttpGetHandler(HttpGet httpGet)
    {
        SpawnIterator<HttpGet>(httpGet, Handler);
    }
    
    bool _wait = true;
    
    IEnumerator<ITask> Handler(HttpGet httpGet)
    {
        if (_wait)
        {
            _wait = false;
    
            yield return Timeout(60000);
        }
    
        httpGet.ResponsePort.Post(new HttpResponseType(HttpStatusCode.OK, _state));
    
        yield break;
    }

    Can you confirm this behavior is intended? If yes:

    - what is the reason?

    - how does it impact other HTTP and DSS handlers in the same service?

    - how does it impact the overall behavior of the DSS node?

    Thanks.

    Saturday, June 15, 2013 5:22 PM

Answers

  • The general answer to your question is that ports are added to the exclusive or concurrent (or teardown) receiver group in the main interleave. You haven't posted that code, so I'm not sure what's happening there. This determines whether multiple concurrent receives can happen. Additionally, handlers may be marked as exclusive or concurrent (as you've done). This determines whether they will run concurrently with other handlers on the same port.

    So, the Concurrent attribute on the individual handler above means that it will run concurrently with other concurrent handlers on the same port. It's still a possibility that the receiver group to which you've added the handler is not the ConcurrentReceiverGroup in your main port interleave. I'm guessing that's the issue.

    Also, by the way, once you do that, you will have a potential race condition around the _wait field. I doubt that's the root of the consistent behavior you're seeing, but this could cause an occasional *extra* wait on startup.

    Hope this helps!

    Monday, June 17, 2013 6:55 PM
    Moderator