hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: [HttpConn] manager
Date Sat, 20 Jan 2007 22:46:47 GMT
Hi Oleg,

> Mike put a lot of hard work into the multithreaded connection manager.
> To this point it still constitutes the most significant and complex
> contribution to the project. Even though it does look like some kind of
> black magic MTHCM has been working really well for us. I urge you to not
> start taking it apart until we have enough test coverage to test for
> regressions. Let's just get it working with the new API and then see
> what could be improved.

I appreciate the work that Mike and others have put into the MTHCM.
And I can well imagine how it developed over time. I'm sure that
originally connections were handed out directly, which explains why
they get deleted and created instead of being managed. Then the
wrappers came, and so on.
But I'm currently looking at the result of all these changes over
time. And I can't see where to start with making _small_ changes.
I can't "just make it work with the new API".
I thought it couldn't be so hard to have one interface for the
connections being managed and another one for the wrappers being
given to the caller. Then I look at the code and realize that the
connections are not being managed by reference, they are subclassed.
And the only purpose of the subclass is to create a weak reference
to the object itself, which will then be put into some static map,
to be retrieved I don't know when for I don't know what. Oh, and
there is code to put references in and out of those maps for reasons
I don't understand either.
The idea of moving some of the classes out to make things simpler
was a dead end too. The stuff is nested, with most of the complexity
being in the ConnectionPool class with plenty of private methods.
It won't help to move it to an extra file and make the methods public.

Basically nothing in MTHCM works in a way that is remotely in line
with my understanding of what the class is supposed to do. I don't
work or think that way. To me, a pool is a finite set of elements,
some of which are allocated and some of which are not. You keep
references to those elements and when the pool is shut down, you
shut down the elements. The manager *knows* which elements it is
managing. Weak references and garbage collection???
I'm sorry, but I have serious issues with this code. I'm not just
feeling a bit uncomfortable about it, and it's not "I would have
implemented this differently" either. It's not the formatting and
not the variable or method names. The class is based on an extremely
complex design which is completely alien to me. I believe that much
of the complexity will simply vanish if a more straightforward
design is applied to the problem.

I'll give the code one more try tomorrow. But only one.
Meanwhile, I'll appreciate any background information on the
current design that somebody can give me.

cheers,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message