isStale()

[Q Beukes]

Hey,

Isn't isStale() supposed to be able to tell me whether the server is
accepting responses?

--
Quintin Beukes

[olegk]

Quintin Beukes wrote:
> Hey,
>
> Isn't isStale() supposed to be able to tell me whether the server is
> accepting responses?
>

No, it is intended to test if the connection is still valid on the
client side. Blocking I/O provides no good means of telling if the
socket has been closed by the peer. #isStale is a work-around for the
problem.

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[Q Beukes]

Hey,

So.. keepalive is sort of useless then? Because I realised what my problem
is. It wasn't synchronization. It was because connections closed by the
server, and then it fails when I try to re-use the connection.

Basically what I have is this:
I try once, if receiving a NoResponse exception, I remove it from the pool
and try again
If second try fails as well, it gets removed and I try again but with an
isStale() check first.

My problem is that these keep failing until I filtered through all
connections in the pool. In which case I start making new ones.

How does HttpClient handle this? Or what can I do to improve this into being
more reliable (in the sense of reducing failures to a minimum).

Q

On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:

>
> Quintin Beukes wrote:
>
>> Hey,
>>
>> Isn't isStale() supposed to be able to tell me whether the server is
>> accepting responses?
>>
>>
> No, it is intended to test if the connection is still valid on the client
> side. Blocking I/O provides no good means of telling if the socket has been
> closed by the peer. #isStale is a work-around for the problem.
>
> Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> For additional commands, e-mail: httpclient-users-help@...
>
>

--
Quintin Beukes

[Q Beukes]

Will NIO connections work?

On 6/21/08, Quintin Beukes <quintin@...> wrote:

>
> Hey,
>
> So.. keepalive is sort of useless then? Because I realised what my problem
> is. It wasn't synchronization. It was because connections closed by the
> server, and then it fails when I try to re-use the connection.
>
> Basically what I have is this:
> I try once, if receiving a NoResponse exception, I remove it from the pool
> and try again
> If second try fails as well, it gets removed and I try again but with an
> isStale() check first.
>
> My problem is that these keep failing until I filtered through all
> connections in the pool. In which case I start making new ones.
>
> How does HttpClient handle this? Or what can I do to improve this into
> being more reliable (in the sense of reducing failures to a minimum).
>
> Q
>
> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
>>
>> Quintin Beukes wrote:
>>
>>> Hey,
>>>
>>> Isn't isStale() supposed to be able to tell me whether the server is
>>> accepting responses?
>>>
>>>
>> No, it is intended to test if the connection is still valid on the client
>> side. Blocking I/O provides no good means of telling if the socket has been
>> closed by the peer. #isStale is a work-around for the problem.
>>
>> Oleg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
>> For additional commands, e-mail: httpclient-users-help@...
>>
>>
>
>
> --
> Quintin Beukes

--
Quintin Beukes

[olegk]

Quintin Beukes wrote:
> Hey,
>
> So.. keepalive is sort of useless then?

Why? You just have to bear in mind HTTP connections may be closed at
_any_ point of time by either side. Your code must be prepared to handle
such cases.


  Because I realised what my problem

> is. It wasn't synchronization. It was because connections closed by the
> server, and then it fails when I try to re-use the connection.
>
> Basically what I have is this:
> I try once, if receiving a NoResponse exception, I remove it from the pool
> and try again
> If second try fails as well, it gets removed and I try again but with an
> isStale() check first.
>
> My problem is that these keep failing until I filtered through all
> connections in the pool. In which case I start making new ones.
>
> How does HttpClient handle this? Or what can I do to improve this into being
> more reliable (in the sense of reducing failures to a minimum).
>

HttpClient can optionally test connections for being non-stale and
re-open them if needed, but the stale check cannot be 100% reliable.
Basically, well-behaved HTTP agents must be prepared to retry the
request in case of an I/O failure.

Oleg

> Q
>
> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
>> Quintin Beukes wrote:
>>
>>> Hey,
>>>
>>> Isn't isStale() supposed to be able to tell me whether the server is
>>> accepting responses?
>>>
>>>
>> No, it is intended to test if the connection is still valid on the client
>> side. Blocking I/O provides no good means of telling if the socket has been
>> closed by the peer. #isStale is a work-around for the problem.
>>
>> Oleg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
>> For additional commands, e-mail: httpclient-users-help@...
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[olegk]

