BCaching 0.9.1

A minor update to the site today.
- Simplified sign up process and added Geocaching Cacher ID to profile page
- Corrected coordinates were not used in mobile “Nearest” view, not being shown on desktop or mobile maps, or when downloaded as GPX or to Garmin device
- UI tweaks on desktop map for IE
- Send to Garmin device was not honoring the max count

BCaching 0.9

The latest bcaching release 0.9 is now live. There were quite a lot of internal changes but the appearance and behavior of the site should be very similar to before.

Although I did my best to test all aspects of the site to make sure nothing was broken, there were a LOT of changes so there is a higher probably than usual that I missed something. Please be on the lookout for any issues and post details on the forums as soon as possible.

This was the 2nd major overhaul in data organization. The last one was a little over a year ago when we migrated from a relational MySql database to the document-based MongoDB. At the time, many relational concepts were carried over instead of taking full advantage of a document structure.

I also took the opportunity to make some other wish-list changes. One of which was the need for all users to be associated with a geocaching.com cacherid. This was because all user-related data on the site was tied to a cacherid. With the reorganization, user-related data is tied to the internal bcaching userid. In the future, that will allow new users to take advantage of the site without necessarily being geocaching users.

I’m also experimenting with showing Munzee data mixed with geocaches on the desktop and mobile maps. This is a work in progress, but if you want to take a look you can enable this feature on your profile page.

Stay tuned.

Unexpected power outage

There was an unexpected power outage around 2AM EDT and MongoDB did not start up cleanly which left the site down until later this morning.

Free space and repaired database

On Sunday I ordered a new VPS that has more disk and RAM (80GB/4GB vs 40GB/2GB), but less redundancy for a few less dollars. The database server has been migrated over and was reloaded/repaired. It’s also running on the latest version of the software with journaling enabled which should significantly reduce the chance of data corruption in the future.

You may have noticed that GPX file processing is now running behind schedule. It’s not because the pocket queries were backed up, but because the GPX processing is still running on the old machine and the geographical mismatch of the two servers has increased the latency, causing the processing to run a bit slower. GPX processing is database intensive and runs best when it is “near” the database server. Since the database server and GPX processing are now on separate machines, one of which is in Denver and the other in Chicago it’s taking longer than usual. I will be moving the GPX processing to the Database machine in the next day or two so processing speed should improve then.

Update 3/11/2012: Finished migrating web application, autogpx processing, etc. over to the new VPS and processing time is back to normal.

Out of disk space again

Time to upgrade the server again.  I have to apologize to those of you who have been unable to upload new pocket queries. We’ve been busting at the seams of the current system over the past couple months and this morning it hit the fan again.

I’ve been planning to migrate to an alternate “economy” service that has less of the extra features that we don’t use anyway, but provides double the disk space and RAM. I was going to try to wait until the end of April since the current cycle ends at the end of May, but it seems we just can’t wait so I’m ordering the new service today and will move the databases over ASAP.

Alternate fix for IIS6 eurl.axd 404 error

With ASPNET 4.0 there is a breaking change when using IIS6 with a website that has “legacy” ASPNET 2.0 mixed with ASPNET 4.0 applications.

Extensionless URLs that used to be sent to your configured “default content page” such as “Default.aspx” will instead be sent to eurl.axd followed by a hash code. Unfortunately your ASPNET 2.0 application will not automatically handle that.

Microsoft provides 3 workarounds in its ASPNET V4 Breaking Changes document. Two of them are to not mix ASPNET 2.0 and 4.0 applications in the same web site. The third is to disable extensionless URLs altogether.

But what if you DO want to mix ASPNET 2.0 and 4.0 applications in the same website AND use extensionless URLs in your 4.0 application?

Why not just handle the eurl.axd path and redirect it to your default document? This worked for me:

1. Create a class library (i.e. eurlredirect.dll) with a single IHttpHandler class.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;

namespace eurlredirect
{
    public class RedirectHandler : IHttpHandler
    {
        public bool IsReusable
        {
            get { return true; }
        }

        public void ProcessRequest(HttpContext context)
        {
            context.Response.Redirect("Default.aspx");
        }
    }
}

2. Add the class library to your ASPNET 2.0 bin directory.

3. Configure the handler in the ASPNET 2.0 application’s web.config file by adding the following entry to the <httpHandlers> section:

<add verb=”*” path=”eurl.axd” validate=”false” type=”eurlredirect.RedirectHandler, eurlredirect”/>

 

Web server power failure

I don’t know all the details at the moment, but apparently there was a power failure last night around 10 PM EST. The server restarted but not cleanly and needed some manual intervention to get things running correctly again.

Alert emails were sent last night, but I did not check my email until this morning.

Sorry for any inconvenience this may have caused.

Release 0.8.1

0.8.1 is a minor release with a few enhancements.

You can now read your autogpx email messages online, and GPS management has been improved on the mobile map view and the mobile location page.

See the forum post for more details:
http://www.bcaching.com/forums/viewtopic.php?f=2&t=226

Happy July 4th Weekend

We’re on our way to GeoWoodstock IX. Maybe we’ll see a few of you there!

M & W

Site maintenance

Some of you may have noticed bcaching was out of commission for a lengthy period from Thursday night until Friday morning. This was in order to complete as much of the database reorganization (a.k.a. phase III) as possible.

When cache logs were migrated to the new database (mongodb) using the same layout as before (a single list of logs by cache log id with a secondary index on cache id), it caused similar slowdowns as before (on mysql). It’s just too much data and the indexes are too large for the limited resources we have available.

The reorg – to a list of cache documents, each containing all of its related logs – was going painfully slow for about a week and a half when I finally decided to shut the site down for an extended period and use all the server resources to try to just get it done.  It was going reasonably well (maybe 85% complete) until around 5:30 in the morning when mongo decided it needed to allocate more space in the filesystem, even though there was more than adequate space already freed up from dropping the old cache logs table. The problem was likely due to fragmentation within the database files. A “repairdatabase” would have solved it by defragmenting and really freeing up the unused space, but like mysql, mongodb (1.8) requires free disk space to create a new clean copy of the database before it deletes the old one. I didn’t have the space. Luckily mongodb has excellent backup and restore functions that allows backups to be done to and from a separate server so that’s what I did. Incidentally, the next release (2.0) will support an in-place repairdatabase function.

So after the database was restored, I brought the system back up with partially migrated cache logs. You may encounter a few caches that have no logs, but don’t be alarmed. They will reappear over the next few days.

Update 6/19/2011: The cache logs migration is complete. Finally!