On Fri, Sep 18, 2015 at 12:08 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 17 September 2015 at 21:53, Philip Martin <philip.martin_at_wandisco.com>
> > Ivan Zhakov <ivan_at_visualsvn.com> writes:
> >> I think now is good moment to discuss whether we should merge
> >> ra-reuse-session  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
> - 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.
Received on 2015-09-18 01:50:30 CEST