Monthly Archive for April, 2009

Maven, Eclipse, and XMLBeans

One of the great things about using Maven is that XMLBeans are handled quite intelligently. What we traditionally did with Ant was to create individual schema jars and have our actual code modules depend on them. This generally works, but it can be nicer to have the XMLBeans classes directly inserted into your project jars.

The Maven XMLBean plugin does this by default. You place your XML Schema files in src/main/xsd and the java source is first generated to target/generated-sources, then compiled to target/generated-classes, and finally copied over to target/classes with the rest of your code.

This works fine in Maven when using the comand line, but when we used the m2eclipse plugin there is a very strange error that can occasionally manifest.

The first manifestation of the error is when you have “Resolve Workspace Projects” enabled. What happens is that any project that has XMLBeans in it will not expose those beans correctly to projects which depend on it. Everything but the XMLBeans classes themselves is find, but you’ll keep getting spurious “class not found” problems for any XMLBean classes.

The second manifestation of the error is when you try to do a maven build run configuration with the “install” target. (This is when you don’t using the Maven Project Builder, which when you go to the project menu and hit clean works fine). At this point, occasionally (but not always) when you do an install, the compilation phase will fail and you will get the same sort of class not found errors as the mentioned above.

After a few weeks of struggling with this problem, we discovered that the root cause is the “scrub output directory” feature of Eclipse’s Java Builder. What occurs during a project rebuild is this:

  1. The Maven Builder runs. This generates the XML beans and compiles all of our other code.
  2. The Java Builder runs. This re-compiles all of our code. This is necessary to get all of Eclipse’s whiz-bang Java features to work.

The problem is that when you have the “srub output directory” feature enabled in the Java Builder, it will delete all of that XMLBeans code the Maven Builder worked so hard to compile. The code will still exist in target/generated-classes, but will effectively not have been copied over the the target/classes directory. Very annoying.

So, turn off scrub output directory when using the m2eclipse plugin.

High availability with iSCSI

We recently received a question from a researcher regarding using dsNet on top of clustered storage. The researcher asked how dsNet provides high  availability using iSCSI when each initiator connects to a single iSCSI target.

Zachary Mark, the lead iSCSI developer at Cleversafe, commented that when using iSCSI, the high availability (HA) of a dsNet depends on the availability of the access server. For a true HA setup Cleversafe dsNet software provides a good backend, but some special configuration is needed on the initiator frontend to reap the full benefits of HA.

Zach says:

Typically, deployments with multiple access servers exposing the same vault are in an active/passive configuration.  Most initiators have some kind of built-in failover capability through MPIO.  The MS Windows software initiator utilizes Microsoft’s MPIO driver, and OpenISCSI has failover capability as well.  When the initiator detects an access server is no longer available (OpenISCSI, for example, will do periodic path discovery), it will close the existing session, open a new session on the other access server, connect to the same underlying storage, and reissue all commands which were in progress when the failover occurred.

These active/passive configurations are supported by dsNet software. Unfortunately, access clustering using an active/active configuration is not supported. This prevents:

  1. Round-robin style MPIO configurations where multiple access servers are writing to the same underlying storage.
  2. Initiator clustering.

Zach additionally notes:

I’m not especially familiar with the Linux initiator clustering solutions, but Windows has a feature called (surprisingly enough) Failover Clustering.  In short, it allows one to configure redundancy into a group of Windows servers for failover purposes (but allow them to access the same backing storage).  For this feature to operate, Windows requires devices to obey the SCSI reservation protocol (SCSI-2 style reservations in Windows 2003, SCSI-3 persistent reservations in 2008 and later).  The Cleversafe iSCSI target does not currently support SCSI reservations.  Additionally, in order to allow access server redundancy alongside Initiator redundancy, the access servers must be able to synchronize their knowledge of reservations (hence why access server clustering is generally required to support initiator clustering in this manner).