Discussions

News: Cluster4Spring (Clustered Remoting for Spring) 0.85 released

  1. Clustered Remoting For Spring Framework (Cluster4Spring) is open source project that represents alternative implementation of Spring framework remoting subsystem and supports different schemes of remote communication between client and server (1-1, 1-many, dynamic services discovering). The major features of Cluster4Spring library are: * Support of one-to-one scheme of remoting (similar to the one currently supported by Spring); * Support of one-to-many scheme of remoting, which assumes that one client selects remote service for invocation from one of predefined locations; * Support of one-to-many scheme of remoting with dynamic discovering of remote services; * Several built-in policies for selecting remote service for invocation are included (they are applied if service is available in several locations); * Built-in functionality for handling remoting exceptions of method invocations that provides ability to re-invoke remote service using different service location automatically; * Steep learning curve since ideological implementation of Cluster4Spring bears a close resemblance to the implementation of remoting in Spring; * Non-intrusive for existing applications - it is simply enough to change appropriate remoting-related Spring configuration files to start using Cluster4Spring; * Provides a convenient way to add custom interceptors both on client and server side; * Flexible and modular architecture which is ready for further extensions and customizations; * Library is stable and ready to use; Cluster4Spring is released under Apache License v.2.0. To find more about Cluster4Spring details, documentation and examples, please visit the web site.

    Threaded Messages (10)

  2. does it support group communication and broadcasting? is the one->many transport is reliable communication ,and what about its performance comparedto jgroups or similar approach? can we use it to build data grig pattern application? how does it support failover and loadbalancing? is there is a notion of a distributed hashmap or the like?
  3. Hi Joe, Thank you for your interest. Well, briefly speaking this is another implementation of remoting subsystem in Spring. It utilizes the same principles as standard remoting in Spring (i.e. remote proxy factory beans and exporters) yet provides different implementations for them and all details of lookup and invocation of remote service are also hidden within that implementation. If discovering remoting scheme is used (that assumes that there are several instances of remote service available in different locations and they are discovered dynamically), a kind of distributed hash table is used. Internally, implementation of such distributed registry of services may use either custom UDP multicast or sit on the top of JGroups (both implementations are included into distributive), so performance of services discovering is close to any custom approach based on JGroups. Selection of particular underlying protocol could be made based on particular needs of specific application. To find more about distributed registry used by Cluster4Spring by default, please take a look to http://www.soft-amis.com/distregistry/index.html If necessary, it is possible to use alternative implementation of services discovering mechanism (say, based on JBoss Cache) - internal hierarchy of classes was designed to provide easy extension of this subsystem. It is possible to specify whether found services should be discovered on every invocation of remote service or be cached for later use. Failover - there are several options. First, there are several policies that controls what should be done if some remote issue occurred, i.e - try to re-invocate the same service, or select another location of remote service and invoke it, or refresh list of available service locations and invoke service in different location or simply throw remote exception to caller code. Loadbalancing - intentionally, implementing full-fledged loadbalancing functionality was considered out of scope for this release (just for simplicity reasons). However, Cluster4Spring provides several predefined policies that select particular instance of remote service from the list of available ones (last access time, random, first one), so I suppose it is possible to say that initial support of load balancing is included there. And since the user is able to provide it's own implementation of such service selection policy, such a support could be extended even more, if necessary. Regarding data grid patterns - well, not sure, initially it was rather considered to distributed computations (however, it does not pretend to be full-fledge computational grid). Regards, Andrew Sazonov
  4. Replication[ Go to top ]

    So I understand cluster4spring is for load balancing between different replicas (Spring beans) of the same service, and these replicas are discovered automatically. What happens when you invoke a spring bean and that invocation triggers a state change ? Do you update all replicas across the cluster, in other words do you replicate the state changes ? Something akin to PojoCache or Terracotta ? Bela
  5. Re: Replication[ Go to top ]

    So I understand cluster4spring is for load balancing between different replicas (Spring beans) of the same service, and these replicas are discovered automatically.
    Well, in general you are correct, however there are some options there. It is possible to use either static 1-many scheme with predefined set of specified locations of remote service or discover services dynamically. It is possible to make load balancing. However, is is also possible to use different scenario - consider one server as "primary one" (so all remote calls will be forwarded to it) and switch to other "secondary" ones only if that server is not available.
    What happens when you invoke a spring bean and that invocation triggers a state change ? Do you update all replicas across the cluster, in other words do you replicate the state changes ? Something akin to PojoCache or Terracotta ?
    Yes, this is really good question. Current release is intended to be lightweight implementation of remoting and intentionally does not include functionality for data replication. Of course, if remote service is stateful, additional data replication is necessary and since there are lots of products that supports replication available, I considered that this functionality is slightly out of this project scope (at lest, for current release). While there is no transparent support for replication in Cluster4Spring, there is generic purpose distributed registry included into Cluster4Spring (one is used to discover services) and it could be used for data replication. However, for stateless services, it is obvious that there is no limitations related to replication. We've used that project internally in quite a large distributed system we've developed for more than a year, and there we've utilized similar approach - remote services in most cases were stateless and performed well defined pieces of work (generate PDFs, render images etc). However, there was set of application servers (based on Spring) that were used to access database (single clustered instance). On these servers, obviously, synchronization was necessary in several cases (mostly for cached data), and there we've use distributed registry to synchronize changes. Regards, Andrew Sazonov
  6. Re: Replication[ Go to top ]

    I understand that you guys focused on the client-cluster communication, handling load balancing, request discovery and failover etc. However, replication is an important piece of the puzzle that's (IMO) missing. Assuming stateless services means oftentimes that the state is pushed into the DB, where it cannot be cached (besides the DB and possibly JDBC driver's caches), slowing down access to it at the expense of perceived simplicity. Having a clustered DB at least eliminates the single point of failure (the DB). Cheers,
  7. Re: Replication[ Go to top ]

    I understand that you guys focused on the client-cluster communication, handling load balancing, request discovery and failover etc.

    However, replication is an important piece of the puzzle that's (IMO) missing. Assuming stateless services means oftentimes that the state is pushed into the DB, where it cannot be cached (besides the DB and possibly JDBC driver's caches), slowing down access to it at the expense of perceived simplicity.

    Having a clustered DB at least eliminates the single point of failure (the DB).
    Cheers,
    We address that without relying on the DB using openspaces framework - with this framework remoting is integrated with data under the same transaction context - the space. I.e. the space is used for storing the data as well as for delivering the parallel execution of the transactions that are sent as commands to the space. A dynamic proxy is generated to provide a remoting interface that does the implicit transformation between the method call and commands. Since the space stores both data and transactions we share the same cluster and transaction context as well as fail-over and clustering capabilities in a consistent way. Check it out: Clustering with Space Based Spring Remoting Some of the interesting features that you get with this approach are: * High Avaliablity: Since the Space by its nature (based on the cluster topology) is highly available, remote invocations gets this feature automatically when using the Space as the transport layer. * Load Balancing: When using a Space with a partitioned cluser topology each remote invocation will automatically get directed to the appropiate partition (based on its routing handler) providing automatic load balancing. * Performance: Remote invocations are represented in fast internal OpenSpaces objects allowing for fast serialization and transport over the net. * Async Execution: By its nature remoting support is asynchronous allowing for much higher throughput of remote invocations. OpenSpaces allows to use the async execution using Futures and also provides synchronous support (built on top of it). I would welcome anyone that is interested in further details to join our Session and BOF at the Spring ONE event in Brussle next week. Nati S. Write Once Scale Anywhere With OpenSpaces and Spring
  8. Coherence Data Grid for Spring[ Go to top ]

    If all this sounds familiar, you might be interested in Coherence Data Grid for Spring add-on we released last year. (ok... a completely shameless plug for some work I've been doing ;) Coherence Data Grid for Spring is a simple and tiny jar (<40kb) that allows you to effortlessly and reliably cluster Spring application contexts. It provides eight essential features; 1. Declarative membership of a cluster (through the use of a new Spring namespace called "datagrid") eg: In your application context, just do this; And your application will automatically cluster. While you can configure how it does this by configuring coherence ;), typically out-of-the-box that's all you need to do. No need to go to a console to configure it. No need to include 30+mb of jars. 2. Declarative specification of stateful services (Data Grid Beans). While there is a 5 minute introduction on the site, basically it uses Spring AOP to create remoting interfaces for your POJOs and appropriately optimize remoting together and state management (at the same time). It will intelligently keep data local to the application (cached) and ensure it is coherent within a cluster without developer effort. (It uses Coherence as infrastructure). Being built on coherence, you can confidently shutdown (or kill) spring contexts without losing data. You may even have the state backed-out to disk if you choose. It's again, effortless to use and behaves itself in production. Simply set the scope of a regular bean to be "datagrid" and you're done. 3. Provides a mechanism to control concurrency of Data Grid Bean access (ie: locking and concurrency control). Want to lock access to a bean? Simple call one of the several "lock" methods and you're done. 4. Provides a mechanism to register for Data Grid Bean events (as they are mutated) across the cluster. So if you want to know when a Bean changes, you can by simply using the DataGridBeanListeners. The underlying implementation intelligently switches between multi-cast and uni-cast based event subscriptions (and if multicast is permitted / configured) 5. Extends the standard Spring Application context events to support observing the life-cycles of clustered application contexts. So if you want to know when a particular class of application has started, stopped (or crashed), you can by simply using the normal Spring Application Context listeners. 6. Extends the standard Spring event publishing system to support sending messages to other spring application contexts. Want to publish a message to the other members of the cluster? Just use the normal application context publish() method. 7. As Coherence supports .NET, you can provide access to the underlying Data Grid Beans to C#, VB.NET, ASP.NET etc. Including real-time events. No need for SOAP or REST. Coherence provides on the wire compatibility between native .NET (1.1 and 2.0) objects and Java (which means Spring). 8. And lastly, as it's based on Coherence, you can use the standard InvocationService (it's been around for about 3 years I think) to provide a ServiceGrid. That is, you can either synchronously or asynchronously invoke Agents across the members of the cluster to do work, that of which may return a value (or values) or not (including from .NET) Like Nati, I'll be presenting some of this (and using an IDE) in my talk on extreme transaction processing at the Spring One conference in Brussels. You can also catch me at TSS Europe Conference in Barcelona where I'll be keynoting with Doug Clark on "going to the extreme". Cheers -- Brian Oliver Snr. Principal Solutions Architect Fusion Middleware Oracle Corporation
  9. hello Andrew even it it's a warning (and that could be ignored somehow), i still wonder why i get this messages: [INFO] 12:05:03,504 [WARN ] [INFO] traffic class of 8 could not be set, will be ignored [INFO] org.jgroups.protocols.UDP.createSockets(UDP.java:443) DownHandler (UDP) [INFO] [INFO] java.net.SocketException: Invalid argument [INFO] at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) [INFO] at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299) [INFO] at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052) [INFO] at org.jgroups.protocols.UDP.createSockets(UDP.java:440) [INFO] at org.jgroups.protocols.UDP.start(UDP.java:367) [INFO] at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589) [INFO] at org.jgroups.stack.DownHandler.run(Protocol.java:118) [INFO] 12:05:03,511 [WARN ] [INFO] traffic class of 8 could not be set, will be ignored [INFO] org.jgroups.protocols.UDP.createSockets(UDP.java:514) DownHandler (UDP) [INFO] [INFO] java.net.SocketException: Invalid argument [INFO] at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) [INFO] at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299) [INFO] at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052) [INFO] at org.jgroups.protocols.UDP.createSockets(UDP.java:511) [INFO] at org.jgroups.protocols.UDP.start(UDP.java:367) [INFO] at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589) [INFO] at org.jgroups.stack.DownHandler.run(Protocol.java:118) [INFO] 12:05:03,515 [INFO ] [INFO] socket information: [INFO] local_addr=194.199.25.109:51150, mcast_addr=228.5.5.5:45566, bind_addr=/194.199.25.109, ttl=4 [INFO] sock: bound to 194.199.25.109:51150, receive buffer size=64000, send buffer size=32000 [INFO] mcast_recv_sock: bound to 194.199.25.109:45566, send buffer size=80000, receive buffer size=80000 [INFO] mcast_send_sock: bound to 194.199.25.109:51151, send buffer size=80000, receive buffer size=80000 [INFO] org.jgroups.protocols.UDP.createSockets(UDP.java:521) DownHandler (UDP) i'm using jgroups communicationProtocol and helpers. i didn't change jgroups settings, so default ones are being used. any pointer is appreciated.
  10. hello everyone, as part of bigger project, to be released soon as opensource, i've ported the distregistry library to the Fractal component model. The default distribution ships Spring-files, and I thought someone else outthere could be interested in this version. So, drop me a line if you're interested.
  11. Failed under load[ Go to top ]

    I recently spent couple of weeks on writing a distributed Market Data Service for my client. The requirement was to distribute the load on couple of machines as MDS was meant to be used by few houndred node grid. We investigated couple of options and decided to go for Cluster4Spring. It gave us load distribution, failover and dynamic discovery. After couple of days of testing it turned out that we needed to switch the dynamic discovery off as some client nodes were failing to find MDS. This left us with predefined list of RMI endpoints. Unfortunately few days after we realised that some of the nodes were loosing connections to all MDS instances in the middle of the job. I ruled out the network problems. MDS instances were not overloaded, so they were not dropping connections. BTW it struck me that a single node could only handle 50 requests per second. Internal processing of request was taking no more than 1ms ( return map.get(key) ). I tried different config options but nothing helped. At this point I was desperate enough to write my own clustering proxy to replace Cluster4Spring. When I thought about it, it looked like simple task to do. You maintain a list of alive nodes, refresh it periodically. If invocation fails remove node from the list. When invoking you just pick random remote node and that is it. It took me 150 lines, and hey, it works! Single node is able to handle in excess of 100 requests per second. The code is here: http://piotrga.wordpress.com/2007/08/22/rmicluster-working-alternative-for-cluster4spring/ Enjoy!