You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Apache Hudson Server <hu...@hudson.apache.org> on 2010/09/07 14:17:16 UTC

Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>



Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
Duh, I was using the wrong listener (using Listen and MessageReceived
instead of AddToMailbox and NewMessage). Took a while to get right,
but if the tests work this time we won't need any Thread.sleep so our
TwitterAPI test will be cleaner- deterministic and won't slow down
unnecessarily.

Vassil


On Thu, Sep 9, 2010 at 11:15 AM, Vassil Dichev <vd...@apache.org> wrote:
> Actually there's conductor actor in Specs, I seem to steal ideas from
> there a lot lately :)
>
> The problem is that when there are multiple cascaded asyncronous
> calls, it doesn't work so well in practice. For instance, I can
> guarantee that NewMessage has been received, but the AddToMailbox
> might not have been received, even though it's "sent" before
> NewMessage.
>
>
> On Thu, Sep 9, 2010 at 10:26 AM, Ethan Jewett <es...@gmail.com> wrote:
>> Vassil,
>>
>> At some point I'm going to put your conductor actor into the API2 and
>> API tests. That was a great idea. (Did I already say this back when
>> you first checked it in? I definitely thought it :-)
>>
>> Ethan
>>
>> On Wed, Sep 8, 2010 at 9:10 PM, Vassil Dichev <vd...@apache.org> wrote:
>>> OK, after one hour and 276 times of running the TwitterAPI test
>>> without a failure I decided it's OK and committed.
>>>
>>>
>>> On Wed, Sep 8, 2010 at 4:44 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>> Sorry, I had assumed I know which test failed even before reading the
>>>> spec description... I was wrong, and I was trying to "fix" the wrong
>>>> test. I now tried to apply the fix again and I'm currently running the
>>>> tests in a loop again. If they haven't failed after 2 hours, I will
>>>> commit.
>>>>
>>>> Vassil
>>>>
>>>>
>>>> On Wed, Sep 8, 2010 at 4:26 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>> g
>>>>>
>>>>> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>> Well, it's not really a bug of the implementation, it's an
>>>>>> imperfection of the test. If one delivers the final product (war or
>>>>>> whatever it is), the tests are usually not there anyway, so I'm not
>>>>>> even sure it's worth a mention.
>>>>>
>>>>> Good point
>>>>>
>>>>>>
>>>>>> Vassil
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>> I don't see this bug has threatening 1.1
>>>>>>>
>>>>>>> We might want to have a section in the release notes called "Known
>>>>>>> bugs" - this bug and the other small bugs would be added to this
>>>>>>> section.
>>>>>>>
>>>>>>> What do you think about that?
>>>>>>>
>>>>>>> D.
>>>>>>>
>>>>>>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>> There's some good news and some bad news regarding the tests.
>>>>>>>>
>>>>>>>> The good news is that I managed to reproduce the failing test fairly
>>>>>>>> easily- running the test in a loop until it fails resulted in a fail
>>>>>>>> after 10-15 minutes on my machine.
>>>>>>>>
>>>>>>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>>>>>>
>>>>>>>> This means we will probably have to revert to using the good
>>>>>>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>>>>>>> to fail and slowing it down too much.
>>>>>>>>
>>>>>>>> The problem is certainly not critical for release, of course, but
>>>>>>>> eventually I want to have more deterministic tests, but this probably
>>>>>>>> means some small additions to the Distributor API.
>>>>>>>>
>>>>>>>> Vassil
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>>> OK, I've setup some tests to run over the night (these are hard to
>>>>>>>>> reproduce) and we'll see what we get in the morning
>>>>>>>>>
>>>>>>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>>>>>>> that there's no easy way to find out when the message is going to
>>>>>>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>>>>>>> for the problem tonight.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>>>>>>> failing on hudson as well -
>>>>>>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>>>>>>
>>>>>>>>>>>> No idea why
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
Actually there's conductor actor in Specs, I seem to steal ideas from
there a lot lately :)

The problem is that when there are multiple cascaded asyncronous
calls, it doesn't work so well in practice. For instance, I can
guarantee that NewMessage has been received, but the AddToMailbox
might not have been received, even though it's "sent" before
NewMessage.