Quintin Beukes wrote:
> Will NIO connections work?
>

Yep. NIO is event driven, so the I/O selector will trigger an event if a
channel gets closed by the other side

Oleg

PS: I'm off to bed. Wife is angry.

> On 6/21/08, Quintin Beukes <quintin@...> wrote:
>> Hey,
>>
>> So.. keepalive is sort of useless then? Because I realised what my problem
>> is. It wasn't synchronization. It was because connections closed by the
>> server, and then it fails when I try to re-use the connection.
>>
>> Basically what I have is this:
>> I try once, if receiving a NoResponse exception, I remove it from the pool
>> and try again
>> If second try fails as well, it gets removed and I try again but with an
>> isStale() check first.
>>
>> My problem is that these keep failing until I filtered through all
>> connections in the pool. In which case I start making new ones.
>>
>> How does HttpClient handle this? Or what can I do to improve this into
>> being more reliable (in the sense of reducing failures to a minimum).
>>
>> Q
>>
>> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
>>> Quintin Beukes wrote:
>>>
>>>> Hey,
>>>>
>>>> Isn't isStale() supposed to be able to tell me whether the server is
>>>> accepting responses?
>>>>
>>>>
>>> No, it is intended to test if the connection is still valid on the client
>>> side. Blocking I/O provides no good means of telling if the socket has been
>>> closed by the peer. #isStale is a work-around for the problem.
>>>
>>> Oleg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
>>> For additional commands, e-mail: httpclient-users-help@...
>>>
>>>
>>
>> --
>> Quintin Beukes
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[Q Beukes]

Hey,

Hopefully someone is still around to answer this question.

I had a look at the NIO of HttpCore (module-nio). Specifically the examples.

I noticed the client connections are done in a separate thread. Does it have
to happen in a separate thread? Do I need a thread for every "persistent"
connection?

I assume not. I haven't had a proper look, as I'm going to bed myself now. I
just want to confirm something.

I create the new connection by adding an object of my choice to the context
and then connecting it to an IO reactor. Here can be any number of
connections to any number of different hosts, and I just handle each one by
using it's attachment in the event handlers?

So it's basically just set up, and everything then happens via events which
is executed in a single dedicated thread for ALL connections to ALL hosts?

Q

On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:

>
> Quintin Beukes wrote:
>
>> Will NIO connections work?
>>
>>
> Yep. NIO is event driven, so the I/O selector will trigger an event if a
> channel gets closed by the other side
>
> Oleg
>
> PS: I'm off to bed. Wife is angry.
>
> On 6/21/08, Quintin Beukes <quintin@...> wrote:
>>
>>> Hey,
>>>
>>> So.. keepalive is sort of useless then? Because I realised what my
>>> problem
>>> is. It wasn't synchronization. It was because connections closed by the
>>> server, and then it fails when I try to re-use the connection.
>>>
>>> Basically what I have is this:
>>> I try once, if receiving a NoResponse exception, I remove it from the
>>> pool
>>> and try again
>>> If second try fails as well, it gets removed and I try again but with an
>>> isStale() check first.
>>>
>>> My problem is that these keep failing until I filtered through all
>>> connections in the pool. In which case I start making new ones.
>>>
>>> How does HttpClient handle this? Or what can I do to improve this into
>>> being more reliable (in the sense of reducing failures to a minimum).
>>>
>>> Q
>>>
>>> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
>>>
>>>> Quintin Beukes wrote:
>>>>
>>>> Hey,
>>>>>
>>>>> Isn't isStale() supposed to be able to tell me whether the server is
>>>>> accepting responses?
>>>>>
>>>>>
>>>>> No, it is intended to test if the connection is still valid on the
>>>> client
>>>> side. Blocking I/O provides no good means of telling if the socket has
>>>> been
>>>> closed by the peer. #isStale is a work-around for the problem.
>>>>
>>>> Oleg
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
>>>> For additional commands, e-mail: httpclient-users-help@...
>>>>
>>>>
>>>>
>>> --
>>> Quintin Beukes
>>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> For additional commands, e-mail: httpclient-users-help@...
>
>

