Ok. I'll try that.
> -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 15, 2004 7:04 PM > To: Slide Developers Mailing List > Subject: Re: New feature for internally repeating conflicting requests > > > It should not deadlock when you have sequential-mode as > "full" turned on. That's the way to go for 2.1... > > Oliver > > > On Wed, 15 Dec 2004 13:34:22 -0800, Warwick Burrows > <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
