I can't get ServiceActivator working for for Async

[preardon]

I believe I'm probably missing something,

However MessagePump in ServiceActivator always appears to call CommandProcessor.Send or CommandProcessor.Publish and never SendAsync or PublishAsync which results in it throwing an error stating that I can't cast my Command Handler to type 'Paramore.Brighter.IHandleRequests' which is Correct as its a Paramore.Brighter.IHandleRequestsAsync

What am I missing, or what Have I done wrong?

I have both Handlers and AsyncHandlers setup,

services.AddServiceActivator(options => { options.Subscriptions = subscriptions; options.ChannelFactory = new AzureServiceBusChannelFactory(consumerFactory); var outBox = new InMemoryOutbox(); options.BrighterMessaging = new BrighterMessaging(outBox, outBox, AzureServiceBusMessageProducerFactory.Get(asbCfg), null); }) .Handlers(registry => { registry.Register<TestCommand, TestCommandHandler>(); }) .AsyncHandlers(registry => { registry.RegisterAsync<TestAsyncCommand, TestAsyncCommandHandler>(); }) .MapperRegistry(registry => { registry.Add(typeof(TestCommand), typeof(TestMapper)); registry.Add(typeof(TestAsyncCommand), typeof(TestAsyncMapper)); });

From what I can see, the PublishAsync is never called in the ServiceActivor Project

Any pointers or assistance would be appreciated

[preardon]

@iancooper Once I get it working would you like me to commit a sample app (Greeting app like your current ones) for Service Activator and Async Handlers?

[iancooper]

@preardon There is a PR around this, and it's complicated. We don't support an async pipeline as yet. I have a PR in to fix that up, but it won't be v9.

Short version for now:

• We use an event loop model when consuming messages (single-threaded loop)
• We don't let you dispatch async at the moment. Why?
• -- On async you will pull from the queue again when you put I/O on a completion port
• -- This can de-order queue
• -- There is no 'upper bound' to 'in-flight' work
• -- If you callback on a thread pool thread, there is no upper bound to the number of threads
• -- I have seen other messaging frameworks (no names) crash at scale because of this, they essentially can't context switch between all the threads
• So you need to be able to control backpressure
• -- Our model for back-pressure is single-threaded event loops i.e. you run a fixed number multiple of loops (performers)
• -- Think how Node works
• That means we have to callback on the pump
• -- This can be done with our own synchronization context, we post the callback to the same queue as messages
• -- This is essentially Windows Single Threaded Apartment model you see in the UI (STAThread)
• I built this, but it deadlocked, badly, so it was not quite right
• I have a PR for another try (I think the supervisor thread needs to make the postback to the performer)

For now, don't use async in the dispatcher pipeline. Although that seems negative, async is actually painful in a pipeline reading from a queue of work of you don't grok the implications. Just use more performers

[iancooper]

Hopefully I can get this fixed soon after V9 ships. It probably won't be a breaking change as we left most of the function signature changes required in the codebase.

[iancooper]

I'll push it to the top of my priority list now that we have the fixes for v9. I'll put Redis Streams behind it

[preardon]

@iancooper Thanks for the Explanation, Let me know if I can do anything to assist, We have written all of our Handlers as Async and while that works fine with Darker and our In Proc use I am looking to Start our Scale out using this feature

[iancooper]

@preardon Will do. By experience, sync pipelines work just fine for workers reading from a queue when you scale. With an async pipeline you just end up writing governors to stop all the context switching.

[iancooper]

But I'll put async in so folks can see for themselves :-D

[iancooper]

@preardon This should work now, try taking it out for a spin

[iancooper]

Let me take a look, something is not quite right there. Possibly we misinterpret the options being passed to us for async pipelines.

[preardon]

@iancooper Thanks Mate, If you've got a few minutes (probably in another chat) I would love some information on Control Bus, also the documentation is broken (Gives 404).

[iancooper]

Ah that's a bummer. Docs and bug fixes for v9 will be a summer priority once it gets out the door. We can start thinking about what's next then, probably with a view to some projects around telemetry, cli etc in September or so.

[preardon]

Sounds good, I look forward to working on these with you

[iancooper]

We should meet up to talk about them as a group once we get v9 out, perhaps (whisper it) in person

[preardon]

To Update, this will now work as of the Next Release, Fix is in

[preardon]

@honkuan86 this was fixed in v 9.0 beta 2

Is your issue an Async Outbox issue (which outbox are you using?)

In your ServiceActivatorOptions when you configure Brighter Messaging add an outbox (both Async and Sync) your producer Factory (both Async and Sync) and then set useRequestReplyQueues to false.

[honkuan86]

@preardon , thanks for the guide ! I got it to work now.

[preardon]

@honkuan86 Just for completeness on this thread, Was your issue that your Outbox was not an Async one and/or you didn't have useRequestReplyQueues set to false ?

[honkuan86]

I wasn't using an Async outbox, I just didn't set useRequestReplyQueues to false.

[iancooper]

We need to review making the pit of success here a bit easier :-D