On 30 December 2014 at 17:29, Stefan Fuhrmann
<stefan.fuhrmann_at_wandisco.com> wrote:
> n Tue, Dec 30, 2014 at 2:03 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>
>> On 29 December 2014 at 17:39, Stefan Fuhrmann
>> <stefan.fuhrmann_at_wandisco.com> wrote:
>> > On Mon, Dec 29, 2014 at 1:46 PM, Evgeny Kotkov
>> > <evgeny.kotkov_at_visualsvn.com>
>> > wrote:
>> >>
>> >> Stefan Fuhrmann <stefan2_at_apache.org> writes:
>> >>
>> [...]
>> >>
>> >> libsvn_fs-1.dll!get_node_revision_body()
>> >> libsvn_fs-1.dll!svn_fs_fs__dag_get_node()
>> >> libsvn_fs-1.dll!open_path()
>> >> libsvn_fs-1.dll!svn_fs_fs__node_id()
>> >> libsvn_fs-1.dll!svn_fs_fs__check_path()
>> >> mod_dav_svn.so!prep_regular()
>> >> mod_dav_svn.so!get_resource()
>> >> mod_dav.so!dav_get_resource()
>> >> mod_dav.so!dav_method_get()
>> >> ...
>> >>
>> >> Given the above, I am -1 on doing this. Please revert this change and
>> >> other
>> >> related changes that were supposed to fix the problem.
>> >
>> >
>> > I will keep the added sub-pools in place for now. The problems
>> > they cause now will always occur when we move code to the
>> > two-pool paradigm. The DAG cache issue is simply the trigger
>> > to tighten our pool usage in FSFS.
>> >
>> Stefan,
>>
>> Do I understand correctly that you're basically going to ignore this veto?
>
>
> No.
Thanks for reverting these changes!
> I had simply hoped that my explanations would give
> you or Evgeny pause to actually review the changes and
> find the spot where the wrong pool was used - something
> like the one that r1648272 fixed. If that could not be found
> within a few days, I had of course reverted the changes.
>
> But apparently no review is going to happen.
> Back to old bad normal in r1648532.
Just to make things clear. The thorough review was already provided.
In short, subpools are not a solution for the root cause of the
problem being discussed.
--
Ivan Zhakov
Received on 2014-12-30 16:36:14 CET