Discussions

News: GigaSpaces Releases Version 5.2

  1. GigaSpaces Releases Version 5.2 (15 messages)

    GigaSpaces Version 5.2 has been released. This is an implementation of Space-Based Architecture, a model ensuring end-to-end linear scalability of both the middleware (namely with a data grid and a messaging grid) and the business logic associated with it, driven by service-level agreements (SLAs). It comes with built-in support for seamlessly scaling-out Spring-based stateful applications. The new version introduces significantly enhanced support for SQL-based continuous queries and local-views, which enables effective dissemination of the right data to the right consumer at the right time, with optimized bandwidth utilization and minimum performance overhead. Furthermore, it addresses "slow consumers" implicitly and eliminates any dependency on an additional messaging system for that purpose. All of the above now fully supports both Java and .Net environments. The new .Net support brings the benefit of both a mature caching implementation and space-based architecture (SBA) to .Net through the introduction of the concept of PONOs ("Plain Old .Net Objects"), the C# equivalent of Plain Old Java Objects (POJOs). The GigaSpaces .Net infrastructure provides a complete out-of-the-box API, documentation, benchmarks and runtime support for building scalable applications in C#, and is already being used to build pure .Net applications in major organizations in the financial industry. With GigaSpaces, developers can write their stateful business logic in Spring, or with simple POJOs, and scale their application without changing any of their code. All they need to do is plug in another machine and it will automatically join the cluster and scale the application as needed, using a deployment approach driven by SLAs. More details and FAQs are available on the GigaSpaces blog. Major milestones achieved in GigaSpaces Version 5.2:
    • Making a highly-distributed application look and behave as one. Using a space-based architecture and a virtualized middleware stack that includes messaging, data and processing, GigaSpaces 5.2 enables developers and architects to:
      • write distributed applications as if interacting with a single server, while GigaSpaces handles the dynamic distribution, coordination and synchronization of the messaging, processing and data across the entire network; and,
      • deploy applications and services through a single deployment operation, achieving an SLA-driven solution for the entire application stack. This includes continuous availability, on-demand scalability and self-healing.
    • Simple transition from tier-based approach into scalable, high-performance, stateful services. Using a POJO-driven approach and built-in support for Spring applications, GigaSpaces 5.2 provides:
      • POJO-Oriented Services. Developers can develop distributed services and deploy them throughout the network writing POJOs.
      • Co-Locating Business Logic and Data. Providing common infrastructure for real-time analytics and low-latency transactional applications.
      • POJO driven In-Memory Data Grid. The new version’s end-to-end POJO support enables developers to continue writing their POJOs and, via a declarative approach, map their existing data model to an optimized data structure. This allows for efficient and granular query support and data distribution, in a similar fashion to models such as Hibernate and JPA. In addition, using built-in Hibernate support, developers can continue to leverage their existing mapping to relational databases, while gaining the performance benefit of the GigaSpaces in-memory data grid.
    • Bringing Space-Based Architecture to pure .NET environments. With GigaSpaces 5.2, .Net developers write their distributed, high-performance applications using plain C# objects that can interoperate with Java services, while realizing their high-throughput and low-latency requirements. This support for .Net is already used by pure .Net organizations as well as those maintaining heterogeneous development environments that require interoperability.
    For detailed information on 5.2 features, please refer to: http://www.gigaspaces.com/wiki/display/GS/5.2. The Release Candidate of Version 5.2 is now available for download at http://www.gigaspaces.com/os_downloads.html.

    Threaded Messages (15)

  2. Slow Consumers?[ Go to top ]

    Furthermore, it addresses "slow consumers" implicitly and eliminates any dependency on an additional messaging system for that purpose.
    How does it address slow consumers?
  3. Re: Slow Consumers?[ Go to top ]

    Once the space detects slow consumer it is automatically disconnects the slow consumer by canceling its notification registration, enforcing it to reconnect (re-register for notification). This ensures that fast consumer(s) would not be affected from the slow consumer behavior. Slow consumer determined by measuring the notification delivery throughput to a client (see the parameter as part of the space schema). Once the space detects a client that consumes notification below the defined throughput limit it will wait (max time) for it to recover - see the parameter. The space will try to determine several times (see the parameter) during the wait period if the client recovered - if it is still below the defined throughput - its notify registration will be canceled. See more at: http://www.gigaspaces.com/wiki/display/GS/5.2#5.2-Slowconsumer Shay Hassidim VP Product Management GigaSpaces Technologies Write Once. Scale Anywhere.
  4. Re: Slow Consumers?[ Go to top ]

    Once the space detects slow consumer it is automatically disconnects the slow consumer by canceling its notification registration, enforcing it to reconnect (re-register for notification). This ensures that fast consumer(s) would not be affected from the slow consumer behavior.
    I see. I thought you were going to say that you store notifications on stable storage so they are available even for slow consumers ..
  5. Re: Slow Consumers?[ Go to top ]

    Hi Guglielmo
    I see. I thought you were going to say that you store notifications on stable storage so they are available even for slow consumers ..
    In fact that is indeed the traditional way of handling slow consumers which as you can imagine has significant impact in terms of performance and scalability on the server. That is something we deliberately wanted to avoid. If you think again about the real need for a second. The need here is to be able to maintain a consistent local image on the client side even in case of connection failure and/or slow consumer. One way to address that was to ensure that all the events that led to the current state will be stored and replayed as you mentioned, another approach would simply be to get a snapshot of the current state from the server and simply continue to receive updates from that point onward. The later was not really an option with traditional messaging systems since the notion of 'current-state' didn't exist. The Space on the other hand, maintain the current state by its core nature and therfore it maid much more sense to maintain slow consumer in that way i.e. when a local-view is detected as slow consumer it will be disconnected from the server. The client will then reconnect to the server and initiate its current state. HTH Nati S.
  6. Re: Slow Consumers?[ Go to top ]

    The Space on the other hand, maintain the current state by its core nature and therfore it maid much more sense to maintain slow consumer in that way i.e. when a local-view is detected as slow consumer it will be disconnected from the server. The client will then reconnect to the server and initiate its current state.
    Yes, cool. It's true, that the semantics of the tool are such that it makes sense to do this. I guess it's true with anything which has a well-defined state, as opposed to a messaging system, where there are only messages.
  7. Pricing?[ Go to top ]

    Why is it that vendors of grid computing solutions (GigaSpaces, Coherence) are so reluctant to publish the prices of their products on their web pages? IMHO, if you are convinced that your product is worth what you charge, there is no reason not to publish its price. Oliver
  8. Re: Pricing?[ Go to top ]

    GigaSpaces not interested unless you produce an invoice. The invoice should cover a $12k per CPU line item entry. As an Independent consultant, need to establish a credible expertise before a recommendation, have three multi-processor SUN servers and one XP single processor for research & development. GigaSpaces will want $84k, and the maintenance fees, of course, "valuable" time spent learning as well factored in for Total Cost of Ownership. Looks like I will not recommend GigaSpaces to anyone...
  9. Re: Pricing?[ Go to top ]

    As an Independent consultant, need to establish a credible expertise before a recommendation, have three multi-processor SUN servers and one XP single processor for research & development. GigaSpaces will want $84k, and the maintenance fees, of course, "valuable" time spent learning as well factored in for Total Cost of Ownership. Looks like I will not recommend GigaSpaces to anyone...
    George -- We are trying to deal with two different scenarios: large companies who are buying GigaSpaces, and individuals such as yourself who want to experiment and get to know the product -- something we fully encourage. The way we are dealing with the latter scenario is by providing: 1. The Community Edition - which you can use freely in development, testing and *production*. The Community Edition is limited in functionality (specifically clustering). We are aware that this seriously limits the ability to truly see the benefits of the GigaSpaces product, and therefore, are now having internal discussions on how to fix this. We will announce something soon in this regard. 2. The commercial versions of our product, which are available for a FREE 30-day evaluation. As I have already noted on another thread, we often extend this time period in a scenario such as you are describing (and NOT in a scenario where a large company is simply trying to postpone payment). Yes, you will have to talk to someone at GigaSpaces to make this happen, or simply download another eval license. We have been getting a lot of interesting feedback lately from the developer community about the need for better access to the product in terms of evaluation and "playing around" with it. We are taking this to heart and you should expect some interesting announcements soon... Geva Perry GigaSpaces http://www.gigaspaces.com
  10. Re: Pricing?[ Go to top ]

    GigaSpaces not interested unless you produce an invoice. [..] Looks like I will not recommend GigaSpaces to anyone...
    You've probably just run into some over-eager sales person worried about meeting their quota. Next time, just tell them that you are considering using Tangosol Coherence, and they will give you great service :-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  11. how gigaspace deferentiate itself from blitz ,the opensource jini based implementation,is there any difference in the architecture and how the user access the storage or it 's some added features plus performance improvment
  12. how gigaspace deferentiate itself from blitz ,the opensource jini based implementation,is there any difference in the architecture and how the user access the storage or it 's some added features plus performance improvment
  13. Hi Joe I would categorize Blitz as a high-quality opensource project and extremely capable JavaSpaces implementation. I believe that the Blitz project is critical for the adoption of JavaSpaces by a wider community and I wouldn't rule out the option that we (GigaSpaces) may contribute to that project ourselves in the near future. GigaSpaces Enterprise Edition today provides much more than a JavaSpaces implementation and therefore I'm not sure that feature list comparison makes real sense. From a position stand point a strong distinction between GigaSpaces and Blitz is that we (GigaSpaces) have extended our product in many ways beyond the JavaSpaces core API to address a much wider spectrum of the distributed applications problem domain. Our goal is to enable the scaling-out (Scaling between machines) of distributed stateful applications. Another goal is to accomplish all that, in a simple manner. You can find detailed information on GigaSpaces specific enhancements and features on our web site. HTH Nati S.
  14. Nati, If I remember rightly, there also was another opensource javaspaces project that someone was doing and he went to work for you. I think it was JSpace or something like that.
  15. Hi Mark
    If I remember rightly, there also was another opensource javaspaces project that someone was doing and he went to work for you. I think it was JSpace or something like that.
    That was long time ago - good indication that you've been around for a while:) I think that the name of the Guy that you refer to was Talip. He managed the JPower project at the time. He is no longer in GigaSpaces and actually went back to Turkey. Nati S.
  16. how gigaspace deferentiate itself from blitz ,the opensource jini based implementation,is there any difference in the architecture and how the user access the storage or it 's some added features plus performance improvment
    Hello, been distracted elsewhere. In a nutshell, Blitz is designed to provide a developer with tools, easy install etc and act as a "get you started". Many people do actually use Blitz in production and either manage their own support or go to Lone Crusader Ltd for commercial support. Without wishing to over-generalize, GigaSpaces have built a substantial framework on top of a core JavaSpace to provide other facilities and that's where much of their value-add is. Blitz is generally quicker than Outrigger and has some nicer behaviours in confined memory situations plus tools that allow you to see what's going on/happened. Jini is the underlying substrate on top of which Blitz and GigaSpaces are built - JavaSpaces implementations are simply Jini Services so in perhaps more familiar terms, Jini is the platform and Blitz etc are services built on top of that platform. Of course, if you wrap Jini etc up inside of Spring as GigaSpaces have done (and several opensource projects before them) you can't really see Jini at all - that can be good and bad.