Resin 4.0.10 is now available.

1. Several threading and alarm/timing fixes for 4.0.9
2. Created HealthService to generalize the ping and health checks
3. Improved Resin/Watchdog communication, giving more information on restarts

As part of our Resin 4.0 work, we’re going through the various Resin services and improving the testing and quality of each service. In Resin 4.0.9, we revamped the heartbeat service which is at the center of Resin’s clustering configuration.

In each cluster, Resin assigns the first three servers to be the triad servers, the triple-redundant hub for the clustering model. Each of the triad servers can act as a backup for any of the others.

For the heartbeat service, every Resin server in the cluster connects to each triad server and sends a heartbeat every minute. If the connection drops or the heartbeat is missing, the triad knows immediately that the server has failed and can take appropriate measures to deal with the failure. For example, if a server is down, Resin won’t waste effort trying to send messages to the dead server. The heartbeat, however, retries the downed server every 60 seconds, so Resin will know the status as soon as it comes up.

Well, not really, but in most of the specifications I’ve worked with, the architect-types (people who haven’t touched code in years) assume that the cost of adding complexity is zero.

There’s a weird discussion in the websocket spec where people are arguing that saving one (1) byte in the frame header will lead to massive improvements in latency, and at the same time assume the additional code complexity required to pack the frame into the small frame is zero. In reality, the savings from one (1) byte is pretty small, practically unmeasurable, and although the extra code complexity isn’t huge, it’s also not zero.

Now, in the proposal even a tweet can’t fit into the small frame (127 bytes), because a full tweet with metadata is about 350 bytes.

That point was brushed away with the argument that a compressed tweet would fit into 127 bytes. Assuming, I think, that compression is also free because it’s code. So in order to save one byte in a TCP packet, they’re assuming all the overhead of compression.

The thinking that code is free has twisted specifications in the past. EJB is a notorious one. The working assumption was that the EJB design could be messy (in particular the XML), because people would write IDE tools to solve the problem.

Just some quick numbers between SSL vs JSSE on Resin because some people have asked:

485 ops, SSL 1k hello file, no keepalive
135 ops, JSSE 1k hello file, no keepalive

272 ops SSL, 64k file, keepalive
51 ops, JSSE 64k hello file, 4 keepalive

The first set of numbers is for a single request, showing the startup cost of SSL vs JSSE.

The second set shows a more typical page load, with multiple objects (4) and larger 64k, showing the long-term, actual costs of the two.

In both cases, the difference is about 3-4x.

For faster performance, a hardware accelerator would be even faster.

Although engineers understand the purpose and value of CDI for frameworks and applications, it’s been a little more complicated to explain to non-technical staff. One metaphor that’s helped is explaining CDI as a catalyst.

With the idea of a catalyst in mind, it’s not that it’s impossible to write a framework or an application without CDI, or that CDI provides a specific capability, but CDI makes development faster and more extensible than coding alone.

We’re cleaning up the Resin 4.0.8 release this week, passing our own regression tests after finishing up the CDI TCK. Although there are still 9 failures, those all appear to be problems with the TCK itself; as we work on finishing all of the JavaEE WebProfile TCK, we’ll be cleaning those up.

Passing the CDI TCK has given us a chance to plug holes in our own test suite, primarily validation of invalid application classes, but also several important lifecycle issues related to interceptors, alternatives, specializing and producers.

It’s also given a chance to refactor the CanDI implementation a bit, organizing it to make it more maintainable, and improving performance in a number of places.

We’ve still got a ways to go for the full JavaEE 6 WebProfile. The next release will be primarily passing the JTA TCK, and after that finishing up EJBs.

In the large projects that most of us work with, it’s not feasible to rewrite the entire project around a new technology like CDI, even though a redesigned project around CDI would be a better crafted solution. But what you can do is add CDI incrementally and improve your project’s quality piece by piece as time goes on. For example, in an agile-style short release cycle, you’d want to break up the CDI migration task into something small enough to fit in your 2-3 week cycle.

If you’re using JDBC directly, the quickest benefit for CDI is replacing your current DataSource injection (or JNDI) with CDI, since Resin’s database configuration integrates with the CDI injection.
(more…)

DZone has a nice set of basic tutorials for CDI:

CDI part 1 covers @Inject, @Qualifier, @Singleton, and @NormalScoped.

CDI part 2 covers @Produces, @Observes, @Interceptor, @Decorator, and @Alternative.

For people like me who prefer small code examples to explanations, it’s a good overview, giving a quick feel for what programming with CDI is like.

The combination of the CDI @Produces feature with @RequestScoped or @TransactionalScoped is an interesting patter that lets you easily manage connections by skipping the old try-finally block entirely. Like the @Pooled beans, it reduces complexity by avoiding try-finally, and more importantly makes the application more testable. In theory, to test the try-finally pattern, you need a test with a forced exception to verify that the finally actually exists, or more importantly that some future refactoring doesn’t remove the finally by mistake.

The resource proxy pattern of CDI uses the @NormalScope with @Produces. A @NormalScope like @RequestScoped or @TransactionalScoped injects a proxy to the resource, not the resource itself. For JDBC Connections, each thread gets its own actual Connection, while all threads share the same Connection proxy through injection.
(more…)