Re: [jira] Updated: (HTTPCORE-11) [3rd patch]

[Roland Weber <ht...@dubioso.net>]

Hi Oleg,

I had a quick look and will share my initial thoughts here. Maybe I'll think
differently after chewing on this for a while. Or maybe you can add some
ideas of yours in response.

(1) agreed. I hadn't seen that point before.

(2) A connection manager (and/or operator) is responsible for more than one
connection. Per-connection information is best kept with the connection
itself. I don't see why the information shouldn't be publicly accessible in a
read-only fashion. It allows for the implementation of strategies that are
not tied to a specific connection manager (or whatever) implementation.
Such as "don't keep connections to host XYZ alive".

(3) agreed

Two weeks ago we discussed turning the connections into simple containers
that don't know how to establish a connection. While your patch does achieve
that, it also effectively turns connections into throw-away objects. On first
thought, I don't like it because of a gut feeling. On second thought I don't
like it because SimpleHttpDispatcher assumes to have *one* connection which
can be pointed to different targets one after another. It's probably not hard
to change, but throw-away connection objects clash with every thought about
"connection management" I've ever had so far.

cheers,
  Roland


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

Re: [jira] Updated: (HTTPCORE-11) [3rd patch]

[Roland Weber <ht...@dubioso.net>]

Hi Oleg,

> I may not have fully grasped the concept but I felt the proposed
> solution would not work well with NIO where the process of establishing
> a connection was non-blocking.

I'm not sure how that works. The connection factory in your previous
patch would also return a connection object, right?

> And yes, it is kinda complex ;-)

Sorry, I couldn't think of an easier way :-)

> So, my
> intention was to remove all methods from HttpClientConnection interface
> that have to do with connection initialization, provide a simple
> mechanism to bind the default HttpClientConnection impl to an arbitrary
> socket and then deal with HTTPCORE-8

The idea of the patch in HTTPCORE-8 was to keep all connection init methods
in the connection interface, but route them to the operator which gets
exclusive internal access to the container object. I was really just trying
to refactor the code for opening and closing sockets out of the connection.

> But the operator is nonetheless exposed through the HttpClientConnection
> interface, right?

It is exposed as getter and setter, yes. But there are currently no methods
in the operator that could be called directly. The getter/setter is intended
mainly to change the operator while the connection is closed. And of course
to initialize the container object after creation. I think Spring relies on
getters and setters? ;-)

> So, every HTTP client connection would have to
> implement it even though not every kind of connection is capable of
> "re-opening" itself? 

It is only _suggested_ that reopening _tries_ to re-use the socket.
It is perfectly acceptable that the operator simply closes the socket
and creates a new one in response to the re-open call. That much should
be supported by every container for a socket :-)
Connections don't implement an operator, they are provided with one.
It's supposed to be a mix-and-match relation between the two, unless
somebody implements an operator that needs additional attributes in the
connection. That operator would need to provide an extended connection
implementation.

Still, I don't know what implications that has regarding NIO.
Maybe you can write a paragraph or two how a connection will be
openend asynchronously, and how that will be synchronized with
the operation of the application thread?

cheers,
  Roland


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

Re: [jira] Updated: (HTTPCORE-11) [3rd patch]

[Oleg Kalnichevski <ol...@apache.org>]

On Tue, 2006-09-05 at 21:26 +0200, Roland Weber wrote: 
> Hi Oleg,
> 
> > I certainly do not have a problem with exposing the target host through
> > the HttpClientConnection interface. We just have to make sure that
> > HttpClientConnection cannot be (easily) put into an inconsistent state
> > where the target host does not correspond to the remote address of the
> > underlying socket.  
> 
> Agreed.
> 
> > The trouble is that I would not want the HttpClientConnection interface
> > to be directly coupled with java.net.Socket. At the same time I cannot
> > think of an elegant way to re-attach the existing client connection to a
> > new network socket.  Let us think it over.
> 
> So you think the solution I proposed with HTTPCORE-8 is not elegant.
> I admit that it is slightly complex, but the objects have very well
> defined responsibilities. I would also prefer a solution where the
> calls to the operator do not have to be routed through the connection,
> but it somehow matches the telephone analogy :-)
> 

Roland,

