You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by ant elder <an...@gmail.com> on 2006/10/06 09:59:06 UTC
Re: A basic non-blocking http/s implementation for Axis2/Synapse
On 9/28/06, Paul Fremantle <pz...@gmail.com> wrote:
<snip>
Is there any code we can re-use from - for example - commons http?
>
> It seems a shame to have to re-implement the HTTP protocol just
> because the IO has changed.
I also wondered about this. From the description of HttpCore it sounds like
they're trying to make something Synapse should be able to use, have you had
a look at that?
http://jakarta.apache.org/httpcomponents/http-core/index.html
...ant
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Paul Fremantle <pz...@gmail.com>.
Hey that's interesting. I didn't know about that. Its a holiday in Sri
Lanka this weekend so don't expect a reply from Ant instantly.
Any chance you can take a deeper look and see how it compares with
what Asankha has been working on?
Paul
On 10/6/06, ant elder <an...@gmail.com> wrote:
>
> On 9/28/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> <snip>
>
> > Is there any code we can re-use from - for example - commons http?
> >
> > It seems a shame to have to re-implement the HTTP protocol just
> > because the IO has changed.
>
> I also wondered about this. From the description of HttpCore it sounds like
> they're trying to make something Synapse should be able to use, have you had
> a look at that?
>
> http://jakarta.apache.org/httpcomponents/http-core/index.html
>
> ...ant
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2006-10-08 at 22:00 +0100, Paul Fremantle wrote:
> Oleg
>
> Thanks for clearing it up. Which mailing list should I subscribe to if
> I have more questions?
>
> Paul
>
Hi Paul
Please post your questions to httpclient-dev@jakarta.apache.org
(Disregard the name of the list. It will be renamed to
httpcomponents-dev at some point of time).
Cheers,
Oleg
> On 10/6/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Fri, 2006-10-06 at 18:21 +0530, Asankha C. Perera wrote:
> > > Ant
> > >
> > > Yes I checked both AsyncWeb and thier code in the scratch and
> > > HttpAsync as well which is from HttpCore
> > > http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04400.html
> > >
> > > There are both good and bad things about us implementing our own
> > > transport...
> > >
> > > asankha
> > >
> >
> > Asankha,
> >
> > HttpComponents is still very much an evolving project, so the scope of
> > its modules has not been always clearly demarcated, hence the
> > confusion.
> >
> > HttpAsync is intended to be a set of API that sits on top of HttpCore
> > and uses _blocking_ I/O to implement asynchronous HTTP services, which
> > makes it highly specialized, and as such usually it gets lower priority
> > compared to HttpCore and HttpClient.
> >
> > If you want a non-blocking client / server HTTP implementation based on
> > NIO, HttpCore should basically suffice. There is already NIO based
> > transport layer in HttpCore NIO extensions and I am presently working on
> > the event-driven protocol layer to put on top of it. All this code will
> > make it into the next public release of HttpCore.
> >
> > Axis2 1.1 is already dependent on HttpCore. It is also dependent on
> > HttpClient, next version of which will be based on HttpCore as well.
> >
> > So, I do not know what your special requirements are, but you might
> > actually want to consider collaborating with us (Jakarta HttpComponents)
> > in your development effort on non-blocking HTTP transport and / or
> > consider re-using some of HttpCore protocol primitives, since they are
> > already being used by other parts of Axis2. This way Axis2 could
> > indirectly benefit from your contribution.
> >
> > Anyways, take it for what it is worth.
> >
> > Cheers,
> >
> > Oleg
> >
> > > ant elder wrote:
> > > >
> > > > On 9/28/06, Paul Fremantle <pz...@gmail.com> wrote:
> > > >
> > > > <snip>
> > > >
> > > > Is there any code we can re-use from - for example - commons
> > > > http?
> > > >
> > > > It seems a shame to have to re-implement the HTTP protocol
> > > > just
> > > > because the IO has changed.
> > > >
> > > > I also wondered about this. From the description of HttpCore it
> > > > sounds like they're trying to make something Synapse should be able
> > > > to use, have you had a look at that?
> > > >
> > > > http://jakarta.apache.org/httpcomponents/http-core/index.html
> > > >
> > > > ...ant
> > > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Paul Fremantle <pz...@gmail.com>.
Oleg
Thanks for clearing it up. Which mailing list should I subscribe to if
I have more questions?
Paul
On 10/6/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2006-10-06 at 18:21 +0530, Asankha C. Perera wrote:
> > Ant
> >
> > Yes I checked both AsyncWeb and thier code in the scratch and
> > HttpAsync as well which is from HttpCore
> > http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04400.html
> >
> > There are both good and bad things about us implementing our own
> > transport...
> >
> > asankha
> >
>
> Asankha,
>
> HttpComponents is still very much an evolving project, so the scope of
> its modules has not been always clearly demarcated, hence the
> confusion.
>
> HttpAsync is intended to be a set of API that sits on top of HttpCore
> and uses _blocking_ I/O to implement asynchronous HTTP services, which
> makes it highly specialized, and as such usually it gets lower priority
> compared to HttpCore and HttpClient.
>
> If you want a non-blocking client / server HTTP implementation based on
> NIO, HttpCore should basically suffice. There is already NIO based
> transport layer in HttpCore NIO extensions and I am presently working on
> the event-driven protocol layer to put on top of it. All this code will
> make it into the next public release of HttpCore.
>
> Axis2 1.1 is already dependent on HttpCore. It is also dependent on
> HttpClient, next version of which will be based on HttpCore as well.
>
> So, I do not know what your special requirements are, but you might
> actually want to consider collaborating with us (Jakarta HttpComponents)
> in your development effort on non-blocking HTTP transport and / or
> consider re-using some of HttpCore protocol primitives, since they are
> already being used by other parts of Axis2. This way Axis2 could
> indirectly benefit from your contribution.
>
> Anyways, take it for what it is worth.
>
> Cheers,
>
> Oleg
>
> > ant elder wrote:
> > >
> > > On 9/28/06, Paul Fremantle <pz...@gmail.com> wrote:
> > >
> > > <snip>
> > >
> > > Is there any code we can re-use from - for example - commons
> > > http?
> > >
> > > It seems a shame to have to re-implement the HTTP protocol
> > > just
> > > because the IO has changed.
> > >
> > > I also wondered about this. From the description of HttpCore it
> > > sounds like they're trying to make something Synapse should be able
> > > to use, have you had a look at that?
> > >
> > > http://jakarta.apache.org/httpcomponents/http-core/index.html
> > >
> > > ...ant
> > >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-10-30 at 02:21 -0800, Dave Irving wrote:
>
>
> Oleg Kalnichevski wrote:
> >
> > ... If I understand it right, the content generated by
> > individual async workers always end up in an intermediate expandable
> > buffer, before it gets written to the underlying socket channel. If so,
> > under heavy load there is always a chance that the buffer can no longer
> > grow due to OFM condition. In my _humble_ and _personal_ option this
> > totally defeats all benefits of an async transport versus threaded one.
> >
> >
>
> Well yes, in MINA buffers are provided back in to the framework which are
> ultimately queued for (NIO) writing by dedicated selector thread(s). Right
> now, asyncweb has its own write buffer - but with ASYNCWEB-21 we'll be
> writing straight in to these MINA managed buffers. MINA already does buffer
> pooling (as does asyncweb for everything except responses pre ASYNCWEB-21) -
> so for the most part it is unlikely that there will be a lot of allocation
> going on.
> With MINA going TLP, it is going to be getting used and tested in a whole
> range of high-end network applications. I would certainly expect it to be
> very robust (and I think it is already). The challange will be to ensure
> that AsyncWeb makes best use of what MINA offers it to ensure that this
> robustness is carried across in to asyncWeb.
>
> But, of course, with any high end server there is going to need to be some
> capacity planning. On the incoming side, use of connection throttling, and
> per connection + per connector memory usage limits (from MINA) will help
> with this. On the outgoing side, we'll again be using pooled buffers.
> However, if some application thread does blow up - AsyncWeb will detect this
> anyway (timeout) and respond to the ultimate client with an HTTP internal
> server error.
>
Dave,
I'll certainly give AsyncWeb another look when the functionality you are
describing is there. Generally, however, it find MINA's memory
management framework to be its weakest point.
In HttpCore NIO extensions I took especial care to make sure content
gets written directly to the socket channel whenever possible, avoiding
intermediate buffering altogether.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Dave Irving <ir...@logica.com>.
Oleg Kalnichevski wrote:
>
> ... If I understand it right, the content generated by
> individual async workers always end up in an intermediate expandable
> buffer, before it gets written to the underlying socket channel. If so,
> under heavy load there is always a chance that the buffer can no longer
> grow due to OFM condition. In my _humble_ and _personal_ option this
> totally defeats all benefits of an async transport versus threaded one.
>
>
Well yes, in MINA buffers are provided back in to the framework which are
ultimately queued for (NIO) writing by dedicated selector thread(s). Right
now, asyncweb has its own write buffer - but with ASYNCWEB-21 we'll be
writing straight in to these MINA managed buffers. MINA already does buffer
pooling (as does asyncweb for everything except responses pre ASYNCWEB-21) -
so for the most part it is unlikely that there will be a lot of allocation
going on.
With MINA going TLP, it is going to be getting used and tested in a whole
range of high-end network applications. I would certainly expect it to be
very robust (and I think it is already). The challange will be to ensure
that AsyncWeb makes best use of what MINA offers it to ensure that this
robustness is carried across in to asyncWeb.
But, of course, with any high end server there is going to need to be some
capacity planning. On the incoming side, use of connection throttling, and
per connection + per connector memory usage limits (from MINA) will help
with this. On the outgoing side, we'll again be using pooled buffers.
However, if some application thread does blow up - AsyncWeb will detect this
anyway (timeout) and respond to the ultimate client with an HTTP internal
server error.
--
View this message in context: http://www.nabble.com/A-basic-non-blocking-http-s-implementation-for-Axis2-Synapse-tf2350221.html#a7071907
Sent from the Synapse - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-10-30 at 01:44 -0800, Dave Irving wrote:
>
> Oleg Kalnichevski wrote:
> >
> >
> > Hi Dave
> >
> > ASYNCWEB-21 will certainly make things better, but as long as there is a
> > chance of an internal buffer overflow or an OutOfMemory condition
> > because the buffer is unable to expand it capacity (for instance, when
> > the async content producer produces more content that the internal
> > buffer can accommodate) architectural issues with AsyncWeb in my opinion
> > will remain unresolved. I may be wrong but I do not see how ASYNCWEB-21
> > is going to fix that.
> >
> > Cheers,
> >
> > Oleg
> >
> >
>
> Well - we shall see I guess. The streaming support will allow huge numbers
> of requests to be handled in parallel with a small memory footprint. There's
> also a whole load of stuff provided by MINA which will enable us to provide
> cross-cutting memory management strategies. And, of course, connection
> throttling is supported by MINA also, so there is no reason why a user of
> asyncweb couldn't configure the underlying MINA engine to employ this too.
>
> Perhaps you could give an actual concrete example of an individual memory
> problem you percieve which - given ASYNCWEB-21 would not already exist in
> other http components?
>
> Dave
Dave,
It is difficult to give an actual concrete example of issues with a
piece of code which has not been yet written. I do not have a very
detailed knowledge of AsyncWeb inner working (so please correct me if I
am wrong) but If I understand it right, the content generated by
individual async workers always end up in an intermediate expandable
buffer, before it gets written to the underlying socket channel. If so,
under heavy load there is always a chance that the buffer can no longer
grow due to OFM condition. In my _humble_ and _personal_ option this
totally defeats all benefits of an async transport versus threaded one.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Dave Irving <ir...@logica.com>.
Oleg Kalnichevski wrote:
>
>
> Hi Dave
>
> ASYNCWEB-21 will certainly make things better, but as long as there is a
> chance of an internal buffer overflow or an OutOfMemory condition
> because the buffer is unable to expand it capacity (for instance, when
> the async content producer produces more content that the internal
> buffer can accommodate) architectural issues with AsyncWeb in my opinion
> will remain unresolved. I may be wrong but I do not see how ASYNCWEB-21
> is going to fix that.
>
> Cheers,
>
> Oleg
>
>
Well - we shall see I guess. The streaming support will allow huge numbers
of requests to be handled in parallel with a small memory footprint. There's
also a whole load of stuff provided by MINA which will enable us to provide
cross-cutting memory management strategies. And, of course, connection
throttling is supported by MINA also, so there is no reason why a user of
asyncweb couldn't configure the underlying MINA engine to employ this too.
Perhaps you could give an actual concrete example of an individual memory
problem you percieve which - given ASYNCWEB-21 would not already exist in
other http components?
Dave
--
View this message in context: http://www.nabble.com/A-basic-non-blocking-http-s-implementation-for-Axis2-Synapse-tf2350221.html#a7071488
Sent from the Synapse - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2006-10-30 at 00:46 -0800, Dave Irving wrote:
>
> Oleg Kalnichevski wrote:
> >
> > Well, would you want to run a web service in production that can die on
> > you with 'out of memory' exception under load? I would not. This is way
> > worse that refusing connections under load due to the worker thread
> > depletion because it leaves the client without a reliable recovery
> > strategy. In my humble opinion AsyncWeb has severe architectural issues
> > due to its memory management.
> >
>
> Lets not get too carried away here.....
> AsyncWeb started life in an environment where all requests / responses were
> of bounded size - and a complete in memory buffering was totally acceptable.
> That does not in anyway mean that the asyncweb architecture does not allow
> us to easily start to support full request and response streaming - without
> any need to keep the request in memory.
> In fact, it is something which will be arriving in to the AsyncWeb world
> very soon.
> Perhaps you should take a look at ASYNCWEB-21:
> http://jira.safehaus.org/browse/ASYNCWEB-21
>
> Cheers,
>
> Dave
Hi Dave
ASYNCWEB-21 will certainly make things better, but as long as there is a
chance of an internal buffer overflow or an OutOfMemory condition
because the buffer is unable to expand it capacity (for instance, when
the async content producer produces more content that the internal
buffer can accommodate) architectural issues with AsyncWeb in my opinion
will remain unresolved. I may be wrong but I do not see how ASYNCWEB-21
is going to fix that.
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Dave Irving <ir...@logica.com>.
Oleg Kalnichevski wrote:
>
> Well, would you want to run a web service in production that can die on
> you with 'out of memory' exception under load? I would not. This is way
> worse that refusing connections under load due to the worker thread
> depletion because it leaves the client without a reliable recovery
> strategy. In my humble opinion AsyncWeb has severe architectural issues
> due to its memory management.
>
Lets not get too carried away here.....
AsyncWeb started life in an environment where all requests / responses were
of bounded size - and a complete in memory buffering was totally acceptable.
That does not in anyway mean that the asyncweb architecture does not allow
us to easily start to support full request and response streaming - without
any need to keep the request in memory.
In fact, it is something which will be arriving in to the AsyncWeb world
very soon.
Perhaps you should take a look at ASYNCWEB-21:
http://jira.safehaus.org/browse/ASYNCWEB-21
Cheers,
Dave
--
View this message in context: http://www.nabble.com/A-basic-non-blocking-http-s-implementation-for-Axis2-Synapse-tf2350221.html#a7070847
Sent from the Synapse - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2006-10-11 at 14:48 +0530, Asankha C. Perera wrote:
> Hi Oleg
>
> > Yes, it does. This is, however, a temporary hack that enabled me to test
> > NIO based I/O reactor using proven code from HttpCore proper. I am still
> > working on the asynchronous HTTP protocol handler, but I prefer
> > developing and testing code in short iterations.
> >
> Sure.. I will definitely keep a close tab on HttpCore/NIO extensions and
> look forward to the changes
> > Well, would you want to run a web service in production that can die on
> > you with 'out of memory' exception under load? I would not. This is way
> > worse that refusing connections under load due to the worker thread
> > depletion because it leaves the client without a reliable recovery
> > strategy. In my humble opinion AsyncWeb has severe architectural issues
> > due to its memory management.
> >
> I think some kind of throttling logic maybe able to help limit the
> connections accepted/memory usage like the thread pools limit the cpu
> exhaustion and overheads
Asankha,
In practical terms, though, that implies blocking, doesn't it? So, we
are back to where we started. ;-)
> > Do you have any interest in contributing some that code to
> > HttpComponents?
> >
> I am not an an expert in this space.. but would love to contribute any
> code we develop if it is useful to someone. Also with your upcoming
> changes to HttpCore/NIO, I think it would be possible for us to merge
> back in someday soon .. so that we both benefit...
>
With a little bit of luck, inspiration and good will on the part of my
wife I may be able to finish the first take at the event-driven HTTP
protocol handler by the end of this week. I certainly want to see
HttpCore 4.0a3 released this month and am determined to work hard toward
that goal. I'll keep you posted on the progress or lack thereof.
If you want to make the convergence of out code bases more likely please
do consider using basic HTTP protocol primitives (such as Header,
RequestLine, StatusLine, HttpVersion and so on) from HttpCore. This code
has 5+ years of history and has been tested quite well. There is no
point rewriting it. Moreover, this should also enable you to put
HttpCookie and HttpAuth code on top of your HTTP transport and get
client-side HTTP state management and authentication for free.
Cheers
Oleg
> thanks
> asankha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Oleg
> Yes, it does. This is, however, a temporary hack that enabled me to test
> NIO based I/O reactor using proven code from HttpCore proper. I am still
> working on the asynchronous HTTP protocol handler, but I prefer
> developing and testing code in short iterations.
>
Sure.. I will definitely keep a close tab on HttpCore/NIO extensions and
look forward to the changes
> Well, would you want to run a web service in production that can die on
> you with 'out of memory' exception under load? I would not. This is way
> worse that refusing connections under load due to the worker thread
> depletion because it leaves the client without a reliable recovery
> strategy. In my humble opinion AsyncWeb has severe architectural issues
> due to its memory management.
>
I think some kind of throttling logic maybe able to help limit the
connections accepted/memory usage like the thread pools limit the cpu
exhaustion and overheads
> Do you have any interest in contributing some that code to
> HttpComponents?
>
I am not an an expert in this space.. but would love to contribute any
code we develop if it is useful to someone. Also with your upcoming
changes to HttpCore/NIO, I think it would be possible for us to merge
back in someday soon .. so that we both benefit...
thanks
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2006-10-11 at 10:33 +0530, Asankha C. Perera wrote:
> Hi Oleg
>
> I was looking at the example AsyncHttpServer in the NIO extensions and
> am looking at the following two fragments of code...
>
> static class DefaultIoEventDispatch implements IOEventDispatch {
> ....
> public void connected(IOSession session) {
> ...
> httpService.registerRequestHandler("*", new HttpFileHandler());
> ...
> worker.start();
> ...
> }
> ...
> -------------------------
>
> public interface HttpRequestHandler {
>
> void handle(HttpRequest request, HttpResponse response,
> HttpContext context)
> throws HttpException, IOException;
> }
>
>
> Does the above imply that we always need to create a new thread to
> handle each new connection?
Hi Asankha,
Yes, it does. This is, however, a temporary hack that enabled me to test
NIO based I/O reactor using proven code from HttpCore proper. I am still
working on the asynchronous HTTP protocol handler, but I prefer
developing and testing code in short iterations.
> Also, when Synapse receives a message it may not know how to reply to
> it immediately - unlike a web server, as the response may depend on
> the response received from another web service to which the request
> needs to be forwarded. Hence at the implementation of the
> HttpRequestHandler interface's handle() method we have a problem.
>
> AsyncWeb exposes a HttpService.handleRequest(HttpRequest request)
> method, where it is easier for us to handle just the received request.
> Once we are ready to respond, we could use request.createResponse()
> and perform a HttpResponse.commit(). So the processing of the request
> and the response could take place over two distinct threads [of the
> common worker thread pool]. They state that any methods invoked on the
> streams returned by HttpRequest#getInputStream() and
> HttpResponse#getOutputStream() will never block - and I guess this
> implies that they have buffered the complete request in memory.
Well, would you want to run a web service in production that can die on
you with 'out of memory' exception under load? I would not. This is way
worse that refusing connections under load due to the worker thread
depletion because it leaves the client without a reliable recovery
strategy. In my humble opinion AsyncWeb has severe architectural issues
due to its memory management.
> As Synapse runs on top of Axis2, we may not need to 'parse' the
> complete XML messages for us to do play our role (say CBR), but I
> think we should process them only after they have been fully read.. as
> we may need to forward them to another service etc. according to the
> configured rules we use.
>
> As AsyncWeb does not [yet] provide a stable client, we started to try
> and develop our own transport, which is essentially a subset of a
> standard http implementation - but which is very similar to your NIO
> extensions - with the distinction mentioned above, which was borrowed
> from AsyncWeb.
>
Do you have any interest in contributing some that code to
HttpComponents?
Cheers
Oleg
> thanks
> asankha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> additional commands, e-mail: synapse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: A basic non-blocking http/s implementation for Axis2/Synapse
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2006-10-06 at 18:21 +0530, Asankha C. Perera wrote:
> Ant
>
> Yes I checked both AsyncWeb and thier code in the scratch and
> HttpAsync as well which is from HttpCore
> http://www.mail-archive.com/httpclient-dev@jakarta.apache.org/msg04400.html
>
> There are both good and bad things about us implementing our own
> transport...
>
> asankha
>
Asankha,
HttpComponents is still very much an evolving project, so the scope of
its modules has not been always clearly demarcated, hence the
confusion.
HttpAsync is intended to be a set of API that sits on top of HttpCore
and uses _blocking_ I/O to implement asynchronous HTTP services, which
makes it highly specialized, and as such usually it gets lower priority
compared to HttpCore and HttpClient.
If you want a non-blocking client / server HTTP implementation based on
NIO, HttpCore should basically suffice. There is already NIO based
transport layer in HttpCore NIO extensions and I am presently working on
the event-driven protocol layer to put on top of it. All this code will
make it into the next public release of HttpCore.
Axis2 1.1 is already dependent on HttpCore. It is also dependent on
HttpClient, next version of which will be based on HttpCore as well.
So, I do not know what your special requirements are, but you might
actually want to consider collaborating with us (Jakarta HttpComponents)
in your development effort on non-blocking HTTP transport and / or
consider re-using some of HttpCore protocol primitives, since they are
already being used by other parts of Axis2. This way Axis2 could
indirectly benefit from your contribution.
Anyways, take it for what it is worth.
Cheers,
Oleg
> ant elder wrote:
> >
> > On 9/28/06, Paul Fremantle <pz...@gmail.com> wrote:
> >
> > <snip>
> >
> > Is there any code we can re-use from - for example - commons
> > http?
> >
> > It seems a shame to have to re-implement the HTTP protocol
> > just
> > because the IO has changed.
> >
> > I also wondered about this. From the description of HttpCore it
> > sounds like they're trying to make something Synapse should be able
> > to use, have you had a look at that?
> >
> > http://jakarta.apache.org/httpcomponents/http-core/index.html
> >
> > ...ant
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> additional commands, e-mail: synapse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org