• Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3
    • Component/s: None
    • Labels:


      Srinath was working on, and we here at the hackathon got involved in a discussion about asynchrony on the server side. To make a long story short, we decided that it's overkill to make the user specify an asynchronous MessageReceiver in order to get the behavior of spawning a worker thread to do the actual business logic.

      We'd like to instead have a property on the MessageContext (which can of course be set on the operation or service) which specified whether or not to prefer separate threads. If this "preferSeparateThread" property is TRUE, then we will spin off a separate thread to do the business logic if we're using another channel for the response - if we're using the backchannel (WSA anonymous or no WSA), there's no real point in spinning off a thread since the current thread is most likely going to have to wait around for the response anyway.

      We propose to put this logic in AbstractMessageReceiver.receive(), and to head towards deleting AbstractAsyncMessageReceiver and all its subclasses (simpler code is better code!) by deprecating them for 1.3. We can actually delete them in a release or two.

      (Interesting code tidbit - the RPCMessageReceiver and the RPCInOutAsyncMessageReceiver are, code-wise, just about IDENTICAL except for their parent class and whitespace!)


          Issue Links



              • Assignee:
                gdaniels Glen Daniels
                gdaniels Glen Daniels
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: