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 <[email protected]> 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 <[email protected]> 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 <[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>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to