--
Quintin Beukes

[olegk]

On Sat, 2008-06-21 at 02:40 +0200, Quintin Beukes wrote:
> Hey,
>
> Hopefully someone is still around to answer this question.
>
> I had a look at the NIO of HttpCore (module-nio). Specifically the examples.
>
> I noticed the client connections are done in a separate thread. Does it have
> to happen in a separate thread? Do I need a thread for every "persistent"
> connection?

Quintin,

You only need 2 threads: one for the I/O reactor and a controller thread
to control the I/O reactor. All new connections are established on the
I/O reactor thread.

>
> I assume not. I haven't had a proper look, as I'm going to bed myself now. I
> just want to confirm something.
>
> I create the new connection by adding an object of my choice to the context
> and then connecting it to an IO reactor. Here can be any number of
> connections to any number of different hosts, and I just handle each one by
> using it's attachment in the event handlers?
>

Yes.

> So it's basically just set up, and everything then happens via events which
> is executed in a single dedicated thread for ALL connections to ALL hosts?
>

Yes.

Oleg

> Q
>
> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> >
> > Quintin Beukes wrote:
> >
> >> Will NIO connections work?
> >>
> >>
> > Yep. NIO is event driven, so the I/O selector will trigger an event if a
> > channel gets closed by the other side
> >
> > Oleg
> >
> > PS: I'm off to bed. Wife is angry.
> >
> > On 6/21/08, Quintin Beukes <quintin@...> wrote:
> >>
> >>> Hey,
> >>>
> >>> So.. keepalive is sort of useless then? Because I realised what my
> >>> problem
> >>> is. It wasn't synchronization. It was because connections closed by the
> >>> server, and then it fails when I try to re-use the connection.
> >>>
> >>> Basically what I have is this:
> >>> I try once, if receiving a NoResponse exception, I remove it from the
> >>> pool
> >>> and try again
> >>> If second try fails as well, it gets removed and I try again but with an
> >>> isStale() check first.
> >>>
> >>> My problem is that these keep failing until I filtered through all
> >>> connections in the pool. In which case I start making new ones.
> >>>
> >>> How does HttpClient handle this? Or what can I do to improve this into
> >>> being more reliable (in the sense of reducing failures to a minimum).
> >>>
> >>> Q
> >>>
> >>> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> >>>
> >>>> Quintin Beukes wrote:
> >>>>
> >>>> Hey,
> >>>>>
> >>>>> Isn't isStale() supposed to be able to tell me whether the server is
> >>>>> accepting responses?
> >>>>>
> >>>>>
> >>>>> No, it is intended to test if the connection is still valid on the
> >>>> client
> >>>> side. Blocking I/O provides no good means of telling if the socket has
> >>>> been
> >>>> closed by the peer. #isStale is a work-around for the problem.
> >>>>
> >>>> Oleg
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> >>>> For additional commands, e-mail: httpclient-users-help@...
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Quintin Beukes
> >>>
> >>
> >>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> > For additional commands, e-mail: httpclient-users-help@...
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[Q Beukes]

Hey,

Basically my program works like this:

I have incoming connections. NIO or Blocking IO can be used by
configuration. Which doesn't really matter, as thread pools handle the
connections anyway, exposing the connecting client's IO as streams.

Then, inside these threads I will be doing connections out to the server.
It's basically a custom load balancer.

So, on top of all this, I have to create 2 new threads like mentioned above,
and then my existing threads will
send the request to the IO reactor, and go into pause.

With this, my event handlers will be basically set an InputStream in a
separate thread and "notify" it to continue, which makes the event handler
basically forget about it, and my threads try and consume all content
+ return.

Would this design work?

Regarding, connection management ? Would I still be able to implement all
my connection re-use logic? I noticed a ConnectionReuseStrategy, but that
won't work, because it simply returns true whether or not the connection
should be reused.

thanks,
Q

On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:

