Based on Bill's feedback -- I changed it. If you want to use the
feature --set an env. variable or a system property called APS_WAIT and
set it to "true".
If you do nothing then nothing special will happen.
I also updated the wiki page [1]
[1]
http://wikis.sun.com/display/GlassFish/AdminTests#AdminTests-JustInTimeDebugging
On 4/4/2011 1:37 PM, Byron Nevins wrote:
> 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
--
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