jasperfx / wolverine Goto Github PK

See SagaFramePolicy. Use a custom exception with more context. Similar validation to what we did for projections in Marten

Way more analysis necessary. At first thought, collect:

• Standing count of outgoing messages in inbox/outbox -- observable gauge
• Count of queue depth. Sampled observable gauge
• Aggregate "effective time" from sent to successfully processed. Histogram?
• Aggregate average of sent messages -- counter
• Number of messages handled by endpoint. Success & failure. Retries? -- counter with tags
• Queue length -- observable gauge

For Rabbit MQ queues, it should be the queue name. Or exchange name
For SQS, the queue name
and so on

This will help a bit w/ diagnostics and logging

Not exactly sure what this entails yet. Thinking that it means some codegen ahead of time.

Need the ability to specify properties of various endpoints more easily

Tasks

• Rabbit MQ conventional routing needs an allow/deny list filter. Chain configuration for listener/sender using expression somehow
• Policies.UseDurableInboxForAllListeners()
• Policies.UseDurableOutboxForAllSenders()
• chain configuration for Rabbit MQ listeners
• chain configuration for Rabbit MQ senders
• Policies.LocalQueues(configure)
• Policies.UseSeparateLocalQueueForEachMessageType(configure)
• New way of registering endpoint policies

cc @AlexZeitler

• Improve the description of cascading messages. Do something w/ ItemCreated
• Link to the handler discovery, but add more description
• Probably more, so just review. That was written years ago.

Instead introduce new conventions for middleware.

Using either Rabbit MQ or Azure Service Bus, you should be able to interchange messages with an app using NServiceBus

I changed the docs, but there might still be really old support for other positions in the code

It was a hokey way of making it easy to load all settings from configuration by using Uri, but that just doesn't really fly now.

Reconsider this.

Low hanging fruit. Just copy from the Envelope within the IMessageContext

It could turn up issues with Envelope mapping for different transports

Look at the listener / subscriber configuration elements

Using .NET 6 and Wolverine 0.8.2 I get an exception when invoking commands of different types in parallel.
A gist reproducing the issue can be found here:
https://gist.github.com/gztamas/50997c72c61b9ed7809156bdb76c7be1

According to the gitter discussion with @jeremydmiller it might be an issue of insufficient/bad locking.

See https://martendb.io/configuration/optimized_artifact_workflow.html. Or really, just make this automatic.

There's some TODOs. When the BoundedCapacity gets full on the worker queue, slow it down

cc @AlexZeitler

If a user has https://github.com/rabbitmq/rabbitmq-delayed-message-exchange installed, use an "opt in" mode to utilize native Rabbit MQ scheduled send.

Today scheduled send with Rabbit MQ falls back into Wolverine's persistent scheduled messages

Just based on message ids

Rewrite it just a little bit to query by endpoint? Make sure it's not pulling down incoming envelopes to listeners that are paused

Like the async daemon in Marten. Publish events and metrics. Might make testing better.

• Evaluate usage
• When asking for the "single XYZ of anything", and there's more than one or none, throw a better exception with the full history

Build a sample project, put it into the documentation. I don't think it's worth distributing a Nuget for that.

FubuTransportation left over. Just adds confusion.

Epic spanning the work to close #10, #16, #26, #29, and #30

Might require some work on the Marten side of things. I think I'd want an ISessionFactory<T> where the T could be Jasper's IExecutionContext

Go hunt down and find old usages of Console.Writeline() where it should just be logging. RabbitMqTransport is a known offender.

Also see JasperFx/jasper#520 for older context

Wolverine.Persistence.SqlServer --> Wolverine.SqlServer et al. Clean up the docs as well

There's a lot of stuff on that thing that's not relevant to users

Do some research. Should do before 1.0 to verify the abstraction

If buffered, try to keep in memory. If durable, send to persistence as owned by zero. Latch either way.

