Typesafe Config contribution of new feature .. "required includes"

Phew.

It's taken ages but I've finally managed to finish my contribution of a long standing functional enhancement to Typesafe config.

The new feature allows one to specify whether included resources are optional or mandatory. By default when Typesafe Config encounters a resource that it can't find then it carries on silently; this is by design.

However, often we want Typesafe Config to abort if certain includes are not found, and that's what I've added by way of a new keyword `required`.

The details of the change are here https://github.com/typesafehub/config/pull/421

The syntax for this is ...

include required("foo.conf")
include required(file("foo.conf"))
include required(classpath("foo.conf"))
include required(url("http://localhost/foo.conf"))

Introducing ClasspathHell - Classpath collision mayhem detector

Think your build is stable and repeatable? Think again.

First release of https://github.com/portingle/classpathHell

It's far too easy to end up with multiple copies of a class or resource on your classpath leading to difficult to trace runtime errors that due to classpath ordering instability might not show up until late in your release cycle, or possibly even production.

Don't let that happen - just use this detector.

An excellent example is that Dropwizard and Codahale metrics have the same fully qualified class names, but with different interfaces and different implementations.

Google QUIC, a better web protocol?

A friend recently drew my attention to Google's networking innovation, QUIC, Google's alternative to HTTPS over TCP. It's a better secure fault tolerant protocol than TCP for many usages.

My greetings contacted me because he remembered that I had done something rather similar ten years ago at a bank, even down to their use of forward error correction (FEC).

TCP slow start problem was a big concern for us as our traffic was really bursty and WAN based, but time sensitive and we couldn't afford the slow start.

Both Google and myself used a reliable UDP instead of TCP. But QUIC is far more sophisticated, my approach didn't bother with in-built security, multiplexing or fairness.

My approach did however solve the problem we had which was low latency for  high bandwidth but bursty comms.

If your are interested in FEC then this may be of interest https://tools.ietf.org/html/rfc3453

The trick to reliable big throughput low latency wan comms was dumping large numbers of datagrams onto the network optimistically but including FEC to reduce the risk of loss in transit and then for belts and braces we fall back to a rarely  used resend protocol.

Of course on a corp network this works well but as the network deteriorates then the perf will degrade and approach TCP, or worse.

Anyway that work was great fun and it's interesting to see Google using similar approaches.

It'salso interesting to note how because Google have such a large browser market share and a webservices market share, they are able to fire up innovations like this doing blue/green deploys or whatever they need in order to prototype on a large scale, gathering great metrics along the way.

If there were a few good open source QUIC impls then it might be really useful in many projects. Chrome supports it and all Google services expect it. See also the Caddy webserver which looks very interesting.

Worth keeping an eye on.