Mantaray p2p messaging framework 1.8 released

Discussions

News: Mantaray p2p messaging framework 1.8 released

  1. Mantaray is a peer-to-peer messaging framework providing JMS, RMI, and C++ API's, featuring integration with JBoss, WebLogic, and WebSphere; guaranteed delivery; security; transactions; with TCP & SSL transport support. Version 1.8 includes improved prioritization and expiration of messages, topic hierarchies (an ability to subscribe to a set or a subset of a hierarchal topic tree), and HTTP transport for use as a firewall-friendly transport layer.

    Mantaray distributed under GPL and is backed by Coridan, which provides professional open source consulting/training around Mantaray, as well as commercial licenses, and add-on products such as Mantaray Activators, which turn the project into an integration solution by enabling access to web services and relational databases via JMS.

    Threaded Messages (19)

  2. High availability?[ Go to top ]

    Mmm, that sounds great, gotta have a closer look in a few days. Can it also do clustered HA?
  3. High availability?[ Go to top ]

    I concurr, I spoke to them at JavaOne and although they admitted to not being the first ones to offer these features they beleive they do it with much more flexibility that the competition (eg. extensions).If only they could change the license to LGPL...
  4. Re: High availability?[ Go to top ]

    Ok, so the hunt for a truely HA-capable open source messaging system with a business-friendly license is still open.. :(
  5. Re: High availability?[ Go to top ]

    Ok, so the hunt for a truely HA-capable open source messaging system with a business-friendly license is still open.. :(

    I'd be interested to find out why ActiveMQ can't suit your needs. Its Apache 2.0 licensed and integrated into Geronimo, so is just about J2EE certified.

    James
    LogicBlaze
  6. Re: High availability?[ Go to top ]

    I'd be interested to find out why ActiveMQ can't suit your needs.

    Mantaray's claim to fame seems to be that it is a p2p architecture. Can ActiveMQ operate serverless?

    Floyd
  7. Re: High availability?[ Go to top ]

    I'd be interested to find out why ActiveMQ can't suit your needs.
    Mantaray's claim to fame seems to be that it is a p2p architecture. Can ActiveMQ operate serverless?Floyd

    Sure. We support a pure peer based network, federated networks of brokers or a combination of both (peer groups for JMS clients which discover remote clusters of brokers for the durable part).

    We can create pretty much any network topology to suit your needs & deal with whatever firewall configuration you have. Whether a peer network where clients automatically discover each other via multicast or zeroconf - or where clients discover brokers, or where you tell the clients which brokers to connect to etc. We also support auto-reconnection if you're using a federated network and the broker you're connected to fails etc.

    James
    LogicBlaze
  8. Re: High availability?[ Go to top ]

    Last time we checked activemq (about two months ago), messages sent into a 2-nodes test cluster seem to got *physically* distributed to each nodes in an equal rate (50-50%). Plugging off one node resulted in those messages not anymore available for the other node and not getting processed at all. As soon as we plugged back the node it started processing its messages again.. That's not exactly what we were looking for.
  9. From my limited knowledge of clustering, that's hard feature to implement. It's not nearly as simple as it might appear. If i setup a 2 node cluster (A and B) and node A is unavailable, how should node B pick up the traffic? Since node B may not be able to get a positive confirmation from Node A, how long should it wait to assume responsibility? If node A has reached the connection limit, but is still alive, it is better to for node B to assume node A will resume normal operation in a reasonable amount of time.

    If node B were to instantly take the full load, chances are it would crash the system, which means the entire message bus is down. Even in larger clusters, it's often not desirable to fail over too quickly, because it can cause a cascading failure. Many systems use a heart beat multi-cast to determine if a system is alive or dead. when a system stops sending it's heart beat, the live systems can "figure out" how to distribute the load.

    In the telco world, these kinds of scenarios are critical. Building that level of HA is very hard to achieve. How many of the commercial messaging systems really support that kind of HA?

    peter
  10. Peter, I know it's very far from trivial (and pretty expensive usually) but I think that's what HA is about.. or am I wrong here?
  11. not to nitpick[ Go to top ]

    Peter, I know it's very far from trivial (and pretty expensive usually) but I think that's what HA is about.. or am I wrong here?

    I know there's a lot of different definitions out there, but I always though HA meant High Availability. In non technical terms, I think of HA in terms of supporting a large number of concurrent users. Automatically failing over to another system feels more like fault tolerance to me. The 2 node cluster scenario to me fits the narrow definition of HA. By that i mean this. If a JMS client is written such that it stores the messages locally until a node is available again and the time to restore service is within a few minutes, the user may not realize one node was temporarily unavailable.

    fault tolerance on the other hand would mean that my messages are automatically re-routed to a live server and any messages not delivered will be sent when the server is revived. HA and fault tolerant go hand in hand, and many people mean both when they say HA.

    I think it really comes down to semantics and how one defines HA. It would be nice if everyone used the same definition, but I really doubt that will happen.

    peter
  12. not to nitpick[ Go to top ]

    I know there's a lot of different definitions out there, but I always though HA meant High Availability. In non technical terms, I think of HA in terms of supporting a large number of concurrent users. Automatically failing over to another system feels more like fault tolerance to me.

    Availability refers to the probability that a service or application is available, which is e.g. like "five nines" (the app is reachable and operating 99.999% of the time).

    Supporting a large number of concurrent users is the role of concurrency (how an application behaves given concurrent load) and throughput (how much aggregate work per unit of time the application can handle). Achieving high levels of throughput is usually the role of scalability, and making sure that those users don't wait is the role of performance.

    However, HA can refer to the ability to support a large number of concurrent users in one sense: If an application cannot handle a high concurrent load and has to turn away users, it is considered to be at least partially "unavailable" (the opposite of HA).

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  13. your definition is better I think[ Go to top ]

    I know there's a lot of different definitions out there, but I always though HA meant High Availability. In non technical terms, I think of HA in terms of supporting a large number of concurrent users. Automatically failing over to another system feels more like fault tolerance to me.

    Availability refers to the probability that a service or application is available, which is e.g. like "five nines" (the app is reachable and operating 99.999% of the time).Supporting a large number of concurrent users is the role of concurrency (how an application behaves given concurrent load) and throughput (how much aggregate work per unit of time the application can handle). Achieving high levels of throughput is usually the role of scalability, and making sure that those users don't wait is the role of performance.However, HA can refer to the ability to support a large number of concurrent users in one sense: If an application cannot handle a high concurrent load and has to turn away users, it is considered to be at least partially "unavailable" (the opposite of HA).

    Peace,
    Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    your definition is much better than mine. that brings up a good question of how one measures availability in a cluster. Say I have a cluster of 30 nodes and one or more nodes may be down for an hour or two every year. The cluster as a whole is always available, but some nodes may be down temporarily for maintenance or unresponsive for a few seconds due to load.

    What kind of metric do people use to measure 99.9999% availability? I know some of the biggest firms have backup systems that are exact mirrors of production and fail-over occurs with a few minutes. But most business can't afford that level of redundancy and availability. Especially when you consider natural disasters happen, achieving 99.9999% availability in practice is much more work than just having a piece of software that claims to offer HA.

    peter
  14. your definition is better I think[ Go to top ]

    The cluster as a whole is always available, but some nodes may be down temporarily for maintenance or unresponsive for a few seconds due to load.What kind of metric do people use to measure 99.9999% availability?

    They should be measuring whether their end users, in general, can "reach" and "use" the application.

    You know when a site is down ;-) .. you type "www.somesite.com" and press enter and it times out or gives you an error.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  15. your definition is better I think[ Go to top ]

    The cluster as a whole is always available, but some nodes may be down temporarily for maintenance or unresponsive for a few seconds due to load.What kind of metric do people use to measure 99.9999% availability?
    They should be measuring whether their end users, in general, can "reach" and "use" the application.You know when a site is down ;-) .. you type "www.somesite.com" and press enter and it times out or gives you an error.

    Peace,

    Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    Thanks for that laugh cameron :)

    Related to that, I think one could build a HA application with ActiveCluster or any other mature JMS product that supports clustering. Having a solid JMS provider is the starting point. The rest is blood, sweat and tons of hard work.

    peter
  16. Re: High availability?[ Go to top ]

    Last time we checked activemq (about two months ago), messages sent into a 2-nodes test cluster seem to got *physically* distributed to each nodes in an equal rate (50-50%). Plugging off one node resulted in those messages not anymore available for the other node and not getting processed at all. As soon as we plugged back the node it started processing its messages again.. That's not exactly what we were looking for.

    With our networks we distribute messages using store and forward to brokers which have consumers on them - which is what you'd want - it provides a reliable federated network of durable messaging across an arbitrarily large network of producers and consumers with firewalls, WAN connections etc. This page describes how it all works...

    http://activemq.org/Clustering

    The problem is, if you loose a broker (which could be due to a network outage - it might still be running, just that noone else in the network can see it. So to avoid replaying duplicates, we leave a message owned by a single broker at any point in time. When a broker fails and is restarted, messages are not lost.

    However it sounds like you need a more HA message store along these lines...

    http://activemq.org/Replicated+Message+Store

    James
    LogicBlaze
  17. Re: High availability?[ Go to top ]

    What you describe is a very basic way to provide scalability and availability for active, but there are better approaches that they really don't address on their web site. For example, you could have single a single logical broker divided across a 3-host configuration. Your clients use all three IP addresses in their connection URL and the active client round-robbins among all three. The journals/data stores for each cluster would be hosted on a resiliant shared file store, say RedHat GFS. Then using a tool like whackamole (http://www.backhand.org/wackamole/), brokers on a failed node are restarted to another node. So, if A/B/C are active and C dies, either A or B picks up the broker (and the IP address as well). This is a simpler, less network intensive way to achive the same effect as a Sonic cluster (not to mention it will save you loads of $$$).

    The issue I see with Manta's P2P approach is that, from a JMS approach, it's possible to ack a message intended for a destination that is down causing the message to be stored locally. So the application goes on its merry way thinking the message is sent, then the disk dies and you've lost your message. With the above approach, such a scenario is far less likely and you place less burdeon on the sender's hardware allowing you to scale out the broker layer as needed. I see the P2P approach having limited value when you are dealing with messages you can't afford to lose.
  18. Re: High availability?[ Go to top ]

    What you describe is a very basic way to provide scalability and availability for active, but there are better approaches that they really don't address on their web site. For example, you could have single a single logical broker divided across a 3-host configuration. Your clients use all three IP addresses in their connection URL and the active client round-robbins among all three. The journals/data stores for each cluster would be hosted on a resiliant shared file store, say RedHat GFS. Then using a tool like whackamole (http://www.backhand.org/wackamole/), brokers on a failed node are restarted to another node. So, if A/B/C are active and C dies, either A or B picks up the broker (and the IP address as well). This is a simpler, less network intensive way to achive the same effect as a Sonic cluster (not to mention it will save you loads of $$$).

    Agreed. Though note that you don't need to use wackamole or an IP load balancer - ActiveMQ has inbuilt reconnection logic which can achieve the same effect.

    e.g. each JMS client could connect to the URL

    reliable:tcp://A:port,tcp://B:port,tcp://C:port

    Then each JMS client will randomly connect to A, B or C. If C dies, all the clients connected to C will automatically reconnect to A or B. In the URL you've full control over reconnection timeouts, maximum number of retry attempts and so forth.

    http://activemq.org/Configuring+Transports

    Its totally fine to use an IP load balancer, it might be easier to use if you already have one in use for your other servers. However if you are not using an IP load balancer, its often easier to use ActiveMQ's inbuild 'wackamole' like feature.

    BTW I totally agree with using the shared file system for journals/files.

    The issue I see with Manta's P2P approach is that, from a JMS approach, it's possible to ack a message intended for a destination that is down causing the message to be stored locally. So the application goes on its merry way thinking the message is sent, then the disk dies and you've lost your message. With the above approach, such a scenario is far less likely and you place less burdeon on the sender's hardware allowing you to scale out the broker layer as needed. I see the P2P approach having limited value when you are dealing with messages you can't afford to lose.

    Agreed. For non-durable (non persistent) messaging - or for development - a P2P network is great.

    As soon as you need persistence and to never loose a message and recover files/journals in the event of catastrophic data centre or hardware failure then P2P can be a little scary. Its often much simpler and less worrying to have a fixed number of brokers in a well known place with their files/journals in known locations on shared disks / SANs so that if you suffer serious hardware/data centre failure you can easily recover.

    I recommend to all our customers who are using durable / persistent messaging to not use P2P and use a cluster of brokers with known locations of the journals/files for easier backup, maintenance and disaster recovery.

    James
    LogicBlaze
  19. .
  20. Others[ Go to top ]

    Is that similar to ActiveCluster / ActiveMQ ?