On Thu, Sep 9, 2010 at 10:26 AM, Ethan Jewett <es...@gmail.com> wrote:
> Vassil,
>
> At some point I'm going to put your conductor actor into the API2 and
> API tests. That was a great idea. (Did I already say this back when
> you first checked it in? I definitely thought it :-)
>
> Ethan
>
> On Wed, Sep 8, 2010 at 9:10 PM, Vassil Dichev <vd...@apache.org> wrote:
>> OK, after one hour and 276 times of running the TwitterAPI test
>> without a failure I decided it's OK and committed.
>>
>>
>> On Wed, Sep 8, 2010 at 4:44 PM, Vassil Dichev <vd...@apache.org> wrote:
>>> Sorry, I had assumed I know which test failed even before reading the
>>> spec description... I was wrong, and I was trying to "fix" the wrong
>>> test. I now tried to apply the fix again and I'm currently running the
>>> tests in a loop again. If they haven't failed after 2 hours, I will
>>> commit.
>>>
>>> Vassil
>>>
>>>
>>> On Wed, Sep 8, 2010 at 4:26 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>> g
>>>>
>>>> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>> Well, it's not really a bug of the implementation, it's an
>>>>> imperfection of the test. If one delivers the final product (war or
>>>>> whatever it is), the tests are usually not there anyway, so I'm not
>>>>> even sure it's worth a mention.
>>>>
>>>> Good point
>>>>
>>>>>
>>>>> Vassil
>>>>>
>>>>>
>>>>> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>> I don't see this bug has threatening 1.1
>>>>>>
>>>>>> We might want to have a section in the release notes called "Known
>>>>>> bugs" - this bug and the other small bugs would be added to this
>>>>>> section.
>>>>>>
>>>>>> What do you think about that?
>>>>>>
>>>>>> D.
>>>>>>
>>>>>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>> There's some good news and some bad news regarding the tests.
>>>>>>>
>>>>>>> The good news is that I managed to reproduce the failing test fairly
>>>>>>> easily- running the test in a loop until it fails resulted in a fail
>>>>>>> after 10-15 minutes on my machine.
>>>>>>>
>>>>>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>>>>>
>>>>>>> This means we will probably have to revert to using the good
>>>>>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>>>>>> to fail and slowing it down too much.
>>>>>>>
>>>>>>> The problem is certainly not critical for release, of course, but
>>>>>>> eventually I want to have more deterministic tests, but this probably
>>>>>>> means some small additions to the Distributor API.
>>>>>>>
>>>>>>> Vassil
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>> OK, I've setup some tests to run over the night (these are hard to
>>>>>>>> reproduce) and we'll see what we get in the morning
>>>>>>>>
>>>>>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>>>>>> that there's no easy way to find out when the message is going to
>>>>>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>>>>>> for the problem tonight.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>>>>>> failing on hudson as well -
>>>>>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>>>>>
>>>>>>>>>>> No idea why
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Ethan Jewett <es...@gmail.com>.
Vassil,

At some point I'm going to put your conductor actor into the API2 and
API tests. That was a great idea. (Did I already say this back when
you first checked it in? I definitely thought it :-)

Ethan

