Thursday, September 12, 2013
(untitled)
Oh, sweet nectar of life: few things taste as good as this first cup of home-brewed coffee after a 42+ hour fast! That peanut butter and honey sandwich was a distant second.
Wednesday, September 11, 2013
New entrants in the Chrome OS space
Big news today on the Chrome OS front: three new Chromebooks and a new Chromebox, all based on the Intel Haswell architecture. I'm interested in these on two different fronts:
- A possible replacement for my aging-but-still-plugging-along dev channel Cr-48, and
- A replacement for my aging Gateway desktop, which is currently running Ubuntu Linux and which we only turn on when we need to print something or when Li wants to play some of her PBSkids games or use ChessKids.com. That system seems ripe for replacement with a Chromebox, perhaps combined with a networked printer supporting Google's CloudPrint.
Lost in translation?
As a follow-on to my earlier post related to prematurely-expired chart images in Adobe ColdFusion, I came across this link: http://www.elliottsprehn.com/cfbugs/bugs/86743
The bug is clearly related to what I am wrestling with, although this bug appears to be more related to orphaned image files piling up. What caught my eye initially was the comments about how at least one of the settings in the CF Admin UI was basically useless the apparent lack of documentation of this configuration file.
Out of curiosity, I wanted to see if this particular bug was ever resolved -- curiosity driven in large part because I am wrestling with this same sort of problem and could easily see this bug (if still unresolved) impacting my servers as we play with the configuration settings to get past the expired chart images.
Guess what? This bug does not appear to exist in the Adobe ColdFusion bug tracker in any form... no matter how I search, I can find no reference to it in their current system: not by content, by author, by ID, or even by date. I can find bugs prior to this and following this but not this one. Which raises a really interesting question: how many other issues like this, that a user of their products troubled themselves to investigate and document, got lost or dropped?
I don't really know what Elliot's system is drawing information from, but it seems like it might be worth Adobe taking a second look at what might have gotten lost.
The bug is clearly related to what I am wrestling with, although this bug appears to be more related to orphaned image files piling up. What caught my eye initially was the comments about how at least one of the settings in the CF Admin UI was basically useless the apparent lack of documentation of this configuration file.
Out of curiosity, I wanted to see if this particular bug was ever resolved -- curiosity driven in large part because I am wrestling with this same sort of problem and could easily see this bug (if still unresolved) impacting my servers as we play with the configuration settings to get past the expired chart images.
Guess what? This bug does not appear to exist in the Adobe ColdFusion bug tracker in any form... no matter how I search, I can find no reference to it in their current system: not by content, by author, by ID, or even by date. I can find bugs prior to this and following this but not this one. Which raises a really interesting question: how many other issues like this, that a user of their products troubled themselves to investigate and document, got lost or dropped?
I don't really know what Elliot's system is drawing information from, but it seems like it might be worth Adobe taking a second look at what might have gotten lost.
Monday, September 9, 2013
Changing perceptions
"For folks who are concerned about putting your digital life in the hands of PPL connect, all transmissions to and from its servers are encrypted. And, the company is currently devising a fully encrypted system whereby the data's only accessible with a single, user-owned key."
From an article on Engadget, but the source really doesn't matter. And you can change the words "PPL connect" to pretty much anything you choose.
My point is that this certainly does not carry the same weight today that it might have a few days ago.
Sunday, September 8, 2013
Sounds
Sitting by an open window this evening, listening to the low rumbles of distant thunder as a late summer storm rolls through on one side and the trickling water of Deb's fountain on the other, and enjoying a couple of finds from the music Ian left us, thinking we might like it: Robert Miles' "Dreamland" and Kruder & Dorfmeister's "G-Stoned". The K&G, in particular, is both a little surprising (but not a lot, given Ian's tastes in music) and pleasing.
Saturday, September 7, 2013
Just wondering...
Deb and I spent yesterday morning on our (typically) twice-per-year task of washing down the outside of our house. Deb almost always couples this task with washing all of the windows, inside and out. The only really enjoyable aspect of this 4-hour job is that it is a good excuse for me to get out the power-washer, but other than that, it is a pretty lousy way to spend a Friday off from work.
Every time we do this, some variation of the same question comes to mind: why do we never see anyone else washing their house? I can't believe we're the only people who do, and although I've never walked right up to a statistically significant sampling of homes in our neighborhood to see how dirty they are, I have to believe other home-owners (aside from those "responsible" for the nearly-abandoned house just to the west of us) have some means of keeping their house clean.
Thoughts?
Every time we do this, some variation of the same question comes to mind: why do we never see anyone else washing their house? I can't believe we're the only people who do, and although I've never walked right up to a statistically significant sampling of homes in our neighborhood to see how dirty they are, I have to believe other home-owners (aside from those "responsible" for the nearly-abandoned house just to the west of us) have some means of keeping their house clean.
Thoughts?
Stuff Li says
Li doesn't like licking envelopes to seal them. She says they "... taste like couscous."
A surprising highlight
Li's U-8 girls team played their first match of the fall season this morning. The end result was, in truth, pretty ugly (a 9-1 loss) but one of the real highlights came from Li. She played the third "quarter" (yes, quarters in soccer: they split the match into quarters to facilitate substitutions) as goalkeeper, and kept a clean sheet. She managed to grab a couple balls, and blocked a couple others.
This from the player who, before the season started when she found out we had a goalkeeper on the field at this level, was pretty emphatic that she did not want to play in goal.
This from the player who, before the season started when she found out we had a goalkeeper on the field at this level, was pretty emphatic that she did not want to play in goal.
Friday, September 6, 2013
Wrestling with expired chart images in Adobe ColdFusion
TL;DR
Change the timeouts specified in webcharts3d.xmlLong Version
We are in the midst of migrating several existing Web applications to Adobe ColdFusion 10 (ACF10) as part of a server consolidation effort at work. One of these apps has a page that takes a Web-eternity to generate (over 30 seconds, in some situations based on load and other what the user has opted to include) based on the sheer volume of data that has to be digested, and includes several charts created by invoking cfchart. For years, we've struggled with situations where the chart images in this particular report don't show up and instead are replaced with placeholder images indicating the image has "expired". In spite of playing with the limited configuration options related to chart caching in the ACF administrator UI, we've never really found a way to ensure the chart images don't expire. (And, yes, we've invested a significant amount of time to improving the efficiency of the logic behind the report and improving performance of the underlying queries used to retrieve the data.) I think we finally made a bit of a breakthrough on this front yesterday.I was wrestling with this problem on my development server, which although reasonably fast, is significantly slower than our staging server where we are testing this particular app. Because my dev server is slower, the problem with these expired chart images was exacerbated and I was consistently getting this particular report back with all of the images expired: good for testing and troubleshooting, but useless in terms of the report itself. The ACF admin UI provides only two configuration options that seemed relevant to solving the problem: the size of the cache (how many chart images will be cached) and whether the chart images are cached to disk or to memory. The cache size on my dev server was configured at 200 charts, but given that I am the only one who can connect to my dev server, it made no sense that the half-dozen charts on this report could be expiring based on the cache being filled quickly enough to cause them to be expired. They had to be expiring based on something else... age, perhaps?
I verified this by switching the cache to be on disk and watching the content of the folder being used for the cache. In spite of the specified cache size in the ACF admin UI, there were never more than a handful of image files present in the folder. Something other than the number of chart images was at play here.
A quick search of the ACF bug list yielded nothing relevant in terms of a known problem. Searching the ACF forums brought up a couple other topics related to expired images but nothing that on the surface seemed really relevant to what I was seeing. The entry that seemed most relevant was in a clustered environment and seemed to be related to how requests got moved among the various servers in the cluster and how that seemed to be leading to expired chart images. But... in that post there was a reference to an XML configuration file for the underlying charting engine... and a timeout parameter in that file.
The ACF forum post referred to minTimeout and maxTimeout parameters in a configuration file named webcharts3d.xml. At least on my system, that file resides at {cf_home}/cfusion/lib/webcharts3d.xml. Locate the <server ...> element near the top of the file, and adjust the minTimeout and maxTimeout attributes. On my system, they were set to 5000 and 30000, respectively, which I believe to be 5 and 30 seconds. When I saw those values, I was convinced I had found my solution, as it seemed like when the report in question took more than 30 seconds to generate, I was consistently getting the expired images. Recognizing that this long-running report can take as long as a couple minutes to generate under load, I changed the minTimeout attribute to 120000 (120 seconds) and the maxTimeout attribute to 300000 (5 minutes). I saved the file and bounced ACF on my dev server, and... no more expired images. Watching the cache folder, I started seeing images pile up (as I would have expected). Problem solved.
Having said that, I still have a couple questions:
- What exactly do those configuration parameters in the ACF admin UI for cache size and number of threads actually control (if anything)?
- Is there documentation somewhere for the webcharts3d.xml file, explaining what the cache, minTimeout, maxTimeout, cacheSize, and maxThreads attributes do? Several of those have similarly-named settings in the CF admin UI but updating the CF admin UI values does not touch this file. So far, I've not been able to find any documentation on-line.
And for the record, this just might be the first time I've found something of value in the ACF forums, but that's a topic for another post and another day.
The importance of purpose
Li started first grade this week. In her class, each of the students is assigned a job and they rotate through the jobs over the course of the school year. I love the fact that Li is so excited to have been assigned the job of "paper and pencil monitor" even though she indicates she has no idea what that job means or what she will have to do...
Thursday, September 5, 2013
Subscribe to:
Posts (Atom)