That response sounds familiar but really isn’t that comforting or
realistic. You’re suggesting its rare to have instances disappear yet
it happened twice in less than 6 months. You’re suggesting I upgrade
to a more expensive server which may or may not solve the problem. You
don’t know what causes the instances to disappear but for some reason
a more expensive instance solves the problem. I’m not sure how those
dots are connected but it certainly doesn’t add up to me. You want me
to spend more money per month without any real justification,
quantitative data, or explanations.

To summarize:

* You don’t know why instances disappear.
* Its rare for instances to disappear.
* The solution is to spend more money per month.

From my perspective, you still haven’t resolved the underlying
problem. You suggest maybe hardware but hardware crashes twice in 6
months? That doesn’t sound realistic. The issue that concerns me is
that you haven’t addressed the underlying problem of why the instances
disappeared. You’ve only offered a solution that has no connection to
the actual problem: Get a better server. Of course, I could just go
straight to Amazon and bypass EY altogether if I were to get another
server.

Without really understanding why the instances are disappearing it
points to a bigger problem at EY than just this issue. It points to a
lack of concern for your clients, a lack of understanding of your own
technology, and a fundamental problem in how you attempt to solve the
problems presented to you. Its a ‘shuffle it under the rug’ approach
to solving your problems which doesn’t bode well with me. Your
solution is, simply put, one without any technical merit. Anyone in
sales could have given me the same answer. If I were to refer clients
to EY and they had other problems that you couldn’t figure out would
your solution be that they need to upgrade their servers?

I appreciate your delayed investigation into the issue but I
definitely won’t be moving more of my clients to EY anytime soon. I’m
actually glad you reached out to me recently because its given me the
motivation to review what I still see as this outstanding issue. As
such, I’ve decided to cancel my EY account.

> From: EY
>
> X and Y asked me to follow up with you on this.
> First of all, if someone on my team dropped the ball on getting back to you,
> we apologize. I will follow up with the engineers on my end.
> Re. instances disappearing – I found and reviewed the ticket for when this
> happened. It appears that it was no longer possible to SSH into your
> instance and when our engineer tried to terminate it, it was stuck in a
> shutting down state. I can’t answer why this happened in this particular
> case, but out of the several thousand AWS instances we manage on the EY
> AppCloud, occasionally we have observed that an instance can disappear or
> become unresponsive. This can happen, for example, if the physical server
> it is mounted on fails. The few times we have seen it, it has been for
> Small instances, which is what you had. Our default AWS instance size for
> EY AppCloud is now Medium, which we to date have not observed issues with.
> Hope that answers your question – and feel free to contact me for any
> additional questions about this.

It was just brought to my attention that my company’s homepage was pointing to the wrong app. This has happened a few times since I’ve switched to EngineYard. They don’t include www aliases in the default nginx configuration so you have to add them with a keep.domain.conf file. I recently migrated my company site to a new instance and left the default configuration. When I checked to make sure the app was setup on the new instance properly, http://onomojo.com , it worked fine and I didn’t think anything of it. Of course, I didn’t test http://www.onomojo.com which ended up pointing to an app that is still in the early phases of development since I didn’t customize the nginx config. What a huge goof. No wonder I’m getting mixed responses from potential new work lately. If you’re reading this and you saw the awkward half broken site with the test video please revisit the site again.

I like to do my part to save the planet and this is just one way in which Onomojo is trying to help. We’ve just recently finished a non-profit site promoting No Plastic Day which is on June 8, 2010. So far we’ve got a decent amount of people joining the event and I’m asking for your help in promoting it further. We all need to do our part to save the planet. One day without disposable plastics isn’t much to ask. Join us and together we can create a better future.

Rojo is Onomojo’s Ruby on Rails Content Management System. You can find it here:

http://github.com/onomojo/rojo

Today we made some changes to make the initial setup of a Rojo instance easier. The steps to setup a new Rojo instance are clearly detailed in the README. This should help eliminate most of the problems new users were encountering when trying to setup Rojo from scratch. Please let us know if you have any comments or suggestions for improving the setup process.

In the next few weeks, we will be releasing the plugins that we’ve developed for Rojo including a blog, video gallery, photo gallery, and more so stay tuned.

I am experimenting with a new Engine Yard account today and their Setup basically requires you to have your projects in git. Since the site was from a private svn repos I decided I’d go ahead and signup for a paid Github account so I can host my projects there privately instead of having to setup my own git server. I should have trusted my gut because not more than a few hours later here I am trying to access my Github account and the site is broken again.

We’ve been working on this part time for a while now and I finally decided to just go ahead and release it. Its far from perfect and isn’t what I originally envisioned but it does work and we do use it on a number of sites. Its fairly stable and we have a handful of plugins that I’ll be releasing in the next week or two.