On Wed, Sep 8, 2010 at 9:10 PM, Vassil Dichev <vd...@apache.org> wrote:
> OK, after one hour and 276 times of running the TwitterAPI test
> without a failure I decided it's OK and committed.
>
>
> On Wed, Sep 8, 2010 at 4:44 PM, Vassil Dichev <vd...@apache.org> wrote:
>> Sorry, I had assumed I know which test failed even before reading the
>> spec description... I was wrong, and I was trying to "fix" the wrong
>> test. I now tried to apply the fix again and I'm currently running the
>> tests in a loop again. If they haven't failed after 2 hours, I will
>> commit.
>>
>> Vassil
>>
>>
>> On Wed, Sep 8, 2010 at 4:26 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> g
>>>
>>> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>> Well, it's not really a bug of the implementation, it's an
>>>> imperfection of the test. If one delivers the final product (war or
>>>> whatever it is), the tests are usually not there anyway, so I'm not
>>>> even sure it's worth a mention.
>>>
>>> Good point
>>>
>>>>
>>>> Vassil
>>>>
>>>>
>>>> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>> I don't see this bug has threatening 1.1
>>>>>
>>>>> We might want to have a section in the release notes called "Known
>>>>> bugs" - this bug and the other small bugs would be added to this
>>>>> section.
>>>>>
>>>>> What do you think about that?
>>>>>
>>>>> D.
>>>>>
>>>>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>> There's some good news and some bad news regarding the tests.
>>>>>>
>>>>>> The good news is that I managed to reproduce the failing test fairly
>>>>>> easily- running the test in a loop until it fails resulted in a fail
>>>>>> after 10-15 minutes on my machine.
>>>>>>
>>>>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>>>>
>>>>>> This means we will probably have to revert to using the good
>>>>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>>>>> to fail and slowing it down too much.
>>>>>>
>>>>>> The problem is certainly not critical for release, of course, but
>>>>>> eventually I want to have more deterministic tests, but this probably
>>>>>> means some small additions to the Distributor API.
>>>>>>
>>>>>> Vassil
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>> OK, I've setup some tests to run over the night (these are hard to
>>>>>>> reproduce) and we'll see what we get in the morning
>>>>>>>
>>>>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>>>>> that there's no easy way to find out when the message is going to
>>>>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>>>>> for the problem tonight.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>>>>> failing on hudson as well -
>>>>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>>>>
>>>>>>>>>> No idea why
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Richard Hirsch <hi...@gmail.com>.
Just performed a Hudson build and the problem is gone
(https://hudson.apache.org/hudson/job/ESME/341/console)

Thanks

On Wed, Sep 8, 2010 at 9:10 PM, Vassil Dichev <vd...@apache.org> wrote:
> OK, after one hour and 276 times of running the TwitterAPI test
> without a failure I decided it's OK and committed.
>
>
> On Wed, Sep 8, 2010 at 4:44 PM, Vassil Dichev <vd...@apache.org> wrote:
>> Sorry, I had assumed I know which test failed even before reading the
>> spec description... I was wrong, and I was trying to "fix" the wrong
>> test. I now tried to apply the fix again and I'm currently running the
>> tests in a loop again. If they haven't failed after 2 hours, I will
>> commit.
>>
>> Vassil
>>
>>
>> On Wed, Sep 8, 2010 at 4:26 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> g
>>>
>>> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>> Well, it's not really a bug of the implementation, it's an
>>>> imperfection of the test. If one delivers the final product (war or
>>>> whatever it is), the tests are usually not there anyway, so I'm not
>>>> even sure it's worth a mention.
>>>
>>> Good point
>>>
>>>>
>>>> Vassil
>>>>
>>>>
>>>> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>> I don't see this bug has threatening 1.1
>>>>>
>>>>> We might want to have a section in the release notes called "Known
>>>>> bugs" - this bug and the other small bugs would be added to this
>>>>> section.
>>>>>
>>>>> What do you think about that?
>>>>>
>>>>> D.
>>>>>
>>>>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>> There's some good news and some bad news regarding the tests.
>>>>>>
>>>>>> The good news is that I managed to reproduce the failing test fairly
>>>>>> easily- running the test in a loop until it fails resulted in a fail
>>>>>> after 10-15 minutes on my machine.
>>>>>>
>>>>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>>>>
>>>>>> This means we will probably have to revert to using the good
>>>>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>>>>> to fail and slowing it down too much.
>>>>>>
>>>>>> The problem is certainly not critical for release, of course, but
>>>>>> eventually I want to have more deterministic tests, but this probably
>>>>>> means some small additions to the Distributor API.
>>>>>>
>>>>>> Vassil
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>> OK, I've setup some tests to run over the night (these are hard to
>>>>>>> reproduce) and we'll see what we get in the morning
>>>>>>>
>>>>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>>>>> that there's no easy way to find out when the message is going to
>>>>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>>>>> for the problem tonight.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>>>>> failing on hudson as well -
>>>>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>>>>
>>>>>>>>>> No idea why
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
OK, after one hour and 276 times of running the TwitterAPI test
without a failure I decided it's OK and committed.


