dev@grizzly.java.net

Re: HTTP Proxy Grizzly based

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 16 Dec 2008 14:35:48 -0500

Salut,

I've fixed the OSGI missing meta data. If you have a chance, can you try it?

https://grizzly.dev.java.net/issues/show_bug.cgi?id=354

Thanks!!!

-- Jeanfrancois

Hubert Iwaniuk wrote:
> Hello,
>
> On Mon, Dec 15, 2008 at 4:13 PM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>> wrote:
>
> Salut,
>
>
> Hubert Iwaniuk wrote:
>
> Hi All,
>
> I've just created base of Grizzly based HTTP Proxy
> (http://github.com/neotyk/http-proxy/tree/master)
>
>
> Great!
>
>
> I still have some problems running it as OSGi bundle, but that
> is secondary concern for now.
>
>
> Let me know if I can be of any help. Our OSGi implementation needs
> improvement (we have some split package that might cause issues).
>
>
> I've attached "mvn pax:provision" log. It seems like
> package=com.sun.grizzly.portunif is not a bundle but is expressed as a
> dependency of grizzly-http.
> I'll also probably will need to repackage commons-httpclient.
>
>
>
>
>
>
> Questions I have:
>
> 1. Is there Grizzly HTTP Client?
>
> I would like to get rid of commons-httpclient from this proxy
> implementation.
> What I would found useful is connection pooling, events on
> received all Headers, received chunk (so proxy could stream
> data
> straight to client).
>
>
> Like Kedar and Alexey said, we are working on it (I've got many many
> many requests during Devoxx :-))
>
>
> That is great.
>
>
>
>
> 2. Would you expect performance boost if client connections
> would be
>
> suspended when proxy is waiting for target host to reply?
>
>
> I do think it will help as you will free a thread and avoid blocking
> for the response to comes back.
>
>
> How would you achieve this kind of behavior?
> My initial guess would be:
> 1. Since commons-httpclient is blocking I/O, create Callable for each
> Proxy-TargetServer reqeuest, submit it to ExecutorCompletionService,
> suspend reqeuest.
> 2. Have thread collecting completed tasks that resumes request and
> streams response.
>
> But I don't really see benefit here, for each request proxy receives it
> would need another thread doing blocking I/O.
> I'm looking forward to get my hands on Grizzly Client...
>
>
>
> Thanks for the head up! Was nice to see you @ Devoxx :-)
>
>
> You are welcome, and thanks for talking @ Devoxx it helped me a lot to
> get this Proxy started.
> Hubert.
>
>
>
> A+
>
> -- Jeanfrancois
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net