Hi

Finally got around to playing with this.

I am clearly doing somethign wrong, as no matter how I configure
things, each instance of the consumer get the same message so I just
end up doing the same work multiple times.

I have a console app "Distributor", this starts a bus and a
loadbalancer with the following config:

    <facilities>
      <facility id="rhino.esb" >
        <bus threadCount="1"
             numberOfRetries="5"
             loadBalancerEndpoint="msmq://localhost/ESBTests.balancer"
             endpoint="msmq://localhost/ESBTests.queue"
             />
        <messages>
        </messages>
      </facility>
      <facility id="rhino.esb.loadbalancer" >
        <loadBalancer threadCount="1"
             endpoint="msmq://localhost/ESBTests.balancer"
             />
      </facility>
    </facilities>
  </castle>

The distributor will send a message to the bus every time you press a
key like so:

            var container = new WindsorContainer(new
XmlInterpreter());
            container.Kernel.AddFacility("rhino.esb", new
RhinoServiceBusFacility());

            var container2 = new WindsorContainer(new
XmlInterpreter());
            container2.Kernel.AddFacility("rhino.esb.loadbalancer",
new LoadBalancerFacility());

            using (var loadBalancer =
container2.Resolve<MsmqLoadBalancer>())
            using (var bus =
container.Resolve<IStartableServiceBus>())
            {
                MsmqUtil.GetQueuePath(loadBalancer.Endpoint).Create();

                loadBalancer.Start();
                bus.Start();

                while (true)
                {
                    var message = new ActivityCreated() { ActivityID =
Guid.NewGuid() };
                    //bus.Send(message);
                    bus.Notify(message);

                    Console.WriteLine("Activity Created: {0}",
message.ActivityID);
                    Console.ReadLine();
                }
            }

Note: bus.Send is commented out as it errors complaining about no
message owners could be found (probably the key to the issue), so I am
using Notify instead.

I then have another console app "Consumer", this starts a bus with the
following config

  <castle>
    <facilities>
      <facility id="rhino.esb" >
        <bus threadCount="1"
             numberOfRetries="5"
             endpoint="msmq://localhost/ESBTests.consumer"
             />
        <messages>
          <add name="Common" endpoint="msmq://localhost/
ESBTests.balancer"/>
        </messages>
      </facility>
    </facilities>
  </castle>

And listens for messages

    public class ActivityListener : ConsumerOf<ActivityCreated>
    {
        #region ConsumerOf<ActivityCreated> Members

        public void Consume(ActivityCreated message)
        {
            Console.WriteLine("ActivityListener - Activity Created:
{0}", message.ActivityID);
        }

        #endregion
    }


If you start up both apps whenever you hit return in the distributor
you see a Activity Created message in the consumer.

Now if I start up a second instance of the consumer app having
modified the endpoint in the bus config to be 
msmq://localhost/ESBTests.consumer2,
because a load balancer is in place I would expect one instance of the
consumer app to take on the work i.e. only see a Activity Created
message in one consumer console window. What I am actually seeing is
no different to pub/sub, i.e both instances of the consumer app are
recieving the message and displaying the Activty Created message.

Any ideas?


On Apr 1, 6:57 pm, Ayende Rahien <[email protected]> wrote:
> Crowley,
> RSB comes with Load Balancer, which is how you would handle this scenario,
> take a look at the tests to see how this works.
>
> On Tue, Mar 30, 2010 at 12:08 AM, crowley_mark <[email protected]>wrote:
>
> > I have a consumer that processes a file. The activity of the consumer
> > process is resource intensive; therefore I have set the bus thread
> > count to 1 (effectively creating a queue).
>
> > In times of load I would like to start 1 or more new instances of the
> > consumer on new machines. We are using Amazons EC2 infrastructure so
> > creating new machine instances involves minimum effort.
>
> > My question is how to utilise ESB to the best advantage in such a
> > scenario.
>
> > My thoughts are...
>
> > I don’t think I can utilise the Publish/Subscribe functionality, as
> > each subscriber will just get the same message, so I will just end up
> > processing the same file multiple times on different machines.
>
> > As the process that sends the messages will not know of the location/
> > name/ip of the consumer machines, it could  just send the messages to
> > a predefined local queue. Having this local queue will ensure that
> > messages are persisted, even if no consumers are in existence (unlike
> > pub/sub model).
>
> > Consumers on remote machines are configured to recieve messages from
> > the predefined queue, and use the reply semantics to send any response
> > message back to the sender. Any errors are persisted back to the
> > queues error subqueue.
>
> > New machines that come up will just pick off the next message,
> > process, and reply.
>
> > When a consumer machine is dropped (load reduced), because there are
> > no subscribers etc. it simply disappears.
>
> > Does this make sense. I believe this is possible, is there a better
> > way? Any obvious disadvantages, other thoughts?
>
> > Thanks.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Rhino Tools Dev" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<rhino-tools-dev%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/rhino-tools-dev?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Rhino Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rhino-tools-dev?hl=en.

Reply via email to