Today I'm shilling for an amazing company, Spark::red. They provide unparalleled managed ATG application hosting. I know and trust the folks running it, and have been working with them for a while now. They have really been stellar to deal with and have turned things around in hours and days, whereas I'd gotten used to waiting weeks and month with the previous hosting situation.

If you, or anyone you know, uses ATG, you owe it to yourself to check Spark::red out.

Here is the press release:

In PDF Form

In Text Form:

Spark::red Expands ATG Hosting Offering

SEATTLE, WA- December 17, 2007 - Spark::red LLC announced today that it will launch general availability of their ATG-specialized hosting solutions.

Spark::red has been providing hosting and technology services to an exclusive group of clients, including a Fortune-500 company.

"We made certain that we could respond to our clients' individual needs with the personal attention and quality that allows us to distinguish ourselves," said Russell Moore, spokesperson for Spark::red. "We have proven our capability, and are ready to expand our client base. ATG customers now have a premier hosting option, one that takes pride in delivery to the customer above all else."

About Spark::red LLC
Spark::red, a managed ATG hosting provider, focuses on providing a specialized hosting solution for ATG applications. The staff of experienced ATG architects allows Spark::red to deliver production environments in days, instead of weeks or months.
With competitive pricing, a Tier 4 data center, and every staff member boasting over eight years of experience working with some of the largest ATG installations in the world, launching a new site or migrating an existing application will be quick, secure and painless. With Spark::red you will enjoy expert support, the fastest servers, and peace of mind. They invite you to contact them and discover the superiority of their ATG-specific hosting solution.

http://sparkred.com

Contacts:
Russell Moore
Spark::red LLC
russell@sparkred.com

Sales Inquiries
sales@sparkred.com

If you're uptight about uptime, if you're anxious about availability, if you nervously watching Nagios, have I got the program for you. Forget 12 step programs, mine has 13!

First let's talk load balancing. Load balancing is basically distributing some type of load across multiple servers or resources. For the sake of simplicity, we'll assume that it's web requests to web servers that we're talking about, but it's all equally applicable to databases, mail servers, or just about any other network accessed computing resource (assuming you can handle the back-end synchronization if required, such as with a database).

There are two primary reasons to load balance:

1. Capacity: one server may not have enough power or resources to handle all of the requests, so you need to break the load out across multiple servers.
2. Redundancy: relying on a single server means that if it fails, everything is down. A single point of failure can bring down your critical application. Servers fail; both hardware and software. A blown power supply, bad RAM, a dead NIC, eventually something will go out. No software is 100% bulletproof either. If you have two or more servers handling the load, then even if one fails, the other(s) can take over without your application or users seeing any difficulties.

A load balancer sits between your users (human or machine) and your servers. It typically passes requests through to multiple servers and returns the responses to the end user, acting like a transparent proxy. It can distribute load in many different ways, randomly, round-robin, or in more complex ways. It usually monitors the servers so that if a server dies it is removed from the pool and no user requests are sent there.

(more...)

Don't just block them, get a little more creative....

http://www.ex-parrot.com/~pete/upside-down-ternet.html

Enjoy:)

This is mostly for own use, but: If you've ever had a server which netstat showed was listening on one or more ports you weren't expecting, you can use this command to find out which process is listening there:

fuser -vn tcp 4444

Which in this case happens to be owned by JBoss, and not some linux version of a windows worm:)

For more info on fuser, check out the man page, or the simple help below:

Usage: fuser [ -a | -s | -c ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
[ - ] [ -n SPACE ] [ -SIGNAL ] [ -kimuv ] NAME...
fuser -l
fuser -V
Show which processes use the named files, sockets, or filesystems.
-a display unused files too
-c mounted FS
-f silently ignored (for POSIX compatibility)
-i ask before killing (ignored without -k)
-k kill processes accessing the named file
-l list available signal names
-m show all processes using the named filesystems
-n SPACE search in this name space (file, udp, or tcp)
-s silent operation
-SIGNAL send this signal instead of SIGKILL
-u display user IDs
-v verbose output
-V display version information
-4 search IPv4 sockets only
-6 search IPv6 sockets only
- reset options
udp/tcp names: [local_port][,[rmt_host][,[rmt_port]]]

As you know if you've been following my blog, 10MinuteMail starting dying with OutOfMemory errors seemly randomly. Sometimes it would happen after 2 days of uptime, sometimes after a week. I ran load tests and profilers but could not reproduce the issue. On the upside I can say that the 10 Minute Mail application can handle a TON of load:)

I made some code changes and optimizations on Friday, and since then, no problems. Obviously that's too early to tell for sure, but I found something last night, which might have explained the previous issues, and it is the root cause, then my latest fixes should have solved it.

I THINK the problem is..... porn. I was watching the inbox size for 10MinuteMail last night, which usually goes between 0k and 2MB in size, and it leapt from 540k to 45MB in a couple of seconds, and then went to 86MB a second later. So first I need to back up a little.

When 10MinuteMail was crashing with OutOfMemory errors, I would wake up and find the server useless due to the memory errors, and inbox would have swollen to a gigabyte or more. I assume this was a cause and effect situation, namely that the server would tank, and then the inbox would pile up afterward.

What I found was that some people used their 10MinuteMail e-mail addresses to sign up for things like the "asianscans" google group, and other lists that periodically would deliver e-mails filled with large (2 MB) images as attachments. 15 10 MB e-mails is 150 MB in your inbox in a few seconds. The old code would parse and load all of the attachments (even though I never completed the attachment download code). Now with 150 MB of attachments being read through a 8k byte array, and into these large in memory objects, that can take a little while. Get a big enough inbox, and it becomes impossible to clean it up as you just keep falling further and further behind. Eventually you run out of memory trying to load up a 800 MB inbox.

So instead of the server running out of memory, tanking, and then letting the inbox build up, I think that what was really happening is that the inbox filled up with huge attachements very quickly, the server fell further and further behind trying to process them, and eventually ran out of memory, tanked, and then of course the inbox just got worse.

The latest code ignores attachments, and took about 4 seconds to process the 80+ MB inbox I saw last night.

I'm knocking on wood that this was in fact the root cause to the earlier problems, and that the future should be smooth sailing:)

As a side note, last month had over 2.1 million page hits to 10MinuteMail.com! Thanks guys! I'm glad people find it useful!