Comments on: Terracotta Server as a Message Bus

By: Ronald Kurr

Ronald Kurr — Sat, 19 Dec 2009 17:20:09 +0000

Mark, the idea of adding a simple command socket to a headless application is brilliant. An embarrassingly simple idea that I can’t believe I never thought of myself! Many Thanks.

By: namqer

namqer — Mon, 07 Sep 2009 09:20:42 +0000

any chance you can make some of this very, very interesting framework public? this has the possibility of becoming a project with it’s own life (with community feedback/involvement)..

thanks for the post

By: Lemonade Joe

Lemonade Joe — Thu, 04 Dec 2008 13:35:56 +0000

Hi all,

I’m at starting point to develope application that in short: aggregate data from a lot of providers and return summary response to client that sent query. I tried ServiceMix. Does Terracotta and some additional tools is something that can replace it? What could be the scenario? How can be realized splitter and aggregator patterns in scenario based on terracotta?

Thank you very many!
Joe

By: Interesting Links « Darryl Nelson’s Blog

Interesting Links « Darryl Nelson’s Blog — Thu, 11 Sep 2008 11:39:39 +0000

[...] Terracotta Server as a Message Bus by Mark Gregory Turansky Interesting idea outside the conventional solutions. [...]

By: Victor Yao

Victor Yao — Mon, 04 Aug 2008 08:14:40 +0000

Mark,

Very interesting stuff. We would like to do similar things for some time because we were fulstrated my our current jms queues but don’t know how to start. Could you please shed some lights on how (in a bit details) you did it or give us some ponters where to look?

Thank you very much for your assistence

By: » HOW TO: Use mini-batching to improve grid performance

» HOW TO: Use mini-batching to improve grid performance — Fri, 25 Jul 2008 20:20:45 +0000

[...] doing any kind of grid computing (by way of Terracotta’s Master-Worker project, GridGain, or rolling your own), check out the effects mini-batching can have on your throughput. You might be [...]

By: » HOW TO: Use mini-batching to improve grid performance

» HOW TO: Use mini-batching to improve grid performance — Fri, 25 Jul 2008 20:20:45 +0000

By: Gabriel K.

Gabriel K. — Mon, 21 Jul 2008 13:54:21 +0000

We too had a lot of problem with activeMQ stability. Moreover, it could not disconnect/reconnect properly, and the documentation is poor (was poor, 1,5 year ago, now I do not know…)
So we switched to Joram, the Jonas implementation of JMS and our needs of reliability went satisfied.

By: William K.

William K. — Tue, 20 May 2008 23:04:39 +0000

Any performance benchmarks ? Tibco Rendezvous does up to 6K messages per second, Server publishing, client consuming, both on the same box.

Also it would be helpful to know across network performance for messaging consumers and publishers.

thanks a bundle for the great article.

By: » More proof that you can’t keep a good idea down?

» More proof that you can’t keep a good idea down? — Wed, 07 May 2008 03:18:16 +0000

[...] Nygard describes an architecture that echoes many of the features I implicitly spoke of in my first blog article about my big integration project / message bus. You may be asking yourself right now, why does he keep talking about this particular project? [...]

By: » You can’t keep a good idea down

» You can’t keep a good idea down — Fri, 02 May 2008 03:25:35 +0000

[...] message bus project was more than just replacing JMS with a POJO messaging system. It’s a whole piece of [...]

By: » Very Old School — Walking down memory lane

» Very Old School — Walking down memory lane — Sun, 20 Apr 2008 04:54:01 +0000

[...] we are, a decade later, and I’m busy integrating legacy applications into our shiny new message bus. It’s highly concurrent, runs all our integrated applications in a single JVM but in isolated [...]

By: David

David — Wed, 02 Apr 2008 23:52:57 +0000

@Tom: I have to concur with your take on ActiveMQ stability. I had to pull back from using it, as members were randomly leaving the network of brokers, never joining it back again.

FYI. I have switched to a clustered deployment of Sun’s Open MQ, which is sturdy and less fancy than other OSS JMS implementations out there, and, so far, I am more than happy with it.

By: » Why Linux will never be the world’s primary desktop

» Why Linux will never be the world’s primary desktop — Wed, 02 Apr 2008 15:30:47 +0000

[...] I’ve installed Ubuntu on a work machine. Damned Small Linux is our OS of choice for our message bus. I’m in the minority of users. It takes one to know [...]

By: » No one should work alone. Ever.

» No one should work alone. Ever. — Wed, 26 Mar 2008 02:05:56 +0000

[...] pieces of software from the monolithic whole and deployment them as separate components on our message bus. All our components are deployed in isolated classloaders, which will solve their problem. The [...]

By: Jordan

Jordan — Tue, 11 Mar 2008 17:21:11 +0000

This looks very promising! btw – is there a known clean way to handle a topic or pub-sub model as opposed to a distributed queue using similar components.

By: » Scalability & High Availability with Terracotta Server

» Scalability & High Availability with Terracotta Server — Fri, 07 Mar 2008 21:59:42 +0000

[...] message bus will be deployed to production this month. We’re currently sailing through QA. Whatever bugs [...]

By: » Horses For Courses 2 (or Tools for Fools)

» Horses For Courses 2 (or Tools for Fools) — Sat, 01 Mar 2008 21:28:12 +0000

[...] you’ve got a dozen nodes on the network, each one hosting components of your enterprise message bus. You and your operations folks need visibility into the entire system so that you can tell at a [...]

By: » htop on Solaris

» htop on Solaris — Fri, 29 Feb 2008 03:41:27 +0000

[...] got used to htop’s color-coded bars in a console for our messaging system, and then we deployed to a datacenter on Sun hardware without htop. prstat just isn’t quite [...]

By: » Code complete doesn’t mean you’re done

» Code complete doesn’t mean you’re done — Wed, 13 Feb 2008 11:05:24 +0000

[...] our system today. This past weekend, we pumped over one million real-world messages through our message bus. Our concurrency issues are gone, memory usage is predictable, and we stopped our test only to let [...]