You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by keith chapman <ke...@gmail.com> on 2007/02/28 07:10:23 UTC

[AXIS2] Holding response in HTTPWorker

Hi,

I was working on adding HTTP methods PUT and DELETE to HTTPWorker so that we
can get that support. This code appears at the end of handling HTTP POST.

Boolean holdResponse = (Boolean) msgContext.getProperty(
RequestResponseTransport.HOLD_RESPONSE);

            if (pi.equals(InvocationResponse.SUSPEND) || (holdResponse !=
null && Boolean.TRUE.equals(holdResponse))) {
                try {
                ((RequestResponseTransport)msgContext.getProperty(
RequestResponseTransport.TRANSPORT_CONTROL)).awaitResponse();
              }
                catch (InterruptedException e) {
                throw new IOException("We were interrupted, so this may not
function correctly:"+ e.getMessage());
              }
            }

Whats the reason for having this in the POST case? It does not appear in the
GET. Was wondering whether its needed for PUT too.

Does anybody know the reason for this code?

Thanks,
Keith.

-- 
Keith Chapman
WSO2 Inc.
Oxygen for Web Services Developers.
http://wso2.org/

Re: [AXIS2] Holding response in HTTPWorker

Posted by David Illsley <da...@gmail.com>.
I believe it's there to support async processing of one-way messages
and of async 2-way (via ws-addressing).

So... I don't think it's needed for PUT but I'm not entirely sure. The
javadoc for RequestResponseTransport is pretty giid and might help.

David

On 28/02/07, keith chapman <ke...@gmail.com> wrote:
> Hi,
>
> I was working on adding HTTP methods PUT and DELETE to HTTPWorker so that we
> can get that support. This code appears at the end of handling HTTP POST.
>
> Boolean holdResponse = (Boolean) msgContext.getProperty
> (RequestResponseTransport.HOLD_RESPONSE);
>
>             if (pi.equals(InvocationResponse.SUSPEND) || (holdResponse !=
> null && Boolean.TRUE.equals(holdResponse))) {
>                 try {
>
> ((RequestResponseTransport)msgContext.getProperty(
> RequestResponseTransport.TRANSPORT_CONTROL)).awaitResponse();
>               }
>                 catch (InterruptedException e) {
>                 throw new IOException("We were interrupted, so this may not
> function correctly:"+ e.getMessage());
>               }
>             }
>
> Whats the reason for having this in the POST case? It does not appear in the
> GET. Was wondering whether its needed for PUT too.
>
> Does anybody know the reason for this code?
>
> Thanks,
> Keith.
>
> --
> Keith Chapman
> WSO2 Inc.
> Oxygen for Web Services Developers.
> http://wso2.org/


-- 
David Illsley - IBM Web Services Development

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Re: [AXIS2] Holding response in HTTPWorker

Posted by Bill Nagy <na...@watson.ibm.com>.
Hi Keith,

The relevant commits are:

Revision 489259 - (view) (download) (annotate) - [select for diffs] 
Modified Thu Dec 21 03:39:21 2006 UTC (2 months, 1 week ago) by
chamikara 
File length: 13755 byte(s) 
Diff to previous 487227 (colored) 
Added a mechanism to give the current state of the RequestResponseTransport. This could be used by RM 
in resending of messages. Message will be allowed to be resent only if the RequestResponseTranspor object 
is in the correct state.

Added a mechanism to allow somebody to set an custom transport response code. 
For e.g. Sandesha2 has a requirement to return HTTP 408, but there was not way do do this in Axis2.

Added a boolean property which should be used by transports to decide weather or not a certain request 
thread should be blocked (by calling RequestResponseTransport.awaitResponse () ) object. Simply doing 
this based on wehater or not the request has been is paused is not enough in some cases.

Please see javadocs for more details.

and 

Revision 481505 - (view) (download) (annotate) - [select for diffs] 
Modified Sat Dec 2 05:38:19 2006 UTC (2 months, 3 weeks ago) by nagy 
File length: 13301 byte(s) 
Diff to previous 475355 (colored) 
Extended RequestResponseTransport to allow the transport to block after control is returned (e.g. if the
message is paused) and then resume once a response is available.  This will enable RM to be used for
IN-OUT MEPs over a request/response transport.

In short, it's required for RM to support a request/response transport in a request/response fashion
(i.e. not as a one-way connection.)  Since you can't really use RM with those other verbs,
I don't really have another use case right now where it would make sense to replicate that code.

-Bill

On Wed, 2007-02-28 at 11:40 +0530, keith chapman wrote:
> Hi,
> 
> I was working on adding HTTP methods PUT and DELETE to HTTPWorker so
> that we can get that support. This code appears at the end of handling
> HTTP POST.
> 
> Boolean holdResponse = (Boolean) msgContext.getProperty
> (RequestResponseTransport.HOLD_RESPONSE);
>             
>             if (pi.equals(InvocationResponse.SUSPEND) ||
> (holdResponse != null && Boolean.TRUE.equals(holdResponse))) {
>                 try {
> 
> ((RequestResponseTransport)msgContext.getProperty( RequestResponseTransport.TRANSPORT_CONTROL)).awaitResponse();
>               }
>                 catch (InterruptedException e) {
>                 throw new IOException("We were interrupted, so this
> may not function correctly:"+ e.getMessage());
>               }
>             }
> 
> Whats the reason for having this in the POST case? It does not appear
> in the GET. Was wondering whether its needed for PUT too.
> 
> Does anybody know the reason for this code? 
> 
> Thanks,
> Keith.
> 
> -- 
> Keith Chapman
> WSO2 Inc.
> Oxygen for Web Services Developers.
> http://wso2.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org