On Wed, Sep 8, 2010 at 4:44 PM, Vassil Dichev <vd...@apache.org> wrote:
> Sorry, I had assumed I know which test failed even before reading the
> spec description... I was wrong, and I was trying to "fix" the wrong
> test. I now tried to apply the fix again and I'm currently running the
> tests in a loop again. If they haven't failed after 2 hours, I will
> commit.
>
> Vassil
>
>
> On Wed, Sep 8, 2010 at 4:26 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> g
>>
>> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>>> Well, it's not really a bug of the implementation, it's an
>>> imperfection of the test. If one delivers the final product (war or
>>> whatever it is), the tests are usually not there anyway, so I'm not
>>> even sure it's worth a mention.
>>
>> Good point
>>
>>>
>>> Vassil
>>>
>>>
>>> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>> I don't see this bug has threatening 1.1
>>>>
>>>> We might want to have a section in the release notes called "Known
>>>> bugs" - this bug and the other small bugs would be added to this
>>>> section.
>>>>
>>>> What do you think about that?
>>>>
>>>> D.
>>>>
>>>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>>> There's some good news and some bad news regarding the tests.
>>>>>
>>>>> The good news is that I managed to reproduce the failing test fairly
>>>>> easily- running the test in a loop until it fails resulted in a fail
>>>>> after 10-15 minutes on my machine.
>>>>>
>>>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>>>
>>>>> This means we will probably have to revert to using the good
>>>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>>>> to fail and slowing it down too much.
>>>>>
>>>>> The problem is certainly not critical for release, of course, but
>>>>> eventually I want to have more deterministic tests, but this probably
>>>>> means some small additions to the Distributor API.
>>>>>
>>>>> Vassil
>>>>>
>>>>>
>>>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>> OK, I've setup some tests to run over the night (these are hard to
>>>>>> reproduce) and we'll see what we get in the morning
>>>>>>
>>>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>> Thanks
>>>>>>>
>>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>>>> that there's no easy way to find out when the message is going to
>>>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>>>> for the problem tonight.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>>>> failing on hudson as well -
>>>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>>>
>>>>>>>>> No idea why
>>>>>>>>>
>>>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
Sorry, I had assumed I know which test failed even before reading the
spec description... I was wrong, and I was trying to "fix" the wrong
test. I now tried to apply the fix again and I'm currently running the
tests in a loop again. If they haven't failed after 2 hours, I will
commit.

Vassil


On Wed, Sep 8, 2010 at 4:26 PM, Richard Hirsch <hi...@gmail.com> wrote:
> g
>
> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>> Well, it's not really a bug of the implementation, it's an
>> imperfection of the test. If one delivers the final product (war or
>> whatever it is), the tests are usually not there anyway, so I'm not
>> even sure it's worth a mention.
>
> Good point
>
>>
>> Vassil
>>
>>
>> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> I don't see this bug has threatening 1.1
>>>
>>> We might want to have a section in the release notes called "Known
>>> bugs" - this bug and the other small bugs would be added to this
>>> section.
>>>
>>> What do you think about that?
>>>
>>> D.
>>>
>>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>>> There's some good news and some bad news regarding the tests.
>>>>
>>>> The good news is that I managed to reproduce the failing test fairly
>>>> easily- running the test in a loop until it fails resulted in a fail
>>>> after 10-15 minutes on my machine.
>>>>
>>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>>
>>>> This means we will probably have to revert to using the good
>>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>>> to fail and slowing it down too much.
>>>>
>>>> The problem is certainly not critical for release, of course, but
>>>> eventually I want to have more deterministic tests, but this probably
>>>> means some small additions to the Distributor API.
>>>>
>>>> Vassil
>>>>
>>>>
>>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>> OK, I've setup some tests to run over the night (these are hard to
>>>>> reproduce) and we'll see what we get in the morning
>>>>>
>>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>> Thanks
>>>>>>
>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>>> that there's no easy way to find out when the message is going to
>>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>>> for the problem tonight.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>>> failing on hudson as well -
>>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>>
>>>>>>>> No idea why
>>>>>>>>
>>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Richard Hirsch <hi...@gmail.com>.
g

On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <vd...@apache.org> wrote:
> Well, it's not really a bug of the implementation, it's an
> imperfection of the test. If one delivers the final product (war or
> whatever it is), the tests are usually not there anyway, so I'm not
> even sure it's worth a mention.

