[Paperclips-discuss] ideal timeout values for persistent connection

[Nic Ferrier]

I've been thinking about how to manage persistent connections better.

Current HEAD contains code that handles persistent-cons by using
socket timeouts. This seems to work well and I thought about adding a
config option for timeout values so people could configure Paperclips
to a timeout value that matched the number of threads they use.

However, that means people understanding the subtle relationships
between threads and sockets and all that jazz. These things are
complex and so people easily get it wrong. That can cause people to
develop a false perception of Paperclips.

And anyway, what sort of advice can I give people about timeout
values? it's just too complex a subject to cover without detailed
knowledge of the application and hosting environment.

So are there any other was to manage timeouts?

I found this:

http://www8.org/w8-papers/5c-protocols/policies/policies.html

This paper points out there are 3 ways of managing persistent
connections:

1. use a static timeout
2. use heuristics to work out a timeout during connection life
3. use a cache of connections, reuse them (timeout old connections)
when the cache is fully utilized.

There's some interesting commentary and stats.

As far as including these things in Paperclips goes I think #2 is
probably the best option.

#3 seems, at first, easiest to implement but in fact it turns out
that it would require significant change to the way that the
socket-server works. Since socket-server is meant to be generic (I'm
using it for an IMAP server for example) hacking it to support an HTTP
feature would be a bad idea.

For those of you who are interested the problem with a cache system
would be that the connection handler would have to notify the
socket-server Server when it had finished performing io. The Server
would then have to index the handler in some way so it could easily
find the least used handler.

Such a system would be a nonsense under any protocol but HTTP.


#2 is promising because it tested best. It also leaves timeouts
completly to the protocol implementation which is a good thing.

I'll be looking at implementing it (as an option) over the next few
days. If anyone has any bright ideas I'd love to hear them.


Nic

BTW I'm also continuing to think about how Paperclips might utilize
non-blocking io. I think I'm getting somewhere with this so I'll post
something about it in the next few days.