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> >> . >> 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.
