You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Davanum Srinivas <da...@gmail.com> on 2006/05/18 01:40:53 UTC
Re: Extensions and revisions to SimpleHTTPServer
Chuck,
1. Yes, Please don't use it in production. See item #2 in your message :)
2. some tests fail (some some do fail intermittently even now) because
of problems in the http stream reading problems. the full copy
prevented a few problems but i still get random errors in security
tests, especially on win32 under jrockit. So it is not stable.
3. Please don't waste time right now....Reason below.
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
Again, Please don't use what exists now in production now :) Please
ping/watch the httpcomponents guys and let us switch to that and then
make it production ready.
thanks,
dims
On 5/17/06, Chuck Williams <ch...@manawiz.com> wrote:
>
> Hi All,
>
> I'm interested in using SimpleHTTPServer in production because it
> simplifies installation and packaging and it is (or should be) lean and
> fast. The application is a dedicated SOAP service that does not need other
> web or application server facilities. To use SimpleHTTPServier, I need to
> make some extensions and revisions. I'd appreciate any feedback on these
> ideas and an indication of whether others would find the changes and
> features useful:
>
>
>
> SimpleHTTPServer declares that it is not intended for production use. Is
> there any fundamental reason for not using it in production?
>
>
> SimpleHTTPServer uses HTTPWorker as its request handler. When processing
> SOAP messages, HTTPWorker reads the entire message, writes it into a
> ByteArrayOutputStream, and converts this to a byte[] that is then wrapped in
> a ByteArrayInputStream. The ByteArrayInputStream is used as the actual
> stream that gets wrapped by a stax reader. This copying has several
> problems. It is uncontrollable so a flurry of large messages will exhaust
> the jvm's Xmx. It is inefficient. It seems to eliminate the opportunity to
> process the message by streaming. My app has some messages with very large
> payloads that are processed by streaming message receivers. I'd like to
> eliminate the copying in HTTPWorker but suspect it is there for a reason.
> Does anybody know why it would be important to read the entire message
> before processing it? If the only concern is http timeouts, there are other
> ways to manage this.
>
>
> I'd like to add facilities for assigning operations to a set of alternative
> thread pools than can be separately prioritized and resource-managed. E.g.,
> small status-related requests would get immediate high-priority processing,
> while larger requests that will demand a lot of memory and cycles will wait
> for availability of a thread in a smaller pool.
> Any feedback appreciated.
>
> Thanks,
>
> Chuck
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Extensions and revisions to SimpleHTTPServer
Posted by Davanum Srinivas <da...@gmail.com>.
Chuck,
i'd say go for it, we can always find a home for it :)
-- dims
On 5/18/06, Chuck Williams <ch...@manawiz.com> wrote:
>
>
> Oleg Kalnichevski wrote on 05/18/2006 11:17 AM:
> On Thu, 2006-05-18 at 11:07 -1000, Chuck Williams wrote:
>
>
> 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.
>
>
> HttpCore is a set of low level components focused exclusively on the
> transport aspects of the HTTP protocol. HttpCore does not (and will not)
> provide connection and thread pooling. We are very much welcome to
> contribute these components. For a start, I'll hack up something very
> simple.
>
>
>
>
> Should the facility to manage operation-dependent prioritizable thread
> pools be a part of axis2? If not already planned or being worked on by
> someone else, I could provide this. I'd like to have a general mechanism
> that supports application logic to control thread allocation.
>
> If others think this best left out of axis2 and created by each app, then
> I'll just do it for my app.
>
> Chuck
>
> ---------------------------------------------------------------------
> 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
Re: Extensions and revisions to SimpleHTTPServer
Posted by Oleg Kalnichevski <ol...@apache.org>.
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,
HttpCore is a set of low level components focused exclusively on the
transport aspects of the HTTP protocol. HttpCore does not (and will not)
provide connection and thread pooling. We are very much welcome to
contribute these components. For a start, I'll hack up something very
simple.
Cheers,
Oleg
> 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
> >>> <ma...@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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <ba...@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 <sa...@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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Jeff Barrett <ba...@us.ibm.com>.
Howdy Dims,
Thanks for the clarification!
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
"Davanum Srinivas" <da...@gmail.com>
05/23/2006 08:19 AM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
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 <ba...@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 <sa...@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
>
>
>
--
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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Davanum Srinivas <da...@gmail.com>.
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 <ba...@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 <sa...@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
>
>
>
--
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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Jeff Barrett <ba...@us.ibm.com>.
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 <sa...@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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
>
> 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?
This is the stock version of SimpleHttpServer. There's no test code
involved at all. It basically appears to drop connection on every second
request when bombarded with requests in a tight loop, hence the serious
performance degradation.
>
> 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.
Oleg
>
> 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 <ol...@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
> > > > > > > > > <ma...@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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@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
> > > > >>> <ma...@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
Re: [Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Davanum Srinivas <da...@gmail.com>.
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 <ol...@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
> > > >>> <ma...@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
[Axis2] Re: Extensions and revisions to SimpleHTTPServer
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
> > >>> <ma...@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
Re: Extensions and revisions to SimpleHTTPServer
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
> >>> <ma...@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
Re: Extensions and revisions to SimpleHTTPServer
Posted by Chuck Williams <ch...@manawiz.com>.
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
>>> <ma...@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
Re: Extensions and revisions to SimpleHTTPServer
Posted by Oleg Kalnichevski <ol...@apache.org>.
Chuck Williams wrote:
>
> robert burrell donkin wrote on 05/18/2006 07:56 AM:
>> On 5/18/06, *Davanum Srinivas* <davanum@gmail.com
>> <ma...@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
Re: Extensions and revisions to SimpleHTTPServer
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/18/06, Davanum Srinivas <da...@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
>
> Again, Please don't use what exists now in production now :) Please
> ping/watch the httpcomponents guys and let us switch to that and then
> make it production ready.
+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?
- robert