axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Date Sat, 20 May 2006 22:40:18 GMT
On Sat, 2006-05-20 at 18:30 -0400, Davanum Srinivas wrote:
> Oleg,
> 
> We use it for one-way/async scenarios. Example see here:
> http://www.w3.org/2002/ws/addr/testsuite/exchanges/#SOAP11-HTTP-In-Only
> 
> there are more patters on that page...
> 

I see. Is there a change to find out whether a message falls into the
one-way/async category before it gets fed into
HTTPTransportUtils#processHTTPPostRequest() method? I am just trying to
see if there is a way to avoid response content buffering for
synchronous scenarios.

Cheers,

Oleg

> thanks,
> dims
> 
> On 5/20/06, Oleg Kalnichevski <olegk@apache.org> wrote:
> > Davanum, et al (sorry about my previous message),
> >
> > I took at the first stub at the rewrite of the SimpleHTTPServer based on
> > HttpComponents HttpCore and got it (more or less) functional. In fact I
> > appears to be holding up quite well.
> >
> > Judging by some _very_ _preliminary_ results SimpleHTTPServer got quite
> > a bit faster when streaming out schema definitions and similar stuff [1].
> >
> > One thing bothers me, though. From what I read in the code (I may well
> > be wrong) it appears Axis2 must always buffer the response content in
> > order to be able to determine what status code needs to be sent back to
> > the user 200 (OK) or 202 (Accepted)
> >
> > ======================
> > Object contextWritten = null;
> > if (operationContext != null) {
> >   contextWritten =
> >    operationContext.getProperty(Constants.RESPONSE_WRITTEN);
> > }
> > if ((contextWritten != null) &&
> >   Constants.VALUE_TRUE.equals(contextWritten)) {
> >     response.setStatusLine(new StatusLine(ver, 200, "OK"));
> > } else {
> >     response.setStatusLine(new StatusLine(ver, 202, "OK"));
> > }
> > ======================
> >
> > What's the reason for that? What's the purpose of sending 202 back to
> > the user? This effectively prevents me from being able to stream out
> > response content, which has a negative impact on performance of the HTTP
> > transport.
> >
> > Cheers,
> >
> > Oleg
> >
> > [1]
> > SimpleHttpServer in Axis2 1.0
> > =============================
> > oleg@dld810:~/src/apache.org/jakarta/httpcomponents/httpcore$ java
> > -cp /opt/libjava/commons-cli.jar:bin
> > org.apache.http.contrib.benchmark.HttpBenchmark -k -n 3000
> > http://localhost:8080/axis2/services/MyService?xsd
> > Server Software:        null
> > Server Hostname:        localhost
> > Server Port:            8080
> >
> > Document Path:          /axis2/services/MyService
> > Document Length:        314 bytes
> >
> > Time taken for tests:   152.884 seconds
> > Complete requests:      1500
> > Failed requests:        1500
> > Content transferred:    471000 bytes
> > Requests per second:    9.81136 [#/sec] (mean)
> > Time per request:       101.92267 [ms] (mean)
> >
> > SimpleHttpServer based on HttpCore and Axis SVN trunk
> > =====================================================
> > oleg@dld810:~/src/apache.org/jakarta/httpcomponents/httpcore$ java
> > -cp /opt/libjava/commons-cli.jar:bin
> > org.apache.http.contrib.benchmark.HttpBenchmark -k -n 3000
> > http://localhost:8080/axis2/services/MyService?xsd
> > Server Software:        Simple-Server/1.1
> > Server Hostname:        localhost
> > Server Port:            8080
> >
> > Document Path:          /axis2/services/MyService
> > Document Length:        314 bytes
> >
> > Time taken for tests:   1.752 seconds
> > Complete requests:      3000
> > Failed requests:        0
> > Content transferred:    942000 bytes
> > Requests per second:    1712.3287 [#/sec] (mean)
> > Time per request:       0.584 [ms] (mean)
> >
> >
> >
> > On Sat, 2006-05-20 at 22:17 +0200, Oleg Kalnichevski wrote:
> > > Davanum, et al,
> > >
> > > I took at the first stub at the rewrite of the SimpleHTTPServer
> > >
> > >
> > >
> > > On Thu, 2006-05-18 at 11:07 -1000, Chuck Williams wrote:
> > > > Thanks Oleg.  I'll exercise your code, report issues, provided patches,
> > > > etc., as soon as it is available.
> > > >
> > > > I need some features that might not be available in a simple
> > > > implementation, primarily the ability to control a set of thread pools
> > > > assigned to different operations.  E.g., I've got a bunch of quick small
> > > > operations and a few big slow ones.  I need to limit the processing of
> > > > the large ones so that reading and processing the incoming messages does
> > > > not run the jvm out of memory or cause performance issues, while
> > > > allowing the small ones to get through at high priority.  In general,
> > > > I'd like to be able to control the allocation of incoming messages to
> > > > threads in operation-dependent thread pools, limit the threads in the
> > > > each pool, and relatively prioritize the pools.
> > > >
> > > > This might have architectural implications has the dispatching needs to
> > > > be done to determine the operation and thereby select the thread pool.
> > > > It is essential that the reading of messages be performed by the axis2
> > > > message receivers so the large ones can be streamed through.  Ideally,
> > > > the sizes of the thread pools could be varied dynamically, so that for
> > > > example a particularly large message could prevent other threads from
> > > > being assigned until it completes; however, I can provide the dynamic
> > > > size-based resource control in the app even with fixed size thread
> > > > pools.  Even without operation-based thread pools, so long as the
> > > > messages are not read by the http client, I could implement this
> > > > mechanism as a secondary thread assignment in the app.
> > > >
> > > > I'd be happy to add support for this kind of functionality if not part
> > > > of the core package.
> > > >
> > > > Chuck
> > > >
> > > >
> > > > Oleg Kalnichevski wrote on 05/18/2006 10:54 AM:
> > > > > Chuck Williams wrote:
> > > > >>
> > > > >> robert burrell donkin wrote on 05/18/2006 07:56 AM:
> > > > >>> On 5/18/06, *Davanum Srinivas* <davanum@gmail.com
> > > > >>> <mailto:davanum@gmail.com>> wrote:
> > > > >>>
> > > > >>> <snip>
> > > > >>>
> > > > >>>     The long term plan is to use HttpCore in HttpComponents.
See
> > > > >>> thread:
> > > > >>>
> > > > >>> http://marc.theaimsgroup.com/?l=axis-dev&w=2&r=1&s=httpcomponents&q=b
> > > > >>>
> > > > >>> <http://marc.theaimsgroup.com/?l=axis-dev&w=2&r=1&s=httpcomponents&q=b>
> > > > >>>
> > > > >>>
> > > > >>> +1
> > > > >>>
> > > > >>>  this will happen all the more quickly if contributors step
up and
> > > > >>> lend a hand.
> > > > >>>
> > > > >>> chuck - sounds you like you have a real itch: want to help
us
> > > > >>> scratch it?
> > > > >> Yes, I do.  Unlike some others on the list, I need to deliver
a
> > > > >> robust product using axis2 in just a few months.  I chose axis2
> > > > >> because of its architecture, basis in stax, support for streaming,
> > > > >> and position to be the Java soap platform of the future, but
I need
> > > > >> to make my use of it solid now.  I have a dedicated soap service
> > > > >> component and definitely want to use a thin built-in http server
> > > > >> rather than say a full tomcat installation.
> > > > >>
> > > > >> Robert, are you connected with HttpCore?  Do you know if I could
grab
> > > > >> it now and create a replacement for SimpleHTTPServer and friends
> > > > >> based on it?  Are there others with a similar need now who want
to
> > > > >> coordinate/collaborate?  I don't mind fixing some bugs or adding
a
> > > > >> few features along the way, as I'm doing with axis2.
> > > > >>
> > > > >> Chuck
> > > > > Chuck,
> > > > >
> > > > > You can find some info on the HttpComponents project here:
> > > > > http://jakarta.apache.org/httpcomponents/index.html
> > > > >
> > > > > I'll throw together a drop-in replacement for SimpleHTTPServer based
> > > > > on HttpCore this weekend and post a patch against Axis2 SVN trunk.
> > > > > Essentially this is all it takes to create a simple HTTP server based
> > > > > on HttpCore:
> > > > > http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/src/examples/org/apache/http/examples/ElementalHttpServer.java
> > > > >
> > > > >
> > > > > It will be hugely appreciated if you could help me test it and see
how
> > > > > well (or badly) it fares.
> > > > >
> > > > > Mind you, HttpCore is still an early ALPHA. We are not prepared to
> > > > > freeze the API yet. However, it is very much the proverbial chicken
> > > > > and egg situation: the more people start testing HttpCore in real
life
> > > > > applications and give us feedback the sooner we can finalize the
API
> > > > > and stabilize the code.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > >>
> > > > >> ---------------------------------------------------------------------
> > > > >> 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
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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


Mime
View raw message