Saturday Mar 31, 2007

NetBeans and GlassFish clusters:What are your needs?

We are looking for feedback from users of NetBeans and GlassFish on what they would like to see in terms of their runtime interactions through the IDE with cluster(s) in GlassFish.

Most IDEs provide the ability to work with a single instance of an application server such as GlassFish, etc.  I do not see the notion of cluster(s) in the IDEs unless I have missed something obvious. There must be various use cases wherein a developer (typically an advanced developer/deployer/tester such as a System Integrator) would need the ability to interact with a cluster through the IDE.

Clustering typically involved an environment consisting of many instances that can be located on different remote machines. Such instances are created/started/stopped/deleted on each machine by a dedicated agent process that follows instructions from an administrative server within which a cluster is a logical configuration entity while instances are physical entities. So, within the IDE, there are possibly but a few operations that can be executed/managed.

So here are some questions for which I'd appreciate responses through comments (Add more if you can think of any further):

  1. Is there indeed a need for interacting with clusters through the IDE?
  2. What problems do you see today with respect to clusters from within your IDE?
  3. If the browser based admin console of the appserver can be lauched from within the IDE would this  be sufficient to address your needs?
  4. If not, why is the IDE an important piece to help solve that problem?
  5. If interacting with cluster(s) is important, what should that interaction functionality be from within an IDE?
  6. If debugging seems like an obvious use case, would that not already be addressed by working with individual instances that are part of a cluster?
  7. What other use cases do you work with that you wish an IDE could provide when working with clusters?

Do add more questions and answers if you can think of more.

Thursday Jan 25, 2007

GlassFish v2 Milestone 4 includes Shoal

GlassFish v2 has reached its Milestone 4 which is the Hard Code Freeze for the Beta. During this time, we addressed many bugs and features in Shoal and delivered a stable version to GlassFish

Shoal gets autoenabled when a cluster is created (Of course, one can disable it by setting the cluster's heartbeat-enabled attribute to false). When a cluster is created, the Domain Admin Server creates an instance of this cluster as a group and joins it as a Spectator member. So for each cluster, the Domain Admin Server participates as a Spectator member.

After instances are added to cluster and as these are started, each instance in the cluster participates in this Shoal cluster and can then communicate with each other and monitor each other's state. When an instance or cluster is shutdown administratively, Shoal notifies all instances about this impending shutdown allowing Shoal GMS client components within each instance to do appropriate pre-shutdown operations. Similarly, when an instance fails, Shoal notifies client components in all surviving instances about this failure and if needed to notify the need to perform any recovery operations. Details of these features are available at the Shoal site.  

Shoal is used in GlassFish for group membership monitoring and for value add features like automated transaction recovery performed by a delegate instance, self management wherein administrator can define remedial actions based on occurence of events including group events that Shoal notifies. The IIOP Load Balancer uses Shoal for dynamically generating failover IIOP end points as cluster shape changes and provides this to IIOP clients out-of-band so that these have updated failover targets. The In-Memory Replication component uses Shoal to confirm failures and to determine when a member has joined or gracefully left the group.

By GlassFish FCS, we will make Shoal stable enough to be released on its own as a standalone infrastructural component that other projects/products can use.

Shoal presents some interesting product use cases.

An in-memory cache on the lines of memcached should be a little more work and is a good possibility. A Shoal-based compute grid is another possibility with relatively small incremental code to be written to make that happen. I can also think of a Derby cluster using Shoal as the underlying clustering and replication mechanism. Once you think of Derby, any other product could be applied here. For instance, a directory server cluster, a web server cluster, a message queue cluster, etc. Another possibility is that Web-only apps could directly use Shoal to cache states among instances of web containers. So you see, the possibilities are endless and is only limited by imagination. :)


Shreedhar Ganapathy


« July 2016