M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

There are still 8 Outstanding JIRAs for M2. Can we resolve these or
bump them to the next release if that is appropriate.

Wouldn't look good to be releasing M2 with outstanding tasks against it.
-- 
Martin Ritchie

Re: M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> Martin Ritchie wrote:
> > On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> >> Robert Greig wrote:
> >>> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> >>>
> >>>> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
> >>>> port it to the branch.
> >>> OK. Are you going to merge it into the M2.1 branch?
> >> I can, but I was hoping that someone more familiar with that piece of
> >> code would have a look at it.
> >
> > I can do so I need to look over the rollback code anyway.
> > I also wanted to respond to the reject problem you raised. I remember
> > clearly needing to do the rejects for JMS. Annoyingly it has been so
> > long I don't remember the precise issue. I just remember needing to
> > adjust the Reject method to allow messages to be resent to the
> > rejecting consumer rather than a true 0_8 interpretation of reject
> > which says never send to client again. I could of course got the total
> > wrong end of the stick in what need to be done. I shall do my best to
> > find time at the weekend to look this over. I've got my new(ish) linux
> > box almost ready so might find home dev a little easier.
>
> I'd be interested in knowing more details if you remember them. FWIW
> 0-10 has a message.release that is closer to what you're using reject
> for, however I'm still not clear why it would be necessary to use in
> that manner.

Annoyingly neither do I. My recollections were around needing to cause
the message to be resent which recover didn't do but that isn't quite
right.

> --Rafael
>


-- 
Martin Ritchie

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Martin Ritchie wrote:
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>> Robert Greig wrote:
>>> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>>>
>>>> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
>>>> port it to the branch.
>>> OK. Are you going to merge it into the M2.1 branch?
>> I can, but I was hoping that someone more familiar with that piece of
>> code would have a look at it.
> 
> I can do so I need to look over the rollback code anyway.
> I also wanted to respond to the reject problem you raised. I remember
> clearly needing to do the rejects for JMS. Annoyingly it has been so
> long I don't remember the precise issue. I just remember needing to
> adjust the Reject method to allow messages to be resent to the
> rejecting consumer rather than a true 0_8 interpretation of reject
> which says never send to client again. I could of course got the total
> wrong end of the stick in what need to be done. I shall do my best to
> find time at the weekend to look this over. I've got my new(ish) linux
> box almost ready so might find home dev a little easier.

I'd be interested in knowing more details if you remember them. FWIW 
0-10 has a message.release that is closer to what you're using reject 
for, however I'm still not clear why it would be necessary to use in 
that manner.

--Rafael

Re: M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> Robert Greig wrote:
> > On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> >
> >> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
> >> port it to the branch.
> >
> > OK. Are you going to merge it into the M2.1 branch?
>
> I can, but I was hoping that someone more familiar with that piece of
> code would have a look at it.

I can do so I need to look over the rollback code anyway.
I also wanted to respond to the reject problem you raised. I remember
clearly needing to do the rejects for JMS. Annoyingly it has been so
long I don't remember the precise issue. I just remember needing to
adjust the Reject method to allow messages to be resent to the
rejecting consumer rather than a true 0_8 interpretation of reject
which says never send to client again. I could of course got the total
wrong end of the stick in what need to be done. I shall do my best to
find time at the weekend to look this over. I've got my new(ish) linux
box almost ready so might find home dev a little easier.

> --Rafael


-- 
Martin Ritchie

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Robert Greig wrote:
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> 
>> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
>> port it to the branch.
> 
> OK. Are you going to merge it into the M2.1 branch?

I can, but I was hoping that someone more familiar with that piece of 
code would have a look at it.

--Rafael

Re: M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
> On 07/09/2007, Martin Ritchie <ri...@apache.org> wrote:
>
> > Would be good if we had a think about how we are going to maintain the
> > two code lines. 0_8/0_9 and 0_10.
> >
> > svnmerge is going to get out of hand too quickly. I would like to
> > suggest that we get attach the patches to the JIRAs that way we can
> > retreive them and apply to the code.
>
> I agree with the earlier comment about just knowing the svn commit number.
>
> But the main question about managing the two code lines:
>
> I think we need to accept the the 0-8/9 codebase is going to live for
> another year. From what I understand (and correct me if I am wrong)
> the 0-10 changes are more focussed on the lower layer rather than for
> example the broker. Therefore I think that developers must merge
> changes into both streams where possible.

"Leaving it until "later" will as you say become unmanagable."

That is so true!

