users@grizzly.java.net

Re: Proxy implementation

From: Karsten Ohme <widerstand_at_t-online.de>
Date: Tue, 5 Jun 2007 16:07:57 +0200

On Tue, Jun 05, 2007 at 03:05:50PM +0200, Oleksiy Stashok wrote:
> Hmm, I see you refused to use Grizzly client side interfaces. For simple
> case maybe it makes sense, but it's possible to easy enable caching if
> you use it.

What interfaces you mean? TCPConnector... Well, the conenct method is
not blocking, I have to use a callback and I have to remember the whole
time to byteBuffer I want to write and must care if in the meanwhile new
read request are coming in and keep the correct order. This sounds
painful. I have tried your tunnel implementation but it lasts more or
the same time than mine.

> In your implementation one thing is not clear to me. It's your Map. May
> be I missed something, but seems it's just one-direction map. In other
> words what will be if request will come to proxy in several parts? How
> it will be processed?

No, the map contains the SocketConnections from the client to the proxy
as key and proxy to server as value and also the other direction.

>
> And from chart you sent, not sure I understand the description of each
> bar. Where is "grizzly code" bar there? :)

The largest one, everything which is non blocking. non blocking large
file and non blocking small page.

Best Regards,
Karsten
>
> WBR,
> Alexey.
>
> Karsten Ohme wrote:
> >Hi,
> >
> >The main problem of implementation was the usage of Context. I thought
> >Context can be used to store global attributes, but this seem not to be
> >true, everything is setup again for each SelectionKey event. I have
> >attached teh implementation. It get sometimes a
> >ClosedConnectionException, don't know who closed it, but the most time
> >it works.
> >The performance of my implementation is quite poor.
> >Using Callbacks and TCPConnector seems to be cumbersome and not working.
> >I don't believe this can boost the performance.
> >Can have used a blocking connect method and write the dat in blocking
> >mode. Can this cause problems? As far as I see the Pipiline is executed
> >eahc time a SelectionKey event happens but by defualt 20 threads are
> >only executed. Can this be a limit? Can the performance be improved?
> >
> >I have also attached test results from JMeter compared to a blocking
> >solution and a direct conenction to a Tomcat server.
> >
> >Ragards,
> >Karsten
> >
> >
> >------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> >For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>