Axis2
  1. Axis2
  2. AXIS2-1134

Want to Store the MessageContext together with the OutputStream for later use

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: kernel
    • Labels:
      None

      Description

      Use Case is to be able to send a delayed reply to an InOut invocation. One example is BPEL receive and reply activities. In this example we need to send a reply after some time to the received invocation. Holding of the invoking thread till we can write the response is unacceptable.

      In a scenario like above, we can store the incoming messagecontext to send the response later. But this causes the invoking thread to be returned. Returning of that thread causes the writing of an HTTP 200 OK to the outstream.

      We can introduce a new switch, which can be set when we want to do the above scenario. Axsi2 transport module can send an HTTP 100 Continue to the client in the presence of that switch to let him know that we'll be sending the response later.

        Issue Links

          Activity

          Hide
          Thilina Gunarathne added a comment -

          This problem arises in the case of AsyncMessageReceiver too...

          Without the above mentioned switch to send http 100 continue upon returning of the calling thread, Axis2 will not be able to send a response in the same channel in the case of AsyncMessageReceiver....

          Show
          Thilina Gunarathne added a comment - This problem arises in the case of AsyncMessageReceiver too... Without the above mentioned switch to send http 100 continue upon returning of the calling thread, Axis2 will not be able to send a response in the same channel in the case of AsyncMessageReceiver....
          Hide
          Thilina Gunarathne added a comment -

          Since this effects the behaviour of AsyncMessageReceiver

          Show
          Thilina Gunarathne added a comment - Since this effects the behaviour of AsyncMessageReceiver
          Hide
          Davanum Srinivas added a comment -

          DO we need to fix this for 1.3?

          Show
          Davanum Srinivas added a comment - DO we need to fix this for 1.3?
          Hide
          Eran Chinthaka added a comment -

          Thilina,

          I have little doubt whether on doing this. The problem is there can be timeouts of the transports and some one needs to keep sending keep-alive messages. Also I am not sure about how long you can keep a socket open. So don't we need to limit this scenario only when WS-Addressing is available?

          Show
          Eran Chinthaka added a comment - Thilina, I have little doubt whether on doing this. The problem is there can be timeouts of the transports and some one needs to keep sending keep-alive messages. Also I am not sure about how long you can keep a socket open. So don't we need to limit this scenario only when WS-Addressing is available?
          Hide
          Thilina Gunarathne added a comment -

          Yes.. TimeOut's can be an issue in this case. To be honest I cannot remember the actual use case we had..
          I'm fine with restricting this scenario to only when WS-Addressing is present... But it'll be better if we can support this at least for a limited amount of time..

          This issue has close ties to the AsyncReciever behaviour too... Where a client side sync request fails due to Axis2 sending back http-200-OK when the thread is returned...

          Show
          Thilina Gunarathne added a comment - Yes.. TimeOut's can be an issue in this case. To be honest I cannot remember the actual use case we had.. I'm fine with restricting this scenario to only when WS-Addressing is present... But it'll be better if we can support this at least for a limited amount of time.. This issue has close ties to the AsyncReciever behaviour too... Where a client side sync request fails due to Axis2 sending back http-200-OK when the thread is returned...
          Hide
          Srinath Perera added a comment -

          I purposed not to support this. It is not clear how Output stream is to be stored (serialized), and even we though able to do it, OS resources will not be avalible for ever. Supporting this will be big hassle and it will lead to many future problems.

          Show
          Srinath Perera added a comment - I purposed not to support this. It is not clear how Output stream is to be stored (serialized), and even we though able to do it, OS resources will not be avalible for ever. Supporting this will be big hassle and it will lead to many future problems.
          Hide
          Eran Chinthaka added a comment -

          Bringing down the priority. Thilina what do u wanna do with this? I prefer marking this as won't fix. It is your call.

          Show
          Eran Chinthaka added a comment - Bringing down the priority. Thilina what do u wanna do with this? I prefer marking this as won't fix. It is your call.
          Hide
          Davanum Srinivas added a comment -

          I agree with Eran. this is a "won't fix"

          thanks,
          dims

          Show
          Davanum Srinivas added a comment - I agree with Eran. this is a "won't fix" thanks, dims

            People

            • Assignee:
              Deepal Jayasinghe
              Reporter:
              Thilina Gunarathne
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development