Good point

>
> Vassil
>
>
> On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> I don't see this bug has threatening 1.1
>>
>> We might want to have a section in the release notes called "Known
>> bugs" - this bug and the other small bugs would be added to this
>> section.
>>
>> What do you think about that?
>>
>> D.
>>
>> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>>> There's some good news and some bad news regarding the tests.
>>>
>>> The good news is that I managed to reproduce the failing test fairly
>>> easily- running the test in a loop until it fails resulted in a fail
>>> after 10-15 minutes on my machine.
>>>
>>> The bad news is that with my fixes it still fails eventually, if not faster.
>>>
>>> This means we will probably have to revert to using the good
>>> old-fashioned timeouts, which are a tradeoff between risking the test
>>> to fail and slowing it down too much.
>>>
>>> The problem is certainly not critical for release, of course, but
>>> eventually I want to have more deterministic tests, but this probably
>>> means some small additions to the Distributor API.
>>>
>>> Vassil
>>>
>>>
>>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>> OK, I've setup some tests to run over the night (these are hard to
>>>> reproduce) and we'll see what we get in the morning
>>>>
>>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>> Thanks
>>>>>
>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>>> that there's no easy way to find out when the message is going to
>>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>>> for the problem tonight.
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>>> failing on hudson as well -
>>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>>
>>>>>>> No idea why
>>>>>>>
>>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
Well, it's not really a bug of the implementation, it's an
imperfection of the test. If one delivers the final product (war or
whatever it is), the tests are usually not there anyway, so I'm not
even sure it's worth a mention.

Vassil


On Wed, Sep 8, 2010 at 12:00 PM, Richard Hirsch <hi...@gmail.com> wrote:
> I don't see this bug has threatening 1.1
>
> We might want to have a section in the release notes called "Known
> bugs" - this bug and the other small bugs would be added to this
> section.
>
> What do you think about that?
>
> D.
>
> On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>> There's some good news and some bad news regarding the tests.
>>
>> The good news is that I managed to reproduce the failing test fairly
>> easily- running the test in a loop until it fails resulted in a fail
>> after 10-15 minutes on my machine.
>>
>> The bad news is that with my fixes it still fails eventually, if not faster.
>>
>> This means we will probably have to revert to using the good
>> old-fashioned timeouts, which are a tradeoff between risking the test
>> to fail and slowing it down too much.
>>
>> The problem is certainly not critical for release, of course, but
>> eventually I want to have more deterministic tests, but this probably
>> means some small additions to the Distributor API.
>>
>> Vassil
>>
>>
>> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>>> OK, I've setup some tests to run over the night (these are hard to
>>> reproduce) and we'll see what we get in the morning
>>>
>>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>> Thanks
>>>>
>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>>> I thought I had these sorted out, but obviously not. The problem is
>>>>> that there's no easy way to find out when the message is going to
>>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>>> for the problem tonight.
>>>>>
>>>>>
>>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>>> failing on hudson as well -
>>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>>
>>>>>> No idea why
>>>>>>
>>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>>> <hu...@hudson.apache.org> wrote:
>>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Richard Hirsch <hi...@gmail.com>.
I don't see this bug has threatening 1.1

We might want to have a section in the release notes called "Known
bugs" - this bug and the other small bugs would be added to this
section.

What do you think about that?

D.

On Wed, Sep 8, 2010 at 6:42 AM, Vassil Dichev <vd...@apache.org> wrote:
> There's some good news and some bad news regarding the tests.
>
> The good news is that I managed to reproduce the failing test fairly
> easily- running the test in a loop until it fails resulted in a fail
> after 10-15 minutes on my machine.
>
> The bad news is that with my fixes it still fails eventually, if not faster.
>
> This means we will probably have to revert to using the good
> old-fashioned timeouts, which are a tradeoff between risking the test
> to fail and slowing it down too much.
>
> The problem is certainly not critical for release, of course, but
> eventually I want to have more deterministic tests, but this probably
> means some small additions to the Distributor API.
>
> Vassil
>
>
> On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
>> OK, I've setup some tests to run over the night (these are hard to
>> reproduce) and we'll see what we get in the morning
>>
>> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> Thanks
>>>
>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>>> I thought I had these sorted out, but obviously not. The problem is
>>>> that there's no easy way to find out when the message is going to
>>>> appear in the timeline, because it's asynchronous. Will try to look
>>>> for the problem tonight.
>>>>
>>>>
>>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>>> failing on hudson as well -
>>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>>
>>>>> No idea why
>>>>>
>>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>>> <hu...@hudson.apache.org> wrote:
>>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
There's some good news and some bad news regarding the tests.

