Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
From: Sanjiva Weerawarana <sanjiva@opensource.lk>
To: dims@apache.org
Cc: axis-dev@ws.apache.org
In-Reply-To: <19e0530f0605230619q582e1106t4929743abb166854@mail.gmail.com>
References: <1148236547.24844.36.camel@localhost.localdomain>
	 <OF5F8C8656.41E9AC26-ON86257176.0071A5D1-86257177.004883D7@us.ibm.com>
	 <19e0530f0605230619q582e1106t4929743abb166854@mail.gmail.com>
Content-Type: text/plain
Organization: Lanka Software Foundation
Date: Tue, 23 May 2006 19:59:35 +0530
Message-Id: <1148394575.10294.16.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Plus .. we didn't have any other choice on the client side in the J2SE
case. If the listener manager stuff is configured correctly then when
the client is running in a server environment it should pick up the
server's listener.

Anyway, now we appear to have a client side solution that we can be
proud of :) and one that can indeed scale to a standalone-server level.
Excellent!

Sanjiva.

On Tue, 2006-05-23 at 09:19 -0400, Davanum Srinivas wrote:
> Jeff,
> 
> This warning is for use ON the server-side :) Definitely not for high
> volume stuff that a server needs to handle. Client-side is ok.
> 
> thanks,
> dims
> 
> On 5/23/06, Jeff Barrett <barrettj@us.ibm.com> wrote:
> >
> >
> > Hi Sanjiva,
> >
> > I'm a bit confused by the statement "the current SimpleHTTPServer was of course never meant for production use".  I see the following tag specified in shipped version of axis2.xml:
> >     <transportReceiver name="http" class="org.apache.axis2.transport.http.SimpleHTTPServer">
> >
> > I understand the "non-production" statement from a server-side perspective due to integration with the server.  However, on a J2SE client, the SimpleHTTPServer is what is used to receive async responses.  Are you saying that client-side async responses aren't expected or supported in a "production environment"?  What are the expectations regarding Axis2 support for async responses in a production environment?
> >
> >  Thanks,
> >  Jeff
> >
> >  IBM Software Group - WebSphere Web Services Development
> >  Phone: 512-838-4587 or Tie Line 678-4587
> >  Internet e-mail and Sametime ID: barrettj@us.ibm.com
> >
> >
> >
> >  Sanjiva Weerawarana <sanjiva@opensource.lk>
> >
> > 05/21/2006 01:35 PM
> >
> > Please respond to
> >  axis-dev@ws.apache.org
> >
> >
> > To axis-dev@ws.apache.org
> >
> > cc
> >
> >
> > Subject Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, 2006-05-21 at 20:17 +0200, Oleg Kalnichevski wrote:
> >  > On Sun, 2006-05-21 at 07:57 -1000, Chuck Williams wrote:
> >  > > Oleg,
> >  > >
> >  > > Thanks for doing this!  Is your code committed or posted somewhere?
> >  > > Please let me know when and where I can obtain it for testing, and to
> >  > > create a resource-manageable http server based on it.
> >  >
> >  > I plat to create a Jira ticket and attach a patch to it. I just would
> >  > like to run a few more performance benchmarks. The current version of
> >  > SimpleHttpServer keeps on falling flat every time I am trying to put
> >  > some load on it with the HTTP benchmarking tool. At some point I'll just
> >  > give up.
> >
> >  :) .. the current SimpleHTTPServer was of course never meant for
> >  production use.
> >
> >  If you want to compare perf with Tomcat etc. you could use the perf
> >  benchmark that Dims recently posted; see:
> >                   http://www.wso2.net/2006/05/axis2_performance_testing_round_1
> >
> >  > > Re. the 202 issue, if only used for in-only messages, then the
> >  > > responses are always empty.  Could you use this to provide streaming
> >  > > for non-empty responses?
> >  >
> >  > I do not see a way to tell those messages apart at the HTTP transport
> >  > level. That's the trouble.
> >
> >  That's only visible by looking at the WS-Addressing headers. We know
> >  this info fairly early but because we're executing the message thru
> >  using the transport thread we couldn't shut down the stuff earlier when
> >  using a servlet transport. With a native HTTP processor however I see no
> >  reason why we can't early close the incoming channel when there's a
> >  wsa:ReplyTo which will cause the 202 to be sent.
> >
> >  We of course need to do that w/o making the WS-Addr stuff specific to
> >  this type of transport. One option would be to introduce a special
> >  handler only in that case which will execute this logic.
> >
> >  (Do you need more detailed hints? Seems like you've broken in quite well
> >  already :) .. thanks!)
> >
> >  Sanjiva.
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >  For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
> 
> 
> 


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