>
> On Sat, 2008-06-21 at 02:40 +0200, Quintin Beukes wrote:
> > Hey,
> >
> > Hopefully someone is still around to answer this question.
> >
> > I had a look at the NIO of HttpCore (module-nio). Specifically the
> examples.
> >
> > I noticed the client connections are done in a separate thread. Does it
> have
> > to happen in a separate thread? Do I need a thread for every "persistent"
> > connection?
>
>
> Quintin,
>
> You only need 2 threads: one for the I/O reactor and a controller thread
> to control the I/O reactor. All new connections are established on the
> I/O reactor thread.
>
>
> >
> > I assume not. I haven't had a proper look, as I'm going to bed myself
> now. I
> > just want to confirm something.
> >
> > I create the new connection by adding an object of my choice to the
> context
> > and then connecting it to an IO reactor. Here can be any number of
> > connections to any number of different hosts, and I just handle each one
> by
> > using it's attachment in the event handlers?
> >
>
>
> Yes.
>
>
> > So it's basically just set up, and everything then happens via events
> which
> > is executed in a single dedicated thread for ALL connections to ALL
> hosts?
> >
>
>
> Yes.
>
>
> Oleg
>
>
> > Q
> >
> > On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> > >
> > > Quintin Beukes wrote:
> > >
> > >> Will NIO connections work?
> > >>
> > >>
> > > Yep. NIO is event driven, so the I/O selector will trigger an event if
> a
> > > channel gets closed by the other side
> > >
> > > Oleg
> > >
> > > PS: I'm off to bed. Wife is angry.
> > >
> > > On 6/21/08, Quintin Beukes <quintin@...> wrote:
> > >>
> > >>> Hey,
> > >>>
> > >>> So.. keepalive is sort of useless then? Because I realised what my
> > >>> problem
> > >>> is. It wasn't synchronization. It was because connections closed by
> the
> > >>> server, and then it fails when I try to re-use the connection.
> > >>>
> > >>> Basically what I have is this:
> > >>> I try once, if receiving a NoResponse exception, I remove it from the
> > >>> pool
> > >>> and try again
> > >>> If second try fails as well, it gets removed and I try again but with
> an
> > >>> isStale() check first.
> > >>>
> > >>> My problem is that these keep failing until I filtered through all
> > >>> connections in the pool. In which case I start making new ones.
> > >>>
> > >>> How does HttpClient handle this? Or what can I do to improve this
> into
> > >>> being more reliable (in the sense of reducing failures to a minimum).
> > >>>
> > >>> Q
> > >>>
> > >>> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> > >>>
> > >>>> Quintin Beukes wrote:
> > >>>>
> > >>>> Hey,
> > >>>>>
> > >>>>> Isn't isStale() supposed to be able to tell me whether the server
> is
> > >>>>> accepting responses?
> > >>>>>
> > >>>>>
> > >>>>> No, it is intended to test if the connection is still valid on the
> > >>>> client
> > >>>> side. Blocking I/O provides no good means of telling if the socket
> has
> > >>>> been
> > >>>> closed by the peer. #isStale is a work-around for the problem.
> > >>>>
> > >>>> Oleg
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> > >>>> For additional commands, e-mail:
> httpclient-users-help@...
> > >>>>
> > >>>>
> > >>>>
> > >>> --
> > >>> Quintin Beukes
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> > > For additional commands, e-mail: httpclient-users-help@...
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> For additional commands, e-mail: httpclient-users-help@...
>
>

--
Quintin Beukes

[olegk]

On Sat, 2008-06-21 at 18:17 +0200, Quintin Beukes wrote:
> Hey,
>
> Basically my program works like this:
>
> I have incoming connections. NIO or Blocking IO can be used by
> configuration. Which doesn't really matter, as thread pools handle the
> connections anyway, exposing the connecting client's IO as streams.
>

>From my personal experience classic I/O and NIO models are completely
different and both serve to solve different kind of problems. They do
not quite mix. Stick to the classic I/O because it is simpler unless you
are absolutely sure your application needs ability to handle HTTP
requests / responses asynchronously.

> Then, inside these threads I will be doing connections out to the server.
> It's basically a custom load balancer.
>
> So, on top of all this, I have to create 2 new threads like mentioned above,
> and then my existing threads will
> send the request to the IO reactor, and go into pause.
>
> With this, my event handlers will be basically set an InputStream in a
> separate thread and "notify" it to continue, which makes the event handler
> basically forget about it, and my threads try and consume all content
> + return.
>
> Would this design work?
>

What are the functional requirements you are trying to fulfill? What is
it exactly you are trying to achieve?

