In general, there should be a mechanism to wait precisely the right
time.
For example, if JMX Notifications were emitted by the server when
deployment was initiated and finished, the code could just wait the
correct amount of time. The deprecated V2 AMX deployment API had such
a mechanism, and JSR 88 deployment API also has one. Perhaps no such
facility is available in V3 yet, but it should be added, and then such
tests can simply wait deterministically via the appropriate API or
callback.
Lloyd
On Sep 26, 2008, at 8:21 PM, Jason Lee wrote:
> On Sep 26, 2008, at 7:32 PM, Kedar Mhaswade wrote:
>
>> I am seeing this counting to 100 and giving up too. (By the way
>> counting
>> to 100 is quite inexplicable. It's QL. How about counting to 10?)
>
>
> Kedar, I just got in from a family thing and it looks like Anissa
> got things figured out (thanks!) but I wanted to address the
> timeout. Originally, I had a iteration limit of 10, with a ten
> second pause between attempts. Ken suggest lowering that to 1
> second with a 100 iteration max. That gave us the same amount of
> time total, with the possibility of succeeding more quickly.
> Overall, the number of iterations and the wait are arbitrary, but we
> did run into a situation with... someone who had a slower box and
> the test was giving up before the app was deployed, indicating a
> failure, even though the app did eventually deploy.
>
> With a good tree, the test should complete in just a few seconds.
> The only time one will see the long and painful wait is when one
> breaks the tree, so you get what you deserve, right? I kid.
> Mostly. :P I'm certainly open to tweaking all those numbers, but
> we need to be careful so that we don't cause false alarms on the
> slower boxes.
>
> Jason Lee
> Senior Java Developer
> GlassFish Administration Console
>
> Sun Microsystems, Inc.
> Phone x31197/+1 405-343-1964
> Email jasondlee_at_sun.com
> Blog http://blogs.sun.com/jasondlee
> Blog http://blogs.steeplesoft.com
>