Make it much more clear which methods require an active session. Maybe split incoming vs outgoing persistence? Use IReadOnlyList everywhere. Maybe bring in CancellationToken? Deal with any TODO in the code too.

Today all the routing is done based on message type. Analyze if there's any value in doing this by choosing the message route based on the data of the message body itself.

Just got Jasper stuff in there now

What do do when the sender is latched and it's not durable? Throw at the point of sending? Move the Envelope.QuickSendAsync() logic into ISendingAgent? The variability is there.

Inline RequestAndWait(CancellationToken) : Task,

Don't want to do that, but probably necessary for some users.

Really just making sure that ConsumerOptions and ProducerOptions are both exposed and usable from PulsarEndpoint. Might try to make the subscription name be configurable too, but use the service name as the default.

Not sure if that'll require a separate library or not yet. Hoping that LocalStack is viable

There's a unique InMemoryScheduledJobProcessor for each lightweight, local queue + the JasperRuntime. The diagnostics are useless.

Might be worth just improving the diagnostics on IJasperRuntime to show you everything that's outstanding.

• With Marten
• With EF Core

The big goal is to make the creation and usage of middleware easier.

Test cases

• Instance methods on middleware is scoped
• Static methods
• Synchronous "before"
• Asynchronous "before"
• Synchronous "after"
• Asynchronous "after"
• No filter
• User-defined filter
• Inferred filter by message applicability
• Use multiple middleware on one handler
• Add middleware by attribute too!
• Can use services
• Use objects built by middleware
• Dispose middleware objects that are created
• Filter model?

Use the inbox & outbox

Turn off the listeners if messages get backed up

Might be cool on each handler to see what the error handling policies are

Need more context here. This is going to be used to standardize the workflow we built as custom code for a client to do acknowledgements about success or failure of an outgoing message, but with some mechanism to pass back contextual information about the original message.

To be clear, this will not be any kind of full blown, alternative AspNetCore framework because that way lies madness, heartbreak, and failure

Goal: Mechanism to utilize Jasper's execution pipeline within Minimal API HTTP endpoints without having to manually delegate through to ICommandBus.

Signature

Use the Endpoint suffix nomenclature for discovery. Either use fubu-style naming conventions on the method names, or
override with [HttpPost("route")] style attributes. So:

public class SomethingEndpoint
{
    public Task<Output> post_something(Input request, Service service, Service2 service2)
    {

    }

    // OR

    [HttpPost("/something")]
    public Task<Output> Post(Input request, Service service, Service2 service2)
    {

    }
}

Notes:

• Still support method injection
• The base class generated around this will handle registration with Minimal API? Or one generated class to make it all faster.
• Gotta figure out how to expose metadata about the endpoints through to AspNetCore. Stuff like Open API configuration
  or [Authorize] attributes
• How to designate outgoing messages versus the HTTP response??? Could there be a base class just to add outgoing messages
  ala Saga.MarkCompleted()?
• Start making some of the other middleware HTTP aware? Thinking about making Marten being able to move the correlation id
  from the HTTP request to the session. Also ability to move the correlation id from HttpContext to the Jasper IExecutionContext?
  maybe that gets done with OTEL machinery???
• Do the code generation well, and this could be a good Azure Functions / AWS Lambda serverless strategy by cutting out a lot of cold start issues
• Support it on Saga as well? Why not?
• Also want a more efficient way to delegate through to ICommandBus. Something where you get an IInvoker<T> or IQuery<TRequest, TResponse> behind the scenes?

Special Services

These services should be resolved to the main Jasper method automatically:

1. HttpContext
2. ClaimsPrincipal
3. HttpRequest
4. HttpResponse
5. CancellationToken -- but this should come from the HTTP request

Publishing messages will allow users to easily register handlers for big events. Thinking:

• circuit tripped off
• circuit resumed
• endpoint paused
• endpoint restarted
• endpoint failed?
• endpoint too deep?

All of these are available for the tracker too? The observable path is beneficial too maybe.

Might decide not to do this at all, but it was handy once upon a time.