The 2 main motivations for Rojo came from the lacking diversity in Ruby on Rails content management systems. There are a few and some work well but I wasn’t happy with the learning curve with the ones I explored when we initially started this project. It seemed to me that every time I embraced a CMS the CMS ended up determining how I had to write my application. Its simply impossible to craft a CMS that enforces a strict data and programming interface that works for every situation. I didn’t want a content management system that forced me to write my tables one way or another or forced me to communicate with the CMS in certain ways. In short, I really just wanted a simple core that I could easily extend in any way I needed without having to conform to any standard imposed by the CMS.

You can check out the Rojo code here: http://github.com/onomojo/rojo

My previous post was about using Thread in Rails which simply doesn’t work properly when you’re doing anything with ActiveRecord despite what anyone else is claiming.

This post will focus on my second attempt at a solution to intra-request threading in Rails. Basically, I have a Rails app where I want to run multiple computations at the same time. Since I had problems with Ruby’s native Thread method previously, I had no intention of going down that route again. I decided to try out the Spawn plugin.

Spawn was able to successfully segregate my multiple threads, or forks in my case. This got around the MySQL errors I reported in my previous post but it created a whole new set of problems all its own.

The first problem I had was that the spawn forks I was creating weren’t able to communicate their changes back to the main Rails request. I was creating forks and they were running fine and even saving data via ActiveRecord. I could confirm this via the console. The problem was that I need to know what data was being written by the spawn forks inside of the main Rails request. It was as if the main Rails request didn’t even know that something new was written to the database. I was able to get around this by forcing a reload from the database on the object I was trying to get association data from.

No big deal and it seems to make sense to do that anyway. That’s not where the real problem occurs though. After I got past that I realized that since each fork was essentially using a ‘copy’ of the database and not actually live connections that the data validations randomly failed. Basically if two forks are writing data to the database at the same time when there is a validates_uniqueness on the data. They both write to the database and both actually pass validation. The result is a database full of incorrect data which should have never passed the validation. I’m still not sure if that’s a problem with Spawn or an inherent problem with ActiveRecord’s connection pool.

I’ve been working on threading a Rails application lately and after reading headlines like ‘Rails is thread safe’ I figured how hard could it be. My first discovery was that when people talk about Rails and threads there are two different types of threading in Rails.

Multiple request threading – This is where Rails itself threads among different requests to your web server and allows ActiveRecord to behave properly without having to keep a copy of Rails in memory for each request.
Intra-request threading – This is where you have 1 request to your web server and inside the action you want to create multiple threads that run concurrently.

I’ll be talking about Intra-request threading. In particular, I want my threads to execute some code, read and write to the database, and play nicely with each other. My first attempt was to use the Ruby Thread method. This seemed to work somewhat until I started seeing strange errors coming in from MySQL. The problems seemed to occur randomly and what I determined was that the threads were trying to write to the database at the same time which ended up causing some collisions of sorts resulting in ‘lock wait timeout exceeded’ errors.

After considerable Googling, I found numerous posts about setting:

ActiveRecord::Base.allow_concurrency = true

The problem with that is that this is deprecated in the newest version of Rails in favor of connection pooling.

The short answer: Don’t use the Ruby Thread method within Rails when doing anything with ActiveRecord.

Here I am yet again at a standstill because the Rails gems have mostly all migrated to Github and the site is down. This is the second or third time this year that Github has messed up and caused me to stop dead in my tracks because I couldn’t access the gems I needed. I can’t even remember the last time my subversion repository went down. This is exactly the reason I thought the Rails community was crazy for mass migrating to Github. Its just not a good idea to have 1 centralized location responsible for all your gems. Especially when they go down all the time. What we need is a company with experience maintaining quality uptime to manage this site in the short term and in the long term we need a more distributed mirror type system to roll-over when Github dies again.

Github down again

I’ve just finished adding AOL support to the Rails contacts gem.

Until this is officially added to the contacts gem release, you’ll need to create a RAILS_ROOT/lib/contacts/aol.rb file with the following contents:

class Hash
def to_query_string
u = ERB::Util.method(:u)
map { |k, v|
u.call(k) + "=" + u.call(v)
}.join("&")
end
end

class Contacts
require ‘hpricot’
class Aol < Base
URL = "http://www.aol.com/"
LOGIN_URL = "https://my.screenname.aol.com/_cqr/login/login.psp"
LOGIN_REFERER_URL = "http://webmail.aol.com/"
LOGIN_REFERER_PATH = "sitedomain=sns.webmail.aol.com&lang=en&locale=us&authLev=0&siteState=ver%3a4|rt%3aSTANDARD|ac%3aWS|at%3aSNS|ld%3awebmail.aol.com|uv%3aAOL|lc%3aen-us|mt%3aAOL|snt%3aScreenName&offerId=mail-second-en-us&seamless=novl&xchk=false"
# http://webmail.aol.com/28878/aim-2/en-us/Suite.aspx
CONTACT_LIST_URL = "http://webmail.aol.com/28878/aim-2/en-us/Lite/ContactList.aspx?folder=Inbox&showUserFolders=False"
CONTACT_LIST_CSV_URL = "http://webmail.aol.com/28878/aim-2/en-us/Lite/ABExport.aspx?command=all"
PROTOCOL_ERROR = "AOL has changed its protocols, please upgrade this library first. If that does not work, dive into the code and submit a patch at http://github.com/cardmagic/contacts"