> Regarding, connection management ? Would I still be able to implement all
> my connection re-use logic? I noticed a ConnectionReuseStrategy, but that
> won't work, because it simply returns true whether or not the connection
> should be reused.
>

Why would you need anything else? A connection is either re-usable or
not?

Oleg

> thanks,
> Q
>
> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> >
> > On Sat, 2008-06-21 at 02:40 +0200, Quintin Beukes wrote:
> > > Hey,
> > >
> > > Hopefully someone is still around to answer this question.
> > >
> > > I had a look at the NIO of HttpCore (module-nio). Specifically the
> > examples.
> > >
> > > I noticed the client connections are done in a separate thread. Does it
> > have
> > > to happen in a separate thread? Do I need a thread for every "persistent"
> > > connection?
> >
> >
> > Quintin,
> >
> > You only need 2 threads: one for the I/O reactor and a controller thread
> > to control the I/O reactor. All new connections are established on the
> > I/O reactor thread.
> >
> >
> > >
> > > I assume not. I haven't had a proper look, as I'm going to bed myself
> > now. I
> > > just want to confirm something.
> > >
> > > I create the new connection by adding an object of my choice to the
> > context
> > > and then connecting it to an IO reactor. Here can be any number of
> > > connections to any number of different hosts, and I just handle each one
> > by
> > > using it's attachment in the event handlers?
> > >
> >
> >
> > Yes.
> >
> >
> > > So it's basically just set up, and everything then happens via events
> > which
> > > is executed in a single dedicated thread for ALL connections to ALL
> > hosts?
> > >
> >
> >
> > Yes.
> >
> >
> > Oleg
> >
> >
> > > Q
> > >
> > > On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> > > >
> > > > Quintin Beukes wrote:
> > > >
> > > >> Will NIO connections work?
> > > >>
> > > >>
> > > > Yep. NIO is event driven, so the I/O selector will trigger an event if
> > a
> > > > channel gets closed by the other side
> > > >
> > > > Oleg
> > > >
> > > > PS: I'm off to bed. Wife is angry.
> > > >
> > > > On 6/21/08, Quintin Beukes <quintin@...> wrote:
> > > >>
> > > >>> Hey,
> > > >>>
> > > >>> So.. keepalive is sort of useless then? Because I realised what my
> > > >>> problem
> > > >>> is. It wasn't synchronization. It was because connections closed by
> > the
> > > >>> server, and then it fails when I try to re-use the connection.
> > > >>>
> > > >>> Basically what I have is this:
> > > >>> I try once, if receiving a NoResponse exception, I remove it from the
> > > >>> pool
> > > >>> and try again
> > > >>> If second try fails as well, it gets removed and I try again but with
> > an
> > > >>> isStale() check first.
> > > >>>
> > > >>> My problem is that these keep failing until I filtered through all
> > > >>> connections in the pool. In which case I start making new ones.
> > > >>>
> > > >>> How does HttpClient handle this? Or what can I do to improve this
> > into
> > > >>> being more reliable (in the sense of reducing failures to a minimum).
> > > >>>
> > > >>> Q
> > > >>>
> > > >>> On 6/21/08, Oleg Kalnichevski <olegk@...> wrote:
> > > >>>
> > > >>>> Quintin Beukes wrote:
> > > >>>>
> > > >>>> Hey,
> > > >>>>>
> > > >>>>> Isn't isStale() supposed to be able to tell me whether the server
> > is
> > > >>>>> accepting responses?
> > > >>>>>
> > > >>>>>
> > > >>>>> No, it is intended to test if the connection is still valid on the
> > > >>>> client
> > > >>>> side. Blocking I/O provides no good means of telling if the socket
> > has
> > > >>>> been
> > > >>>> closed by the peer. #isStale is a work-around for the problem.
> > > >>>>
> > > >>>> Oleg
> > > >>>>
> > > >>>>
> > ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> > > >>>> For additional commands, e-mail:
> > httpclient-users-help@...
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>> --
> > > >>> Quintin Beukes
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> > > > For additional commands, e-mail: httpclient-users-help@...
> > > >
> > > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@...
> > For additional commands, e-mail: httpclient-users-help@...
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[Q Beukes]

