Exposing additional integration events

[seanfarmar]

#1445

[danielmarbach]

I think this lacks also acceptance tests under the corresponding External integration folder. See for example When_a_message_has_failed_detected

[mikeminutillo]

Probably also need to expose FailedMessageGroupArchived.

Do we know what the impact on performance is?

For Azure Service Bus this will increase the number of operations against the broker, even if there are no subscribers. Should we consider having a way to disable some/all integration events?

[SzymonPobiega]

Minor suggestions

Fixed

[mikeminutillo]

All in all this looks good. My chief concerns would be:

• Publishing the results of bulk opertaions with a list of GUIDs could quickly create very large messages. We should maybe consider batching these at the integration event level.
• Publishing more events may incur more costs in cloud environments. We should look at providing options to disable some/all of these event types.

[SzymonPobiega]

Publishing the results of bulk opertaions with a list of GUIDs could quickly create very large messages. We should maybe consider batching these at the integration event level.

We have changed the code to publish these messages for each archived batch (1000 docs) so we are safe here that we won't cross the threshold even on the most restricted transport (ASQ)

[SzymonPobiega]

We should maybe consider batching these at the integration event level

I think we are not making things significantly worse because the biggest impact on cost is probably MessageFailed event.

[mikeminutillo]

We should maybe consider batching these at the integration event level

I think we are not making things significantly worse because the biggest impact on cost is probably MessageFailed event.

My concern is that for every MessageFailed event we are adding at least one more eventual event. So the number of events published will be 2x.

[tmasternak]

My concern is that for every MessageFailed event we are adding at least one more eventual event. So the number of events published will be 2x.

One more event is a situation that was already there before we added new events. Secondly, these events won't get published unless there is an integration event subscriber in the system.

[mikeminutillo]

One more event is a situation that was already there before we added new events.

I am not following this. Can you explain how this situation was already present?

Secondly, these events won't get published unless there is an integration event subscriber in the system.

For message-driven pub-sub that is true. For native-pub sub transports like Azure Service Bus (where every operation costs money) we still are going to push the event to the topic, even if there are no subscribers for it.

[seanfarmar]

From Slack
@mikeminutillo's summary:

To summarize the conversation:

• We already publish 1 event for every failed message
• Now, if you retry, we will publish 1 additional event for every failed message
• If you archive, then we batch those notification events
• If every message is retried once, we double the number of events published
• On most transports, this won't matter much
  • For any with some kind of subscription storage (native or message-driven), we will see that there are no subscribers for these new messages and not bother publishing them
  • For any with native pub-sub, we will publish the message to the broker regardless. This puts more pressure on the broker.
    • For RabbitMQ that's probably OK. Rabbit is often much faster than we are anyway and the customer has already paid the cost of setting up the infra. There is usually not an additional cost per operation.
    • For Azure Service Bus that's probably not OK. Each operation costs money and we may be publishing events that the customer doesn't even care about. For them, they will upgrade to a new version and their costs will go up. They will have questions about that.

The outcome is that we will introduce a config flag to turn off the publishing of integration events.

• This flag allows those ASB customers to switch off these events if they don't use them.
  • Customers that don't care about any integration events will benefit from this, and we might be able to reduce costs for them
  • There may be a small number of customers that do care about the old integration events but not the new ones. I think we'd like to hear from them before we build anything more complex
• Even non-ASB customers might be interested in this because it takes the pressure off of RavenDB.
  • In high-throughput scenarios where we don't use Integration Events, I would advise turning this feature off.
  • I'd even go so far as to make it off by default, but I'd want to do that in a major with a user experience around turning it back on at runtime

Adressed

[danielmarbach]

A few comments

[tmasternak]

@danielmarbach can you have a look now? Thx.