Support for GlassFish – What’s in it for me?

The short answer is access to the support team, access to sustaining builds and indemnification. Read on for the longer answer.

Before I go on, there isn’t such a thing as support for GlassFish per say. Support is for Sun Java System Application Server 9.1 which is the same exact set of jar files (different installer though). Details here and here. As Eduardo has previously explained, we productize in public (similar to the Ubuntu model as I understand it). His post also describes the sustaining model, but I’d like to cover this more here and answer the question of “why should I care about support?”.

Some may ask “but how could anyone go into production without support??”. It is likely that the higher you go up the management chain, the less chances you have to hear this. The reality is that support from the community is pretty good and that a good chunk of people have been getting help in very effective ways directly from the engineers building the product and with no “where’s your support contract?” upfront question ;). The important thing to consider here is that GlassFish developers are active on the forum because they care about the product they actively work on and its adoption – this will not last as they move along to newer stuff.

Now, let’s try to answer the initial question “Support – What’s in it for me?”. First, you do get the hotline/calling support with an associated SLA (Service Level Agreement for response times), escalation process and access to a knowledge database. Second, and often not well understood, you have access to the sustaining branch. A sustaining branch is created when a product is released (this is when GlassFish v2 becomes SJS Application Server 9.1 if you will). See schema on the right.

A sustaining branch is something that only integrates highly tested bug fixes with a strict process. Releases go out on a regular basis every 6 weeks. Fixes also go into the main branch (the trunk), but is it very hard given the activity there to identify them one by one, let alone to create patches. That’s the reason for having a sustaining branch in the first place. Promoted public builds just do not undergo the same amount of testing as they are mainly focused on Java EE compliance vs. quality and performance. With access to the sustaining branch, a fixed bug simply requires installing the latest patch.

If you hit a bug, you should report it using the issue tracker or your support channel. Once the fix is available, supported customers escalating the problem get a FVB (Fix Verification Binary) from the sustaining team to verify that the bug is indeed fixed. While a FVB undergoes a 24-hour set of regression tests before it is sent to the customer, a sustaining build is going through a longevity test of 4 weeks, which is what is applied to final releases. Patches releases are then made available via SunSolve. If needed, the customer can be supported on this build until it is integrated in a sustaining release (again, they ship every 6 weeks). Note that we offer various levels of support. With a premium support contract, a P1 bug gets a live transfer to a support engineer for example.

Yet another benefit of buying a support contract is access to indemnification. IANAL but Sun indemnifies you against any legal action associated with open source software distributed by Sun. This is often times way enough to justify by itself the support contract and this Kodak thing usually helps drives the point home.

High risk applications where user perception of your web property is important or money is at stake should have you think of the risk up front and if the support price is right (and starting at $4,500 for 4 socket, we think it is), there really shouldn’t be any reason to not buy support. Otherwise, let us know.


Author: alexismp

Google Developer Relations in Paris.