Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (herse.apache.org: domain of nagy@watson.ibm.com designates
 129.34.20.6 as permitted sender)
Subject: Re: [AXIS2] Holding response in HTTPWorker
From: Bill Nagy <nagy@watson.ibm.com>
To: axis-dev@ws.apache.org
In-Reply-To: <b72c94b30702272210o24135ee6pe14ff3adf432a5f7@mail.gmail.com>
References: <b72c94b30702272210o24135ee6pe14ff3adf432a5f7@mail.gmail.com>
Content-Type: text/plain
Date: Wed, 28 Feb 2007 06:05:44 -0800
Message-Id: <1172671544.14412.25.camel@scylla.watson.ibm.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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