def real_connect

postdata = {
"loginId" => login,
"password" => password,
"rememberMe" => "on",
"_sns_fg_color_" => "",
"_sns_err_color_" => "",
"_sns_link_color_" => "",
"_sns_width_" => "",
"_sns_height_" => "",
"offerId" => "mail-second-en-us",
"_sns_bg_color_" => "",
"sitedomain" => "sns.webmail.aol.com",
"regPromoCode" => "",
"mcState" => "initialized",
"uitype" => "std",
"siteId" => "",
"lang" => "en",
"locale" => "us",
"authLev" => "0",
"siteState" => "ver%3A4%7Crt%3ASTANDARD%7Cac%3AWS%7Cat%3ASNS%7Cld%3Awebmail.aol.com%7Cuv%3AAOL%7Clc%3Aen-us%7Cmt%3AAOL%7Csnt%3AScreenName",
"isSiteStateEncoded" => "true",
"use_aam" => "0",
"seamless" => "novl",
"aolsubmit" => CGI.escape("Sign In"),
"idType" => "SN",
"usrd" => "4222992",
"doSSL" => "",
"redirType" => "",
"xchk" => "false"
}

# Get this cookie and stick it in the form to confirm to Aol that your cookies work
data, resp, cookies, forward = get(URL)
postdata["stips"] = cookie_hash_from_string(cookies)["stips"]
postdata["tst"] = cookie_hash_from_string(cookies)["tst"]

data, resp, cookies, forward, old_url = get(LOGIN_REFERER_URL, cookies) + [URL]
until forward.nil?
data, resp, cookies, forward, old_url = get(forward, cookies, old_url) + [forward]
end

doc = Hpricot(data)
(doc/:input).each do |input|
postdata["usrd"] = input.attributes["value"] if input.attributes["name"] == "usrd"
end
# parse data for <input name="usrd" value="2726212" type="hidden"/> and add it to the postdata

postdata["SNS_SC"] = cookie_hash_from_string(cookies)["SNS_SC"]
postdata["SNS_LDC"] = cookie_hash_from_string(cookies)["SNS_LDC"]
postdata["LTState"] = cookie_hash_from_string(cookies)["LTState"]

data, resp, cookies, forward, old_url = post(LOGIN_URL, postdata.to_query_string, cookies, LOGIN_REFERER_URL) + [LOGIN_REFERER_URL]

until forward.nil?
data, resp, cookies, forward, old_url = get(forward, cookies, old_url) + [forward]
end

if data.index("Invalid Screen Name or Password.")
raise AuthenticationError, "Username and password do not match"
elsif data.index("Required field must not be blank")
raise AuthenticationError, "Login and password must not be blank"
elsif data.index("errormsg_0_logincaptcha")
raise AuthenticationError, "Captcha error"
elsif data.index("Invalid request")
raise ConnectionError, PROTOCOL_ERROR
elsif cookies == ""
raise ConnectionError, PROTOCOL_ERROR
end

@cookies = cookies
end

def contacts
postdata = {
"file" => ‘contacts’,
"fileType" => ‘csv’
}

return @contacts if @contacts
if connected?
data, resp, @cookies, forward, old_url = get(CONTACT_LIST_URL, @cookies, CONTACT_LIST_URL) + [CONTACT_LIST_URL]

until forward.nil?
data, resp, cookies, forward, old_url = get(forward, cookies, old_url) + [forward]
end

if resp.code_type != Net::HTTPOK
raise ConnectionError, self.class.const_get(:PROTOCOL_ERROR)
end

# parse data and grab <input name="user" value="8QzMPIAKs2" type="hidden"/>
doc = Hpricot(data)
(doc/:input).each do |input|
postdata["user"] = input.attributes["value"] if input.attributes["name"] == "user"
end

data, resp, cookies, forward, old_url = get(CONTACT_LIST_CSV_URL, @cookies, CONTACT_LIST_URL) + [CONTACT_LIST_URL]

parse data
end
end
private

def parse(data, options={})
data = CSV.parse(data)
col_names = data.shift
@contacts = data.map do |person|
["#{person[0]} #{person[1]}", person[4]] unless person[4].empty?
end.compact
end
end

TYPES[:aol] = Aol
end

I’ve submitted the source to the authors so it should be added in the next few weeks.

UPDATE: My changes have been merged into the trunk.