Josh, When Webrick gets over a certain threshold, it just falls over.
Mongrel degrades more gracefully and can recover. Depending on how complicated your configurations are and how long they compile, you might need to run more than one instance of mongrel. Regards, Andrew On Fri, Sep 12, 2008 at 11:09 AM, josh <[EMAIL PROTECTED]> wrote: > > Andrew, > I am using Webrick ,and yes, the process becomes unresponsive. > I ran puppetmasterd in --no-daemonize mode, and nothing useful, after > a certain amount of time just no more log data was being generated. > It's almost like it's not reading my puppet.conf (Do I need to call it > puppetmasterd.conf? From what I understand it shouldn't matter) > > And yes, I'm reading on page 142 of the "Advanced Puppet" book that > WEBrick can't scale well. (Thanks James for the book - I just got it > yesterday and it's quite helpful). Time to crank open mongrel and sanother might be hard in the general case. Cheers, Jon On Fri, Sep 12, 2008 at 11:16 PM, Ethan Davis <[EMAIL PROTECTED]> wrote: > Hi Dale, > > Dale Robinson wrote: >> >> I guess we are getting to the core of this discussion, at least in terms >> of whether or not my further involvement is needed. > > Yes indeed. Good discussion > >> The question for me is, does or will the CF convention allow some method >> to include offsets between tidal datums, or allow some other means for a >> user to convert among z referenced to different datums? >> Your answer below suggests that the CF convention is not the place for >> this information... that the information is out there and it is up to the >> user to find it. >> Please let me know if I've got that right. > > Sorry that detail of your question slipped under my radar and I was focused > on how to identify a vertical datum. It is an interesting question since the > grid mapping part of CF was originally designed to describe a > mapping/transformation between two sets of coordinates. The existing grid > mappings generally have a half dozen or so parameters and a name to identify > the set of formulas in which to use those parameters to perform the > transformation. In your case, it sounds like the vertical datum grid mapping > variable would contain an offset for each point where you have data. You > wouldn't even need to name the transformation (though you probably would > want to name the two vertical CRS if known), you would just need to indicate > how the offset is applied. > > Which leads me to think that CF very well may be the place for data on > offsets between vertical datums. What do others think about a grid mapping > variable being an actual array of data as opposed to simply a container for > attributes? > > Ethan > > PS Just a thought about grid mappings. Both EPSG and ISO 19111 keep CRS and > transformations between CRS as separate entities. Grid mappings kind of do > double duty as they can now either: > > 1) define both a transformation and the two CRS at the endpoints of the > transformation, or > 2) just define a single CRS. > > Of course, I can't think of many advantages to separating things into > components and the disadvantage is separation of related information. > >> Cheers. >> >> -Dale >> >> ----------------------------- >>> >>> 3) "The fact the Dale wants to distinguish the various tidal datums shows >>> that they define distinct quantities." >>> >>> When I think about it, yes they seem to be distinct quantities. The range >>> of mean lower low water and mean higher high water varies from location to >>> location. A user of the data may not know what the offsets among datums are >>> in a particular area. Heights referenced to these datums (especially MLLW) >>> are very important to local users of the data. As a user of the CF >>> convention and netCDF, I want to make sure that the people using my data can >>> convert the height values we give them into values most useful to them. So >>> inclusion of an offset variable, especially one so intuitively named >>> (altitude_of_mean_low_water) would help me and many of the users of my data >>> immensely. >> >> Even if the user doesn't know the offsets between two tidal datums, they >> do exist. To me, that doesn't seem like enough of a difference to consider >> them distinct quantities. >> >> Ethan >> >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -- > Ethan R. Davis Telephone: (303) 497-8155 > Software Engineer Fax: (303) 497-8690 > UCAR Unidata Program Center E-mail: [EMAIL PROTECTED] > P.O. Box 3000 > Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ > --------------------------------------------------------------------------- > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 [EMAIL PROTECTED] http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
