You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2012/05/20 20:37:41 UTC
APR/native and per socket timeouts.
Currently, time outs for APR/native sockets are managed at the Pollset
level. This means all sockets in a single Pollset must have the same
time out. This is starting to become a nuisance.
I have already had to add a second Pollset to AprEndpoint to handle
separate connection and keep-alive time outs. Now I need to be able to
handle infinite time outs for WebSocket and I do not want to have to add
a third Pollset.
Therefore, I intend modifying the APR/native code to support per socket
time outs. I would be grateful if those of you with more C knowledge
than I (which is most people on this list) could:
a) tell me now if this is a crazy idea (and why)
b) keep an extra close eye on any commit of mine that touches the C code.
I intend to retain backwards compatibility so newer versions of the
native connector will work with older Tomcat versions but Tomcat 7 will
have a new minimum native version so that this feature is available.
This means that the next Tomcat 7 release is likely to have to wait for
the next native release.
Looking at the code so far, I am likely to start with some renaming to
clarify the current code before actually changing anything functional.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Mark Thomas <ma...@apache.org>.
On 20/05/2012 19:44, Henri Gomez wrote:
> Did there is a need to have sockets with differents timeout in day to day case ?
So far, no. The requirements could be met by three pollsets. One for new
connections, one for keep-alive connections and one for WebSocket
connections.
My concern is that this approach is not sustainable. I don't yet know
what requirements may emerge from the Servlet 3.1 or WebSocket EGs. Even
if no new requirements emerge, a per socket time out would be simpler to
work with, consistent with BIO and NIO and may allow for further
refactoring to deduplicate code.
This is based on my current understanding of the native code which is
that adding a per socket time out is relatively simple. I could be
wrong. If I am wrong, three pollsets is my fall back plan.
Mark
>
> For example did it is required by specs or API ?
>
> The finer, the better but only if there is a real need :-)
>
> Btw, i'll take a look to your commits.
>
> Le 20 mai 2012 à 20:37, Mark Thomas <ma...@apache.org> a écrit :
>
>> Currently, time outs for APR/native sockets are managed at the Pollset
>> level. This means all sockets in a single Pollset must have the same
>> time out. This is starting to become a nuisance.
>>
>> I have already had to add a second Pollset to AprEndpoint to handle
>> separate connection and keep-alive time outs. Now I need to be able to
>> handle infinite time outs for WebSocket and I do not want to have to add
>> a third Pollset.
>>
>> Therefore, I intend modifying the APR/native code to support per socket
>> time outs. I would be grateful if those of you with more C knowledge
>> than I (which is most people on this list) could:
>> a) tell me now if this is a crazy idea (and why)
>> b) keep an extra close eye on any commit of mine that touches the C code.
>>
>> I intend to retain backwards compatibility so newer versions of the
>> native connector will work with older Tomcat versions but Tomcat 7 will
>> have a new minimum native version so that this feature is available.
>> This means that the next Tomcat 7 release is likely to have to wait for
>> the next native release.
>>
>> Looking at the code so far, I am likely to start with some renaming to
>> clarify the current code before actually changing anything functional.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Henri Gomez <he...@gmail.com>.
Did there is a need to have sockets with differents timeout in day to day case ?
For example did it is required by specs or API ?
The finer, the better but only if there is a real need :-)
Btw, i'll take a look to your commits.
Le 20 mai 2012 à 20:37, Mark Thomas <ma...@apache.org> a écrit :
> Currently, time outs for APR/native sockets are managed at the Pollset
> level. This means all sockets in a single Pollset must have the same
> time out. This is starting to become a nuisance.
>
> I have already had to add a second Pollset to AprEndpoint to handle
> separate connection and keep-alive time outs. Now I need to be able to
> handle infinite time outs for WebSocket and I do not want to have to add
> a third Pollset.
>
> Therefore, I intend modifying the APR/native code to support per socket
> time outs. I would be grateful if those of you with more C knowledge
> than I (which is most people on this list) could:
> a) tell me now if this is a crazy idea (and why)
> b) keep an extra close eye on any commit of mine that touches the C code.
>
> I intend to retain backwards compatibility so newer versions of the
> native connector will work with older Tomcat versions but Tomcat 7 will
> have a new minimum native version so that this feature is available.
> This means that the next Tomcat 7 release is likely to have to wait for
> the next native release.
>
> Looking at the code so far, I am likely to start with some renaming to
> clarify the current code before actually changing anything functional.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Mladen Turk <mt...@apache.org>.
On 05/21/2012 02:55 PM, Mark Thomas wrote:
> On 20/05/2012 21:47, Mladen Turk wrote:
>> On 05/20/2012 08:37 PM, Mark Thomas wrote:
>>> Therefore, I intend modifying the APR/native code to support per socket
>>> time outs. I would be grateful if those of you with more C knowledge
>>> than I (which is most people on this list) could:
>>> a) tell me now if this is a crazy idea (and why)
>>> b) keep an extra close eye on any commit of mine that touches the C code.
>>>
>>
>> This should be easy to implement.
>> Inside native we track socket_ttl for each socket.
>> Currently when socket is added it's set to apr_time_now()
>> and later compared with max_ttl (usually keepAliveTimeout).
>>
>> We can add new API that would add socket with timeout relative
>> to max_ttl. A bit awkward but wouldn't create backward incompatibility.
>>
>> Take a look at poll.c add function.
>> The new addt would have additional timeout parameter and
>> you would set:
>> ...
>> if (p->max_ttl> 0)
>> p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout);
>> ...
>>
>> Now that new timeout param would actually be called as
>> Poll.add(pollset, socket, events, perSocketPollTimeout - keepAliveTimeout);
>> given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout);
>>
>> So effectively socket_ttl would become 'now() - ttlOffset'
>
> Thanks for confirming I am heading in the right direction with this. I'm
> hesitant to follow exactly the path above. While it is a minimal change
> from the current code, I think it could be difficult for folks new to
> the code to figure out what is going on.
>
The easier solution would be to use the math inside native
by providing a desired perSocketTimeout and internally substracting from
pollset's ttl. In that case pollset's ttl can be almost anything (well as long
it's not zero which means disabled)
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Costin Manolache <co...@gmail.com>.
On Mon, May 21, 2012 at 12:16 PM, Mladen Turk <mt...@apache.org> wrote:
> On 05/21/2012 08:01 PM, Costin Manolache wrote:
>
>> On Mon, May 21, 2012 at 10:48 AM, Mark Thomas<ma...@apache.org> wrote:
>>
>>
>> My point was that you don't need to change anything in native.
>>
>> Leave APR as it is - just use '0' as timeout for the websocket sockets (
>> or
>> any scoket that needs arbitrary timeout ). That will disable the
>> processing
>> in maintain - and java side can do the expiration.
>>
>> No compilation headaches - the only downside is that the actual expiration
>> may happen a bit later.
>>
>>
> This approach would be bad for performance.
> The reason why I put the maintenance inside native is to
> lower down the number of JNI calls.
>
> If you do it in java for each socket, then you will have to
> inform the poller to remove each expired from the native pollset.
> This mean N*sockets extra JNI calls.
>
> If you look at the implementation I return array of all expired sockets
> at once, meaning 1 JNI call.
>
You could send an array of sockets to close and get the same 1 JNI call
if performance is the main reason.
My point is that you can implement per-socket timeout with no native code
changes. If you are to make native code changes - bulk close seems a simple
change.
Costin
>
>
> Regards
> --
> ^TM
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**org<de...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: APR/native and per socket timeouts.
Posted by Mladen Turk <mt...@apache.org>.
On 05/21/2012 08:01 PM, Costin Manolache wrote:
> On Mon, May 21, 2012 at 10:48 AM, Mark Thomas<ma...@apache.org> wrote:
>
>
> My point was that you don't need to change anything in native.
>
> Leave APR as it is - just use '0' as timeout for the websocket sockets ( or
> any scoket that needs arbitrary timeout ). That will disable the processing
> in maintain - and java side can do the expiration.
>
> No compilation headaches - the only downside is that the actual expiration
> may happen a bit later.
>
This approach would be bad for performance.
The reason why I put the maintenance inside native is to
lower down the number of JNI calls.
If you do it in java for each socket, then you will have to
inform the poller to remove each expired from the native pollset.
This mean N*sockets extra JNI calls.
If you look at the implementation I return array of all expired sockets
at once, meaning 1 JNI call.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Costin Manolache <co...@gmail.com>.
On Mon, May 21, 2012 at 10:48 AM, Mark Thomas <ma...@apache.org> wrote:
> On 21/05/2012 18:30, Costin Manolache wrote:
> > On Mon, May 21, 2012 at 9:29 AM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 21/05/2012 15:26, Costin Manolache wrote:
> >>> My understanding is that the timeout is implemented in poll.c
> maintain()
> >> -
> >>> by scanning the socket list in C.
> >>>
> >>> Why not doing the same thing in java - i.e. don't touch native code,
> have
> >>> all sockets 'long', and close whenever you need from java ?
> >>
> >> The timeout is also used in poll so it wouldn't be a completely clean
> >> solution.
> >
> >
> > How is it used in poll ? The poll can be arbitrary - there is no need to
> > guarantee that sockets timeout at the exact moment, it can happen later.
> > If poll time is 1/2 hour - than if no event happens you'll check every
> 1/2
> > hour which sockets are expired.
>
> It is used to ensure that the poll does not last beyond the next
> expected time out. While I agree time out can happen later, the current
> API isn't written that way and I not happy changing something like that
> in a point release.
>
My point was that you don't need to change anything in native.
Leave APR as it is - just use '0' as timeout for the websocket sockets ( or
any scoket that needs arbitrary timeout ). That will disable the processing
in maintain - and java side can do the expiration.
No compilation headaches - the only downside is that the actual expiration
may happen a bit later.
> > The benefit of doing it in java is that you have more control - and may
> use
> > more advanced structures ( C is just a loop over the list of sockets,
> > wouldn't scale very well to 100K+ sockets - which are probably normal
> case
> > for websocket ).
>
> In the WebSocket case, the time out will be in Java. I just need the
> ability to set it to infinite without creating yet another PollSet.
> While I currently think per socket timeout is the way to go (it will
> simplify the current APR/native Poller code) I'm not wedded to the idea.
> If this doesn't work, I'm happy to look at alternatives.
>
What's the problem with creating another PollSet ?
The spdy implementation does create one ( AprSocketContext ), doesn't seem
so bad.
BTW - given the use case for web sockets, i.e. very large number of mostly
idle sockets, you may have to create multiple pollsets anyway, don't
remember what are the limits on one pollset but you probably don't want to
mix 100K idle websockets in the active http pollset.
Costin
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: APR/native and per socket timeouts.
Posted by Mark Thomas <ma...@apache.org>.
On 21/05/2012 18:30, Costin Manolache wrote:
> On Mon, May 21, 2012 at 9:29 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 21/05/2012 15:26, Costin Manolache wrote:
>>> My understanding is that the timeout is implemented in poll.c maintain()
>> -
>>> by scanning the socket list in C.
>>>
>>> Why not doing the same thing in java - i.e. don't touch native code, have
>>> all sockets 'long', and close whenever you need from java ?
>>
>> The timeout is also used in poll so it wouldn't be a completely clean
>> solution.
>
>
> How is it used in poll ? The poll can be arbitrary - there is no need to
> guarantee that sockets timeout at the exact moment, it can happen later.
> If poll time is 1/2 hour - than if no event happens you'll check every 1/2
> hour which sockets are expired.
It is used to ensure that the poll does not last beyond the next
expected time out. While I agree time out can happen later, the current
API isn't written that way and I not happy changing something like that
in a point release.
> The benefit of doing it in java is that you have more control - and may use
> more advanced structures ( C is just a loop over the list of sockets,
> wouldn't scale very well to 100K+ sockets - which are probably normal case
> for websocket ).
In the WebSocket case, the time out will be in Java. I just need the
ability to set it to infinite without creating yet another PollSet.
While I currently think per socket timeout is the way to go (it will
simplify the current APR/native Poller code) I'm not wedded to the idea.
If this doesn't work, I'm happy to look at alternatives.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Costin Manolache <co...@gmail.com>.
On Mon, May 21, 2012 at 9:29 AM, Mark Thomas <ma...@apache.org> wrote:
> On 21/05/2012 15:26, Costin Manolache wrote:
> > My understanding is that the timeout is implemented in poll.c maintain()
> -
> > by scanning the socket list in C.
> >
> > Why not doing the same thing in java - i.e. don't touch native code, have
> > all sockets 'long', and close whenever you need from java ?
>
> The timeout is also used in poll so it wouldn't be a completely clean
> solution.
How is it used in poll ? The poll can be arbitrary - there is no need to
guarantee that sockets timeout at the exact moment, it can happen later.
If poll time is 1/2 hour - than if no event happens you'll check every 1/2
hour which sockets are expired.
The benefit of doing it in java is that you have more control - and may use
more advanced structures ( C is just a loop over the list of sockets,
wouldn't scale very well to 100K+ sockets - which are probably normal case
for websocket ).
Costin
> It would probably work but there might be some odd edge cases.
> It think it is probably better - for now - to keep this in native.
>
>
> Mark
>
>
> >
> > Costin
> >
> > On Mon, May 21, 2012 at 5:55 AM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 20/05/2012 21:47, Mladen Turk wrote:
> >>> On 05/20/2012 08:37 PM, Mark Thomas wrote:
> >>>> Therefore, I intend modifying the APR/native code to support per
> socket
> >>>> time outs. I would be grateful if those of you with more C knowledge
> >>>> than I (which is most people on this list) could:
> >>>> a) tell me now if this is a crazy idea (and why)
> >>>> b) keep an extra close eye on any commit of mine that touches the C
> >> code.
> >>>>
> >>>
> >>> This should be easy to implement.
> >>> Inside native we track socket_ttl for each socket.
> >>> Currently when socket is added it's set to apr_time_now()
> >>> and later compared with max_ttl (usually keepAliveTimeout).
> >>>
> >>> We can add new API that would add socket with timeout relative
> >>> to max_ttl. A bit awkward but wouldn't create backward incompatibility.
> >>>
> >>> Take a look at poll.c add function.
> >>> The new addt would have additional timeout parameter and
> >>> you would set:
> >>> ...
> >>> if (p->max_ttl > 0)
> >>> p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout);
> >>> ...
> >>>
> >>> Now that new timeout param would actually be called as
> >>> Poll.add(pollset, socket, events, perSocketPollTimeout -
> >> keepAliveTimeout);
> >>> given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout);
> >>>
> >>> So effectively socket_ttl would become 'now() - ttlOffset'
> >>
> >> Thanks for confirming I am heading in the right direction with this. I'm
> >> hesitant to follow exactly the path above. While it is a minimal change
> >> from the current code, I think it could be difficult for folks new to
> >> the code to figure out what is going on.
> >>
> >> I'd like to see if I can come up with a change that will be more obvious
> >> on first reading. I expect it will be a little more invasive than the
> >> change you suggested. Depending on my level of confidence, I'll either
> >> post a patch or commit the change when I have something concrete.
> >>
> >> Cheers,
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: APR/native and per socket timeouts.
Posted by Mark Thomas <ma...@apache.org>.
On 21/05/2012 15:26, Costin Manolache wrote:
> My understanding is that the timeout is implemented in poll.c maintain() -
> by scanning the socket list in C.
>
> Why not doing the same thing in java - i.e. don't touch native code, have
> all sockets 'long', and close whenever you need from java ?
The timeout is also used in poll so it wouldn't be a completely clean
solution. It would probably work but there might be some odd edge cases.
It think it is probably better - for now - to keep this in native.
Mark
>
> Costin
>
> On Mon, May 21, 2012 at 5:55 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 20/05/2012 21:47, Mladen Turk wrote:
>>> On 05/20/2012 08:37 PM, Mark Thomas wrote:
>>>> Therefore, I intend modifying the APR/native code to support per socket
>>>> time outs. I would be grateful if those of you with more C knowledge
>>>> than I (which is most people on this list) could:
>>>> a) tell me now if this is a crazy idea (and why)
>>>> b) keep an extra close eye on any commit of mine that touches the C
>> code.
>>>>
>>>
>>> This should be easy to implement.
>>> Inside native we track socket_ttl for each socket.
>>> Currently when socket is added it's set to apr_time_now()
>>> and later compared with max_ttl (usually keepAliveTimeout).
>>>
>>> We can add new API that would add socket with timeout relative
>>> to max_ttl. A bit awkward but wouldn't create backward incompatibility.
>>>
>>> Take a look at poll.c add function.
>>> The new addt would have additional timeout parameter and
>>> you would set:
>>> ...
>>> if (p->max_ttl > 0)
>>> p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout);
>>> ...
>>>
>>> Now that new timeout param would actually be called as
>>> Poll.add(pollset, socket, events, perSocketPollTimeout -
>> keepAliveTimeout);
>>> given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout);
>>>
>>> So effectively socket_ttl would become 'now() - ttlOffset'
>>
>> Thanks for confirming I am heading in the right direction with this. I'm
>> hesitant to follow exactly the path above. While it is a minimal change
>> from the current code, I think it could be difficult for folks new to
>> the code to figure out what is going on.
>>
>> I'd like to see if I can come up with a change that will be more obvious
>> on first reading. I expect it will be a little more invasive than the
>> change you suggested. Depending on my level of confidence, I'll either
>> post a patch or commit the change when I have something concrete.
>>
>> Cheers,
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Costin Manolache <co...@gmail.com>.
My understanding is that the timeout is implemented in poll.c maintain() -
by scanning the socket list in C.
Why not doing the same thing in java - i.e. don't touch native code, have
all sockets 'long', and close whenever you need from java ?
Costin
On Mon, May 21, 2012 at 5:55 AM, Mark Thomas <ma...@apache.org> wrote:
> On 20/05/2012 21:47, Mladen Turk wrote:
> > On 05/20/2012 08:37 PM, Mark Thomas wrote:
> >> Therefore, I intend modifying the APR/native code to support per socket
> >> time outs. I would be grateful if those of you with more C knowledge
> >> than I (which is most people on this list) could:
> >> a) tell me now if this is a crazy idea (and why)
> >> b) keep an extra close eye on any commit of mine that touches the C
> code.
> >>
> >
> > This should be easy to implement.
> > Inside native we track socket_ttl for each socket.
> > Currently when socket is added it's set to apr_time_now()
> > and later compared with max_ttl (usually keepAliveTimeout).
> >
> > We can add new API that would add socket with timeout relative
> > to max_ttl. A bit awkward but wouldn't create backward incompatibility.
> >
> > Take a look at poll.c add function.
> > The new addt would have additional timeout parameter and
> > you would set:
> > ...
> > if (p->max_ttl > 0)
> > p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout);
> > ...
> >
> > Now that new timeout param would actually be called as
> > Poll.add(pollset, socket, events, perSocketPollTimeout -
> keepAliveTimeout);
> > given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout);
> >
> > So effectively socket_ttl would become 'now() - ttlOffset'
>
> Thanks for confirming I am heading in the right direction with this. I'm
> hesitant to follow exactly the path above. While it is a minimal change
> from the current code, I think it could be difficult for folks new to
> the code to figure out what is going on.
>
> I'd like to see if I can come up with a change that will be more obvious
> on first reading. I expect it will be a little more invasive than the
> change you suggested. Depending on my level of confidence, I'll either
> post a patch or commit the change when I have something concrete.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: APR/native and per socket timeouts.
Posted by Mark Thomas <ma...@apache.org>.
On 20/05/2012 21:47, Mladen Turk wrote:
> On 05/20/2012 08:37 PM, Mark Thomas wrote:
>> Therefore, I intend modifying the APR/native code to support per socket
>> time outs. I would be grateful if those of you with more C knowledge
>> than I (which is most people on this list) could:
>> a) tell me now if this is a crazy idea (and why)
>> b) keep an extra close eye on any commit of mine that touches the C code.
>>
>
> This should be easy to implement.
> Inside native we track socket_ttl for each socket.
> Currently when socket is added it's set to apr_time_now()
> and later compared with max_ttl (usually keepAliveTimeout).
>
> We can add new API that would add socket with timeout relative
> to max_ttl. A bit awkward but wouldn't create backward incompatibility.
>
> Take a look at poll.c add function.
> The new addt would have additional timeout parameter and
> you would set:
> ...
> if (p->max_ttl > 0)
> p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout);
> ...
>
> Now that new timeout param would actually be called as
> Poll.add(pollset, socket, events, perSocketPollTimeout - keepAliveTimeout);
> given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout);
>
> So effectively socket_ttl would become 'now() - ttlOffset'
Thanks for confirming I am heading in the right direction with this. I'm
hesitant to follow exactly the path above. While it is a minimal change
from the current code, I think it could be difficult for folks new to
the code to figure out what is going on.
I'd like to see if I can come up with a change that will be more obvious
on first reading. I expect it will be a little more invasive than the
change you suggested. Depending on my level of confidence, I'll either
post a patch or commit the change when I have something concrete.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Mladen Turk <mt...@apache.org>.
On 05/20/2012 08:37 PM, Mark Thomas wrote:
> Therefore, I intend modifying the APR/native code to support per socket
> time outs. I would be grateful if those of you with more C knowledge
> than I (which is most people on this list) could:
> a) tell me now if this is a crazy idea (and why)
> b) keep an extra close eye on any commit of mine that touches the C code.
>
This should be easy to implement.
Inside native we track socket_ttl for each socket.
Currently when socket is added it's set to apr_time_now()
and later compared with max_ttl (usually keepAliveTimeout).
We can add new API that would add socket with timeout relative
to max_ttl. A bit awkward but wouldn't create backward incompatibility.
Take a look at poll.c add function.
The new addt would have additional timeout parameter and
you would set:
...
if (p->max_ttl > 0)
p->socket_ttl[p->nelts] = apr_time_now() + J2T(timeout);
...
Now that new timeout param would actually be called as
Poll.add(pollset, socket, events, perSocketPollTimeout - keepAliveTimeout);
given that keepAliveTimeout was used for Poll.setTtl(keepAliveTimeout);
So effectively socket_ttl would become 'now() - ttlOffset'
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Henri Gomez <he...@gmail.com>.
> That is what we do currently. I'm not convinced that is a scalable long
> term solution as the number of things that need different time outs
> increases.
Main question is :
What will be the faster to handle ?
A table of pollsets and associate sockets to them (ie: 30s, 60s, 120s,
infinite) or handle timeout by sockets ?
Hard to tell without seeing code and them code in action.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Mark Thomas <ma...@apache.org>.
On 20/05/2012 19:46, Henri Gomez wrote:
> And what about using pollsets with specific timeout and associate sockets to pollset according to their timeout needs ?
That is what we do currently. I'm not convinced that is a scalable long
term solution as the number of things that need different time outs
increases.
Mark
>
> Just an idea.
>
> Le 20 mai 2012 à 20:37, Mark Thomas <ma...@apache.org> a écrit :
>
>> Currently, time outs for APR/native sockets are managed at the Pollset
>> level. This means all sockets in a single Pollset must have the same
>> time out. This is starting to become a nuisance.
>>
>> I have already had to add a second Pollset to AprEndpoint to handle
>> separate connection and keep-alive time outs. Now I need to be able to
>> handle infinite time outs for WebSocket and I do not want to have to add
>> a third Pollset.
>>
>> Therefore, I intend modifying the APR/native code to support per socket
>> time outs. I would be grateful if those of you with more C knowledge
>> than I (which is most people on this list) could:
>> a) tell me now if this is a crazy idea (and why)
>> b) keep an extra close eye on any commit of mine that touches the C code.
>>
>> I intend to retain backwards compatibility so newer versions of the
>> native connector will work with older Tomcat versions but Tomcat 7 will
>> have a new minimum native version so that this feature is available.
>> This means that the next Tomcat 7 release is likely to have to wait for
>> the next native release.
>>
>> Looking at the code so far, I am likely to start with some renaming to
>> clarify the current code before actually changing anything functional.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: APR/native and per socket timeouts.
Posted by Henri Gomez <he...@gmail.com>.
And what about using pollsets with specific timeout and associate sockets to pollset according to their timeout needs ?
Just an idea.
Le 20 mai 2012 à 20:37, Mark Thomas <ma...@apache.org> a écrit :
> Currently, time outs for APR/native sockets are managed at the Pollset
> level. This means all sockets in a single Pollset must have the same
> time out. This is starting to become a nuisance.
>
> I have already had to add a second Pollset to AprEndpoint to handle
> separate connection and keep-alive time outs. Now I need to be able to
> handle infinite time outs for WebSocket and I do not want to have to add
> a third Pollset.
>
> Therefore, I intend modifying the APR/native code to support per socket
> time outs. I would be grateful if those of you with more C knowledge
> than I (which is most people on this list) could:
> a) tell me now if this is a crazy idea (and why)
> b) keep an extra close eye on any commit of mine that touches the C code.
>
> I intend to retain backwards compatibility so newer versions of the
> native connector will work with older Tomcat versions but Tomcat 7 will
> have a new minimum native version so that this feature is available.
> This means that the next Tomcat 7 release is likely to have to wait for
> the next native release.
>
> Looking at the code so far, I am likely to start with some renaming to
> clarify the current code before actually changing anything functional.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org