axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Date Sat, 20 May 2006 22:30:08 GMT
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...

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


-- 
Davanum Srinivas : http://wso2.com/blogs/

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