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.
In your benchmark below for Axis2's current SimpleHttpServer, note
these two lines:
Complete requests: 1500
Failed requests: 1500
This does not seem right, and the results seem too slow. Is there
perhaps an error in your test code generating faults?
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?
Chuck
Oleg Kalnichevski wrote on 05/20/2006 12:40 PM:
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 <[EMAIL PROTECTED]> 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
=============================
[EMAIL PROTECTED]:~/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
=====================================================
[EMAIL PROTECTED]:~/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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
