I agree with you about new features and 2.1. Unfortunately my company can't go into QA or production with -911 errors failing our transactions so I will just have to keep any changes I make to fix this problem with 2.1 in my own sandbox and won't submit them back unless they apply to the HEAD. Then I will have to wait until 2.2 before I can sync my tree up with CVS again. And if that's the way it has to be then I'm fine with that.
My concern is that the Slide 2.1 release is not suitable for any scenarios where load is important while this problem is outstanding in the 2.1 tree. Though I agree your solution is a feature, it could also be considered as a bug fix since Slide returns a 500 error when it gets this exception and applications don't have a way to deal with that. Warwick > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 15, 2004 10:59 AM > To: Slide Developers Mailing List > Subject: Re: New feature for internally repeating conflicting requests > > > On Wed, 15 Dec 2004 17:07:26 +0100, Oliver Zeigermann > <[EMAIL PROTECTED]> wrote: > > On Wed, 15 Dec 2004 16:55:58 +0100, Oliver Zeigermann > > <[EMAIL PROTECTED]> wrote: > > > On Tue, 14 Dec 2004 17:52:02 -0800, Warwick Burrows > > > <[EMAIL PROTECTED]> wrote: > > > > > > A real problem is that the ConcurrencyConflictException > > > > > doesn't make > > > > > > it past LockMethod when it bubbles up from the store. In > > > > > > LockMethod its caught in a generic Exception catch block at > > > > > > line 368 and converted into a WebdavException. This > may happen > > > > > > in other methods too. Had you looked at all > > > > > > > > > > Have you considered this: > > > > > > > > > > public class ConcurrencyConflictException extends > > > > > /* > > > > > * XXX: this must be an error to ensure it > gets caught > > > > > in the webdav > > > > > * layer only > > > > > */Error { > > > > > > > > > > Line 368 catches an Exception, not an Error, that's > the trick ;) > > > > > > > > And it would be great except that AbstractStore.java catches > > > > "throwables" including Errors and is wrapping the Error > inside a > > > > ServiceAccessException which is then thrown back to LockMethod. > > > > > > Argh! You are right! I was only provoking to throw this exception > > > from the core. I'd say the problem is in AbstractStore, > it certainly > > > should not catch errors... > > > > > > > I need to fix this concurrency issue in Slide so we can go into > > > > our QA load test phase next week :-) I was trying to work back > > > > from the changes you had made to AbstractWebdavMethod > and the db > > > > stores for this retry feature but really need a list of > the files > > > > you changed so I can merge them back into our 2.1 > source tree. I > > > > don't have the submission logs for the defects you > submitted for > > > > this feature. > > > > > > We not go for CVS head then? > > > > One more reason for you to stick to the CVS head for new > features is > > shown by this issue. There will be no support for this > retry feature > > in 2.1 and it isn't even alpha, yet (as we have seen). It needs to > > evolve and mature with a full 2.2 release cycle. > > Still another example of the worth of community based open > development. I implement a new feature in the open, others > contribute like you and finally it gets going. So, do not > create your own branch... > > Oliver > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