IIRC we have both had huge merges to do and SVN really isn't the tool for it.



>
> RG
>


-- 
Martin Ritchie

Re: M2 JIRAs

[Robert Greig <ro...@gmail.com>]

On 07/09/2007, Martin Ritchie <ri...@apache.org> wrote:

> Would be good if we had a think about how we are going to maintain the
> two code lines. 0_8/0_9 and 0_10.
>
> svnmerge is going to get out of hand too quickly. I would like to
> suggest that we get attach the patches to the JIRAs that way we can
> retreive them and apply to the code.

I agree with the earlier comment about just knowing the svn commit number.

But the main question about managing the two code lines:

I think we need to accept the the 0-8/9 codebase is going to live for
another year. From what I understand (and correct me if I am wrong)
the 0-10 changes are more focussed on the lower layer rather than for
example the broker. Therefore I think that developers must merge
changes into both streams where possible. Leaving it until "later"
will as you say become unmanagable.

RG

Re: M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> Martin Ritchie wrote:
> > On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
> >> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> >>
> >>> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
> >>> port it to the branch.
> >> OK. Are you going to merge it into the M2.1 branch?
> >>
> >> RG
> >
> > Would be good if we had a think about how we are going to maintain the
> > two code lines. 0_8/0_9 and 0_10.
> >
> > svnmerge is going to get out of hand too quickly. I would like to
> > suggest that we get attach the patches to the JIRAs that way we can
> > retreive them and apply to the code.
> >
> > Thoughts?
>
> Putting the SVN revision number in JIRA should be equivalent to
> attaching a patch and possibly a bit easier. That's what I did for QPID-573.

Indeed, as long as we are quite strict with ourselves at only fixing
one JIRA per commit. I know in the past that I've been guilty of
fixing a bunch of issues in one commit. Makes it hard to know what
relates to what fix.


> --Rafael
>


-- 
Martin Ritchie

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Martin Ritchie wrote:
> On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
>> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>>
>>> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
>>> port it to the branch.
>> OK. Are you going to merge it into the M2.1 branch?
>>
>> RG
> 
> Would be good if we had a think about how we are going to maintain the
> two code lines. 0_8/0_9 and 0_10.
> 
> svnmerge is going to get out of hand too quickly. I would like to
> suggest that we get attach the patches to the JIRAs that way we can
> retreive them and apply to the code.
> 
> Thoughts?

Putting the SVN revision number in JIRA should be equivalent to 
attaching a patch and possibly a bit easier. That's what I did for QPID-573.

--Rafael

Re: M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>
> > QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
> > port it to the branch.
>
> OK. Are you going to merge it into the M2.1 branch?
>
> RG

Would be good if we had a think about how we are going to maintain the
two code lines. 0_8/0_9 and 0_10.

svnmerge is going to get out of hand too quickly. I would like to
suggest that we get attach the patches to the JIRAs that way we can
retreive them and apply to the code.

Thoughts?



-- 
Martin Ritchie

Re: M2 JIRAs

