asynch websocket, how to timeout?

[Eric Covener <co...@gmail.com>]

There is a deficiency in the asynch websocket stuff in trunk.

For background, the websockets proxy acts like mod_proxy_connect after
the initial setup.  It can ask event to watch both sockets for it and
return SUSPENDED.

But there is no separate timeout if neither end sees activity, so the
request can stretch out a long time.

My only idea here is:

Fire off some separate timer event at a relatively long interval to
see if the pair of sockets has been idle for a very long time (it
would have the same baton as the other callback)

Optionally, the timer event could be cancelled when the socket
callback fires -- we would need to add a way to cancel those events.

Otherwise, it would just try to grab the invoke mutex then check to
see when the last socket activity was.

Anybody have better ideas?


-- 
Eric Covener
covener@gmail.com

Re: asynch websocket, how to timeout?

[Jim Jagielski <ji...@jaguNET.com>]

+1... 
On Feb 18, 2014, at 9:29 AM, Eric Covener <co...@gmail.com> wrote:

> I think this needs to be handled as 1 API within event, taking the
> existing API and adding a timeout, rather than having the caller
> register separate timed callbacks.
> 
> This way, event can mark the timeout as no longer needed before
> pushing the first event to the worker.  This way there's no question
> about the timers and callbacks running in different orders.
> 
> When we are pulling timer events off the timer list, we can just
> ignore ones that are no longer needed.  The ignore flag can be set w/o
> the lock rather than trying to fish it out of the list.
> 
> On Sat, Feb 15, 2014 at 1:45 PM, Eric Covener <co...@gmail.com> wrote:
>> There is a deficiency in the asynch websocket stuff in trunk.
>> 
>> For background, the websockets proxy acts like mod_proxy_connect after
>> the initial setup.  It can ask event to watch both sockets for it and
>> return SUSPENDED.
>> 
>> But there is no separate timeout if neither end sees activity, so the
>> request can stretch out a long time.
>> 
>> My only idea here is:
>> 
>> Fire off some separate timer event at a relatively long interval to
>> see if the pair of sockets has been idle for a very long time (it
>> would have the same baton as the other callback)
>> 
>> Optionally, the timer event could be cancelled when the socket
>> callback fires -- we would need to add a way to cancel those events.
>> 
>> Otherwise, it would just try to grab the invoke mutex then check to
>> see when the last socket activity was.
>> 
>> Anybody have better ideas?
>> 
>> 
>> --
>> Eric Covener
>> covener@gmail.com
> 
> 
> 
> -- 
> Eric Covener
> covener@gmail.com
> 

Re: asynch websocket, how to timeout?

[Eric Covener <co...@gmail.com>]

I think this needs to be handled as 1 API within event, taking the
existing API and adding a timeout, rather than having the caller
register separate timed callbacks.

This way, event can mark the timeout as no longer needed before
pushing the first event to the worker.  This way there's no question
about the timers and callbacks running in different orders.

When we are pulling timer events off the timer list, we can just
ignore ones that are no longer needed.  The ignore flag can be set w/o
the lock rather than trying to fish it out of the list.

On Sat, Feb 15, 2014 at 1:45 PM, Eric Covener <co...@gmail.com> wrote:
> There is a deficiency in the asynch websocket stuff in trunk.
>
> For background, the websockets proxy acts like mod_proxy_connect after
> the initial setup.  It can ask event to watch both sockets for it and
> return SUSPENDED.
>
> But there is no separate timeout if neither end sees activity, so the
> request can stretch out a long time.
>
> My only idea here is:
>
> Fire off some separate timer event at a relatively long interval to
> see if the pair of sockets has been idle for a very long time (it
> would have the same baton as the other callback)
>
> Optionally, the timer event could be cancelled when the socket
> callback fires -- we would need to add a way to cancel those events.
>
> Otherwise, it would just try to grab the invoke mutex then check to
> see when the last socket activity was.
>
> Anybody have better ideas?
>
>
> --
> Eric Covener
> covener@gmail.com



-- 
Eric Covener
covener@gmail.com