Tim Bray has been exploring JXTA, a peer-to-peer networking API for Java, and has written what he considers the minimum JXTA code necessary to get a JXTA application running, in "Just Enough JXTA."

JXTA has all these elaborate capabilities around pipes and abstract services and concrete services; I found them hard to understand and since they try really hard to avoid the Fallacies of Distributed Computing, they don’t sugar-coat much.

On the other hand, if you want a reliable, reasonably-simple way for a bunch of processes in the network to discover each other dynamically—sort of a friendly wrapper for multicast, if you will—in my experience JXTA is just the ticket. You set up a peer group, you join it, you add a DiscoveryListener, drop into a DiscoveryService.getRemoteAdvertisements() loop, and you’re pretty well done. It looks like the process can be made very secure, too, although I haven’t worked through that part yet.

JXTA is, as stated, a peer-to-peer technology, as opposed to the more traditional client-server represented by Java, Enterprise Edition. Some grid solutions already have applications for Java EE - do you think technologies like JXTA have wider applications?

Where's the link to the original text?

http://www.tbray.org/ongoing/When/200x/2005/09/01/Just-Enough-JXTA

Ah, the happiness of having all your sources right in front of you - thanks, I did manage to check all links in the post, but I apparently forgot the most important one. :*

I've found this one: Cajo, seems much simpler than Jini, JXTA or JavaSpaces. Is there any site with comparisons between these distributed object frameworks?

Maybe there needs to be a framework around this stuff...

Maybe there needs to be a framework around this stuff...

Sort of like http://p2psockets.jxta.org/ ?

Maybe there needs to be a framework around this stuff...

Check out MantaRay, a peer-to-peer messaging framework for connecting applications and distributed components using JMS standards. Very lightweight and embeddable, easy to deploy, seamlessly connects to well known application servers.

Alon
Coridan

Check out MantaRay, a peer-to-peer messaging framework for connecting applications and distributed components using JMS standards. Very lightweight and embeddable, easy to deploy, seamlessly connects to well known application servers.

Hi Alon,

I hadn't heard of this product before. How does it compare to ActiveMQ?

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Check out MantaRay, a peer-to-peer messaging framework for connecting applications and distributed components using JMS standards. Very lightweight and embeddable, easy to deploy, seamlessly connects to well known application servers.

Hi Alon,I hadn't heard of this product before. How does it compare to ActiveMQ?Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

BTW Cameron ActiveMQ can work in a pure peer to peer network model too - its actually the out of the box default if you just instantiate an ActiveMQ ConnectionFactory.

If you want to use durable messaging then typically you'd want to manage the persistent stores on known hosts - so you would probably want to use ActiveMQ's cluster or brokers when using durable messaging (i.e. a federated networks of clients and brokers). Possibly using multicast discovery for each tier to find each other.

BTW if you want a performance report of ActiveMQ versus MantaRay, JBossMQ, Sonic and JORAM using various different qualify of services (topics v queues, durable v non durable etc), then send an email to dev at logicblaze.com.

James
LogicBlaze

Check out MantaRay, a peer-to-peer messaging framework for connecting applications and distributed components using JMS standards. Very lightweight and embeddable, easy to deploy, seamlessly connects to well known application servers.

Hi Alon,I hadn't heard of this product before. How does it compare to ActiveMQ?Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

Hi Cameron,

MantaRay's core technology combines two cutting edge design concepts that complement and build upon each other - messaging system optimization and peer-to-peer architecture. It was designed from the ground up to work in a peer-to-peer model, and has no critical element in the system, thus it has no single point of failure and no single point of congestion. This architecture makes the system highly scalable and provides great performance that increases linearly when dealing with a many-to-many configuration.
Regarding the performance, to give you some numbers (which I'm sure you'll understand why you will not see them in the benchmark document that ActiveMQ guys are publishing), in a 1 producer / 1 consumer / 1 topic scenario, MantaRay runs at ~6000 messages per second. Now the real strength of MantaRay stems from its distributed nature. Running MantaRay in a 50 producers / 50 consumers / 50 topics scenario would yield ~250,000 messages per second (the ActiveMQ benchmark has dropped that value from their graph for some reason).
Regarding management, MantaRay Console controls the system from any location. It lets you see a real-time topology map with online status of each node in the system, browse queues and get some statistics.

If you want me to send you the full MantaRay benchmark document, just send me an e-mail.


Best regards,

Alon Eizenman
Coridan

