Re: Http client decoder & encoder

[Trustin Lee <tr...@gmail.com>]

Hi Tim,

On 4/14/07, Kimmet, Tim <tk...@ebay.com> wrote:
> Does Jakarta Commons HttpClient support async i/o? If not, then wouldn't a
> MINA-based client (that would support async i/o) offer a good advantage
> because less threads would be required to process each http request?

Yes.  You might also be interested in Apache Jakarta HttpComponent project:

http://jakarta.apache.org/httpcomponents/index.html

I didn't look into the asynchronous part yet though.

> Let's also take this one step further and think about even larger
> benefits... Let's say I wanted to use AsyncWeb to host a service that spends
> most of its time doing HTTP calls to a 3rd-party-service. Let's say the
> total request time in the AsyncWeb service is 110 millis, but the HTTP-call
> to the 3rd-party-service takes 100 millis. I would think that AsyncWeb +
> MINA-Http-Client would provide huge benefits in this scenario because the
> whole request/response lifecycle and 3rd-party-service call to the back-end
> would be totally async. That is, in a typical Java Servlet model (without
> async i/o) using the Jakarta Commons HttpClient (I don't think it supports
> async i/o) would require MANY more threads to support the same throughput as
> AsyncWeb + MINA-HTTP-Client in a totally i/o-bound service. In addition,
> manageability is difficult in the typical Servlet model because in the
> Servlet model you'd have to increase the threads in HttpClient when you
> increase threads in the Servlet container thread pool.
>
> Thoughts?

With modern operating system with O(1) scheduler, the number of thread
won't affect the performance much.  I think it highly depends on the
number of connections.  Blocking I/O can perform better than NIO with
about 2000~3000 threads.  Anyways, it's true that NIO will outperform
eventually.

The actual problems of blocking I/O are 1) that too many threads can
make debugging very difficult and 2) that the service with many
keep-alive connections can go out-of-service just because the thread
pool is exhausted even if the server is actually idle and it leads
huge irrational thread pool size (i.e. 30000).

I gave a presentation about this topic recently in Korea:

http://www.gleamynode.net/BCSeoul2006.pdf

It's written in Korean, but it might help.  :)

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Http client decoder & encoder

[Trustin Lee <tr...@gmail.com>]

Hi,

On 4/19/07, pmorelli <pm...@gmail.com> wrote:
>
> What is the roapmap/plan for asyncweb, there have been some updates about
> lawyers and forms, but what's the plan going forward? It's sort of
> languished for a while...

The software grant the lawyers sent is missing.  They are sending it
again to us, so please be patient.  :)

> Even a barebones outline of point releases or milestones, or even just a
> feature list, would be nice.

AsyncWeb will be included in Apache MINA 2.0.0-M1.  AsyncWeb needs
improvement before its first release at the ASF, and MINA 2.0.0-M1
needs some time, too.  I hope we cut the release before this fall, but
the schedule highly depends on the contributor activity.  You could
lend us your hand if you need it soon.

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Http client decoder & encoder

[pmorelli <pm...@gmail.com>]

What is the roapmap/plan for asyncweb, there have been some updates about
lawyers and forms, but what's the plan going forward? It's sort of
languished for a while...

Even a barebones outline of point releases or milestones, or even just a
feature list, would be nice.

Thanks...


Trustin Lee wrote:
> 
> Tim,
> 
> On 4/17/07, Kimmet, Tim <tk...@ebay.com> wrote:
>> I apologize- I meant to ask  "Does Jakarta Commons HttpClient support
>> Non-Blocking async i/o", not simply "async i/o". I am aware of the
>> "async i/o" support and I thought MINA would be a good fit to fill in
>> the Non-Blocking part. Threads in Java can have a bit of memory
>> overhead, especially when the stack size of each thread is increased.
>> Therefore, if I can lower my thread count I'll have more memory to
>> process requests. Also- my OS is NT!
> 
> Oh I see.  The aim of AsyncWeb is not just about server.  We have a
> plan to support both server and client side, although I will take some
> time to get there.  You can always lend your hand to accelerate the
> project. :)
> 
> Trustin
> -- 
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
> 
> 

-- 
View this message in context: http://www.nabble.com/Re%3A-Http-client-decoder---encoder-tf3581976.html#a10060323
Sent from the mina dev mailing list archive at Nabble.com.

Re: Http client decoder & encoder

[Trustin Lee <tr...@gmail.com>]

Tim,

On 4/17/07, Kimmet, Tim <tk...@ebay.com> wrote:
> I apologize- I meant to ask  "Does Jakarta Commons HttpClient support
> Non-Blocking async i/o", not simply "async i/o". I am aware of the
> "async i/o" support and I thought MINA would be a good fit to fill in
> the Non-Blocking part. Threads in Java can have a bit of memory
> overhead, especially when the stack size of each thread is increased.
> Therefore, if I can lower my thread count I'll have more memory to
> process requests. Also- my OS is NT!

Oh I see.  The aim of AsyncWeb is not just about server.  We have a
plan to support both server and client side, although I will take some
time to get there.  You can always lend your hand to accelerate the
project. :)

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6