Support send-only endpoints

[danielmarbach]

The transaction session can now be used in send-only endpoints. See our documentation for more details.

Context

Currently, the transactional session requires the endpoint using the transactional session to be an endpoint with a queue. Send-only endpoints are not supported. One of the restrictions is given by the Core since the outbox seam prevents it being used in send-only endpoints.

By lifting these constraints (potentially with a settings bypass) we could separate the endpoint configuration into two parts:

• Enabling the sending part, including a logical address of the "owning endpoint" (potentially the backend for the frontend). This would also instruct Core to lift the outbox constraint mentioned above
• Enabling the receiving part (the control message behaviors) on the "owning endpoint" (potentially the backend for the frontend)

[pardahlman]

I'm looking forward using this package and get rid of complicated code written to get consistency between NServiceBus message publishing and database updates in our ASP.NET Core applications.

However, it surprises me that it is not possible to use this package in a send-only endpoint yet. When reading the documentation and blog posts it sounds like just the scenario you're aiming for.

Are there any estimates on when send-only endpoints will be supported?

[SzymonPobiega]

@pardahlman no estimates currently. To make sure we understand you use case better -- is there anything that would prevent you from using full NServiceBus endpoint in the web application?

[pardahlman]

Thanks for getting back to me 🙏

No, there is no technical limitation, rather a logical one: these endpoint does not consume messages and is therefor correctly configured as send-only endpoints. Making them full endpoints would slow down startup slightly and also create unwanted topology in our transport.

[SzymonPobiega]

OK, I understand.

The current limitation is related to the fact, that the transactional session uses a message send locally to commit or abort the transaction. This special control message plays the role which is fulfilled by a database polling background process in other outbox implementation. We decided to use the message because the polling mechanism causes serval issue in any non-trivial production deployment, especially with partition data stores:

• polling a database when there is no traffic is a waste of resource
• polling might not be easy when using serverless hosting (or requires a dedicated timer-based process)
• polling partition data stores with a query that needs to read all partitions is very costly

Thanks for your feedback, we are definitely going to take it into account when releasing new versions. We will again analyze the consequences of introducing (optional) polling or having a dedicated endpoint processing the control messages so that the web frontend endpoints can stay send-only.

[danielmarbach]

Please allow me to add a bit more context here too. We have also discussed that we could allow sending the control message to a dedicated "backend" endpoint. During the initial design discussions, we have discussed the concept of ownership of endpoint data and how that "backend" endpoint would fit it. We brought up the argument that many times API endpoints that are send-only have some sort of a backend endpoint already and that one has to be treated as part of the "same service". So, ownership of the outbox data should not be too much of a problem. Yet because we didn't entirely settle on a viable approach on these discussions, we have decided to "scope it out" from the initial release. I'm mentioning this because we don't necessarily need to introduce polling. Sending the control message to somewhere else is totally feasible too.

[andreasohlund]

Core 8.1 will contain a backdoor setting to force the outbox to enable send-only endpoints to enable this scenario to be implemented. See Particular/NServiceBus#6750 for details

[hugovlc]

Now that the backdoor setting that allows this to be implemented is done, do you guys have a planned milestone to implement the feature in the near future?

[andreasohlund]

Hi @hugovlc this will likely be picked up by our recurring enhancement release process but I can't give you a timeline at this stage.

How does the timeline look on your end? Are you blocked by this not being available?

[hugovlc]

@andreasohlund Yes because we recently changed transport to SqlServer transport and our business data is in oracle. TransactionScope is not an option.
So there is no way now to send messages and save business data atomicaly.
We cannot change the endpoint to a full endpoint because then is charged as an extra one.

[alexander-kucherov]

It really cool feature. I'm looking forward for it implementation.
Could you please provide an update on the progress of implementing the functionality?

[mikeminutillo]

It really cool feature. I'm looking forward for it implementation. Could you please provide an update on the progress of implementing the functionality?

There's nothing new to report since this last update. We are tracking this in our backlog, but we have not started the implementation yet.

[patrick-l-boe]

FWIW my team is waiting on this feature before we can stop relying on TransactionScope. This is holding us back from support on some platforms.