On 18 September 2015 at 10:43, Markus Schaber <[email protected]> wrote: > Hi, > > Von: Ivan Zhakov [mailto:[email protected]] >> On 17 September 2015 at 21:53, Philip Martin <[email protected]> >> wrote: >> > Ivan Zhakov <[email protected]> writes: >> > >> >> I think now is good moment to discuss whether we should merge >> >> ra-reuse-session [1] branch to trunk or not: it's better to merge >> >> such branch in the beginning of release cycle, to have more time to >> >> test and dogfood. >> > >> > +1 to merge. >> > >> >> Cons: >> >> - In makes behavior less stable. RA session pool doesn't reuse >> >> sessions that was unused for some time to avoid timeout issues >> >> - There is the chance that we will try to reuse 'broken' RA session >> >> due the bug and operation will fail >> > >> > Do you have a plan to fix this? >> I don't have specific to fix bug that didn't happen. But if we got one we >> have two directions: >> - Do not release RA session back to pool in specific case where we get it >> broken >> - Make RA session more resilent to errors. There is no reason why ra_svn >> cannot reconnect after TCP connection times out or something. >> >> > Detect the error from a broken RA >> > session and create another? Track the time when the session was last >> > used? Something else? >> > >> Current implementation tracks last time when session was used and do not >> reuse RA sessions that was inactive for 5 minutes. > > I created some of my own session reuse logic for the SharpSVN > "SvnRemoteSession" > which is a wrapper around the RA sessions. For "connectionless" sessions like > http(s), > I just reuse them, while for "connection" sessions (svn:// and especially > svn+ssh://), is > end a small "ping" in form of an "stat" request to validate that the session > is still > active. This gives me a high reliability, and a huge speedup over creating a > new > session (especially for ssh connections), but still have the guarantee that I > won't > hand out sessions which are totally broken. > > Maybe some similar scheme can be used here, possibly with a small time period > after last successful usage where the revalidation may be skipped. > Interesting proposal, but I think should not be used for validating since it may generate false authorization log records. I also think we should skip revalidation if session was inactive for short period: otherwise we end up with optimizing obtaining/releasing sessions to save revalidation round-trip.
The best option would be incorporate all this logic to RA session itself: RA session knows all internal details and may issue OPTIONS request for example to validate connection state and open new connection on error. But I think all of this can be implemented in trunk. -- Ivan Zhakov
