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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> g >>> >>> On Wed, Sep 8, 2010 at 11:08 AM, Vassil Dichev <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> wrote: >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Tue, Sep 7, 2010 at 2:27 PM, Vassil Dichev <[email protected]> >>>>>>>> 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 >>>>>>>>> <[email protected]> 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 >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> See >>>>>>>>>>> <https://hudson.apache.org/hudson/job/ESME/org.apache.esme$esme-server/339/changes> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
