Then I'm afraid it sounds like you're not using DomainEvents the right way - each event from the domain should be a discrete domain occurrence.
-- Udi Dahan -----Original Message----- From: rhino-tools-dev@googlegroups.com [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols Sent: Wednesday, August 04, 2010 3:45 PM To: Rhino Tools Dev Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting I am publishing the DomainEvents from my domain. These events are subscribed to by 1 (or more report) services that update the db state from those events. @Udi - I could publish them one at a time, yes, but I'd rather the whole batch fail since they represent a unit of work from my domain...I don't want some messages to succeed and others to fail leaving the db in an odd state. On Aug 4, 5:39 am, Ayende Rahien <aye...@ayende.com> wrote: > What is the scenario in which you would want to publish a message batch? > And publishing doesn't use the owners, it uses the subscriptions list. > I think that I had the wrong idea in mind about what we are talking about, > yes, for publish, that would make sense, but I still want to know what your > scenario is. > > On Wed, Aug 4, 2010 at 3:33 PM, Mike Nichols <nichols.mik...@gmail.com>wrote: > > > Isn't that the difference between Publish and Send though? > > 'Publishing' an event in my mind doesn't carry any assumption about > > who is dealing with its payload. 'Sending' on the other hand does > > carry those transactional assumptions. > > > On Aug 4, 5:26 am, Ayende Rahien <aye...@ayende.com> wrote: > > > Mike, > > > The problem is that there is a difference between the expectations. > > > You should be aware which messages goes to which endpoints. > > > By splitting a batch you may be violating the assumption of the user that > > > they are sending one unit of work to the server. > > > > I don't have an issue with throwing if you are sending a batch to mixed > > > endpoints, though. > > > > On Wed, Aug 4, 2010 at 3:22 PM, Mike Nichols <nichols.mik...@gmail.com > > >wrote: > > > > > Yes, but each endpoint _will_ treat the batch as a single unit for the > > > > batch though only in its own context. Otherwise the publisher is > > required to > > > > have some knowledge of its subscribers right? To be clear (sorry if I > > am > > > > thick), how do you handle this scenario: > > > > 1. There are two messages in a batch > > > > 2. Message1 is subscribed to by Endpoint1 > > > > 3. Message2 is subscribed to by Endpoint2 > > > > 4. You Publish(new[]{ message1,message2}); > > > > > With the current codebase, only Endpoint1 will receive the batch of > > > > messages...(it looks at 'messages[0]' to GetSubscriptions). That > > doesn't > > > > seem predictable. > > > > > Another option is to have the publisher somehow split up the messages > > so > > > > that they will be published to the correct endpoint. That seems to > > turns > > > > things upside down though. > > > > > Other than feeding messages one by one is there some better > > alternative? > > > > > On Wed, Aug 4, 2010 at 12:45 AM, Ayende Rahien <aye...@ayende.com> > > wrote: > > > > >> Mike, > > > >> Perf isn't what worries me. > > > >> Message batches are treated as a single transactional unit. > > > >> If you send them to different endpoints, you break that assumption. > > > > >> On Wed, Aug 4, 2010 at 6:29 AM, Mike Nichols < > > nichols.mik...@gmail.com>wrote: > > > > >>> I have (clumsily) fixing an issue in rsb where it currently simply > > > >>> looks at the first message in batch being Published for its > > > >>> subscription info. > > > >>> I am publishing a number of messages that may or may not be > > subscribed > > > >>> to (these are events from a store) and which are subscribed to at > > > >>> different endpoints. Under the current setup (PublishInternal), if a > > > >>> message doesn't happen to be subscribed to in the same endpoint the > > > >>> first message in the batch it will not get sent to get handled. > > > > >>> The initial fix is to GetSubscriptions for each message in the batch > > > >>> to make sure all subscriptions have been harvested that are > > > >>> interested. > > > > >>> My question is about the performance of something like this on a > > > >>> massive batch of messages where I am iterating on the collection > > > >>> (please see my pull request). > > > > >>> This scenario doesn't seem far fetched to me, but if there is a > > better > > > >>> way of implementing it I'd like to hear it. > > > > >>> -- > > > >>> You received this message because you are subscribed to the Google > > Groups > > > >>> "Rhino Tools Dev" group. > > > >>> To post to this group, send email to > > rhino-tools-...@googlegroups.com. > > > >>> To unsubscribe from this group, send email to > > > >>> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g ooglegroups.com> > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252Bunsubscr i...@googlegroups.com> > > > > >>> . > > > >>> 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 rhino-tools-dev@googlegroups.com > > . > > > >> To unsubscribe from this group, send email to > > > >> rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g ooglegroups.com> > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252Bunsubscr i...@googlegroups.com> > > > > >> . > > > >> 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 rhino-tools-...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g ooglegroups.com> > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252Bunsubscr i...@googlegroups.com> > > > > > . > > > > 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 rhino-tools-...@googlegroups.com. > > To unsubscribe from this group, send email to > > rhino-tools-dev+unsubscr...@googlegroups.com<rhino-tools-dev%2bunsubscr...@g ooglegroups.com> > > . > > 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 rhino-tools-...@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. 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 rhino-tools-...@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
