I have not voiced my opinion on anything in the past year but I just have to make my opinion known on our transition to OpenSolaris from FreeBSD at Fabulously40. It has been absolutely freaking spectacular!

First off, some admins might want to flog me for using the bleeding edge OpenSolaris Indiana install for a production setup. However, I feel comfortable enough to use it in our production setting. Its not like we are a banking site or something ridiculously mission critical. I am sure the OpenSolaris community could use some early adopter reports from production server use, if there is even any to report at all!

First off why the switch and what went wrong with our old setup

For about 3 years we happily hosted Fabulously40 and other sites including this blog on an initial FreeBSD-5.2 install, which has been upgraded to 6.0,6.1 and 7.0 respectively. I gradually saw performance get better with FreeBSD with each new release. During this time frame it all ran fine. We had little traffic and all was good until we started pick up on more traffic. I would have monthly or bi-weekly kernel panics. I filled out tickets for a techie to run some diagnostic tests on the hardware from where we were renting out the server from. They told me all was okay with the hardware. Enough was enough so we decided to go with our own dedicated hardware.

So we purchased a 2 socket quad core xeon 5355 (8 cores total), 4 gigs of ram , 500×2 gig drive 1u rackmount. The thing is a beast.

Since now we own the hardware, I can go with any OS install that I want. Oh, it feels like being a fat kid in a candy shop. I could try our luck again with FreeBSD but after all these stability issues I am not sure I want to risk it again. So I took a look at my options; Linux (debian), NetBSD or OpenSolaris. I have had extremely good uptime with NetBSD at home on a Soekris router. However, NetBSD does not scale well with many-core systems and does not have Jails. Linux looked like a good candidate but after looking at the software RAID setup, nope not for me, just seemed really arcane and complex and no Jail support. OpenSolaris seems to have everything that I want in a server OS, everything "just works." Mirror raid support works out of the box thanks to ZFS and Solaris takes the Jails concept to a whole new level with Zones.

NetBSD

pros:
Good stability from my experience

cons:
Does not scale well to many cpu cores (hear say)
No Jail support

Linux

pros:
Scales to many cpu cores
apt-get, large package repository

cons:
Lack of Jail support, chroot is primitive.
Complex RAID setup

OpenSolaris:

pros:
Stability (hear say, lets see what happens)
Scales well to many cpu cores
Zones - Jails taken to the next level
ZFS - file system taken to the next level

cons:
pkg, great starting point but small repository.
Using Sun Studio 11 to compile perl and ruby (makes cpan/gem modules require it, note: roll your own ruby/perl/python in a custom prefix instead)
Software packages such as Varnish and PowerDNS need patching to get them to run on Solaris.

So I decided on OpenSolaris. I absolutely love the system. The observability in the OS beats the crap out of anything out there. DTRACE is king, I am already addicted to dtrace one liners. Adding dtrace SDT probes to software such as nginx is brain dead simple. Took me about 30 minutes to figure out how to add dtrace probes into nginx, and I have no C/C++ knowledge! ZFS, this is what we should be expecting from modern filesystems. I am hooked on snapshots, I am already contemplating on using it for postgresql hot-backups. Zones, I love it. I wish I had zoneadm on my FreeBSD boxes at work to control jails. Zone management is a whole lot easier than working with Jails. Furthermore, I have no issues using perl's cpan command utility in a zone unlike within a FreeBSD Jail due to not having access to /dev/tty*.

The one thing I really enjoy about OpenSolaris, it is tweaked out of the box to work optimally on GOOD hardware and not on the lowest common denominator-ware. It seems like every Linux distribution out there caters to the low-end hardware crowd. Sorry, but this is 2008 and we all have hardware well above Pentium 3 class systems.

So to sum it up, if you have modest needs with a single CPU,single hard drive server stick with FreeBSD, Debian or even CentOS. If you need the advance features that Solaris provides then by all means go with it. I am loving the performance and observability of the OS! Next time we need to pick up an extra server I will be taking a look at sun.com and coolthreads servers, they have won a new customer over here thanks to project Indiana.

Not sure what that is, looks like some type of arthropod. This really reminds me of that face implant alien from the movies Aliens. Any care to guess what this is?

Today as I sat down at my cubicle and did my daily routine to initiate eclipse. I encountered a horrible sight; eclipse would start and all of a sudden just crash.

I first tried the obvious solution, to clean out the workspace.

	./eclipse -clean

Nope, no go, still eclipse kept crashing. Ugh, I fell into despair, all those key-binds and spring templates, all gone. So, rationally I hopped on to #eclipse on irc.freenode.net to get some feed back on my situation. Rcjsuen was kind enough to provide the answer that would solve my problem.

