Hello John,
> In question 2) I meant connect() always fires the method
> public void onConnect(IOEvent<Context> e) {}
> of CallBackHandler.
>
> This irritates me because when I reuse a Connection from the
> cache I would think that a real connect is not actually executed.
>
> But maybe there's a good reason for this, or I'm doing something
> wrong in the underneath code
You're understanding is correct.
At time I implemented cache, I had the idea to make it hidden for
developer, so developer will not even know whether he uses connection
from cache or new one. That's why onConnect is called all the time,
even if connection was taken from cache.
I have to be frankly, current implementation of cache is not perfect,
as has some issues, which even could not be fixed. IMHO, mistake was
in making cache implementation too common, transport independent,
which finally make it very complex :(
For Grizzly 2.0 I would like to see different cache implementation,
where developers will have more control over the cache. Hope with help
of community, we will be able to define connection cache requirements
better.
Nearest time we're going to start Grizzly 2.0 discussions on mailing
list. So, invite you to participate in building Grizzly 2.0
requirements and connection cache as part of it.
Thanks.
WBR,
Alexey.
>
>
> Please forget about Question 3 and 4
>
> Many Greetings
> John
>
>
>
>
> ------------------------------------------------------------------
>>> Hello,
>
>>> I have a client talking to the server.
>
>
> I setup pooling like this:
>
> Controller controller = new Controller();
>
> ConnectorHandlerPool cacheableHandlerPool = new
>
> CacheableConnectorHandlerPool(controller, 5,2, 1);
> controller.setConnectorHandlerPool(cacheableHandlerPool);
>
>
>
> And on every "client write" I do something like:
>
> ------------------------------------------------------------------
>
> public void send(Object params[]) throws Exception {
> connector_handler =
> controller.acquireConnectorHandler(Controller.Protocol.TCP);
> while (true) {
> try {
> connector_handler
> .connect(
> new InetSocketAddress(host, port),
> getConnectCallbackHandle());
>
> break;
>
> } catch (Exception ex) {
> System.out.println("just try again ");
> }
> }
> writeRequest(params); // has same connector_handler
>
> try {
> connector_handler.close();
> } finally {
> controller.releaseConnectorHandler(connector_handler);
> }
>
> }
> ----------------------------------------------------------------------
> My questions are :
>
> 1) Does the code look ok?
>
> 2) When I reuse an existing connection
> the connect call always fires the Callbackhandler.
> Since the connection is already connected this irritates me ?
>
> 3) if a connection is broken I obviously just don't
> hand it back to the pool. But I guess this broken connection
> would still hold on to resources. Is this an issue?
>
> 4) Is the set up of the Connection Pool with
> CacheableConnectorHandlerPool(controller, 5,2, 1);
> alright for my usecase?
>
> Many Greetings
> John
>
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
> --
> 249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
> Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>