@Udi I am not sure I understand. I am using event sourcing, so I persist events on the domain side for rehydration of Aggregates, etc (domain-side). The bus publishes these events, which are subscribed to by interested query-side denormalizers.
On Thu, Aug 5, 2010 at 12:40 AM, Udi Dahan <thesoftwaresimpl...@udidahan.com > wrote: > I think that the reason you're running into difficulty is that your > persisting data on the command side that should have only been persisted on > the query side. > > Cheers, > > -- Udi Dahan > > > -----Original Message----- > From: rhino-tools-dev@googlegroups.com > [mailto:rhino-tools-...@googlegroups.com] On Behalf Of Mike Nichols > Sent: Thursday, August 05, 2010 1:09 AM > To: Rhino Tools Dev > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > @Udi > I am persisting the events. After the events have been persisted they > are put on the bus for publication. > My initial concern here though was about the assumption that the first > message in a batch is the sole provider of subscription details for an > entire batch of messages. It seems like a user should just Publish a > batch of messages on a bus and not be concerned about who is > subscribed to them. > > To be clear this code from the PublishInternal method in the > defaultservicebus is what I am discussing.What this code is saying is > that if you have two messages in a batch being Published, and each one > is subscribed to by different endpoints, then the second message in > the batch will not get published. That seems unpredictable to me: > private bool PublishInternal(object[] messages) > { > if (messages == null) > throw new ArgumentNullException("messages"); > > bool sentMsg = false; > if (messages.Length == 0) > throw new MessagePublicationException("Cannot publish > an empty message batch"); > object msg = messages[0]; > IEnumerable<Uri> subscriptions = > subscriptionStorage.GetSubscriptionsFor(msg.GetType()); > foreach (Uri subscription in subscriptions) > { > > transport.Send(endpointRouter.GetRoutedEndpoint(subscription), > messages); > sentMsg = true; > } > return sentMsg; > } > > > > m > > > On Aug 4, 9:51 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: > > Mike, > > > > The case of CQRS usually has the service layer publishing the events in > > response to commands, domain events has nothing to do with it. If you're > > talking about event-based persistence on the command-side, again, domain > > events have nothing to do with the bus. > > > > Cheers, > > > > -- 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 4:46 PM > > To: Rhino Tools Dev > > Subject: [rhino-tools-dev] Re: rhino rsb subscription harvesting > > > > If I have 5 events that took place on my aggregate root during the > > course of a unit of work. My understanding is that the root represents > > a transactional boundary. So I publish the events on the bus as a > > batch. The subscriber (in this case, denormalizers for events that > > write to a database) will go through each event and update the > > database, ideally in a single transaction so that if one of the > > handlers fails, then they all fail. > > As I think about it, I am not sure why that is so important other than > > the convenience of having NHib in a single session and cut down on the > > number of roundtrips. But I realize this is an impl detail that > > shouldn't be the driver. > > > > @Udi - I actually went back and forth on whether to publish these > > individually or not, so it is helpful to hear from you on this. Can > > you see why I would consider the batch a single unit though? If you > > are using a denormalizer you always only send one event at a time to > > that endpoint? > > > > On Aug 4, 6:35 am, Udi Dahan <thesoftwaresimpl...@udidahan.com> wrote: > > > 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...@googlegroups.com> > <rhino-tools-dev%2bunsubscr...@g > > > ooglegroups.com> > > > > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252bunsubscr...@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...@googlegroups.com> > <rhino-tools-dev%2bunsubscr...@g > > > ooglegroups.com> > > > > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252bunsubscr...@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...@googlegroups.com> > <rhino-tools-dev%2bunsubscr...@g > > > ooglegroups.com> > > > > > <rhino-tools-dev%2bunsubscr...@googlegroups.com<rhino-tools-dev%252bunsubscr...@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...@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<rhino-tools-dev%2bunsubscr...@googlegroups.com> > . > > > For more options, visit this group > > athttp://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...@googlegroups.com> > . > > For more options, visit this group > athttp://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...@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...@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.
