On Fri, Sep 18, 2015 at 12:08 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> 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. > +1 to merge for dogfooding. I have not looked at the branch but I'm +1 on the general concept. So, let's start looking for the real issues now simply by using it ... > >> 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. > My 2 cents: I wonder whether 5 minutes are a good default or whether 0.5 .. 1 minute wouldn't be a better one. A lower value allows for faster recovery from intermittent failures. The typical use-cases for this feature are c/o with many svn:externals and interactive GUIs like TSVN's repo browser. Both should be fine with timeouts of about 1 minute. But this is just a small point that sprang to my attention and I don't feel like we need to have a discussion on this topic right now. -- Stefan^2.