[Robert Greig <ro...@gmail.com>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:

> QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to
> port it to the branch.

OK. Are you going to merge it into the M2.1 branch?

RG

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Rafael Schloming wrote:
> Robert Greig wrote:
>> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>>> FWIW, I believe there are several serious race conditions on both the
>>> trunk and M2. The JIRAs I've filed against M2 have instructions on how
>>> to reproduce them. If these do in fact exist on M2 I would consider it
>>> unreleasable.
>>
>> Could any of them result in message loss?
> 
> The intermittent failures described in QPID-580 could quite possibly 
> indicate message loss, although it is impossible to know for sure due to 
> the way the test is constructed.
> 
> Also, QPID-573 causes message duplication which, depending on your 
> application, may be as bad as message loss.

QPID-573 is fixed on the trunk, BTW, so it should be a simple matter to 
port it to the branch.

--Rafael

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Robert Godfrey wrote:
> On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
>> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>>
>>> Keep in mind I haven't actually tested the M2 branch directly. However
>>> the problem showed up on the trunk after the M2 -> trunk merge which is
>>> why I strongly suspect it is on the M2 branch also. I posted
>>> instructions in the JIRA on how to tweak the timings so as to reliably
>>> replicate the problem. Without the tweaking it only happens once every 5
>>> or 10 test runs which is a little bit annoying when debugging. I believe
>>> Rob (the other one) said he was going to have a look early next week.
>> I plan on doing some testing (more focussed on interop) on the M2
>> codebase this weekend but if I get a spare moment I will definitely
>> try to reproduce this.
> 
> 
> As shall I ...
> 
> The rest of my computers arriving at my new place tomorrow having seemingly
> been on a tour of Europe (or at least Northern Germany) so I should be in a
> better position to do some heavy duty testing...

Please post to the JIRA if you run into any issues/questions reproducing 
the problem. I'll check my email periodically this weekend.

--Rafael

Re: M2 JIRAs

[Robert Godfrey <ro...@gmail.com>]

On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
>
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>
> > Keep in mind I haven't actually tested the M2 branch directly. However
> > the problem showed up on the trunk after the M2 -> trunk merge which is
> > why I strongly suspect it is on the M2 branch also. I posted
> > instructions in the JIRA on how to tweak the timings so as to reliably
> > replicate the problem. Without the tweaking it only happens once every 5
> > or 10 test runs which is a little bit annoying when debugging. I believe
> > Rob (the other one) said he was going to have a look early next week.
>
> I plan on doing some testing (more focussed on interop) on the M2
> codebase this weekend but if I get a spare moment I will definitely
> try to reproduce this.


As shall I ...

The rest of my computers arriving at my new place tomorrow having seemingly
been on a tour of Europe (or at least Northern Germany) so I should be in a
better position to do some heavy duty testing...

-- Rob


RG
>

Re: M2 JIRAs

[Robert Greig <ro...@gmail.com>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:

> Keep in mind I haven't actually tested the M2 branch directly. However
> the problem showed up on the trunk after the M2 -> trunk merge which is
> why I strongly suspect it is on the M2 branch also. I posted
> instructions in the JIRA on how to tweak the timings so as to reliably
> replicate the problem. Without the tweaking it only happens once every 5
> or 10 test runs which is a little bit annoying when debugging. I believe
> Rob (the other one) said he was going to have a look early next week.

I plan on doing some testing (more focussed on interop) on the M2
codebase this weekend but if I get a spare moment I will definitely
try to reproduce this.

RG

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Robert Greig wrote:
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> 
>> The message ordering problem shows up for me when just publishing three
>> messages in a row, i.e. not really heavy load, just a quick burst. My
>> machine may be more prone to it than others though because I test on a
>> dual CPU system.
>>
>> Based on my understanding of the problem, I would expect there to be
>> almost no ordering maintained under continuous load.
> 
> Hmm, this is indeed worrying. Our main test platform is a four way
> dual core system so I am not sure why this hasn't been red flagged
> sooner.
> 
> Something to investigate further when we're back in the office next week.

Keep in mind I haven't actually tested the M2 branch directly. However 
the problem showed up on the trunk after the M2 -> trunk merge which is 
why I strongly suspect it is on the M2 branch also. I posted 
instructions in the JIRA on how to tweak the timings so as to reliably 
replicate the problem. Without the tweaking it only happens once every 5 
or 10 test runs which is a little bit annoying when debugging. I believe 
Rob (the other one) said he was going to have a look early next week.

--Rafael

Re: M2 JIRAs

[Robert Greig <ro...@gmail.com>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:

> The message ordering problem shows up for me when just publishing three
> messages in a row, i.e. not really heavy load, just a quick burst. My
> machine may be more prone to it than others though because I test on a
> dual CPU system.
>
> Based on my understanding of the problem, I would expect there to be
> almost no ordering maintained under continuous load.

Hmm, this is indeed worrying. Our main test platform is a four way
dual core system so I am not sure why this hasn't been red flagged
sooner.

Something to investigate further when we're back in the office next week.

RG

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Martin Ritchie wrote:
> On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
>> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>>
>>> The intermittent failures described in QPID-580 could quite possibly
>>> indicate message loss, although it is impossible to know for sure due to
>>> the way the test is constructed.
>>>
>>> Also, QPID-573 causes message duplication which, depending on your
>>> application, may be as bad as message loss.
>> OK. My own feeling is that we should release M2 now and plan to
>> release an M2.1 (as already discussed) and potentially an M2.0.1 (for
>> any users who want just the bug fixes without the protocol upgrade
>> "risk").
>>
>> M2 (or mostly M2) is being used in production today and has undergone
>> a fair amount of testing so I think it is reasonable to go ahead with
>> it. I would rather draw a line in the sand with it, and then get into
>> a habit of doing much more frequent bug fix and minor improvement
>> releases.
> 
> I would tend to agree. Looking at the JIRAs I don't see any message
> loss issues. The worse case is message ordering under load my not be
> maintained.

The message ordering problem shows up for me when just publishing three 
messages in a row, i.e. not really heavy load, just a quick burst. My 
machine may be more prone to it than others though because I test on a 
dual CPU system.

Based on my understanding of the problem, I would expect there to be 
almost no ordering maintained under continuous load.

I'm also concerned about the correctness of the message selectors when 
messages are delivered asynchronously, but that may be my own 
misunderstanding of the code. See my comments on QPID-572 for more details.

--Rafael

Re: M2 JIRAs

[Martin Ritchie <ri...@apache.org>]

On 07/09/2007, Robert Greig <ro...@gmail.com> wrote:
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>
> > The intermittent failures described in QPID-580 could quite possibly
> > indicate message loss, although it is impossible to know for sure due to
> > the way the test is constructed.
> >
> > Also, QPID-573 causes message duplication which, depending on your
> > application, may be as bad as message loss.
>
> OK. My own feeling is that we should release M2 now and plan to
> release an M2.1 (as already discussed) and potentially an M2.0.1 (for
> any users who want just the bug fixes without the protocol upgrade
> "risk").
>
> M2 (or mostly M2) is being used in production today and has undergone
> a fair amount of testing so I think it is reasonable to go ahead with
> it. I would rather draw a line in the sand with it, and then get into
> a habit of doing much more frequent bug fix and minor improvement
> releases.

I would tend to agree. Looking at the JIRAs I don't see any message
loss issues. The worse case is message ordering under load my not be
maintained.

> RG
>


-- 
Martin Ritchie

Re: M2 JIRAs

[Robert Greig <ro...@gmail.com>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:

> The intermittent failures described in QPID-580 could quite possibly
> indicate message loss, although it is impossible to know for sure due to
> the way the test is constructed.
>
> Also, QPID-573 causes message duplication which, depending on your
> application, may be as bad as message loss.

OK. My own feeling is that we should release M2 now and plan to
release an M2.1 (as already discussed) and potentially an M2.0.1 (for
any users who want just the bug fixes without the protocol upgrade
"risk").

M2 (or mostly M2) is being used in production today and has undergone
a fair amount of testing so I think it is reasonable to go ahead with
it. I would rather draw a line in the sand with it, and then get into
a habit of doing much more frequent bug fix and minor improvement
releases.

RG

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

Robert Greig wrote:
> On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
>> FWIW, I believe there are several serious race conditions on both the
>> trunk and M2. The JIRAs I've filed against M2 have instructions on how
>> to reproduce them. If these do in fact exist on M2 I would consider it
>> unreleasable.
> 
> Could any of them result in message loss?

The intermittent failures described in QPID-580 could quite possibly 
indicate message loss, although it is impossible to know for sure due to 
the way the test is constructed.

Also, QPID-573 causes message duplication which, depending on your 
application, may be as bad as message loss.

--Rafael

Re: M2 JIRAs

[Robert Greig <ro...@gmail.com>]

On 07/09/2007, Rafael Schloming <ra...@redhat.com> wrote:
> FWIW, I believe there are several serious race conditions on both the
> trunk and M2. The JIRAs I've filed against M2 have instructions on how
> to reproduce them. If these do in fact exist on M2 I would consider it
> unreleasable.

Could any of them result in message loss?

RG

Re: M2 JIRAs

[Rafael Schloming <ra...@redhat.com>]

FWIW, I believe there are several serious race conditions on both the 
trunk and M2. The JIRAs I've filed against M2 have instructions on how 
to reproduce them. If these do in fact exist on M2 I would consider it 
unreleasable.

--Rafael

Rajith Attapattu wrote:
> How about bumping them to M2.0.1 ?
> 
> Regards,
> 
> Rajith
> 
> On 9/7/07, Martin Ritchie <ri...@apache.org> wrote:
>> There are still 8 Outstanding JIRAs for M2. Can we resolve these or
>> bump them to the next release if that is appropriate.
>>
>> Wouldn't look good to be releasing M2 with outstanding tasks against it.
>> --
>> Martin Ritchie
>>
> 

Re: M2 JIRAs

[Rajith Attapattu <ra...@gmail.com>]

How about bumping them to M2.0.1 ?

Regards,

Rajith

On 9/7/07, Martin Ritchie <ri...@apache.org> wrote:
>
> There are still 8 Outstanding JIRAs for M2. Can we resolve these or
> bump them to the next release if that is appropriate.
>
> Wouldn't look good to be releasing M2 with outstanding tasks against it.
> --
> Martin Ritchie
>