On Wed, Aug 7, 2013 at 4:15 PM, Roderich Schupp
> Actually I think that your worst case scenario should be illegal
> and that Apache should close a connection when the user changes
> between requests.
I disagree that this sort of scenario should be disallowed. It's a
fundamental feature of HTTP that each request is independent. I
realize it's horribly inconvenient for us that HTTP is stateless, but
it's the reality.
On Thu, Aug 8, 2013 at 5:41 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> I don't see problem here: in worst scenario cache size would same as
> authorization file. So even for large authorization files memory usage
> will be limited.
Yes I realize it's not entirely unbounded.
It's my opinion that caches should always have bounds outside of just
the source data.
It is much better to limit the cache and then run slower in these rare
circumstances than it is to simply fail entirely due to out of memory
> Other approaches are:
> 1. use svn_cache__t object to store cached values
I think this is the route you have to go if you want to set limits.
I'm not sure how reasonable it is to keep only doing per-connection
caches with this though. Caching beyond the connection means you have
to start dealing with cache invalidation from changes to the conf
> 2. Factor out configuration file parser and store authorization
> settings in our own hash table with interesting cached values.
I tend to think there's a lot bigger savings from this because the
config parser is certainly not storing things in a way that is optimal
for an authz system.
Received on 2013-08-08 21:05:37 CEST