axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Nagy <>
Subject Re: [AXIS2] Holding response in HTTPWorker
Date Wed, 28 Feb 2007 14:05:44 GMT
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
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
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
thread should be blocked (by calling RequestResponseTransport.awaitResponse () ) object. Simply
this based on wehater or not the request has been is paused is not enough in some cases.

Please see javadocs for more details.


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
(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


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
> 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message