I may not have fully grasped the concept but I felt the proposed
solution would not work well with NIO where the process of establishing
a connection was non-blocking. And yes, it is kinda complex ;-) So, my
intention was to remove all methods from HttpClientConnection interface
that have to do with connection initialization, provide a simple
mechanism to bind the default HttpClientConnection impl to an arbitrary
socket and then deal with HTTPCORE-8

> I am aware of two options for giving exclusive access to some of the
> methods. The first one is what I've done in HTTPCORE-8: use an extra
> callback object that is passed only to an entitled caller. The other
> one is based on passing a secret "ticket" object to restricted calls,
> which must have been set previously when the state became locked.
> Then only the owner of the secret can perform modifications.
> For the connections, I like the first solution better since it does
> not pollute the connection interface. The user of the connection does
> not even have to be aware of the connection/operator interaction.
> 

But the operator is nonetheless exposed through the HttpClientConnection
interface, right? So, every HTTP client connection would have to
implement it even though not every kind of connection is capable of
"re-opening" itself? 

Oleg

> 
> cheers,
>   Roland
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


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

Re: [jira] Updated: (HTTPCORE-11) [3rd patch]

[Roland Weber <ht...@dubioso.net>]

Hi Oleg,

> I certainly do not have a problem with exposing the target host through
> the HttpClientConnection interface. We just have to make sure that
> HttpClientConnection cannot be (easily) put into an inconsistent state
> where the target host does not correspond to the remote address of the
> underlying socket.  

Agreed.

> The trouble is that I would not want the HttpClientConnection interface
> to be directly coupled with java.net.Socket. At the same time I cannot
> think of an elegant way to re-attach the existing client connection to a
> new network socket.  Let us think it over.

So you think the solution I proposed with HTTPCORE-8 is not elegant.
I admit that it is slightly complex, but the objects have very well
defined responsibilities. I would also prefer a solution where the
calls to the operator do not have to be routed through the connection,
but it somehow matches the telephone analogy :-)

I am aware of two options for giving exclusive access to some of the
methods. The first one is what I've done in HTTPCORE-8: use an extra
callback object that is passed only to an entitled caller. The other
one is based on passing a secret "ticket" object to restricted calls,
which must have been set previously when the state became locked.
Then only the owner of the secret can perform modifications.
For the connections, I like the first solution better since it does
not pollute the connection interface. The user of the connection does
not even have to be aware of the connection/operator interaction.

cheers,
  Roland

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

Re: [jira] Updated: (HTTPCORE-11) [3rd patch]

[Oleg Kalnichevski <ol...@apache.org>]

On Tue, 2006-09-05 at 14:56 +0200, Roland Weber wrote:
> Hi Oleg,
> 
> I had a quick look and will share my initial thoughts here. Maybe I'll think
> differently after chewing on this for a while. Or maybe you can add some
> ideas of yours in response.
> 
> (1) agreed. I hadn't seen that point before.
> 
> (2) A connection manager (and/or operator) is responsible for more than one
> connection. Per-connection information is best kept with the connection
> itself. I don't see why the information shouldn't be publicly accessible in a
> read-only fashion. It allows for the implementation of strategies that are
> not tied to a specific connection manager (or whatever) implementation.
> Such as "don't keep connections to host XYZ alive".

Hi Roland,

I certainly do not have a problem with exposing the target host through
the HttpClientConnection interface. We just have to make sure that
HttpClientConnection cannot be (easily) put into an inconsistent state
where the target host does not correspond to the remote address of the
underlying socket.  

> 
> (3) agreed
> 
> Two weeks ago we discussed turning the connections into simple containers
> that don't know how to establish a connection. While your patch does achieve
> that, it also effectively turns connections into throw-away objects. On first
> thought, I don't like it because of a gut feeling. On second thought I don't
> like it because SimpleHttpDispatcher assumes to have *one* connection which
> can be pointed to different targets one after another. It's probably not hard
> to change, but throw-away connection objects clash with every thought about
> "connection management" I've ever had so far.
> 

The trouble is that I would not want the HttpClientConnection interface
to be directly coupled with java.net.Socket. At the same time I cannot
think of an elegant way to re-attach the existing client connection to a
new network socket.  Let us think it over.

Oleg

> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


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