>
> What are the functional requirements you are trying to fulfill? What is
> it exactly you are trying to achieve?


I need to detect when a connection is open or not.

But let me draw a picture of my problem. I have a max of 20 connections.
After a period of high concurrency all these connections were opened and
added to the pool. Then a period of quiet follows and all these sockets time
out. Now the pool has 20 references to closed connections.

So I try one. The pool thinks it's still open and returns it. A NoResponse
exception is thrown. I remove it and try another one, same story.

I remove it, but this time I try with an isStale() check. The isStale()
check doesn't really help in this case, but I would like to be able to have
some check that can see if the connection is open. I figured I could write
my own isStale() check that sends a request to the server, but if NIO is
possible, it would be much nicer to have a reliable isOpen() check done
first, to avoid the overhead of making an actual request to the server.

The side effect of the above problem is that the next 20 connections fail,
since it first tries to use all those in the pool.

An alternative is to force open a new connection on the 3rd try, but I would
also like to be able to check if a connection is really open.


> Why would you need anything else? A connection is either re-usable or
> not?


We used to use a commercial load balancer, and am implementing some of it's
features into our custom one.

These are ones like reusing connections to benefit from the server's cache.
Like if a certain server just served http://somehost/logo.png, then have
that same server serve it again.

This one can be implemented in the TargetHost selection, but not ones like
configurable per host maximums. Like Host X can only have 10 open
connections, where the stronger host Y can have 20 open connections. Or if
host Z doesn't have available connections, host Y can stand in and take
over the request if certain conditions are met, and this has to update the
Heap structure for the load balancer. An example of such a condition is for
example, is this a request for a list of known static files of less than
100kbss. If these conditions aren't met, then the connection fetching should
block until one becomes available.

--
Quintin Beukes

[olegk]

Quintin Beukes wrote:

>> What are the functional requirements you are trying to fulfill? What is
>> it exactly you are trying to achieve?
>
>
> I need to detect when a connection is open or not.
>
> But let me draw a picture of my problem. I have a max of 20 connections.
> After a period of high concurrency all these connections were opened and
> added to the pool. Then a period of quiet follows and all these sockets time
> out. Now the pool has 20 references to closed connections.
>
> So I try one. The pool thinks it's still open and returns it. A NoResponse
> exception is thrown. I remove it and try another one, same story.
>
> I remove it, but this time I try with an isStale() check. The isStale()
> check doesn't really help in this case, but I would like to be able to have
> some check that can see if the connection is open. I figured I could write
> my own isStale() check that sends a request to the server, but if NIO is
> possible, it would be much nicer to have a reliable isOpen() check done
> first, to avoid the overhead of making an actual request to the server.
>
> The side effect of the above problem is that the next 20 connections fail,
> since it first tries to use all those in the pool.
>
> An alternative is to force open a new connection on the 3rd try, but I would
> also like to be able to check if a connection is really open.
>

You should not keep connections in the pool infinitely and should have
an eviction policy of some kind. For instance, close all connections
that have been idle for more than 30 sec. You could even have different
eviction settings per host, as you might want to evict connections to
less reliable hosts more aggressively

>
>> Why would you need anything else? A connection is either re-usable or
>> not?
>
>
> We used to use a commercial load balancer, and am implementing some of it's
> features into our custom one.
>
> These are ones like reusing connections to benefit from the server's cache.
> Like if a certain server just served http://somehost/logo.png, then have
> that same server serve it again.
>
> This one can be implemented in the TargetHost selection, but not ones like
> configurable per host maximums. Like Host X can only have 10 open
> connections, where the stronger host Y can have 20 open connections. Or if
> host Z doesn't have available connections, host Y can stand in and take
> over the request if certain conditions are met, and this has to update the
> Heap structure for the load balancer. An example of such a condition is for
> example, is this a request for a list of known static files of less than
> 100kbss. If these conditions aren't met, then the connection fetching should
> block until one becomes available.
>

Right, but this still does not invalidate ConnectionReuseStrategy
because it purpose is to test whether a connection is re-usable from the
HTTP protocol standpoint. If you can still implement a more
sophisticated connection re-use policy but there is no point trying to
re-use connections that are deemed non re-usable by the protocol.

Hope this helps

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[Q Beukes]

Hey,

