Mind the Gap

Friday, April 11, 2014

Better error handling idioms in Go

How often have you seen, or written, Go code like this?

file, err := os.Open("someFile")
if err != nil {
    return err

Explicit, inline error handling is necessary since Go doesn't have exceptions. The code is sufficient for small programs, even if the error is returned from more than one level of function call. Hopefully at some point the error is logged and it's fairly easy then to guess what caused the error, especially since os.Open returns a failure helpful error string, for example:

"open someFile: No such file or directory"

However, in larger programs, this approach breaks down. There tend to be too many calls which could have returned the error and (an unbounded amount of) work has to be done to isolate the failing call.

We'd like to see a stack trace, so let's add one as soon as we detect the error.

file, err := os.Open("someFile")
if err != nil {
    var stack [4096]byte
    runtime.Stack(stack[:], false)
    log.Printf("%q\n%s\n", err, stack[:])
    return err

The resultant log looks something like this (at least in the playground):

2009/11/10 23:00:00 "open someFile: No such file or directory"
goroutine 1 [running]:
 /tmpfs/gosandbox-xxx/prog.go:15 +0xe0
 /tmp/sandbox/go/src/pkg/runtime/proc.c:220 +0x1c0
which is better than simply seeing the error message from os.Open.

Clearly this is too much code to write after each call, but some of the code can be moved into a custom error type. (Also 4K isn't enough to capture deep stack traces which is a shame when there is enough free memory available. Maybe there's room for improvement in the runtime package?)

An important consideration is that of "soft" errors - errors which don't appear to need diagnosing at one level of the stack, but which turn out to be more serious from the perspective of one (or more) of the callers. It will probably be too expensive to capture a stack trace every time an error is detected. But it may be sufficient for the first caller which regards the error as serious to capture the stack trace. The combination of a stack trace of this caller and a reasonably helpful error message may be good enough in most cases of soft errors.

Another consideration is logging of errors. It can be very distracting to see the same error logged over and over again. So it might be necessary to keep state in an error to record whether it has already been logged.

I'm interested to hear what error handling practices are evolving in the Go community. An early blog acknowledges the problem:
It is the error implementation's responsibility to summarize the context.
but doesn't address the difficulty of large codebases where the immediate program context isn't always sufficient to diagnose problems.

Some will argue for adding exceptions to Go, but I think that may be overkill, especially for soft errors. I like explicit error handling as it encourages good recovery logic. However, there may be room for improvement in the way the context of an error can be captured. Let's see what nice idioms are beginning to emerge...

Wednesday, November 20, 2013

Prototype Virgo charm

In the previous post, I mentioned a use case for the Virgo buildpack of running Virgo as an Ubuntu Juju charm. With some advice from the guys at Canonical, for which I'm grateful, a first prototype is now working.

The purpose of a charm is to instantiate a service in a cloud. I'm testing on Amazon EC2, although the charm should run without change on other clouds. The crucial contents of a charm are a simple metadata description and a series of hooks to control the lifecycle of the service associated with the charm and its relationships with other entities in the cloud.

So far, I've implemented two simple hooks. An install hook downloads and installs a JRE and Virgo as well as a test application. It does this by installing the test application and then running the Virgo buildpack compile operation against the application, which in turn downloads and installs a suitable JRE and Virgo (actually, Virgo Server for Apache Tomcat). A start hook starts Virgo using a command similar to that output by running the Virgo buildpack release operation against the test application.

The following pieces of work are necessary to tidy up the prototype:

  • Make the start hook reuse the output of the release operation which is a piece YAML containing the basic shell command necessary to start Virgo. It will probably be simplest to rewrite the start script in Ruby so that parsing the YAML file will be trivial.
  • Somehow synchronise the termination of the start script with the completion of starting Virgo. Currently, the start hook "fires and forgets" using an asynchronous invocation of the Virgo start script. The result is that the start hook returns before Virgo has started, which gives the wrong impression of the state of the charm, especially if Virgo startup fails for any reason.
  • Implement any other hooks which are required as a bare minimum, including, presumably, a stop hook.
  • Provide a mechanism to deploy a specified application to Virgo in place of the test application.
Please see the list of issues on github for all known bugs and restrictions.

There is also the small matter of the charm being checked into git. It is currently necessary to delete the .git directories of the charm itself and of the Virgo buildpack submodule since Juju uses git to version the uploaded charm and .git directories cause the install hook to fail. Canonical have some better support for git in mind, so this may just be a question of waiting.

If you want to try out the charm, you can clone it from github (tagged at the time of writing as v0.1). I've put some simple management scripts (which could also do with a bit of tidying up) in the scripts subdirectory which allow me to refresh a copy of the charm without .git directories, start up the Juju environment, deploy the charm, and tear down the Juju environment (currently the only way to stop the Virgo without using the EC2 console).

I've licensed the code under the Apache v2 license and would be delighted to accept contributions if anyone would like to raise issues, make some of the changes mentioned above, or otherwise improve the charm.

Friday, November 15, 2013

Virgo Buildpack Refreshed

I'm no longer leading the Virgo project, but I am still fond of Virgo, so I thought I would update the Virgo buildpack (previously mentioned in this blog) in my own time to re-base it on the current Java buildpack.

It now inherits all the benefits of the Java buildpack (more here):

  • Ability to upgrade Virgo without changing the buildpack or the application - great when a security fix needs to be applied.
  • Automatic calculation of JVM memory settings.
  • Clean separation of components - Virgo is a new container (described here) and the other components including OpenJDK support are inherited for free.
  • Helpful diagnostics including automatic JVM destruction on "out of memory" and debug logging of the buildpack's operations.
I decided to stick to the most general style of application layout that the previous version of the Virgo buildpack used. This consists of a pickup directory containing zero or more applications and, optionally, a repository/usr directory containing any additional dependencies of the application which are not provided by Virgo. This has the advantage that the detection criterion for Virgo (existence of the pickup directory) does not overlap with the detection criteria of the other containers inherited from the Java buildpack (Groovy, Play, Java Main, Spring Boot CLI, Tomcat) and so the Virgo buildpack is a functional superset of the Java buildpack.

There are two use cases that interest me. One is running Virgo on Cloud Foundry. The other is running Virgo as an Ubuntu Juju Charm - but more of that on another occasion.

Tuesday, September 03, 2013

Code Climate

We are using Code Climate to check the quality of the Ruby code in our Cloud Foundry Java buildpack. It's an excellent tool, but some improvements would really help.

1. Scans need to be triggered by git push so that I can rely on notifications rather than prodding/polling.

2. Sometimes code duplication detection is a bit harsh, IMO. I'd like an option to annotate a class/method to allow duplication. Filtering out whole files is too coarse-grained. For example, the following methods flag as duplicated but factoring out the duplication would, IMO, damage the readability of the code:

3. I'd like to be able to configure the "Repos" page to show just some of my projects for a quick team-specific summary. Preferably I'd like to be able to switch easily between filtered views.

4. I'd like to be able to add email addresses to the notification configuration, e.g. mailing lists and mail aliases so multiple people can be notified easily.

Wednesday, April 03, 2013

Virgo in the Cloud: a CloudFoundry buildpack

The recent Virgo community survey showed quite a bit of interest in running Virgo in the cloud. With CloudFoundry's forthcoming "buildpack" support, this was relatively easy to achieve.

A Virgo buildpack is available on github - see the README for detailed information. It currently supports two types of application: web applications or "overlays". A web application may be a standard WAR file or an OSGi Web Application Bundle. An overlay is a pair of directories -- pickup for the application(s) to be deployed and repository/usr for any additional dependencies not already provided by Virgo -- which are placed in an instance of Virgo Server for Apache Tomcat.

The support for buildpacks should ship later this month - see the CloudFoundry roadmap.

Monday, February 18, 2013

Virgo survey results

Thanks to the ninety-seven people who filled in the Virgo survey. The survey is now closed and the results are in. I'll summarise the results here, but the raw data (in Open Document Spreadsheet format) are available for anyone who wants more detail.

88% of respondents are on Virgo 3.5.0 or later while only 5% are still using SpringSource dm Server.

Virgo Server for Apache Tomcat is by far the most popular runtime deliverable. I would expect this to change over time if SAP's cloud strategy based on Nano Web is successful, even if such success doesn't feature much in Virgo survey results.

A greater respondents (36%) are in production this time, compared to 23% in May 2011.

OSGi and Spring are both preferred programming models with Java EE being somewhat less preferred.  Admittedly this question doesn't capture those who are forced to use a programming model they would prefer not to, but hopefully that number is small given the choice of programming model provided by Virgo.

The future directions were all of interest, some a little more than others. I'm not going to comment in detail, but better support for OSGi standard applications is particularly strong with a high "Gimme gimme" ranking and a tiny snooze factor.

The written comments were illuminating on the whole. Here are the comments for question 7 "Any other future direction(s) you'd really like to see".

Better Maven integration: Automatic deployment, Automatic installation, etc. Better Documentation on How To do integration tests of a complex Web Appplication in Virgo.

I would like to see a better testing framework for Virgo unit and integration testing.

Ensuring that the tooling follows the development of the Virgo server, because it's quite slow right now and often leads to some null pointer that imply reconfiguring the server in STS :(

reliability and troubleshooting are a major concern. As Virgo exposes OSGi to applications - it's harder to debug classloading problems, compared to pure Tomcat or Jetty environments. xx

Question 11 "Anything else to get off your chest?" produced quite a bit of feedback. The tooling is fairly criticised, so we are hoping the upcoming 1.0.1 release will fix a number of common problems. There are repeated calls for sharing of experience with real world applications and technologies, something I feel the Virgo community could helpfully contribute, for instance via blogs or on the Virgo wiki: I'd invite anyone interested to go ahead and add to the Community section. Meanwhile, we have been revamping the samples and will be issuing a milestone soon.

Integration testing made easy (we talked about cargo integ' on the forum and it's for me the priority to leverage Virgo as a top level platform).

Virgo was not simple to shrink, we ended up with a number of components that we could not easily throw out. We did eventually get the right isolation and app working, but the project failed for other non technical reasons. There are generally too many frame works in java, and the owners of java have let opportunity to fix jar hell slip too many times. Look at other language ecosystems as examples. Erlang makes it super easy for operators to update code in a system.

Virgo: Don't push yourself so hard today. Try to find some relaxation time. If you had big plans, perhaps you should cancel them. Instead, schedule some time with friends or family. Or treat yourself to a little indulgence. Some wine tasting here or appetizers there won't hurt as long as you don't go overboard.

We really would like to see a much more stable version of the virgo tooling. Virgo must be restarted way too often during deployment because of tooling problems.

Move away from Spring. JavaEE + OSGi is a better combination. Nice to see that supported in the latest(?) release.

Generally I'm sorry to say I just don't see a future for Virgo. The container is too hard to use and the complexity is too much for the benefits delivered. Gettting a working build and keeping it working with manifest manipulation is still too hard and error prone. It seems unlikely it will ever get fixed or improved. The "next big thing" seems to be Typesafe. But for the most part, containers are going away, and we're going to move to something like AMQP based services. In fact, you can get JVM isolation just by running more JVMs in the cloud. So the unit of deployment is the Virtual Machine, not an OSGi bundle. Sorry for the negative feedback, personally I have always liked OSGi, but for most developers it's too hard to use for the benefits derived.

The first one thanks for your job, and support of this great Software called Virgo. We are developing in OSGi and Virgo about two years, developing Konekti aka Modular Web business platform. We suffer the bad initial tools in eclipse to develop, actually are better. Of course we would like more documentation :) We think it would be interesting adding any blog or tutorials about integration of other frameworks, or experience with Virgo. Our company spent many time integrating many frameworks like JBMP, Drools, ActiveMQ, Jersey, GWT, Vaadin, Jasper Reports, Quartz, ... , so we could provide our experience. Also we would like to know this experience of other companies that also are developing in OSGi and Virgo. We think that Virgo and OSGi in general are a great technology, but not many people knows about it, so any pedagogical work is necessary, and any must lead it. If in the future you add some meeting point, we can contribute it with our real experience in OSGi and Virgo. Best Regards.

Without Eclipse Virgo we would probably not have choosen to try OSGi in my project. Because we need to migrate a Java web application with quite a lot dependencies.

My take on the future - you need to branch out and ensure as much of the available Java technologies are instantly usable in Virgo. Classify the technologies (something like java-source.net does, but better) and pick a project for each one to start with, involve the community and build a library of addons and examples - you'll not only prevent users from bailing on using Virgo because of too much program infrastructure integration effort, but do just the opposite - attract them with ready-to-use examples and simple working projects. I started playing with Virgo since about 7 months. I am using Virgo to rebuild an existing security application platform which we provide to our customers and i find it very attractive to use for me as a developer. Using Virgo as an application server platform opens up a huge potential to me and allows me to build real modular applications based on osgi without having to deal with osgi runtime basics to get started, which is great. The features Virgo provides are good and do make sense to have in such an environment. Although, as mentioned above, Virgo Tooling should be improved and in my opinion this is the key element to attract more developers for using Virgo.

We use it as a managed osgi runtime and install everything into one region for sanity. Virgo rewriting bundle imports causes more problems than they are worth. Using different containers instead of a partitioned runtime makes more sense for disparate applications.

Virgo tools need a lot of improvements. In my company we ended up implementing a little set of eclipse plug-ins to perform similar tasks as those offered by Virgo tools. For example, ordering of projects deployed to the server, because whenever you open the Virgo server editor it takes ages to show up and you just have a 5 lines list for ordering bundles, with no possibility to perform a multiple selection.

Nice modular concept. Needs examples to host Virgo Nano in regular J2EE web app

I don't know what I'd do without you guys!

sorry but I feel you're apart from rest of the osgi community. Why not use or contribute to bnd, maven-bundle-plugin... (note : I have no idea about politics) Please keep thing simple, because It's not easy to defend osgi. I try in my compagny, but osgi feel complicated. In fact it's not. Just a problem of image.

First up - it's excellent. We were going to migrate to an OSGI stack but Virgo seems to have addressed a whole bunch of issues we knew we would hit. The down sides are: - eclipse tooling a bit unreliable / immature (still cannot deploy a ) - different approach from target platform standard eclipse stuff (more eclipse general issue maybe) - the whole spring, hibernate, cglib, resolve issues, class not found issues, blah blah is still a nightmare (nature of the game I guess) - *particularly if migrating to virgo* - greenfield may be easier

Hate the fact that there is no book on Virgo yet, hate that using it depends on other projects (Gemini) that also have sparse documentation. Even a simple hello world on one of the technologies can be a waste of a few hours when adapting to Virgo. Felix/Aries start to gain more traction now. No Paxrunner support for Virgo yet.

To me virgo nano with documentation regarding on how to build isolation would be perfect.

The whole jetty thing and not having an answer for regular Jdk app server model.

Virgo is great and has been very reliable. It is OSGi and integrating 3rd party software that is the pain. For example, getting DB2 datasources using a ConnectionPool framework and getting the datasources via JNDI lookup or a Declarative service takes a lot of work to configure. I still have not seen any good documentation about storing encrypted data in external properties files and then having a hook to decrypt the data so that it may be used in a blueprint.xml definition in the context of ${var} substitution. I do not want the id/password used for my database connections to be stored in plain text in some properties file. Seems that there should be a good recipe or API for handling such common security concerns. For the most part I am well pleased with what Virgo offers, and I am in the middle of transforming a JBoss J2EE multi-tier application to a pure OSGi application running under Virgo.

I love Virgo but the learning curve is steep. Not only Virgo's fault but overall to develop SpringDM applications I had many problems since there are many technologies involved none of which is particularly stable. Random problems: Bundles where there which were not seen, then they were seen. Spring services were found then were not found anymore. Then deleting the work directory solved a lot. Then a bundle was found with version 0.0.0 and you have no idea why. Then 1 day later you realise there was a missing dependency. Etc. Debugging is still quite tricky, when things work do work but many times to get there is a huge pain. Anyway Virgo rocks :) Also the problem with many JARs around which are not yet OSGfied. And to OSGi them you have to beg the developers. Or you have to wrap it yourself but then you have to do it everytime there's a release. There are ways to easily OSGfy a plugin but it would be very useful to make the process as seamless as possible and push the community to embrace OSGi.

I really appreciate what you guys doing. But I don't like the current state of maven support. We use maven for every project it is key technology at our company. It was not easy to setup maven multi-module project to work with eclipse virgo ide and be able to successfully build outside eclipse as well. (driving all osgi dependencies from maven side + generating manifest + providing transient dependencies so virgo can see them when we add dependency just to pom.xml) Do not have sources this days is just sad (and make it that bundles which comes with virgo to be source-aware is complete madness) - with maven it is just so easy. Anyway keep up good work.

Its still hard to managed those jar dependencies or change to more recent version of spring without running into conflicts.

Tooling tooling tooling. Is has been the biggest issue and time consuming process. We have finally crafted a build setup that support maven in CI and in Sts that works but at times can be fragile and difficult to troubleshoot. Many many times we ponder if there is a better way and aren't able to find the answer.

Startup time is the major pain point for us.

I think you need to do more community development. Work on describing how people can use vanilla technologies deployed in Virgo and then move into OSGi modules if they want to. My main concern is trying to stay within a technology stack that is either directly portable or easily ported to a different server as an option.

Seems like things took a while to transition to Eclipse, but feeling better about Virgo and tooling by the day. We're most interested in running this on tiny devices, so are happy (and hoping) to see continued support for Nano.

We are very happy with Virgo! We enjoy the fact that's pretty lightweight, easy to configure and provides good performance. A good thing would be if more than one pickup-folder could be defined.

In my opinion Virgo is lacking some really good documentation and programming examples. The examples available are all using maven and not the eclipse pde dependencies and tools, wich are the easiest way to develop within Eclipse.

Virgo Tooling with Eclipse is a nightmare. So many bugs, runtime parameters that can't be changed (try to change MaxPermSize...) or the lib\endorsed directory not included - took us hours to find out. You guys should eat your own dog food and start to use these tools not just in hobby projects.... I guess this would improve quality.

You should put more effort in the Virgo Tooling it's the more frustrating thing in Virgo. It is very slow and buggy. Keep the good work!

I want better virgo tooling in eclipse/sts. Each times i open tooling in eclipse, it's very slow still 30-40secs. If i stop virgo in error during starting then i need kill eclipse.

The technology section of the survey is rather long and hard to summarise, but it will provide useful input for future development. See the raw data if you are interested.

Finally, the quiz results were intriguing. The correct (or should I say my) answers are:

JOnAS was the biggest mystery with 49% responding "Dunno". WebLogic was second with 32%, just in front of WebSphere with 28%. One person thought that Virgo does not use OSGi or explicitly support it, but their preferred programming model was Java EE, so perhaps they see Virgo as just another enterprise server.

Monday, February 04, 2013

No solution for complexity

Neil Bartlett's blog of this title is shocking because it shows how slow to adopt proven technology the computing industry is.

David Parnas wrote his seminal paper "On the Criteria To Be Used in Decomposing Systems into Modules" (available here) in 1972. A large transaction processing monitor was modularised in the 1980's because the cost of servicing it was spiralling out of control. (Precise specifications were written for the new modules to clean up the interfaces and minimise dependencies on module internals, but that's another story.)

The OSGi module system for Java has been mature for at least five years, possibly longer depending on how you count it. Most of the major Java application servers are now constructed of OSGi modules and a number of them expose OSGi for applications to use. And yet we still see complaints such as the one Neil quotes. It seems application developers are stuck in their ways or stuck on systems which prevent them from using modularity.

Of course, modularity will eventually be adopted by all business critical software. There's really no rational alternative. But how long it will take is quite another matter.


OSGi (130) Virgo (59) Eclipse (10) Equinox (9) dm Server (8) Felix (4) WebSphere (3) Aries (2) GlassFish (2) JBoss (1) Newton (1) WebLogic (1)