Invalid Virtual Machine

Today I tried to add a VMware VM created by a VMware workstation to my VMware Server 2 on Windows, but failed because it was considered to be invalid. VMware server told me "either the vmx file is corrupted or the VM was created using a newer version of VMware product." Seems both were not the case.

However, it turns out the vmx file could really be "corrupted". In vmx, the first line is

.encoding = "windows-1252"

After change it to be

.encoding = "UTF-8"

The VM is no longer considered to be invalid.

Then after I changed the "numvcpus" from 2 to 1, the VM is able to run on my VMware server, which unfortunately only has one single core CPU.

But interestingly, the original VM can run on a VMware server 2 on Linux.

I also need to change VM's network to be NAT instead of Bridged, and restart VM, to enable networking.

The guideline is that the virtual hardware for a particular Guest OS, such as the number of CPUs and the network type, has to be compatible with the hardware spec of the VMware server installation. For instance, you can not run a 2-CPU VM on a VMware server supporting only one CPU; and if there is no DHCP on the bridged network, then not surprisingly the VM can not acquire an IP if using the bridged network.

JMeter

Apache JMeter is a GUI that allows to compose a performance test without writing a single line of code! Basically what needs to do, in order to implement a performance test, is to properly insert test components such as "thread group, "loop control", "http requests" and "performance data graph", into the test plan. Of course the parameters of these test components should be specified, for instance, how many iterations of the http request are wanted. Then simply start it and a curve as well as data is presented!

With the help of JMeter, I am able to tell in a very simple test, when 27 urlrewrite rules are enabled, the OMII-UK website has a throughput of 3030.915 per minute, i.e., 19.796 ms per request; when rules disable, the throughput is 3005.259 per minute, i.e., 19.965 ms per request. In other words, in this setting, where urlrewrite 2.6 is used, urlrewrite rules pose a 0.9% slowdown. Though the credibility of this particular test result needs to be established.

A Portlet Class Loading Scheme

According JVM Spec 5.3 Creation and Loading, there are two situations for a class D to load or to initiate loading another class C: either there are references to C in D's constant pool, or D creates C using reflection. In either case, if D was defined by a user-defined class loader, then that same user-defined class loader initiates loading of C.

Let's assume the portal framework is a web application, and it has the following directory structure:

WEB-INF/
    classes/
    lib/
    portlets/
            portlet1/
                    classes/
                    lib/
            portlet2/
                    classes/
                    lib/

The web application class loader W will create a portlet class loader P for each portlet, that has W as its parent class loader and is responsible to load classes from portletx/classes and portletx/lib. W will use P to instantiate a portlet entry point using reflection. From the portlet entry point, all required classes will be then loaded by P, but still following the delegation model. It means W will try to load class first, only after that fails, P will load.

This scheme does not violate Servlet Spec 2.4, which states "The Web application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. Also, any requests from the client to access the resources in WEB-INF/ directory must be returned with a SC_NOT_FOUND(404) response." It does not prevent loading class from elsewhere.

The advantages of such a scheme are:

1. It takes the view that the portal framework is a web application; its portlets are just its components instead of web applications themselves.
2. It respects the class loading scheme of the web application server. The portal framework jars can be kept inside the web application, and the portlets share those jars naturally.
3. It also facilitates deploying and undeploying portlets on the fly, because the control is purely inside the portal web application.