The good news is that I managed to reproduce the failing test fairly
easily- running the test in a loop until it fails resulted in a fail
after 10-15 minutes on my machine.

The bad news is that with my fixes it still fails eventually, if not faster.

This means we will probably have to revert to using the good
old-fashioned timeouts, which are a tradeoff between risking the test
to fail and slowing it down too much.

The problem is certainly not critical for release, of course, but
eventually I want to have more deterministic tests, but this probably
means some small additions to the Distributor API.

Vassil


On Tue, Sep 7, 2010 at 10:20 PM, Vassil Dichev <vd...@apache.org> wrote:
> OK, I've setup some tests to run over the night (these are hard to
> reproduce) and we'll see what we get in the morning
>
> On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> Thanks
>>
>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>>> I thought I had these sorted out, but obviously not. The problem is
>>> that there's no easy way to find out when the message is going to
>>> appear in the timeline, because it's asynchronous. Will try to look
>>> for the problem tonight.
>>>
>>>
>>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>>> failing on hudson as well -
>>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>>
>>>> No idea why
>>>>
>>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>>> <hu...@hudson.apache.org> wrote:
>>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
OK, I've setup some tests to run over the night (these are hard to
reproduce) and we'll see what we get in the morning

On Tue, Sep 7, 2010 at 3:30 PM, Richard Hirsch <hi...@gmail.com> wrote:
> Thanks
>
> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
>> I thought I had these sorted out, but obviously not. The problem is
>> that there's no easy way to find out when the message is going to
>> appear in the timeline, because it's asynchronous. Will try to look
>> for the problem tonight.
>>
>>
>> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>>> LOL - the test in the twittwerapi that I mentioned before - is no
>>> failing on hudson as well -
>>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>>
>>> No idea why
>>>
>>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>>> <hu...@hudson.apache.org> wrote:
>>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>>
>>>>
>>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Richard Hirsch <hi...@gmail.com>.
Thanks

On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <vd...@apache.org> wrote:
> I thought I had these sorted out, but obviously not. The problem is
> that there's no easy way to find out when the message is going to
> appear in the timeline, because it's asynchronous. Will try to look
> for the problem tonight.
>
>
> On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
>> LOL - the test in the twittwerapi that I mentioned before - is no
>> failing on hudson as well -
>> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>>
>> No idea why
>>
>> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
>> <hu...@hudson.apache.org> wrote:
>>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>>
>>>
>>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Vassil Dichev <vd...@apache.org>.
I thought I had these sorted out, but obviously not. The problem is
that there's no easy way to find out when the message is going to
appear in the timeline, because it's asynchronous. Will try to look
for the problem tonight.


On Tue, Sep 7, 2010 at 3:19 PM, Richard Hirsch <hi...@gmail.com> wrote:
> LOL - the test in the twittwerapi that I mentioned before - is no
> failing on hudson as well -
> https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/
>
> No idea why
>
> On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
> <hu...@hudson.apache.org> wrote:
>> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>>
>>
>>
>

Re: Hudson build became unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #339

Posted by Richard Hirsch <hi...@gmail.com>.
LOL - the test in the twittwerapi that I mentioned before - is no
failing on hudson as well -
https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/

No idea why

On Tue, Sep 7, 2010 at 2:17 PM, Apache Hudson Server
<hu...@hudson.apache.org> wrote:
> See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes>
>
>
>

Hudson build is back to stable : ESME » Apache Enterprise Social Messaging Experiment (ESME) #341

Posted by Apache Hudson Server <hu...@hudson.apache.org>.
See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/341/changes>



Hudson build is still unstable: ESME » Apache Enterprise Social Messaging Experiment (ESME) #340

Posted by Apache Hudson Server <hu...@hudson.apache.org>.
See <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/changes>