MT3 Access to ReceiveContext within SendContext

91 views
Skip to first unread message

Adam Tybor

unread,
Nov 4, 2015, 1:52:10 PM11/4/15
to masstransit-discuss
I am looking at trying to extend MT3 ServiceBus to support batched publish / sends and also receive / send transactions using VIA MessageSenders and a CommittableTransaction.  This is probably closely related to https://github.com/MassTransit/MassTransit/issues/344

The biggest challenge I have is getting access to the current ReceiveContext inside of the SendContext.  Assuming I could access to the ReceiveContext I could add something like an Outbox to the ReceiveContext and write the messages there, then when the receive is ready to complete I could do the actual sending via batches and within a transaction of the message Complete call so it all succeeds or fails atomicly.

Any thoughts or ideas, the issue must be labeled "hard" for reason?

Adam

Chris Patterson

unread,
Nov 4, 2015, 2:21:37 PM11/4/15
to masstrans...@googlegroups.com
ConsumeContext has the ReceiveContext as a property. Is that what you need?

__
Chris Patterson




--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/bbcce173-dbc8-41a1-aabd-c35482b48fc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adam Tybor

unread,
Nov 4, 2015, 3:49:07 PM11/4/15
to masstransit-discuss
Nope, assume I am in the guts of MT or in the middleware layer, I am implementing an ISendEndpoint which only gets the SendContext.

To do what I want I need a couple different hooks that get me to the ReceiveContext.  The ServiceBusSendEndpointProvider is currently responsible for creating the ASB MessageSender.  In order to use an ASB transaction I need to create an ASB MessageSender using the "via" argument which takes the receive queue address linking the MessageSender to the receive queue so I can complete the receive and perform the sends within an ASB tx.  My approach was going to be to replace the ServiceBusSendEndpointProvider with my own to and return a SendEndpoint that really defers creation of the ASB MessageSender until the actual send takes place.

Within my implementation of the DeferredSendEndpoint I was hoping to get access to the ReceiveContext when a message was sent.  This would allow me to do a couple things.

1) Create the underlying ASB MessageSender linked to the receive queue and access a CommittableTransaction in the ReceiveContext to use in the Send operation
or
2) Access an outbox or buffer in the ReceiveContext to put the message into so the actual sending can happen when the receive completes

Finally, the Receiver would need to be modified to perform the Complete() within the TX if present and / or perform batch sends on messages in the outbox.

Make sense?

Adam



On Wednesday, November 4, 2015 at 1:21:37 PM UTC-6, Chris Patterson wrote:
ConsumeContext has the ReceiveContext as a property. Is that what you need?

__
Chris Patterson




On Wed, Nov 4, 2015 at 10:52 AM -0800, "Adam Tybor" <adam....@gmail.com> wrote:

I am looking at trying to extend MT3 ServiceBus to support batched publish / sends and also receive / send transactions using VIA MessageSenders and a CommittableTransaction.  This is probably closely related to https://github.com/MassTransit/MassTransit/issues/344

The biggest challenge I have is getting access to the current ReceiveContext inside of the SendContext.  Assuming I could access to the ReceiveContext I could add something like an Outbox to the ReceiveContext and write the messages there, then when the receive is ready to complete I could do the actual sending via batches and within a transaction of the message Complete call so it all succeeds or fails atomicly.

Any thoughts or ideas, the issue must be labeled "hard" for reason?

Adam

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

Chris Patterson

unread,
Nov 4, 2015, 4:13:52 PM11/4/15
to masstrans...@googlegroups.com
It makes sense but there must be a better way to enlist into the send operations within the receive context. Something that could be added as middleware on top of the existing receive and send endpoints. Hmm. 

__
Chris Patterson




To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

Adam Tybor

unread,
Nov 4, 2015, 4:29:05 PM11/4/15
to masstransit-discuss
Exactly, hmm.

It would make for some very nice scenarios with ASB since they do support real transactions between sends and receives.  Once I figure that out its on to using message sessions with session state for transactional sagas without dtc and without a separate persistence layer.

Adam

Chris Patterson

unread,
Nov 4, 2015, 5:17:15 PM11/4/15
to masstrans...@googlegroups.com
Okay now that would be very interesting. 

__
Chris Patterson




To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

Chris Patterson

unread,
Nov 20, 2015, 6:57:51 PM11/20/15
to masstrans...@googlegroups.com
So, boom: 
First pass at sagas, storing state via the MessageSession. And the unit test passes. State is only available on net-tcp connections (no AMQP, boo) but it works!


To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/49af5afc-6cf8-4475-b122-88a1c16efde2%40googlegroups.com.

Adam Tybor

unread,
Nov 26, 2015, 10:42:32 AM11/26/15
to masstransit-discuss
Awesome! Is there any advantage to using AMQP, does it do anything different under the covers?  My assumption was AMQP was only a good choice when working from other platforms like java or with native proton bindings.  If MT is a .net stack why not always use the richer NetMessaging protocol?

Adam
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

Chris Patterson

unread,
Nov 26, 2015, 10:49:08 AM11/26/15
to masstrans...@googlegroups.com
I'm pretty sure that AMQP is faster but I could be wrong. I know Clemens Vaster is not a fan of non standard protocols.


__
Chris Patterson




To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages