Back from Vancouver

Welp, faster than a blink, I’m back from Vancouver. Unfortunately, on my second night there I came down with this nasty GI thing that dragged me down for the rest of the trip. I managed to get out and do some walking along the Coal Harbor Seawall and in Stanley Park. But, my planned recreational activities were severely curtailed. The conference was good, although I missed a couple of meals and sessions due to the illness. Bummer.

Verdict on American Airlines is neutral. check-in difficulties and a delayed connecting flight on the way out were offset by a perfectly smooth trip home.

Hopefully, JA-SIG will continue to have occasional conferences in Vancouver. Next time, I’d like to take the whole family.

Anyhow, now I’m back home and back to the daily grind. I’m slowly working through my beer stash. Tonight I tried Magic Hat Humble Patience, which purports to be an Irish Red. It’s a very good beer, but it seems a little chocolaty for an Irish Red. Then again, I very rarely drink this style (it’s not as common as other styles around these parts), so I’m not really an authority on it. Wharf Rat used to brew one; maybe I should get out there and try one for comparison.

Magic Hat is all over the place around here. It’s interesting that it’s so ubiquitous, given that it’s brewed in Vermont. They must have a very good distributor network..

Back in Vancouver

Well, here I am in lovely Vancouver, BC again. Today is my free day, and it looks like my hopes of hiking/sightseeing are going to be dashed, because of a steady drizzle. Oh well, I guess I’ll try to squeeze something in Tuesday evening, when the conference is over and the weather forecast looks more promising. As for today, well, I guess I can get some work done..

So I’m here at this Comfort Inn for another few hours before I take the bus downtown to the conference hotel. Here’s a good one.. At the Comfort Inn, I have complementary wi-fi here in my room. At the conference hotel, which costs three times more per night than the Comfort Inn, I (well, UMBC actually) have to pay $14.95CAD/day for internet access in my room. What’s wrong with this picture?

Now, the Comfort Inn is not fancy, nor is the area it’s in, but the room is clean and perfectly adequate and the wi-fi is nice. For the price, it’s a great value and I’ve always been a fan of the chain for that very reason.

Today’s agenda is… get breakfast, sit around and watch it rain, head over to the conference hotel, sit around some more and watch it rain, and figure out what I’m doing for meals. Maybe I’ll check out the fitness room at the Westin. I think my biggest regret is going to be not bringing an umbrella. Sigh..

Bike to work: the month of May in review

I was only able to bike to work 8 times in May, due to a variety of reasons.. early in the month, I caught a cold, and various obligations at home made it necessary to take the car on several days I otherwise would have biked. Later in the month, I had a week where I couldn’t drag myself out of bed in time to get moving (it’s amazing how much a single late night out screws up my body clock nowadays). I also had this mysterious dry cough that came out of nowhere and persisted for about 4 days. But, now it’s the end of the month and I seem to be back in a good routine. Despite the relative infrequency of my rides, I managed to ride in at least one day each week of the month. My average speed is now consistently over 14mph. This morning I averaged 14.8mph, my high for the season so far.

This past weekend, I picked up two new pairs of biking shorts on sale at Performance. One has the standard chamois padding and the other has this gel stuff. The price was the same, so I figured I’d try ’em both. I’ve ridden once with each pair now. The chamois pair is fine, but the stitching on the gel pair bothered me a little bit. I’ll see how it goes as they break in, but so far I’m not crazy about these.

I’ve also logged almost 1000 miles on my cyclocomputer, a Cateye Astrale. Verdict so far: It’s nice, and I especially like the cadence feature. However, I wish it gave some kind of audio feedback when starting/stopping the timer. There have been a lot of times where I’ve thought I’ve started it but it wasn’t actually running, and vice-versa, and as a result I haven’t gotten any statistics for a particular ride. Forgetting to start/stop it is one thing, but it’s really annoying when I’ve actually made a point to do it, and still don’t get my stats. Otherwise, though, I really like it. Cateye has come out with a newer model since I got mine, so I wonder if they’ve addressed this problem.

June will start out with a week of no biking due to my business trip. However, I hope to get right back into it afterwards.

Next year’s pool project

I’m already thinking about next year’s pool project, and I haven’t even started this year’s yet…

For next year, I’m considering adding an automatic chlorine feed using a chemical metering pump, similar to the setup described here. The main goals of the project would be:

  • Save work;
  • Save money on chlorine by matching the supply more closely with the demand;
  • Provide a continuous feed of sanitizer, thereby eliminating the need for cyanuric acid in the pool.

If I go ahead with this, I’ll probably also move the pool’s electrical controls indoors, which I’ve always wanted to do for convenience more than anything else. I’d also need to run a dedicated 110VAC circuit to power the metering pump, so while I’m at it, I’ll install a convenience outlet near the pool equipment. Right now, I only have 220VAC there.

The metering pump can be had from Grainger for around $300, but I’m watching eBay to see if I can get a new one cheaper.

I’ll add random notes to this entry as I think about this one.

Portal Meltdowns

We had another portal meltdown this morning. I figure I’ll keep a “meltdown log” of sorts to record notes, etc. Hopefully it’ll help me get to the bottom of this.

Background: Every so often, the portal becomes unresponsive. There seems to be no correlation to system load (high demand etc). For example, spring final exams ended yesterday, and today is one of the quietest days of the year around here. Yet we had a meltdown this morning.

Observations:

  1. In portal.log, there are always lots of these DBCP-related errors.
  2. The portal fills up its DB connection pool very quickly and I often see log messages that the pool is “exhausted”.
  3. Lots of ALM-related infinite loops, in getFirstSiblingNode and others. I’ve put loop-breaking code in various spots; otherwise, all the busy-looping threads would kill the JVM pretty quickly. I have it logging the portal userid when this happens, and it doesn’t seem to be limited to specific users. In fact, I picked one from an error log, checked his portal account later, and it worked fine.
  4. When the problem is occurring, restarting the portal (web server, JVM, the whole 9 yards) does not fix the problem.
  5. Both portal server boxes (uportal1 and uportal2) are always affected at the same time, ostensibly ruling out an issue involving the OS, Apache, or Tomcat.

I did a JVM thread dump. One thread was hung doing a database commit (?!?) inside portal.RDBMUserLayoutStore.getNextStructId, a synchronized routine. All other threads (98 of ’em) were hung waiting on this one thread.

[More:]

Sometimes, this problem magically resolves itself. Other times, it’s resolved after the DBA restarts the Oracle instance. We’ve hypothesized that this is being caused by an errant app running at the same time, which is dragging down our database instance. I’m not sure if I buy that or not. But right now it looks like, somehow, a thread is hanging inside a critical section, thereby locking up all the other threads; and the locked threads are all grabbing DB connections from the DBCP pool and never releasing them, thereby hosing up the pool. Next time it happens, I’ll do another thread dump and see if the lockup is in the same spot.

I also did a dump of active portal sessions to see who was logged on around the time of the meltdown. When it happens again, I’ll do another dump and cross-check the two, to see if a particular user or users might be causing the problem.

6/1: Happened again. Lockup occurred in exactly the same spot, with all threads locked waiting on another thread trying to do a database commit. WTF is going on here..

Today’s PAGS tweak

Today I fixed the latest crop of users with portal-access issues: Previous students who took a semester off, or never completed a degree, who want to use myUMBC to register or retrieve a transcript. These students do not have a student affiliation in LDAP, because they’re not “current” students. They also lack an alumni attribute as they never completed degrees. As such, they don’t see the “Academics” tab because we limit display of this tab to users with student or alumni affiliations (well, and a few others as well, but that’s beside the point right now).

Our LDAP directory does not have an affiliation for “past-student-who-never-graduated”. However, we have an attribute for the last term a user was registered for classes. In theory, if a user possesses this attribute, that indicates that they were a student at some time in the past. We can give them the “Academics” tab by expanding the UMBC Student PAGS group to include people with this attribute.

[More:]

Laundry list for doing this:

  1. Make sure the LDAP attribute in question is available in uPortal as a Person Attribute. If not, add the attribute to PersonDirs.xml.
  2. Edit PAGSGroupStoreConfig.xml and add any new groups (or edit existing ones) to incorporate the new attribute.
  3. Redeploy, restart and hope it doesn’t bomb.

In our case, I added an additional clause to check for presence of the umbclasttermreg attribute using the PAGS “Value Exists Tester”, org.jasig.portal.groups.pags.testers.ValueExistsTester.

The PAGS entry on the JA-SIG Wiki has improved quite a bit since I last visited it. Caveat emptor: It references ValueExistsTester and ValueMissingTester. Initially I blindly followed the docs and tried to use ValueExistsTester, and things didn’t work. It turns out these two testers are not present in uPortal 2.4.3.. I had to add ValueExistsTester manually. It’s only around 10 lines of Java, but the Wiki ought to mention that it’s not in 2.4.3.

Dell Widescreen Monitor + Linux: Utter & Complete Frustration

I just wasted an entire day trying to get a new Dell 2007WFP working with my 3-year-old Dell GX270 desktop, which runs Debian. The result: total failure. It works at 1280×1024 (and looks all stretched out), but flatly refuses to work at the monitor’s optimal resolution of 1680×1050.

In the xorg.config file, first I tried just adding a new “Screen” resolution for 1680×1050. This failed with “no such mode” or somesuch. After much head scratching and googling around, I learned that I needed to patch my video BIOS (Intel 810 series) to add the new mode. I did this via a utility called 915resolution. This seems to work.

With 1680×1050 programmed into the BIOS, I then tried several different ModeLine entries in the config file, with varying different modes of failure. At certain settings, X would refuse to use the mode, complaining about “vrefresh out of range” or something. At other settings, when I started X, the monitor would go into power-save mode as if it wasn’t receiving a signal. At other settings, the monitor would display a message stating that the signal was out of range and it couldn’t use it. I fiddled with turning DDC on and off, to no effect. Everything I tried resulted in one of these three failure modes. I’m pretty sure I’ve got good ModeLine numbers, as they match what’s reported by DDC in the X.org log.

I’m pretty much at my wit’s end here, so I’ve given up for now and am back to using my old dual-monitor xinerama setup. Needless to say, I’m not too high on the whole Linux/X desktop scene right now. I’m ready to punt the thing and go to a Mac.

Portal session management tweak

I’ve decided to work a little harder to make myUMBC work for more users. Of course, the ulterior motive is to save work for myself and the help desk. Actually, sometimes my entire job seems geared towards doing things to save myself work. I guess once I’m completely successful, I’ll be able to just sit around my office and surf porn all day long. But anyhow..

We really need a way to make myUMBC work for people without a SSN (soon to be HP-ID) attribute in LDAP. Background on this problem is here. These people are able to log into the portal, but since we can’t look up an identifier for them, we can’t authenticate them to the legacy portal code. As a result, they can’t properly render any of the web proxy channels served by the legacy portal server. These channels handle all of myUMBC’s SIS related functionality (IOW, most of what you currently would want to do in myUMBC), so in effect, this leaves these users dead in the water.

[More:]

Now, unless we know the user’s HP-ID, the user still won’t be able to do anything really useful in the portal. However, we’d still like for them to be able to navigate through the portal and see the channels. To fix the user “for real”, we need to do one of the following:

  1. Manually query SIS to see if the user has an HP-ID. If so, check LDAP to see if the user has multiple entries, and merge the entries if necessary. Otherwise, manually add the user’s HP-ID to LDAP, so we can map the username to the HP-ID. If no HP-ID in SIS, instruct the user to contact the registrar’s office and request one.
  2. Do nothing, and hope the problem resolves itself (might just have to wait for the user’s info to percolate through the various systems of record).

What we’d ideally like to do, is get the portal to do the work for us. If a user logs in and we can’t find an HP-ID for them, we need to get in their face and tell them to contact the registrar to correct the problem (duplicate LDAP entries are a difficult issue, though.. I’m hoping that some of our problems with them will go away after we finish with SSN remediation). But in the meantime, we should make portal navgation work for the user, so they can at least get to functionality that doesn’t require a “real” HP-ID.

The solution I came up with, was to assign the user a “fake” HP-ID on the fly when they initially log in. We can then use that as a primary key for the legacy session management table (auxil.www_sessions), and the user will be able to render the legacy web proxy channels.

The basic logic for getting a session table key now looks like this:

  1. Query auxil.myumbc_user_preferences table for an SSN (HP-ID) that matches the user’s UMBC username. If successful, use that. This allows us to map the user’s LDAP SSN to the SIS SSN when the two differ, which happens a lot when the user’s SSN changes and the change hasn’t percolated to one or the other system. Hopefully, we won’t need this step after SSN remediation, because the HP-ID is never supposed to change.
  2. Query LDAP for the user’s SSN (HP-ID). If successful, use that.
  3. If we couldn’t find the SSN that way, query the legacy session table for a temp SSN matching the username (indicating that we’ve already created them a temp identifier). If we find one, use it.
  4. If all else fails, generate the user a temp identifier within a specified range (currently 995000000-995999999) and use that.

The user is thus able to render legacy channels right away. And the nice thing here, is that once the user gets a “real” SSN (HP-ID) in our system, it’ll automatically stop using the temporary one without any intervention on our part.

All of this magic happens in edu.umbc.uportal.UmbcPersonFactory, which currently lives in the main uPortal source tree.

I have this in production now, and I’ll be keeping an eye on it to see what problems develop. If it seems to be working, we’ll need to see about somehow hassling the user to get the problem rectified. This might be something to do via the big, fancy, vaporware alerts system we’re supposedly launching this fall.

The fun never ends..

Leaf Blower/Vacs: Echo vs. Toro

Here we have it: a head-to-head comparison between the Toro Super Blower/Vac and the Echo ES-210 Shred ‘n Vac. I’ve used the Toro for 3 or 4 years now, and recently bought the Echo. First things first: I’ve always liked the Toro. But, it’s electric, and the cord has always driven me nuts. One of the things I use it for is clearing around my swimming pool. And, corded tools and swimming pools just don’t get along well. Half of the time is spent routing the cord so it doesn’t fall in the pool or get snagged on stuff. And then, the cord is never quite long enough to go everywhere I need to use the unit. So, my primary motivation for buying the Echo was to get a unit that performs similarly to the Toro, sans cord. With that in mind, here’s how the units compare in various departments.

[More:]

Performance: Both units have about the same amount of power, that is to say, they’re both adequate for clearing paved surfaces, which is my primary use for them. The ES-210 has Echo’s smallest blower engine (21.2cc). It’s not going to move big piles of wet leaves in tall grass, but that’s not what I bought it for. Vac performance is similar for both units as well.

Controls: The Echo is a little more versatile in that it has a gas engine with a variable throttle, so I have more control over the blower velocity. The Toro has a two-speed motor (although there is a different model available, the “Ultra Blower Vac”, with a variable speed motor).

Ergonomics: Being gas powered, the Echo is heavier than the Toro, with a dry weight of 9.7lbs plus the weight of the gas. That’s a tradeoff you have to make with gas vs. electric. Operator fatigue will become an issue with any handheld blower after a certain amount of time which varies inversely with the weight. However, for the length of time I typically use the thing, it hasn’t been a problem for me. FWIW, 9.7lbs isn’t too bad as far as handheld gas blowers go — Echo’s next model up, the ES-230, is almost 2 pounds heavier.

In vac mode, the Toro’s ergonomics have always seemed a little awkward to me. The Echo is better in this department.

Convenience: For blowing, you can’t beat a gas blower for convenience. Just take it down, start it up, and blow away. No cord to unspool, set up, and put away when you’re done. Of course, that convenience goes away if the blower doesn’t start easily. With two-cycle gas engines, it’s worth it to pay a bit more and get a brand like Echo or Stihl. The payback is an engine that starts reliably every time, and saves countless hours of aggravation. Don’t waste your time or money on cheap two-cycle engines.

With these particular units, another important convenience aspect is the ease of converting from blower to vac and back again. The Toro has the edge here. With the Toro, I can convert in just a few seconds. All of the pipes have quick release tabs, so it’s just a matter of pulling off the blower pipes and snapping on the vacuum pipes and bag. With the Echo, I have to twist the blower pipe on and off, which is harder to do than with the Toro. Then I have to secure the vac pipe to the unit, which requires a screwdriver to tighten a band clamp. Tho whole process takes a couple of minutes, which is still acceptable, but it’s slow and cumbersome compared to the Toro.

Maintenance: Another department where the electric wins, for obvious reasons. A gas engine requires periodic maintenance while an electric one doesn’t. Of course, there’s not too much that needs to be done with a two-cycle blower.. very few moving parts, no oil to change, etc. End-of-season maintenance shouldn’t take more than 10 or 15 minutes. In my case, I already have 6-odd other gas engines that I maintain, and taking this one on wasn’t really an issue for me at all.

Price: Toro: $60. Echo: $200. Nuff said 🙂

In conclusion: It’s hard to go wrong with either unit. The deciding factor is the cord. If you can deal with the cord, buy the Toro. If not, buy the Echo. Of course, you may think you can deal with the cord at first (as I did), and then find that it’s too much of a hassle. In my case, it’s also a potential hazard. So, I switched to gas and I’m happy. YMMV!

Pool still covered

Yesterday was supposed to be the big pool-uncovering day, but it didn’t happen. The original plan was to open it early so I could get my coping project underway. But, yesterday it occurred to me that I could get started with the cover still on, and just pull the cover back to expose whatever area I happen to be working on. At that point it became a no-brainer: Leave the cover on for now and avoid the hassle of keeping the pool clean in late May when no one is using it.

I already had my help on the way over, so instead of uncovering the pool, we tackled the time-consuming job of scraping the old caulk out of the coping expansion joint. This was fairly easy to do with box-cutter type utility knives and plenty of sharp blades. However, on the decking side, it left a bit of residue because of the roughness of the concrete. I may try wirebrushing this area to get the last bit of caulk out.

Next up is to rent the big concrete saw and cut a true expansion joint (removing the caulk revealed that, as I expected, the joint is non-true around the entire perimeter of the pool). My current plan is to take a day off work and do it the week after Memorial Day. I’d like to get it done before my Vancouver trip; otherwise it’ll have to wait until June 10 at the earliest. Come to think of it, I suppose there’s nothing stopping me from doing it this week, either.. To deal with the dust, I’ll try duct-taping a tarp to the coping edge. With the cover still on, it’ll support the tarp and keep it from submerging. It might work.

I did my first water test yesterday, and surprisingly the numbers weren’t too bad: Free Cl 1.4, Combined Cl 0.2, pH 7.7, Alk 80, Hardness 170, CYA under 30. Water temperature was 63°. I’ll probably add some chlorine today.