1. It only affects *monitoring* devtests
2. It is turned off for Hudson by default.
I see your point though. I'll change the variable and behavior like so:
APS_WAIT -- if it exists and is equal to "true" then wait. Otherwise don't.
So you need to set that in your environment for it to work.
On 4/4/2011 1:30 PM, Bill Shannon wrote:
> This looks useful, but it seems like the default should be to *not* do
> this.
> I don't know about the rest of you, but most of the time I'm *not*
> watching
> Hudson jobs to see the moment they fail, nor am I prepared to attach a
> debugger the instant a devtest fails. If I'm going to debug a devtest,
> I first prepare my environment for doing so.
>
> Byron Nevins wrote on 04/ 4/11 12:06 PM:
>> Our DevTests are all-or-none. One test failing is just exactly as
>> bad as 100
>> tests failing. I added a feature that makes it a bit easier to debug
>> problems.
>> Read on if interested...
>>
>> The monitoring devtests ALWAYS run with jpda debugging turned on
>> (suspend = "n",
>> of course!!). The moment ANY test fails the screen is cleared and
>> the output
>> below is displayed. The code will sit and wait 60 seconds for you to
>> attach
>> your debugger to port 9999. It even tells you how to force it to
>> stop waiting
>> early so you can start debugging -- by setting a static variable to
>> true.
>>
>> This will add one minute to every failed test so I suppose this could
>> create
>> hudson issues. For now I'm setting a magic environmental variable in
>> the Hudson
>> runs that skip this wait.
>>
>> APS_NO_WAIT=true
>>
>> Now if we get some weird issue where Hudson fails but your
>> environment succeeds
>> -- then simply change hudson.sh and don't set the variable and then
>> you can
>> debug at the exact right moment on the Hudson machine!
>>
>> -- Currently this only applies to monitoring devtests but it can be
>> used for all
>> devtests. The main work is adding the right jvmargs to the bazillion
>> different
>> ant targets in build.xml
>>
>> A very useful technique is to attach and then set a breakpoint in the
>> code right
>> after the failed test (look in the call stack). Once it hits, I can
>> leave the
>> debugger and I now have full access to the server(s) in exactly the
>> state I
>> want. I can run plenty of manual tests directly with the server (what
>> does get
>> -m return? Which instances are really running? etc., etc.)
>>
>> =========================================
>>
>> [java]
>> [java]
>> [java]
>> [java]
>> [java]
>> [java] ***************************************************************
>> [java] ***************************************************************
>> [java] ***************************************************************
>> [java] ******* TEST ERROR!! Attach a Debugger NOW at port 9999
>> [java] ******* To stop the timeout:
>> [java] ******* Set the "stopWaiting" variable to true in MonTest
>> [java] ******* I'll wait for 60 seconds...
>> [java] ***************************************************************
>> [java] ***************************************************************
>> [java] ***************************************************************
>> [java]
>> [java]
>> [java] 10
>> [java] 20
>> [java] 30
>> [java] 40
>> [java] 50
>> --
>> Oracle <http://www.oracle.com>
>> Byron Nevins | Principal MTS
>> Phone: +1 6503958992 <tel:+1%206503958992>
>>
>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
>> developing practices and products that help protect the environment
>
--
Oracle <http://www.oracle.com>
Byron Nevins | Principal MTS
Phone: +1 6503958992 <tel:+1%206503958992>
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment