rebus-org / Rebus.Oracle

:bus: Oracle transport for Rebus
https://mookid.dk/category/rebus
Other
5 stars 10 forks source link

Subscribers are competing instead of both subscribing #27

Closed cartsp closed 4 years ago

cartsp commented 4 years ago

Hi,

Not sure if I am doing anything wrong, but when I publish a message either one or the other of my subscribers handles the message rather than both. I am using Oracle as the transport and to handle the subscribers. I have tried doing this a few different ways, but it is the same result each time.

Publisher Code:

            using (var activator = new BuiltinHandlerActivator())
            {
                Configure.With(activator)
                    .Logging(l => l.ColoredConsole(minLevel: LogLevel.Warn))
                    .Transport(t => t.UseOracleAsOneWayClient(oracleCNS, "events_table"))
                    .Options(b => b.SimpleRetryStrategy(maxDeliveryAttempts: 10))
                    .Subscriptions(s => s.StoreInOracle(oracleCNS, "events_subs"))
                    .Start();

           activator.Bus.Publish(new StringMessage("Hello there, I'm a publisher!")).Wait();

Then my subscribers are like so:

   using (var activator = new BuiltinHandlerActivator())
                {
                    activator.Register(() => new Handler());

                    Configure.With(activator)
                        .Logging(l => l.ColoredConsole(minLevel: LogLevel.Warn))
                        .Transport(t => t.UseOracle(oracleCNS, "events_table", "events"))
                        .Routing(r => r.TypeBased().Map<StringMessage>("sub1"))
                        .Start();

                    activator.Bus.Subscribe<StringMessage>().Wait();

Any help would be much appreciated!

mookid8000 commented 4 years ago

It's because your subscribers are using the same "queue": events ("queue" in quotation marks here, because Oracle doesn't really have queues – but the tables are used to create a queue model, which works the same way as an ordinary queue).

This can be a good thing: You can distribute events between multiple instances of the same subscriber.

However, it doesn't sound like this is what you need in this case, since your subscribers are different. The fact that they're different implies that they must each have their own queue.

cartsp commented 4 years ago

Thanks a lot, not sure why I found that so difficult to get my head around! Also massive thanks for this library! :+1: