This project is read-only.

Load Balancing

Jul 2, 2010 at 6:35 PM

I was wondering what, if any, facilities are built into SSB that allow load balancing of recipients? For example, both NServiceBus and MassTransit offer a distributor process that allows this. Personally, I prefer the way any JMS-spec'ed broker implements this through the JMS queue. That way, you don't have to set up and cluster a separate process just to scale out handlers. If SSB can be adapted to ActiveMQ, it could take advantage of this JMS feature. Therefore, I'm very much interested in the SSB-to-ActiveMQ adaptation.

Anyway, what are the thoughts of other SSB users and the SSB core team?

Jul 2, 2010 at 6:41 PM

SSB core team is probably a little overstatement. :)

The SSB development isn't very active. I've taken over the ownership of the project, but I don't really develop it further. I use it my daily job, but in a future refactoring I will probably change to nServiceBus as it seems to be more actively developed. I liked SSB when I compared over a year ago because it was very cleanly written with interfaces and IoC fully implemented. And it serves my need for sure. But I haven't used load balancing yet, my plans to load balance is to do it through a TCP load balancer, or possibly just through distribution to different queues.

 

Jul 2, 2010 at 7:12 PM

Indeed, with the ActiveMQ transport the broker will allow any number of consumers to listen on the same queue, and thus load balance them. Also, ActiveMQ supports a MessageGroupId property which can they provide an affinity to the first handler that consumer a message with such a MessageGroupId, which solves the sequencing issues of messages when you have a pool of dedicated workers.

Jul 2, 2010 at 7:19 PM

Wow, I wasn't expecting such a quick response. I actually like it that SSB doesn't force a built in load balancing mechanism. Otherwise, it could complicate scenarios for those of us that use underlying brokers that natively support it. And great point, livetocode, about the MessageGroupId. It's a really cool feature that saves a lot of plumbing and logic surrounding message sequencing.

Jul 2, 2010 at 7:19 PM

Ah, I didn't know ActiveMQ had that feature, that's really neat. I probably need to try that out before I go the nServiceBus route :)

 

Jul 2, 2010 at 8:24 PM

Yep! ActiveMQ rules! ;-)

But seriously, this is a very good message broker with a load of features, and also a nice embedded web admin console. It supports also a native failover implementation which can automatically retry to connect a client to the broker, either using the same broker, or by providing a list of dedicated brokers. This retry can happen when listening or sending, and what's cool is that it will automatically resubscribe your consumers to the selected broker.

Also, you can either send text or binary messages. The binary messages can be big (> 4Mb of MSMQ) or huge (like movies) by automatically segmenting them in chunks.

ActiveMQ handles dead letter (or poison) queues automatically for you. By default, it will retry 6 times a message before moving it to a DLQ. You can configure it to have a single DLQ or one per queue.

You can also have virtual queues which then broadcast the messages to any number of physical queues.

ActiveMQ supports topics which allows you to do publish/subscribe natively.

Finally, for big enterprise scenarios, you can benefit from the Camel integration which provides an implementation of every known enterprise patterns regarding messaging. 

Jul 3, 2010 at 5:05 PM
Yes, ActiveMQ is far superior to MSMQ. It's very easy to setup and get running as well.

So, to shed some light on my current situation, myself and a colleague are launching an open source project called Reactor. It's hosted here on CodePlex, but it's in its infancy and we barely have much written so far. Essentially, it's a service composition and deployment framework. You can read about it here. It will be based on a CQRS style of messaging architecture, therefore will have to utilize a service bus. ActiveMQ is my broker of choice, so I need a .Net bus framework that adapts to ActiveMQ. So far, I see that SSB, NServiceBus, and MassTransit all do this. I've played around with NServiceBus and MassTransit and find their API quite nice, but they both rely on stand alone processes like a distributor and subscription manager. SSB doesn't seem to have this dependency, and since ActiveMQ already provides features like load balancing via JMS queues, I don't need the separate processes. I don't want Reactor to utilize ActiveMQ directly or even through a JMS specific API like NMS. Rather, I would like to use a cleaner API like the aforementioned three .Net frameworks provide. So, my question to you guys is do you think SSB might be a good fit for this? I know it's not that active, but do you feel it's stable enough for me to create a dependency toward?

Thanks for your responses. Just the fact that you respond so quickly is a definite plus.

Oh....and if you're interested in contributing to Reactor, let me know. We're looking for some good devs to help out. I think it's a unique and powerful approach to composing and deploying services.

-T




On Fri, Jul 2, 2010 at 3:24 PM, livetocode <notifications@codeplex.com> wrote:

From: livetocode

Yep! ActiveMQ rules! ;-)

But seriously, this is a very good message broker with a load of features, and also a nice embedded web admin console. It supports also a native failover implementation which can automatically retry to connect a client to the broker, either using the same broker, or by providing a list of dedicated brokers. This retry can happen when listening or sending, and what's cool is that it will automatically resubscribe your consumers to the selected broker.

Also, you can either send text or binary messages. The binary messages can be big (> 4Mb of MSMQ) or huge (like movies) by automatically segmenting them in chunks.

ActiveMQ handles dead letter (or poison) queues automatically for you. By default, it will retry 6 times a message before moving it to a DLQ. You can configure it to have a single DLQ or one per queue.

You can also have virtual queues which then broadcast the messages to any number of physical queues.

ActiveMQ supports topics which allows you to do publish/subscribe natively.

Finally, for big enterprise scenarios, you can benefit from the Camel integration which provides an implementation of every known enterprise patterns regarding messaging. 

Read the full discussion online.

To add a post to this discussion, reply to this email (SimpleServiceBus@discussions.codeplex.com)

To start a new discussion for this project, email SimpleServiceBus@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com


Jul 4, 2010 at 5:04 AM

Hi,

I've committed my implementation of the ActiveMQ transport for SSB (see http://simpleservicebus.codeplex.com/SourceControl/changeset/changes/48254).

There is of course no documentation ;-) But I made a couple of demos that demonstrate most of the features, the ease of use and the power of the beast!

Feel free to ask any question.

Your reactor framework seems very interesting but unfortunately I am already overloaded and I want to keep the rest of my time for my son! Anyway, if you need my help at a more higher level, like discussing your architecture, design or goals, let me know!

Morgan

 

Jul 8, 2010 at 12:28 AM

Excellent that we now have ActiveMQ support added as well!

I feel SSB is stable enough for your project, I'm using SSB in a production system using MSMQ and I really liked the lightweight implementation, not a lot of strange things going on. I'm also quite busy with a son and my regular work, but I'm always open for questions or advice.

 

Jul 8, 2010 at 4:25 AM

livetocode: Do you think you can verify if [workitem:4585] was committed to the trunk source? And if the issue is resolved? Thanks!

 

Jul 8, 2010 at 4:38 AM
HakanL wrote:

livetocode: Do you think you can verify if [workitem:4585] was committed to the trunk source? And if the issue is resolved? Thanks!

 

Yes, it was!