Paul's Vox

Gopher on MTV

nobody@vox.com(Paul) — Mon, 08 Jun 2009 13:19:45 -0700

I dug this little gem out of the archives. Enjoy!

Read and post comments | Send to a friend

Email Clients Full Circle

nobody@vox.com(Paul) — Wed, 03 Jun 2009 11:23:33 -0700

In the beginning I used elm to read my mail. This was somewhat radical, especially as I worked with the team that created POPMail for the mac and Minuet for the PC, and everyone else moved to pine. Then came Mutt -- happy days -- I was able to slice and dice email with amazing speed.

A couple of years ago I converted over to Mail.app -- mostly because of the contacts and calendar integrations, and the fact that I could merge personal email and corp email accounts. In the intervening time I had to move to comcast, which meant running my own imap server proved more difficult than it was worth, so I moved to Google Apps for Your Domain, all of a sudden my personal domain is running Gmail, and I discovered it has key bindings.

All of a sudden it's mutt deja-vu. navigation with vi j/k keys? yes. Single window view (inbox/message)? yes again. Tagging messages? yes. Blazingly fast? you bet. The only thing I miss is keystroke filtering of messages.

That's one reason why I see things like Google Wave working out so well, I might be late to the gmail party, but plenty of folks have been using this as their primary mode of communication for a long long time.

Read and post comments | Send to a friend

Tomcat and SSL Accelerators

nobody@vox.com(Paul) — Thu, 09 Apr 2009 12:24:21 -0700

Using an SSL Accelerator like a Netscaler is really useful, you can offload a lot of work to a device that supports this in hardware and can use SSL session affinity to send requests to the same backend. In the simplest setup the SSL Accelerator accepts the request and proxies it to your internal set of hosts running on port 80.

However, code that generates redirects and URLs works poorly because the servletRequest.getScheme(), getSecure() and getServerPort() will return http/false/80 for SSL and non-SSL connections.

One way to solve this is listen on multiple ports. Create a Connection on 80 and 443, but do not run SSL on either port. Then for the 443 port you configure it with secure="true" and scheme="https". This is suboptimal however as then you have to manage yet another server pool in your load balancer and you end up sending twice the health checks. Not so good.

You might try to solve this by using a ServletFilter. You can use an HttpServletRequestWrapper instance to change the scheme/port/and secure flag. Sadly this doesn't work, because of the way tomcat implements HttpServletResponse, it uses the original request object to ascertain the scheme/secure flag/port. Overriding these will allow application logic to see the updated values. You get into trouble when you call encodeRedirectURL() or sendRedirect() with non-absolute URLs.

Lucky for us Tomcat supports a way to inject code into the connection handling phase via Valves. A valve can query and alter the Catalina and Coyote request objects before the first filter is run.

To make your Valve work you'll need to configure your load balancer to send a special header when SSL is in use. On the Netscaler this can be done by setting owa_support on. With that enabled the http header Front-End-Https: On is sent for requests that use SSL.

Once we have these pieces in place the Valve is fairly straightforward:

import java.io.IOException;
import javax.servlet.ServletException;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;
public class NetscalerSSLValve extends ValveBase {
   @Override
   public void invoke(Request req, Response resp) throws IOException, ServletException {
   if ("On".equals(req.getHeader("Front-End-Https"))) {
   req.setSecure(true);
   req.getCoyoteRequest().scheme().setString("https");
   req.getCoyoteRequest().setServerPort(443);
   }
   if ( getNext() != null ) {
   getNext().invoke(req, resp);
   }
   }
}

Compile this, stick it in the tomcat lib directory, add an entry in your server.xml and away you go.

Read and post comments | Send to a friend

Google I/O Today

nobody@vox.com(Paul) — Wed, 28 May 2008 07:33:28 -0700

Speaking at "Meet the Containers", "Shindig 101" and "OpenSocial Fireside Chat".

All at Moscone West, check it out!

http://code.google.com/events/io/

Read and post comments | Send to a friend

The Mysteries of Java Character Set Performance

nobody@vox.com(Paul) — Thu, 01 May 2008 01:22:08 -0700

"Two Characters Sets? Seems like plenty!"

So I've been pushing Java to it's limits lately and finding some real nasty concurrency issues inside the JRE code itself. Here's one particulary ugly one -- we had 700 threads stuck here:

java.lang.Thread.State: BLOCKED (on object monitor)

at sun.nio.cs.FastCharsetProvider.charsetForName(FastCharsetProvider.java:118)

- waiting to lock <0x00002aab4cdf91b8> (a sun.nio.cs.StandardCharsets)

at java.nio.charset.Charset.lookup2(Charset.java:450)

at java.nio.charset.Charset.lookup(Charset.java:438)

at java.nio.charset.Charset.isSupported(Charset.java:480)

at java.lang.StringCoding.lookupCharset(StringCoding.java:85)

at java.lang.StringCoding.decode(StringCoding.java:165)

at java.lang.String.<init>(String.java:516)

Digging deeper we find the lookupCharset is called all over the place. The app in question is functions as a web proxy, so it's constantly reading and writing data from web pages in a variety of character sets. The method charsetForName() uses a synchronized data structure to lookup defined character sets. (Yay serialized access....)

But wait, lookup and lookup2 provide us with a cache so we can avoid the big bad synchronized method.. Sigh, here's the implementation:

private static Charset lookup(String charsetName) {

if (charsetName == null)

throw new IllegalArgumentException("Null charset name");

Object[] a;

if ((a = cache1) != null && charsetName.equals(a[0]))

return (Charset)a[1];

// We expect most programs to use one Charset repeatedly.

// We convey a hint to this effect to the VM by putting the

// level 1 cache miss code in a separate method.

return lookup2(charsetName);

}

private static Charset lookup2(String charsetName) {

Object[] a;

if ((a = cache2) != null && charsetName.equals(a[0])) {

cache2 = cache1;

cache1 = a;

return (Charset)a[1];

}

Charset cs;

if ((cs = standardProvider.charsetForName(charsetName)) != null ||

(cs = lookupExtendedCharset(charsetName)) != null ||

(cs = lookupViaProviders(charsetName)) != null)

{

cache(charsetName, cs);

return cs;

}

/* Only need to check the name if we didn't find a charset for it */

checkName(charsetName);

return null;

}

Yes, a whopping 2-entry cache!!

Also, the keys used are not canonical, so if my app asks for "UTF-8", "utf-8", and "ISO-8859-1" with regularity this 2 entry cache is worthless, every call ends up blocking in the evil thread-synchronized data structure.

Someone send them a copy of the ConcurrentHashMap doc. please.

</rant> ....

Read and post comments | Send to a friend