I understand and agree to everything you said.

I made a small program (based on one of the NIO examples) to test NIO,
by minimally emulating what our program does (thread wise). Then I
made a thread pool executor to get it to run with a similar state,
executing requests at similar intervals that we usually expect to
receive at medium "busy-ness".

I then monitored netstat and noticed a new connection being opened for
each and every request. Also, the EventListener's connectionOpen() is
called after each request, which makes it obvious that connection's
aren't being reused.

I debugged the ConnectionReuseStrategy, and it does, however, return
true, which also becomes obvious with connections timing out
eventually (they weren't closed after HC was done with them).

I have not myself worked with NIO at API level, but I did attempt to
see where connection reuse is done in NIO, though I failed to find it.
I'm sure with more effort I can find it, but first I'd try and see if
there is something obvious I'm missing.

I put a cleaned up version online. This is cleanest I think I can go
to demonstrate what I'm talking about:
http://quintin.dev.junkmail.co.za/NHttpTest.java

It's very close to the basic NIO client example.

Even if I can just get the following, it should be sufficient for now:
1. Connection re-use
2. Total maximum
3. Per host maximum (like host1:8580 = 5, host2:8580 = 10)
4. Blocking when maximum is reached, until one becomes available

Q

On 6/22/08, Oleg Kalnichevski <olegk@...> wrote:

> Quintin Beukes wrote:
>
> >
> > >  What are the functional requirements you are trying to fulfill? What is
> > >  it exactly you are trying to achieve?
> > >
> >
> >
> >  I need to detect when a connection is open or not.
> >
> >  But let me draw a picture of my problem. I have a max of 20 connections.
> >  After a period of high concurrency all these connections were opened and
> >  added to the pool. Then a period of quiet follows and all these sockets time
> >  out. Now the pool has 20 references to closed connections.
> >
> >  So I try one. The pool thinks it's still open and returns it. A NoResponse
> >  exception is thrown. I remove it and try another one, same story.
> >
> >  I remove it, but this time I try with an isStale() check. The isStale()
> >  check doesn't really help in this case, but I would like to be able to have
> >  some check that can see if the connection is open. I figured I could write
> >  my own isStale() check that sends a request to the server, but if NIO is
> >  possible, it would be much nicer to have a reliable isOpen() check done
> >  first, to avoid the overhead of making an actual request to the server.
> >
> >  The side effect of the above problem is that the next 20 connections fail,
> >  since it first tries to use all those in the pool.
> >
> >  An alternative is to force open a new connection on the 3rd try, but I would
> >  also like to be able to check if a connection is really open.
> >
> >
>
>  You should not keep connections in the pool infinitely and should have an eviction policy of some kind. For instance, close all connections that have been idle for more than 30 sec. You could even have different eviction settings per host, as you might want to evict connections to less reliable hosts more aggressively
>
>
> >
> >
> > >  Why would you need anything else? A connection is either re-usable or
> > >  not?
> > >
> >
> >
> >  We used to use a commercial load balancer, and am implementing some of it's
> >  features into our custom one.
> >
> >  These are ones like reusing connections to benefit from the server's cache.
> >  Like if a certain server just served http://somehost/logo.png, then have
> >  that same server serve it again.
> >
> >  This one can be implemented in the TargetHost selection, but not ones like
> >  configurable per host maximums. Like Host X can only have 10 open
> >  connections, where the stronger host Y can have 20 open connections. Or if
> >  host Z doesn't have available connections, host Y can stand in and take
> >  over the request if certain conditions are met, and this has to update the
> >  Heap structure for the load balancer. An example of such a condition is for
> >  example, is this a request for a list of known static files of less than
> >  100kbss. If these conditions aren't met, then the connection fetching should
> >  block until one becomes available.
> >
> >
>
>  Right, but this still does not invalidate ConnectionReuseStrategy because it purpose is to test whether a connection is re-usable from the HTTP protocol standpoint. If you can still implement a more sophisticated connection re-use policy but there is no point trying to re-use connections that are deemed non re-usable by the protocol.
>
>  Hope this helps
>
>
>  Oleg
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: httpclient-users-unsubscribe@...
>  For additional commands, e-mail: httpclient-users-help@...
>
>

--
Quintin Beukes

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...