Ahem. Yes. I had meant 300,000 ;) Cheers,
Jim On 28 October 2015 at 12:10, Rad Gruchalski <[email protected]> wrote: > However, it should be 300000, not 30000. It’s milliseconds - 5 mins in > milliseconds is 300000. > > Optional. Default: 300000 (5 minutes) > > Kind regards, > Radek Gruchalski > [email protected] <[email protected]> > de.linkedin.com/in/radgruchalski/ > > > *Confidentiality:*This communication is intended for the above-named > person and may be confidential and/or legally privileged. > If it has come to you in error you must take no action based on it, nor > must you copy or show it to anyone; please delete/destroy and inform the > sender immediately. > > On Wednesday, 28 October 2015 at 13:08, Rad Gruchalski wrote: > > Nobody getting those today ;) Good catch. Worth keeping in mind! > > Kind regards, > Radek Gruchalski > [email protected] <[email protected]> > de.linkedin.com/in/radgruchalski/ > > > *Confidentiality:*This communication is intended for the above-named > person and may be confidential and/or legally privileged. > If it has come to you in error you must take no action based on it, nor > must you copy or show it to anyone; please delete/destroy and inform the > sender immediately. > > On Wednesday, 28 October 2015 at 13:06, James Vanns wrote: > > I shall fix my own problem.... it's embarrassing. Top marks to those of > you that notice I supplied 3000 instead of 30000 (which I understand is > actually the default anyway) to task_launch_timeout! > > Jim > > > On 28 October 2015 at 10:21, James Vanns <[email protected]> wrote: > > Hi all. > > Mesos version = 0.23.0-1.0.ubuntu1404 (mesosphere APT repo) > Marathon version = 0.10.1 (mesosphere APT repo) > > Hopefully this is a simple one for someone to answer, though I couldn't > find anything immediately > obvious in the documentation. We're trialling Mesos in a cloud (EC2/GCE) > environment and the one > thing that continues to bite us in the ass is this; continued task > failures until the docker image is > fully downloaded! Why is this!? Some of our images a small (say 200MB), > some much larger (2GB) > due to the nature of the software packages we're containerising. > Regardless of this size, they fail the > first dozen (or more) times until one of the slaves has pulled the image. > Why is there an apparent > hard time-out and how can I avoid it? I don't want the task to register as > a fail - it hasn't even had a > chance to run yet! Up until now we've just been tolerating the bouncing > around of these tasks but it's > now reached a point where it's darn annoying ;) > > I've tried setting executor_registration_timeout to '5mins' but this made > no apparent difference (every > minute the task is killed still). I should note that these tasks are > launched using the Marathon > framework and I've tried setting 'task_launch_timeout' to '3000' and > again, it makes no difference. > > Based on a brief glance of a mesos slave log file it seems the master > instructs the slave to kill the task off after 1 minute. > > Please advise. > > Cheers, > > Jim > > -- > Senior Code Pig > Industrial Light & Magic > > > > > -- > -- > Senior Code Pig > Industrial Light & Magic > > > > -- -- Senior Code Pig Industrial Light & Magic
