On 30 December 2014 at 17:29, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> wrote: > n Tue, Dec 30, 2014 at 2:03 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> On 29 December 2014 at 17:39, Stefan Fuhrmann >> <stefan.fuhrm...@wandisco.com> wrote: >> > On Mon, Dec 29, 2014 at 1:46 PM, Evgeny Kotkov >> > <evgeny.kot...@visualsvn.com> >> > wrote: >> >> >> >> Stefan Fuhrmann <stef...@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
