Why I migrated from Pair NIC to GoDaddy

I was using Pair NIC for my domains. However, I had to migrate to another and finally chose GoDaddy due to the following reasons.

The foremost reason is that I am using Google Sites to host the websites and Google has started requiring "domain verification". That is, to verify that you do own that domain in order for the site to accept HTTP requests for that domain name. To do that, I have to add an TXT resource record to the zone. This can be done with Pair NIC but then it won't allow email forwarding anymore (technically there is no reason why both can't be done at the same time but it is the way the Pair NIC admin tool works). It means that I can no longer have email addresses like kent@mydomain.com forwarding emails to my Gmail account. Therefore, I have to choose between website branding (www.mydomain.com) or email branding (kent@mydomain.com).

An added benefit is that GoDaddy's email forwarding won't cause any delay like Pair NIC. Pair NIC artificially returns an error to an "unfamiliar" source SMTP server to make sure it is not sending spam. That will cause a delay of 10-20 minutes for that server to retry. GoDaddy doesn't have such a stupid feature. After all, Gmail is doing spam filtering, please just forward the damned mails. Worse yet, that "feature" of Pair NIC is not found anywhere and not mentioned before users making purchases.

In fact, I also found that GoDaddy's admin tool and management functionality is more powerful than that of Pair NIC. It also enjoys better support from Google Sites in terms of auto domain verification. GoDaddy is also cheaper, even though I am happy to pay more as Pair NIC is environmentally friendly and bearing the 100% renewable energy logo.

Implementing an async servlet in Scala with less than 10 lines of code

What is async servlet and why use it? An async servlet can tell the container that it will handle a request later, so that the current thread is not tied up and can be used for another request. Why is it useful? For example, if the request is going to do something relatively time consuming (e.g., generating a report from a DB), instead of tying up the thread doing nothing waiting for the data, you can free up the thread for other requests and wait for the data in a background thread. When the data is received, you can complete the response.

It turns out to be very easy to implement an async servlet (new in servlet 3.0). In Scala, it took less than 10 lines of code (not counting brace brackets and imports):

package com.ttdev.webqos
import javax.servlet.http._
import java.util.concurrent._

class MyServlet extends HttpServlet {
  private val pool = Executors.newFixedThreadPool(1) // create a thread pool

  override def doGet(req: HttpServletRequest, res: HttpServletResponse) {
    req.startAsync  //tel the container the response will be generated later
    pool.execute(new Runnable() {  // add the runnable to the queue
      def run {  // when a thread in pool picks up the runntable...
        res.getWriter.append("hello world!")  // write the response
        req.getAsyncContext.complete  // tell the container that the response is done
      }
    }) 
    // return without a response yet
  }

}