The solution was fairly straight forward. I had to remove org.eclipse.core.resources from my workspace.

	cd ~/Documents/workspace/.metalog/.plugins
	rm -rf  org.eclipse.core.resources

By removing org.eclipse.core.resources, you clear out all the project metadata from your workspace. However, don't worry, once you start eclipse you can just go to "File -> Import -> import eclipse projects" and re-import all your workspace projects.

Perl, singletons, DAOs oh my!

Lately I have been toying with Wicket , Hibernate and Spring for potentially writing a large complex site. Contrary to what people say about Java web development it isn't so bad, at least with Wicket. Since toying with Hibernate and DAOs, I came to the conclusion this can work really well in Catalyst!

Instead of micromanaging what to page cache, just cache the specific area that is the performance penalty: the database.

By utilizing the singleton data access object (DAO) pattern I can avoid the headache of micromanaging what gets page cached on my site. Furthermore, this pattern gives me the flexibility to still keep the dynamism of Template Toolkit and whatever code gets executed in my controller action.

This also solves my problem of exporting incrementally with DBIx::Class::Schema::Loader without over writing whatever business logic I might of added to my classes. This pretty much keeps my controllers clean of business logic. This pattern forces me to have clean separated code.

Lets get down the the beef of how to get this all setup.

Lets begin by setting up our first(?) DAO class

Now here is our controller which utilizes are simple DAO.

So what do you think? makes sense? keeps the controllers nice and simple, without any business logic.

And time to test the performance of the implementation vs the page cache

PageCache run:

