Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Peter Crowther wrote: > [Long email, some comments, some ideas. It's not *quite* rambling > enough to split into separate social and technical responses.] > > >>From: Tony Hoyle [mailto:tmh at nodomain.org] >>It'll keep runnning regardless - each client gets their own process. > > > Sure. But Pat has reported 800+ failed clients, each lingering and > consuming swap space. Sooner or later, the machine falls over with its > swap full. To me, that's not keeping running regardless. If there is that kind of problem, it needs to be fixed. Perhaps by trying a different version. The problem is there is now way of knowing the state of the repository after a crash - if you have 800 of them then that could easily be 800 partial commits. At the very least attempting to isolate the cause on a sandboxed client/server setup is a good idea - if only to find a temporary workaround. > Uh... Tony, I hate to say this, but I feel that's rather controlling on > your part. If I'm providing a piece of software, I want it to be > flexible enough that my users can do what they need with it. This may > include disabling the crashdump on CVSNT if, for example, they have > already sent you a crashdump and you are in the process of debugging it > and releasing one of your timely fixed versions. Using technology to > try to solve a social problem is, in my humble opinion, a mistake. Even > if the default configuration remains unchanged, I'd argue (OK, I'm > arguing :-) ) that there should be alternatives for those users for whom > the default isn't appropriate. A crash is a not a social problem! Getting adequate feedback sometimes is, but I get enough usuallly to diagnose problems - largely because of the crash dialog. Before I had that I'd have to rely on verbal descriptions of the problem in most cases, and it took a lot longer to fix things (I still get that occasionally, eg. with the rename problem which doesn't crash, so I have no way of repeating it or finding out what's wrong). > Indeed. In which case, that particular organisation can't use that > particular notification mechanism - tough. Sorry, I wasn't sufficiently > clear in my original message: I'm not suggesting that email replaces the > existing dialog, merely that it's an alternative for those who run the > server lights-out. On balance I prefer the HTTP PUT idea.. I've already put something like this in for 2.0.59. > Hmm. I get worried by passive sentences like that. Who is it needed > by? Turn that sentence round: 'Without the dialog, <x> needs a way of > notifying the user that is intrusive and annoying enough that they do > something about it (like send me the crashdump, post on the mailing list > or whatever).' Who is <x>? What human or organisational stakeholder in > CVSNT has that requirement? Usually, whoever is in charge of monitoring it. In most cases problems as serious as a crash will be found very quickly after install - probably before the repository goes live. > Thinking aloud here. Application event log? If the process can't get > to that, its authentication is probably sufficiently screwy that it > can't get to filestore either. A fair amount of stuff already gets written there. It probably needs a bit more, though. > It's probably done the API equivalent of 'limit coredumpsize 0'. Your > process should be able to re-enable them via one API call to do with > resource limits - sorry, I'm not near enough to my Linux boxes to give > you the requisite call, but it's the same as the shell 'unlimit > coredumpsize'. I've tried that one (setrlimit) and it didn't work for some reason. It's something I'll probably need to revisit at some point. >>it seems to work well enough. > > > I disagree, for the reasons outlined above. From my point of view I get the dumps, and stuff gets fixed - plus over time the number of dumps has decreased (when I first enabled it I was getting several a day...) which means it's helping to improve stability. Getting some automatic stats would help though, and I'm planning on that for the next version. Tony