Hi John,
John ROM wrote:
> Hello Karsten,
>
> I can only make a few comments because I have not much time at
> the moment and please keep in mind that I do not play grizzly-wise in same league
> as Jeanfrancois.
>
> I think it is very good to post working examples. So that one knows what the other is talking about!
>
> But I actually the way you ported the http proxy to grizzly just
> does not feel right to me.
>
> - I have a problem with the RequestHandler class because its basically an Adapter and has to use com.sun.grizzly.tcp.Request and Response
> and repeat some work which has been done by these classes.
Would it be too complicated to not have the HTTP message parsed? Using a
ProtocolFilter might be complicated if we need to parse the HTTP message
(or re-write some kind of parser).
>
> So in my opinion if you have some programming time and want top performance with
> low resource consumption you should
> hook RequestHandler somewhere nearer to the actual parsing of the bytes. Maybe not use SelectorThread at all but set up your own ProtocolChain ....
>
> - Because of the architecture you are doing way to much Byte/String copying.
This can be optimized. I also suspect using GrizzlyRequest/Response and
GrizzlyAdapter migth also help here.
>
> - maybe look for ways so that the filters can work on streaming data (maybe that is not possible)
>
That's a good idea.
> - Replace RequestStreamer with asynchronous Grizzly Nio writing
Yes, definitively we want it :-)
>
> I favor a Implementation which looks more like
>
> see Thread Subject: Proxy implementation
>
> https://grizzly.dev.java.net/servlets/ReadMsg?list=users&msgNo=83
I think the current code is a really good start. The problem with low
level proxy like the one you listed is it is hard to extend. Peter's
proposal could easily be extended to support more complex scenario (or
combined with a load balancer). Anyway, I've just quickly looked at the
code :-) :-)
What do you think?
A+
-- Jeanfrancois
>
> Many Greetings
> John
>
>