Requests per second: 97.30 [#/sec] (mean)
Time per request: 1027.70 [ms] (mean)
Time per request: 10.28 [ms] (mean, across all concurrent requests)

DAO run:

Requests per second: 66.05 [#/sec] (mean)
Time per request: 1514.10 [ms] (mean)
Time per request: 15.14 [ms] (mean, across all concurrent requests)

So it is a bit slower, well 31% slower to be exact. This is more than adequate performance for a relatively high traffic site.

Mupen64 release, I fixed long standing bugs.

Release notes
Fullscreen now works
Save folder path bug is resolved
10.2/10.3 support is depreciated

Grab the emulator on my emulation page

How to deploy a self contained Rails application on Tomcat, painlessly!

Here at work we have a Postfix email server which handles all our email for multiple domains. The authentication and users are handled via the PostgreSQL database backend. To make life easy, I used Rails to scaffold a few tables in that Postfix PostgreSQL database. End result, is an easy to use interface to manage emails and domains. However, deployment isn't as fun as it could be, even with mongrel. I still have to have Rails/Ruby installed AND manage startup scripts to start the mongrel instance for my Rails MailManager application. Well JRuby to the rescue!

Here is how I created a self-contained Rails Application that can be reused in any Tomcat deployment.

I used the pure Ruby PostgreSQL implementation instead of the Java-centric ActiveRecord-JDBC solution, so I can develop using native Ruby while deploying via WAR using JRuby without any database.yml changes!

First off we want to instal GoldSpike which adds rake tasks to create WAR files.

script/plugin install svn://rubyforge.org/var/svn/jruby-extras/trunk/rails-integration/plugins/goldspike

Now I needed to implement a self-contained postgres-pr module. I implemented it as a Rails Plugin!

Create the postgres plugin

./script/generate plugin postgres

Copy the postgres pure implementation gem files to your Rails plugin

cp -rf /opt/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/* ./vender/plugins/postgres/lib/

Setup database.yml
I setup host as pdatabase, so on any server you deploy the WAR just add an alias to /etc/hosts ; 127.0.0.1 pdatabase

production:
  adapter: postgresql 
  database: postfix 
  username: victori  
  password: .......
  host: pdatabase

Run the rake task to build your reusable self-contained web application

rake war:standalone:create

Pretty darn easy eh?

Quick blurb concerning Typeface

I have been off in Java Wicket Land for the past month or two. In this time, I have let Typeface slide without putting out much needed maintenance releases for the various quirks currently found in Typeface. Anyway, I hope to get a new release of Typeface in a few days or so that will fix some of the rough edges.

Dynamic type languages such as Perl, Ruby, PHP, and Python free you as the developer from managing memory in your application. However, it isn’t a fool proof solution that you won’t have memory leaks in your application. You as the developer should be aware of how the underlying garbage collector of your preferred language works to accommodate for the inadequacies of its garbage collection algorithm.

Currently there are two ways of doing garbage collection; mark and sweep and reference counting. The Perl interpreter uses the latter. Reference counting is a fairly simple garbage collection technique. Each time you declare an instance, the reference count increments by one. When your program reaches the end of scope, objects with a reference of one get collected. However, if your object has a reference count of two it is kept. The one main draw back of reference counting is the fact it can’t deal with circular references. This is when both objects point to each other and they never get garbage collected.

On the other hand, Ruby and Java use the mark and sweep garbage collector. I personally have mixed feelings about it, since I don’t know exactly when my objects will be collected. The way mark and sweep garbage collection works, is it does not collect anything for a period of time. At intervals when the heap gets full, it runs its garbage collection. The downside to this is you don’t know exactly know when this happens and if there are lots of objects to be collected this leads to “stutters” and unresponsiveness of the application. If you have ever used a Java swing application you might have noticed these stutters, this is when garbage collection is taking place. However, it’s not as gloomy as I set the pretense to be with the mark and sweep garbage collection. Mark and sweep garbage collection can handle cyclic references unlike with reference counting, which is a huge boon to its usefulness. There has been much work done on mark and sweep garbage collection, specifically with generational mark and sweep collectors that try to fix the unresponsiveness issue. Java currently uses a generation GC, and Ruby hopes to obtain a generational GC for the Ruby 2.0 interpreter. Ideally a generational garbage collector would be the preferred GC for a long-standing process.

With that little garbage collection background out of the way, lets look at the life cycle of a instance in reference counting garbage collector.

Here is an example of how reference counting works ideally:

Unlike mark and sweep garbage collection with reference counting, you know exactly when your instance gets collected.

Here is a very simple problematic case for reference counting:

This is a fairly simple case of where reference counting falls right on its face. Usually this isn’t a problem since most Perl scripting revolves around short-lived scripts. However, with frameworks such as Catalyst that are long running perl scripts this becomes an issue quickly. Thankfully, with Perl it is extremely easily to nail memory leaks, more so than with Ruby or Java. Enter Devel::Cycle and Devel::Peek, both of these modules can be installed from cpan. Both Devel::Cycle and Devel::Peek can assist you in tracking down the memory leak in a relatively short time.

# Sample output
# ibook:~/Desktop victori$ perl blah.pl     
# Cycle (1):  <-- find_cycle tells you literly where the cyclic reference leak is at.
#   $A->{'child'} => \%B                           
#   $B->{'parent'} => \%A                           
# 
# SV = RV(0x1817898) at 0x1800ec8
#   REFCNT = 1
#   FLAGS = (PADBUSY,PADMY,ROK)
#   RV = 0x18006dc
#   SV = PVHV(0x1830980) at 0x18006dc
#     REFCNT = 2 <-- Notice the reference count of 2 , we know we have a leak
#     FLAGS = (SHAREKEYS)
#     IV = 2
#     NV = 0
#     ARRAY = 0x404e60  (0:6, 1:2)
#     hash quality = 125.0%
#     KEYS = 2
#     FILL = 2
#     MAX = 7
#     RITER = -1
#     EITER = 0x0
#     Elt "name" HASH = 0xe6e17f14
#     SV = PV(0x1801460) at 0x1800ea4
#       REFCNT = 1
#       FLAGS = (POK,pPOK)
#       PV = 0x401730 "victor"\0
#       CUR = 6
#       LEN = 8
#     Elt "child" HASH = 0x33ec6b5
#     SV = RV(0x1817870) at 0x1832ca4
#       REFCNT = 1
#       FLAGS = (ROK)
#       RV = 0x1800484
#       SV = PVHV(0x18309b0) at 0x1800484
#         REFCNT = 2
#         FLAGS = (SHAREKEYS)
#         IV = 2
#         NV = 0
#         ARRAY = 0x404db0  (0:6, 1:2)
#         hash quality = 125.0%
#         KEYS = 2
#         FILL = 2
#         MAX = 7
#         RITER = -1
#         EITER = 0x0
#         Elt "parent" HASH = 0xa99c4651
#         SV = RV(0x18178a0) at 0x1832c44
#           REFCNT = 1
#           FLAGS = (ROK)
#           RV = 0x18006dc

So how do we fix this? Quite simple, all we do is weaken the reference count using weaken(). Here is a proper way of patching up the memory leak we introduced in our program.

We weaken the reference at the parent level to set it back to a reference count of 1, so when it reaches the end of scope it will be collected and the memory leak will be no more.

Hopefully this is a good primer for other Perl coders out there who are facing memory leaks in their running long running perl scripts.

I found this fairly entertaining, definitely worth my 4 minutes of life. For those who don't know Kabayashi is the Japanese gentleman who beats us lard ass Americans at our own game; glutting. This does deliver.

Unlike most people I came to Catalyst from the Rails camp. I miss a few things namely, file_column for mapping file uploads to the filesystem.
Thankfully writing DBIC components is fairly trivial. I wrote this in a few minutes so consider this a hack. This component makes your DBIC class dependent on Catalyst since it uses a reference from the Catalyst upload context.

I hope to improve upon this and add thumbnail support for images. For now this will do.