Veritas cluster server is often used in corporate environments to provide clustering and high availability. Veritas is a complex, closed source product that provides integration for lots of enterprise software such as SAP or Oracle, but it is very simple to use it to cluster open source software as well.
In order for Veritas to manage a piece of open source software you need to provide three scripts; a script to start the service, a script to stop the service and a script that monitors the status of the software. The start and stop scripts don’t need any special knowledge they just need to start and stop the service, if the application has an init.d script that should be sufficient for the start and stop script.
So if we have a mythical open source application called gherkin then the Veritas agent can be configured to use this as a start script:
and this for the stop script:
Unfortunately Veritas doesn’t use standard UNIX return codes for monitoring it has its own numeric values, namely 110 for an active service and 100 for an inactive service, so you will need to provide a script to map the services status to these numbers.
For example if our mythical open source application returns status from its init.d script then we will need a script like this:
#!/bin/bash if /etc/init.d/gherkin status &> /dev/null; then Â Â Â Â exit 110 else Â Â Â Â exit 100 fi
This maps a standard UNIX successful return code to the Veritas success code, 110, and everything else to the Veritas failure code, 100.
Languages like ML, Newspeak, and Scala support pattern matching: it’s a bit like a case/switch statement, only instead of matching on a series of boolean conditions you switch on the shape of some variable. But Prolog goes twice as far: Prolog uses unification. What’s that, you ask?
We have a C# project that recently started to run into a few scaling issues. That search can slow down a little when you get a lot more records isn’t so surprising, but when your basic individual item retrieval starts getting sluggish, it’s time to worry. We were using Entity Framework as the ORM layer, but I suspect this would apply for anything in C#.
LINQ, and the overuse of abstraction is a lot of the problem here. I’m a big fan of LINQ, but as with all abstractions, it fails, at least a little, and every so often it fails a lot. Instead of doing a
select * from FooTable where id = blah you’re doing
context.FooTable.Single(ft => ft.id == blah) and expecting that the results to be identical. Well, to some extent they are, but the intermediate steps can be very, very different, and it depends on your original data types.
You are currently browsing the LShift Ltd. blog archives for May, 2011.