On Fri, Feb 6, 2009 at 1:09 PM, Simon Laws <[email protected]>wrote:
> > > On Fri, Feb 6, 2009 at 12:45 PM, ant elder <[email protected]> wrote: > >> >> >> On Thu, Feb 5, 2009 at 12:25 PM, Simon Laws <[email protected]>wrote: >> >> I switched calculator-rmi-sevice/buil.xml over to use this launcher and >>>>> specify a timeout. A handy tactical fix. You'll see in >>>>> itest/samples/build.xml that the rmi bit is commented out. The timeout >>>>> seems >>>>> to work but after the node is stopped the node launcher doesn't >>>>> terminate. I >>>>> expect we are holding some thread open somewhere. I don't think this has >>>>> anything to do with the addition of the timeout but I don't have time to >>>>> check it out just now. >>>>> >>>>> Simon >>>>> >>>> >>>> Hmm. This means that users trying to run the sample with the "ant run" >>>> target have the node shutdown after a few seconds and there is nothing they >>>> can do about it! That seems quite far from ideal. (and on a side note isn't >>>> the launcher timeout just duplicating function already available on the Ant >>>> tasks?) >>>> >>>> Having itests to test the samples is really good but it needs to be >>>> non-invasive, the primary purpose of the samples is to show users how to do >>>> things as clearly as possible, if we can't get the itests working without >>>> impacting the usability of the samples then i'd prefer we stay with the old >>>> manual testing of the samples. Fortunately I think there will be ways we >>>> can >>>> do the automated testing of this type of sample, perhaps using Ant >>>> timeouts, >>>> IO Redirectors, or even a our own custom Ant task if necessary. >>>> >>>> ...ant >>>> >>>> Hi this was an outstanding TODO. I've changed the script so that the 4 >>> second wait is only actiive when the script is run automatically. When run >>> manually the time to live is 0 which mean wait for a key to be pressed. >>> >>> The propoer solution would of course be some kind of node management >>> interface so we can ask it to stop explicitly. Not really high up the list >>> at the moment though. >>> >>> Simon >>> >> >> Doing this with a timeout still seems like a bit of a kludge to me, I'm >> sure there must be a better way. Its fine as a work around for now but I'm >> going to try to find a better way which doesn't involve having the sample >> build scripts have to include any code for our integration testing. >> >> ...ant >> >> > > 1/ Correct me if I'm wrong but, while you didn't say so, I think you're > agreeing with me. If not then maybe I don't understand what you mean. > > 2/ Give the code we have at the moment our scripts don't have any code in > them which is explicitly for our integration tests. The script in question > sets a timeout of 0 which, if the user were to look at it, would be quite > instructive as that is what the launcher is doing for them, i.e. 0 timeout = > wait til a key is pressed. > > I stress I'm not claiming this is a perfect solution. The better solution > would be to have an mechanism whereby a node will stop when asked to do so. > > Simon > For (1) i'm not sure which bit you're asking if i agree with :), anyway, I'll try to be clearer: The main thing i don't like is the application build script having to have any code at all to support the way out itests work. Right now it does - it needs to define a "time.to.live" property, and when invoking the launcher it needs to pass in that property as a command line argument. In the ideal solution none of that should be required. Having a mechanism to ask a node to shutdown would be one way to fix it and that function would probably be useful outside of itesting, but i think there must also be other ways to fix this particular itest issue which might be simpler than a node shutdown mechanism. But I'm fine with using this time-to-live approach for now in M1. ...ant
