Anyone see the bug in my WordPress theme? I should update it if a new one is available.

Hint: check the post times . . .

Thanks to Cindy at Digital Ramble for releasing her BloglinesBlogroll plug-in. I made some modifications to improve the appearance (stripped out

When viewing YouTube or Google Video on my Powerbook, sometimes sound won’t play from the movies. (Sometimes the movie won’t play at all–that’s when I need to reboot.)

Fixing the sound is easy: change the MIDI input rate to 44 KHz instead of 96 KHz in the Audio MIDI Setup utliity.

Thanks to Fredericiana for the tip!

Main kinds of caching strategies:

• in memory (efficient lookup data structures, such as maps or trees)
• dbm (bdb)
• rdb
• disk (memory mapped or ISAM, which often backs the database solutions)

Caching in large scale systems
Multiple servers in a cluster provide an in-memory live cache of important data objects (such as purchases, character records, insurance policies, etc.). Replication and coherency occurs across the caching cluster to provide for failover and load balancing.

For smaller services and systems, in-memory (per server) DBM-backed hashmap (or some other in-memory data structure) provides ready access and replacement, with expiration times and coherency occuring through certain operations which reset the state of the cached and persisted values.
(more…)

Mike McShaffry warned me about it in Game Coding Complete. Others likewise mentioned the risks of using malloc() and especially realloc() and how most developers replace them with custom calls. NeXT OS malloc() was so broken that Pavel Curtis, et al, shipped LambdaMOO with GNU malloc().

But I had to learn the hard way. Let my benchmarks stand in testimony as to why unrestrained use of malloc() and realloc() is dangerous and why Python managed to outperform naively written C and C++ optimized native code.

This is yet another reason schools should teach C before Java or another VM-hosted or interpreted language.

(more…)

Is guaranteed delivery of a message and resiliancy of the message infrastructure more important than speed and architectual simplicity? Systems like TCP provide guaranteed delivery (or notification of failure) within a relatively simple peer-to-peer system, without relying on an all-knowing message queue to guarantee delivery. This implies that each host in the TCP transaction knows about its peers in some way (such as DNS). Due to its robust design and clean interface, TCP is a reliable base for many application protocols.
(more…)

Failover and state consistency in clusters has a number of non-trivial cases. Below are a few cases where message delivery speed is less important than consistency and guaranteed delivery. To balance multiple MQs, MQ requests should be load balanced (say, through round robin scheduling).

In cases where consistency and guaranteed delivery are less important than speed, requestors can poll multiple MQs with different representations of the service queue state. Likewise, where failover or reliability are less important, a single MQ can be used. Finally, it may make sense to not use any MQ and instead put the queue on each service and deliver messages directly.
(more…)

Following up on my last post about a base self-configuring service class, horizontally scalable services need remote management functions.

• Authentication – Determine if a management client is permitted to connect and issue commands
• Remote Creation – A service daemon lists for creation requests and creates service instances
• Remote Shutdown – The service itself should be able to shut itself down in response to a management command (either because the cluster is shutting down, the software needs to be upgraded, or the service load is low enough to not be needed)
• Load Reporting – When queried, a service should be able to report its load to a client (such as a dashboard monitor)
• Alerts – When certain load thresholds or error rates are exceeded, a service needs to be able to report an alert condition
• Metrics – in addition to load reporting and raising alerts to a monitor, each service should be responsible for providing detailed metrics (generally, these should be logged to a RDB rather than a log file)

This implies dashboard (web) and management (C/S or web) clients. Service management is a backchannel between all services, including those that may not normally respond to network clients (to use a bad example, a log archiver).

Some services are implied by these requirements:

• Management Service – Collects metrics and alerts, provides the dashboard
• Watchdog Service – Makes sure critical services are healthy and restarts them on failure, listens for service creation requests

Finally, a main channel for communication between services should be available, although not all services will take advantage of it. A Message Queue service receives service-to-service messages in a cluster and ensures consistency and delivery. I’ll cover the design for clustered services and the message queue in another post.

I’ve been mucking around with a simple Java based service framework. Configuration is done from a simple (if verbose) XML file when the service is created.

ServiceManager.jar (71k)

This is intended to be used in an system that manages multiple services and provides a base implementation for configurable services. Later, the base service should support remote management.

Why Java and not Python or C#? Execution speed, portability, and that I have an annoying tendency to like statically typed languages. I find it’s harder to verify all execution paths in a dynamically typed program because the compiler won’t catch many runtime type errors. Has anyone found a good solution for that? The biggest problem with C# is that I don’t feel like I have a good development environment on each machine I use. Ironically, Amazon’s laptop has the worst: because I don’t have admin rights, I can’t install a C# IDE.

To catch Java VMs when shutting down, you can hook the runtime shutdown process with a custom thread implementation. You can also register signal hooks (like catching HUP) to add behaviors like reloading configuration files, etc.

// register the shutdown hook
Runtime.getRuntime().addShutdownHook(new Thread() {
    public void run() {
        logger.log(Level.SEVERE, “Caught shutdown hook on server.”);
 
        stopServer();
    }
});
 
// register the interrupt hook (in Win32, this is CTRL-C)
Signal sigInt = new Signal(“INT”);
SignalHandler sigIntHandler = new SignalHandler() {
    public void handle(Signal arg0) {
        logger.log(Level.SEVERE, “Interrupt signal caught.”);
 
        stopServer();
    }
};
Signal.handle(sigInt, sigIntHandler);
 
// register the terminate hook (in Win32, close console window)
Signal sigTerm = new Signal(“TERM”);
SignalHandler sigTermHandler = new SignalHandler() {
    public void handle(Signal arg0) {
        logger.log(Level.SEVERE, “Terminate signal caught.”);
 
        stopServer();
    }
};
Signal.handle(sigTerm, sigTermHandler);