@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...@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
> 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.
> 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.
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
