Discussions

News: Shoal Clustering User Guide Part 1

  1. Shoal Clustering User Guide Part 1 (8 messages)

    Shoal is a Group Management Service (GMS) used in GlassFish. Shreedar Ganapathy has written up "Shoal Clustering User Guide Part 1," a quick guide for how to register for group events, join a pre-defined group, get notifications of group events, send/receive messages, and leave the group. This is another group-management API - along with architectures like JavaSpaces, JXTA, JGroups, and even Terracotta DSO. It's an interesting space; what do you think of not only Shoal, but the entire subgenre?
  2. What are the benefits of using Shoal compared to "raw" JXTA or JGroups?
  3. What are the benefits of using Shoal compared to "raw" JXTA or JGroups?
    First off, Joe, thanks for posting the blog reference to this thread. Shoal provides a client API (in addition to some more functionalities) that allows consuming applications to not tightly bind to a group communication library's specifics. One benefit is that the underlying library can be changed with out affecting consuming clients ability to continue to use group comm facilities. Another benefit is that each group member can simply use the logical name or identifier used in the application to communicate with each member and not have to deal with the end point locational details of the other members. Both JGroups and Jxta have very compelling functionalities to offer but essentially involve tying up implementations to those specific libraries. We saw this as a need arising for GlassFish Appserver and other enterprise infrastructure products in terms of pluggability in the clustering space. The API with Shoal abstracts out much of the common use cases with group comm libraries and can be further extended (given that it is open source). We welcome your feedback, suggestions, and contrributions to make improvements. Shreedhar Ganapathy Sun Microsystems
  4. This is another group-management API - along with architectures like JavaSpaces, JXTA, JGroups, and even Terracotta DSO. It's an interesting space; what do you think of not only Shoal, but the entire subgenre?
    Well, I believe GridGain (http://www.gridgain.org) has also indirectly entered this subgenre. Now, from what I see, Shoal is just an API wrapper on top of underlying GMS and communication layer. What kind of benefit it provides comparing, for example, to using JGroups directly? I can see that there is a uniform API which allows you to switch implementations underneath, but are there any features present in Shoal that are not present, for example, in JGroups? Best, Dmitriy GridGain - Java Grid Computing
  5. This is another group-management API - along with architectures like JavaSpaces, JXTA, JGroups, and even Terracotta DSO. It's an interesting space; what do you think of not only Shoal, but the entire subgenre?


    Well, I believe GridGain (http://www.gridgain.org) has also indirectly entered this subgenre.

    Now, from what I see, Shoal is just an API wrapper on top of underlying GMS and communication layer. What kind of benefit it provides comparing, for example, to using JGroups directly? I can see that there is a uniform API which allows you to switch implementations underneath, but are there any features present in Shoal that are not present, for example, in JGroups?

    Best,
    Dmitriy
    GridGain - Java Grid Computing
    The API wrapper while being convenient is also serving an important purpose. One the fundamental advantages/differences is that Shoal can help you register for Shutdown, Failures, Joins, Suspicions, and Recovery Selection through an event model. Shoal's service provider implementation for a specific group comm library can then deal with the semantics of how library underneath works. For instance, most group comm libraries would not distinguish between a failure and a graceful shutdown. We have seen several instances where this distinction has helped. Also, one of the features we added to the Shoal core layer was to provide clients to register for a failure recovery selection event so that one of the surviving members can be selected as a recovery server on occurence of a failure. This helped in GlassFish v2 to add a feature for automatic transaction recovery such that one of the members is selected by Shoal and the transaction service which is subscribed to get this event will take action in terms of performing recovery operations on the transaction logs of the failed server so in flight transactions can be completed. Do take a look at the API and documentation at the Shoal website (https://shoal.dev.java.net) to see more details. Cheers Shreedhar
  6. Would you use this kind of system to update even local caches in a single JVM environment? Specifically in the JEE server where you have a mix of EJBs and WARs deployed? For example, I have been looking for simple cache notification system to update changes that happen on the app tier, but are cached within the web tier. I was considering having threads in the servlet tier listening to JMS topics that the app tier would publish to. Would this be a better fit for such a system? The example is for systems running cross JVM, but will it work in the same JVM but with, perhaps, different class loaders? Say I had an EAR deployed as well as two separate WARs that made remote calls to the beans in the EAR. Ideally, they would all share the same cache, but that's some great fun with class loader shenanigans (and my caches aren't large enough that I mind duplicating them in the WARs). But, anyway, just curious if this is a good use case for this kind of system, or is there a better option.
  7. This is an interesting use case but one that was not in our design thought process. Though we have not consciously excluded possibility of the same jvm holding multiple "members" participating in the same group at least in the Jxta layer, this also implies that the allowance for such facilities is dictated by the underlying group comm library which usually are designed more for distributed communication and not necessarily between objects.
  8. I can see it more as a perfect design approach to open GlassFish for integration with other products. We’ll be looking closely at GalssFish for deep integration (communication, discovery, etc.) in the next release of GridGain and this is certainly a path we’d like to take. Best, Nikita Ivanov. GridGain – Enjoy Grid Computing.
  9. I can see it more as a perfect design approach to open GlassFish for integration with other products. We’ll be looking closely at GalssFish for deep integration (communication, discovery, etc.) in the next release of GridGain and this is certainly a path we’d like to take.

    Best,
    Nikita Ivanov.
    GridGain – Enjoy Grid Computing.
    I agree. Not only that, in fact with this approach using Shoal APIs and an underlying Group Comm implementation plugged in, you can integrate with pretty much any product that needs clustering facilities.