On 19 September 2015 at 11:58, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 18 September 2015 at 10:43, Markus Schaber <m.schaber_at_codesys.com> wrote:
>> Hi,
>>
>> Von: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>>> On 17 September 2015 at 21:53, Philip Martin <philip.martin_at_wandisco.com>
>>> wrote:
>>> > Ivan Zhakov <ivan_at_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
Received on 2015-09-19 12:10:30 CEST