On 19 September 2015 at 11:58, Ivan Zhakov <i...@visualsvn.com> wrote: > On 18 September 2015 at 10:43, Markus Schaber <m.scha...@codesys.com> wrote: >> Hi, >> >> Von: Ivan Zhakov [mailto:i...@visualsvn.com] >>> On 17 September 2015 at 21:53, Philip Martin <philip.mar...@wandisco.com> >>> wrote: >>> > Ivan Zhakov <i...@visualsvn.com> 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 I meant "'stat' should not be used". > 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
