No duct taping!

14.10.2012. nedjelja

OSGi, Spring, JEE and Virgo - yes, they can

This post is motivated by a few recurring questions in the Virgo forum where people are enquiring about the stability and usability of Virgo server in real production environments. What follows is a short description of our experience on that subject. "Our experience" covers a team of people working in software development at one of Croatia's major telecom operators that is also a part of one of the biggest telco groups in the world. Having said that, keep in mind there is no policy at the company level that prescribes or endorses the use of Virgo (or any other particular technology) in software development, so Virgo is just one of many technologies we use.

For the impatient

Anyone that's here just to get a feel of how Virgo is used in production in this particular case, need not look past this paragraph. Or, if you're really short on time, just read this post in the forums. For the rest, a general note for starters - we're currently running Virgo 3.0.3 Tomcat Server with some tweaks (more on that in a subsequent paragraph) for hosting quite a few of both end-user, as well as internal-use-only, applications. No other version is currently used.

The flagship is certainly our single-sign-on core - a system that manages a database of users for a large number of our web applications and provides functionalities such as registration and lost password support, and also a fully centralized session support (single sign-on and single sign-off). As most other JEE applications, this system uses JPA (EclipseLink) for database work, and additionaly, Atomikos for transaction management. And since the database is pushing toward a 7-figures number of accounts, scale-out ability is a major concern so clustering is built into the architecture. Nothing fancy, mind you - EclipseLink is doing its cache coordination using an external ActiveMQ instance, Tomcat uses its standard, TCP-based, session clustering and the rest of the common application data is shared using Hazelcast, which I can't recommend enough. So, the application is running in a two node, active-active cluster, with Apache front taking the role of a load balancer (sticky sessions turned on). As such, this configuration is taking hundreds of web request hits per second in peak hours, and has been running with no interruptions for months. Even when an upgrade or a major reconfiguration is needed, it's done one member at a time resulting in no downtime and no lost user sessions. So far, there has not been a single incident where there would be a need for a restart caused by Virgo-provided components.

Apart from this, Virgo also powers a few smaller web applications and a framework and a set of internal administrative web modules for various helpdesk-related activites. All of those systems are also running with no problems, and in total there are almost a dozen instances of Virgo Tomcat Server running various production applications on 6+ servers (some physical, some virtual), not including test instances that are separate. While we're far from being an exclusive Virgo-powered shop, for us it has proved more than ready to take on the toughest challenges we could throw at it.

VTS - the tweaked edition

I mentioned that our Virgo is tweaked. Well, here are a few details describing those tweaks that can maybe help if you need something that's not provided out of the box or you need to adapt it to your environment.

All of our deployed instances of Virgo are installed from a custom-built RPM. This RPM creates a system user for Virgo and sets up an LSB-compatible structure for Virgo to conform to a RedHat-based environment of our servers - it basically creates Virgo's directory structure under /etc/virgo by linking:
  • lib and repository directories to /usr/share/virgo/[directory]
  • serviceability to /var/log/virgo
  • pickup and work directories to /var/lib/virgo/[directory]
  • config directory is located directly under /etc/virgo
Apart from that, there is a customized startup script that can manage multiple instances of Virgo on one server (i.e. 'service virgo start/stop [instance]' and a script that sets up or removes the directory structure and configuration tweaks (ports, directories) for each of the instances. Virgo works with no problems in such a configuration.

As far as additional OSGi components that we've included in our custom-built RPM, most of those are already available as OSGi bundles. Those that aren't can easily be converted with bnd. This is a list and a few notes on integrating each of them:
  • Gemini naming - the Gemini OSGi JNDI provider bundle; an additional bundle must also be started (the code and README here), but since Virgo 3.5.0 this has been solved
  • JDBC drivers for Oracle, MySQL, PostgreSQL, MS-SQL (JTDS) and Firebird - all JARs converted to OSGi bundles using bnd using no special customizations
  • EclipseLink 2.1.3 - can already be downloaded as OSGi bundles; in order to make it work with JMS for cache coordination, a special fragment was made to attach to org.eclipse.persistence.core bundle and import the org.apache.activemq.jndi package
  • ActiveMQ - converted to OSGi bundle with bnd, no special customizations needed; in order to serve for cache coordination with EclipseLink, a special fragment was made that attaches to the bundle and imports the org.eclipse.persistence.sessions.coordination package;
  • Atomikos - can be converted to a bundle using bnd, no special customizations are needed and newer versions already provide the library in bundle form; additionally, a fragment is created that attaches to the bundle and imports all of the packages provided by JDBC drivers
  • JSF 2.0 - the two bundles (javax.faces and com.sun.faces) were taken straight from Glassfish and work without any changes
  • our own datasource provider is a custom bundle that reads an external configuration file and exposes an OSGi service providing javax.sql.DataSource instances - we're planning to replace this with Gemini DBAccess

Looking back and outlook

If anyone asked today if Virgo is ready and worth the effort, from our experience, the answer would be a definite YES. We've been running Spring-based OSGi servers, starting with the Spring DM server (1.0) in production, and using them for development, since their first milestone releases. It hasn't been an easy journey, but they have come a long way. Version 1.0 was running one of our self-care/webshop sites for almost 2 years, until the site was taken down and merged into a bigger project that was outsourced. Even with such an early release of a new technology, the site was running with no major problems apart from a need to restart it every few days because of a small memory leak somewhere that might have been caused by one of the additional components/libraries we used. Needles to say, no such problem exists today.

You can see from this writeup that there are still some obstacles to overcome if you want to run full-fledged JEE applications with Virgo. This concern is being taken care of in newer releases and with Virgo 3.6.0, which should include most of JEE-web profile support as one of its deliverables, you'll have pretty much all of the components you need ready out of the box. While basing your applications on OSGi and Spring can seem a bit out of place in full JEE-certified servers like Glassfish, Virgo now provides an environment that you can feel at home with both of those technologies. The benefits of using them are up to you to decide, but my advice is - do at least read up on them. We did, and found them more than worth the time and effort invested, with no small success story to back it up.
Broj komentara: 0
permalink  print  komentiraj