You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Unico Homme <un...@apache.org> on 2012/09/26 11:52:41 UTC
Backporting bugfixes to 2.2.x
Hi all,
I'd like to backport several bugfixes that were fixed on the 2.4 branch to
the 2.2 branch. This concerns the following issues:
[JCR-3349] - The BatchMode of the ConnectionHelper doesn't work in XA
Environment
[JCR-3353] - A DeadLock can occur if an Exception is thrown while unlocking
the Journal
[JCR-3354] - The ReadWriteLock in AbstractJournal can create a Deadlock in
XA Environment
[JCR-3378] - The ConnectionHelper can return a closed Connection in
BatchMode
[JCR-3379] - XA concurrent transactions - NullPointerException
[JCR-3383] - Unclosed Resources in ConnectionHelper if ResultSet is null
[JCR-3387] - On heavy load we see occasional SQLException: closed statement:
next
[JCR-3399] - Shared ISM does not release the internal Writelock if something
unexpectedly is happening in externalUpdate
[JCR-3417] - Failed Journal lock not propagated
Also, if anyone has any other issues they want backported please let me
know so I can pick them up.
Any objections?
--
Unico
Re: Backporting bugfixes to 2.2.x
Posted by Bart van der Schans <b....@onehippo.com>.
On Thu, Sep 27, 2012 at 2:36 PM, Unico Hommes <un...@apache.org> wrote:
>
>
> On Thu, Sep 27, 2012 at 10:54 AM, Bart van der Schans
> <b....@onehippo.com> wrote:
>>
>> Hi Unico,
>>
>> On Wed, Sep 26, 2012 at 11:52 AM, Unico Homme <un...@apache.org> wrote:
>> > Hi all,
>> >
>> > I'd like to backport several bugfixes that were fixed on the 2.4 branch
>> > to
>> > the 2.2 branch. This concerns the following issues:
>> >
>> > [JCR-3349] - The BatchMode of the ConnectionHelper doesn't work in XA
>> > Environment
>> > [JCR-3353] - A DeadLock can occur if an Exception is thrown while
>> > unlocking
>> > the Journal
>> > [JCR-3354] - The ReadWriteLock in AbstractJournal can create a Deadlock
>> > in
>> > XA Environment
>> > [JCR-3378] - The ConnectionHelper can return a closed Connection in
>> > BatchMode
>> > [JCR-3379] - XA concurrent transactions - NullPointerException
>> > [JCR-3383] - Unclosed Resources in ConnectionHelper if ResultSet is null
>> > [JCR-3387] - On heavy load we see occasional SQLException: closed
>> > statement:
>> > next
>> > [JCR-3399] - Shared ISM does not release the internal Writelock if
>> > something
>> > unexpectedly is happening in externalUpdate
>> > [JCR-3417] - Failed Journal lock not propagated
>> >
>> > Also, if anyone has any other issues they want backported please let me
>> > know
>> > so I can pick them up.
>> >
>> > Any objections?
>>
>> Not at all ;-)
>>
>> Claus recently fixed some more issues related to (XA) locks which
>> might be candidates:
>>
>> JCR-3392 Combine the XA aware (Reentrant) LockImpls to prevent duplicate
>> code
>> JCR-3425 XAAwareRWLock implementation fails with IllegalStateException
>> on JBoss AS7
>
>
> I've backported these also.
>
>>
>>
>> This one might be an option:
>> JCR-3386 Adjust some default values of the BasicDataSource in the
>> ConnectionFactory
>>
>>
>> If needed I can also cut the release.
>
>
>
> That would be very welcome. I might want to look over your shoulder to get
> familiar with the process.
Great! We can do this on Monday.
Bart
Re: Backporting bugfixes to 2.2.x
Posted by Unico Hommes <un...@apache.org>.
On Thu, Sep 27, 2012 at 10:54 AM, Bart van der Schans <
b.vanderschans@onehippo.com> wrote:
> Hi Unico,
>
> On Wed, Sep 26, 2012 at 11:52 AM, Unico Homme <un...@apache.org> wrote:
> > Hi all,
> >
> > I'd like to backport several bugfixes that were fixed on the 2.4 branch
> to
> > the 2.2 branch. This concerns the following issues:
> >
> > [JCR-3349] - The BatchMode of the ConnectionHelper doesn't work in XA
> > Environment
> > [JCR-3353] - A DeadLock can occur if an Exception is thrown while
> unlocking
> > the Journal
> > [JCR-3354] - The ReadWriteLock in AbstractJournal can create a Deadlock
> in
> > XA Environment
> > [JCR-3378] - The ConnectionHelper can return a closed Connection in
> > BatchMode
> > [JCR-3379] - XA concurrent transactions - NullPointerException
> > [JCR-3383] - Unclosed Resources in ConnectionHelper if ResultSet is null
> > [JCR-3387] - On heavy load we see occasional SQLException: closed
> statement:
> > next
> > [JCR-3399] - Shared ISM does not release the internal Writelock if
> something
> > unexpectedly is happening in externalUpdate
> > [JCR-3417] - Failed Journal lock not propagated
> >
> > Also, if anyone has any other issues they want backported please let me
> know
> > so I can pick them up.
> >
> > Any objections?
>
> Not at all ;-)
>
> Claus recently fixed some more issues related to (XA) locks which
> might be candidates:
>
> JCR-3392 Combine the XA aware (Reentrant) LockImpls to prevent duplicate
> code
> JCR-3425 XAAwareRWLock implementation fails with IllegalStateException
> on JBoss AS7
>
I've backported these also.
>
> This one might be an option:
> JCR-3386 Adjust some default values of the BasicDataSource in the
> ConnectionFactory
> If needed I can also cut the release.
>
That would be very welcome. I might want to look over your shoulder to get
familiar with the process.
--
Unico
>
> Regards,
> Bart
>
Re: Backporting bugfixes to 2.2.x
Posted by Bart van der Schans <b....@onehippo.com>.
Hi Unico,
On Wed, Sep 26, 2012 at 11:52 AM, Unico Homme <un...@apache.org> wrote:
> Hi all,
>
> I'd like to backport several bugfixes that were fixed on the 2.4 branch to
> the 2.2 branch. This concerns the following issues:
>
> [JCR-3349] - The BatchMode of the ConnectionHelper doesn't work in XA
> Environment
> [JCR-3353] - A DeadLock can occur if an Exception is thrown while unlocking
> the Journal
> [JCR-3354] - The ReadWriteLock in AbstractJournal can create a Deadlock in
> XA Environment
> [JCR-3378] - The ConnectionHelper can return a closed Connection in
> BatchMode
> [JCR-3379] - XA concurrent transactions - NullPointerException
> [JCR-3383] - Unclosed Resources in ConnectionHelper if ResultSet is null
> [JCR-3387] - On heavy load we see occasional SQLException: closed statement:
> next
> [JCR-3399] - Shared ISM does not release the internal Writelock if something
> unexpectedly is happening in externalUpdate
> [JCR-3417] - Failed Journal lock not propagated
>
> Also, if anyone has any other issues they want backported please let me know
> so I can pick them up.
>
> Any objections?
Not at all ;-)
Claus recently fixed some more issues related to (XA) locks which
might be candidates:
JCR-3392 Combine the XA aware (Reentrant) LockImpls to prevent duplicate code
JCR-3425 XAAwareRWLock implementation fails with IllegalStateException
on JBoss AS7
This one might be an option:
JCR-3386 Adjust some default values of the BasicDataSource in the
ConnectionFactory
If needed I can also cut the release.
Regards,
Bart
Re: Backporting bugfixes to 2.2.x
Posted by Unico Homme <un...@apache.org>.
On Thu, Sep 27, 2012 at 10:03 AM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Thu, Sep 27, 2012 at 9:58 AM, Unico Homme <un...@apache.org> wrote:
> > That was my plan, but then I noticed that I don't seem to have the
> > permission to reopen issues. In any case, the option is not there for me.
> > That is why I started creating separate issues.
>
> It's not possible to reopen already closed (i.e. released) issues, but
> you can add edit the issue (add new fix version, etc.) and add
> comments.
>
OK, thanks for explaining. I was under the faulty impression that you
cannot commit on closed issues. I will proceed as you propose.
--
Unico
>
> BR,
>
> Jukka Zitting
>
Re: Backporting bugfixes to 2.2.x
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 27, 2012 at 9:58 AM, Unico Homme <un...@apache.org> wrote:
> That was my plan, but then I noticed that I don't seem to have the
> permission to reopen issues. In any case, the option is not there for me.
> That is why I started creating separate issues.
It's not possible to reopen already closed (i.e. released) issues, but
you can add edit the issue (add new fix version, etc.) and add
comments.
BR,
Jukka Zitting
Re: Backporting bugfixes to 2.2.x
Posted by Unico Homme <un...@apache.org>.
On Thu, Sep 27, 2012 at 9:52 AM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Wed, Sep 26, 2012 at 11:52 AM, Unico Homme <un...@apache.org> wrote:
> > I'd like to backport several bugfixes that were fixed on the 2.4 branch
> to
> > the 2.2 branch. This concerns the following issues:
>
> Sounds good. Cutting a 2.2.13 release once all the fixes are in would
> be useful. Do you want to try cutting the release?
>
Yes, I'd like to try my hand at that.
>
> Note that when backporting fixes, we've normally used the already
> existing (resolved/closed) issue for that. So instead of opening new
> issues for the backports, it's better if you just label the relevant
> commits with the existing issue for that fix and then _edit_ the issue
> to add the 2.2.13 fix version in addition to the existing fix
> versions.
That was my plan, but then I noticed that I don't seem to have the
permission to reopen issues. In any case, the option is not there for me.
That is why I started creating separate issues.
--
Unico
> For completeness I often also add a comment like "Backported
> to the x.y branch in revision n" when adding the new fix version.
>
> BR,
>
> Jukka Zitting
>
Re: Backporting bugfixes to 2.2.x
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Sep 26, 2012 at 11:52 AM, Unico Homme <un...@apache.org> wrote:
> I'd like to backport several bugfixes that were fixed on the 2.4 branch to
> the 2.2 branch. This concerns the following issues:
Sounds good. Cutting a 2.2.13 release once all the fixes are in would
be useful. Do you want to try cutting the release?
Note that when backporting fixes, we've normally used the already
existing (resolved/closed) issue for that. So instead of opening new
issues for the backports, it's better if you just label the relevant
commits with the existing issue for that fix and then _edit_ the issue
to add the 2.2.13 fix version in addition to the existing fix
versions. For completeness I often also add a comment like "Backported
to the x.y branch in revision n" when adding the new fix version.
BR,
Jukka Zitting