I've been getting a lot of requests for the MantaRay benchmark document and realized I forgot to add my email, so here it is - alon(at)coridan.com

Alon

Regarding the performance, to give you some numbers (which I'm sure you'll understand why you will not see them in the benchmark document that ActiveMQ guys are publishing)

Huh? We've a team of folks who spend their time performing performance benchmarks using our JMeter based benchmark suite of all the open source JMS providers and a bunch of commercial ones too - plus we encourage folks to run the benchmark themselves. We don't hide any numbers.

Incidentally MantaRay is the one JMS provider which frequently dies in our test suite with OutOfMemoryException which means we can't always include its numbers in some tests (its because we can't phsically get it to work). I suspect it might be lack of flow control in the producer?

, in a 1 producer / 1 consumer / 1 topic scenario, MantaRay runs at ~6000 messages per second.

Benchmarks are only useful when relative on a fixed bit of hardware. FWIW we've had > 45,000 messages/second on the same configuration on opteron boxes :).

Now the real strength of MantaRay stems from its distributed nature. Running MantaRay in a 50 producers / 50 consumers / 50 topics scenario would yield ~250,000 messages per second (the ActiveMQ benchmark has dropped that value from their graph for some reason).

FWIW you mean total messages per second going through the broker right? So when using 50 producers/consumers things slow down about 20% to ~5000/second.

As it happens we only measure the average performance of messages being published or consumed at a single producer/consumer (typically just the consumer figures are more useful as they show effective throughput and producers are often much faster). So to get the effective broker throughput you just multiply by the number of producers/consumers.

So in our benchmark, just do the math yourself if you wanna think about things that way. We tend to find focussing on the performance per consumer gives a better indication of how a single consumer slows down/speeds up when parallelised, rather than looking at the absolute number per broker.

BTW since ActiveMQ supports a federated network of message brokers; we can get near infinite effective messages/second across the messaging cluster (as you can just keep running brokers and federate messages as not all messages have to go over the same multicast address/socket etc) - which is another reason we tend to prefer to focus on effective throughput rates per client rather than overall throughput numbers per system.

James
LogicBlaze

Huh? We've a team of folks who spend their time performing performance benchmarks using our JMeter based benchmark suite of all the open source JMS providers and a bunch of commercial ones too - plus we encourage folks to run the benchmark themselves. We don't hide any numbers.

We have a team of folks who are spending all their time running benchmark tests, and we use external independent organizations that are doing the same on MantaRay.

Incidentally MantaRay is the one JMS provider which frequently dies in our test suite with OutOfMemoryException which means we can't always include its numbers in some tests (its because we can't phsically get it to work). I suspect it might be lack of flow control in the producer?

That's funny, we got OutOfMemoryException in ActiveMQ while testing it in our labs.

Seriously, two options here:
1. You run an old MantaRay version (and BTW we don't have MantaRay7.1 version still, as you mentioned in your document).
2. You have some serious configuration problems in your test, and I encourage your team to contact our very experienced support team at Coridan who will be happy to help them with that.

I encourage everyone who reads this message to try MantaRay latest version (1.8.1 as of today), and feel the power of a real peer-to-peer messaging framework, and experience the benefits.

Benchmarks are only useful when relative on a fixed bit of hardware. FWIW we've had > 45,000 messages/second on the same configuration on opteron boxes :).

So why are you publishing 1896 msg/sec of durable persistent messages on a topic in your benchmark document? MantaRay is running 6060 msg/sec in such configuration on a Pentium 4 2.4GHz machine.

FWIW you mean total messages per second going through the broker right? So when using 50 producers/consumers things slow down about 20% to ~5000/second.As it happens we only measure the average performance of messages being published or consumed at a single producer/consumer (typically just the consumer figures are more useful as they show effective throughput and producers are often much faster). So to get the effective broker throughput you just multiply by the number of producers/consumers. So in our benchmark, just do the math yourself if you wanna think about things that way. We tend to find focussing on the performance per consumer gives a better indication of how a single consumer slows down/speeds up when parallelised, rather than looking at the absolute number per broker.

You keep talking about broker based environments and MantaRay is not a broker based system, so there is no reason not to look at the total throughput of the system. In a real peer-to-peer environment the real strength is when dealing with many-to-many configuration and in that case the total throughput is a key factor, and I'm not referring to multiple environments of different multicast domains, but rather many-to-many connections in one system.


Alon
Coridan

Can you please provide framework details for blog web application ?