I'm up for some (more) debugging to try to track down the large attachments problem. This is a fairly busy week, but I am free all day Wednesday if that works. I'm also setting up a local FreeBSD machine to try it out myself, but Windows Hyper-V is giving some problems.
Nick On 14 March 2014 18:57, Dave Cottlehuber <d...@jsonified.com> wrote: > On 14 March 2014 14:53, Benoit Chesneau <bchesn...@gmail.com> wrote: > > On Wed, Mar 5, 2014 at 12:24 PM, Klaus Trainer <klaus_trai...@posteo.de> > wrote: > >> On 03/05/2014 11:06 AM, Andy Wenk wrote: > >>> * I tested against master 5989bb324a and all tests pass > >>> * I tested against 1986-fix-ibrowse-infinite-async-timeout b35884580 > >>> and ./test/etap/200-view-group-no-db-leaks.t fails > >>> * rerun with the last one results also in the same error > >>> * I tested against 1.6 branch and 04-replication-large-atts.t fails > >> > >> Does anybody have an idea about what change that is in master but not in > >> the 1.6 branch could make 04-replication-large-atts.t not fail anymore? > >> > > > > > > did you figured? > > > > Also what is the status of this release? > > > > - benoit > > FWIW I still get the replication failures on FreeBSD + master, even if > we sprinkle in the various possible fixes out there. > > I'm concerned that there's some underlying issue that is worse on > FreeBSD but still exists on other platforms -- one of the symptoms is > an exploding RSS memory set during replication. > > If somebody feels like doing some peer debugging next week we might be > able to track this down. > > Worth noting, master works for me fine on OSX but not 1.6. > > I propose to the illustrious Release Manager (Long May They Reign) to > dump the 1.6.x branch unceremoniously & cut a new one from current > master, assuming Fauxton etc are able to work with this? > > A+ > Dave >
