resource consumption management in glassfish
By sduv on Apr 05, 2006
Zones give a fairly lower virtualization of system resources. Each zone has a distinct IP address and hostname and root file systems. You can automate and recreate a similar looking zone on a different machine. One could put a J2EE application server and one business application in each zone and you could do very well isolating and managing resources consumed by each of the apps. In fact we found that this was exactly the model followed at another major financial house that is moving to Solaris 10.
But Zones are only on Solaris 10 and upwards. What about Linux and Windows? What if the applications were numbering in dozens or hundreds and had a fairly limited usage? Would it not be nice if you could deploy them all as you would normally do, one one Application Server, but still be assure Quality of Service? Things I heard mentioned were:
So we got thinking and did some thing pretty interesting in project Glassfish. We found out that by placing a policy engine that examines incoming service requests and assigning them to worker threads based on the policy file, gave us a coarse but fairly accurate control on overall resource consumption. We could restrict no more than say 20 users to a particular web application, at any time. We could set aside some request processing threads, so that users of an important time-sensitive application always received good service, even if there was an over abundance of users for some other co-resident applications. Pretty neat. Jeanfrancois implemented this logic on top of Grizzly, the high performance all Java HTTP engine we have under Glassfish Application Server (Happy to to say that it beats some of the best C++ based HTTP engines out there for latency and throughput!). Me and jeanfrancois have a BOF coming up at the upcoming JavaOne on this topic. Jeanfrancois will be blogging about this soon, so you can look at the code and give us feedback. This is an experimental feature right now. We want to get community feedback and contribution before roling it in as a supported feature.
If you havent already looked at Glassfish, go take a look at http://glassfish.dev.java.net. The code is already checked in.