I'm attempting to hand crank a Saga without using an Automatonymous State Machine (which I started using but found it difficult to correctly unit test) by following a similar pattern to the way that Sagas are implemented in NServiceBus.
However I'm having an issue where a message is hitting the saga before an instance has been created by the initial message, and this causes MassTransit to silently swallow the message without throwing an exception or moving the message to the error queue.
While trying to find out to solve this issue a lot of people are suggesting the use of OnMissingInstance to fault the message and then rely on a retry framework to effectively delay it until the saga has been correctly initialized.
See Here.
I was wondering if there was a way to do this without using the Automatonymous framework, most likely by leveraging some middleware to preemptively check to ensure that a Saga exists for a message (throwing an exception and retrying later if not) before it tries to process it? And if not does this sound like something that would be useful/is possible?
Further information:
-Using Azure Service Bus
-MongoDB for Saga Persistence.
Some code simplified code snippets of what I'm going for:
ec.Saga(new MongoDbSagaRepository<CodeProviderSaga>(sagaDatabase, new MongoDbSagaConsumeContextFactory(), nameof(CodeProviderSaga)), config =>
{
config.UseApplicationInsights(telemetryClient);
config.UseRetry(retryConfig => retryConfig.Exponential(10, TimeSpan.FromMilliseconds(500), TimeSpan.FromMinutes(5), TimeSpan.FromSeconds(1)));
});
public class CodeProviderSaga :
InitiatedBy<FirstEvent>,
Orchestrates<SecondEvent>,
IVersionedSaga
{
[BsonId]
public Guid CorrelationId { get; set; }
public int Version { get; set; }
public bool SecondEventRecieved { get; set; }
public DateTimeOffset? LastUpdated { get; set; }
public Task Consume(ConsumeContext<FirstEvent> context)
{
this.LastUpdated = DateTimeOffset.UtcNow;
return Task.Completed;
}
// An exception should be thrown if this is received first so it can be retried but it is silently dropped atm
public Task Consume(ConsumeContext<SecondEvent> context)
{
this.SecondEventRecieved = true;
this.LastUpdated = DateTimeOffset.UtcNow;
return Task.Completed;
}
}
To close this out, a commit was just added to the develop branch which throws an exception for messages without a matching saga that are specified in the Orchestrates<T> interface.
Related
I am looking into Microsoft Orleans. I have setup a cluster in docker, tt is working perfectly. I am trying to read the documentation on message delivery, but I can't seem to find anything on retry. If I have a grain calling a grain, like this:
public class HelloGrain : Orleans.Grain, IHello
{
private readonly ILogger logger;
private IOtherGrain otherGrain;
public HelloGrain(ILogger<HelloGrain> logger)
{
this.logger = logger;
}
public override async Task OnActivateAsync()
{
otherGrain = GrainFactory.GetGrain(this.GetPrimaryKeyString());
await base.OnActivateAsync();
}
Task<string> IHello.SayHello(string greeting)
{
string otherGrainReturn = await this.otherGrain.MethodAsync();
return Task.FromResult($"\n Client said: '{greeting}', so HelloGrain says: Hello!");
}
}
Is the string otherGrainReturn = await this.otherGrain.MethodAsync(); getting retried, on failure, somehow? Is it only a timeout that decide when the call fails? Is this to be handled as a basic HTTP call, and should i therefore be retrying myself?
It could be awesome with som link to documentation that say something more on the subject (at-least-once retry etc).
You can see here that by design, Orleans doesn't have any kind of retry policy.
But you can add it by yourself with a simple try catch block (Or with a specific library like Polly).
I am very new with orleans and trying to grasp everything with grains and so forth.
What i got is that in my startup.cs file i add the SignalR like this
public IServiceProvider ConfigureServices(IServiceCollection services)
{
Program.WriteConsole("Adding singletons");
services
.AddSingleton(achievementManager)
.AddMvc();
services.AddSingleton(SignalRClient);
return services.BuildServiceProvider();
}
So far everything is fine i can start my host/application and it connects to SignalR as it should. But what i cant wrap my head around is how do i get this down to my grain? if i had a controller i would simply send it down in the constructor on startup but how do i do this with a grain? Or can i even do it like this. Any guidance is appreciated.
In the grain then i want to do something like this
[StatelessWorker]
[Reentrant]
public class NotifierGrain : Grain, INotifierGrain
{
private HubConnection SignalRClient { get; }
public NotifierGrain(HubConnection signalRClient)
{
SignalRClient = signalRClient;
SignalRClient.SendAsync(Methods.RegisterService, Constants.ServiceName);
}
public Task NotifyClients(object message, MessageType type)
{
var registerUserNotification = (RegisterUserNotificationModel)message;
SignalRClient.SendAsync(Methods.RegisterUserToMultipleGroups, registerUserNotification.UserId, registerUserNotification.InfoIds);
}
return Task.CompletedTask;
}
Then i try to call the Notify method from another grain like this
var notifier = GrainFactory.GetGrain<INotifierGrain>(Constants.NotifierGrain);
await notifier.NotifyClients(notification, MessageType.RegisterUser);
But trying to do this ends up with an error like this
InvalidOperationException: Unable to resolve service for type 'Microsoft.AspNetCore.SignalR.Client.HubConnection' while attempting to activate 'User.Implementation.Grains.NotifierGrain'.
Orleans supports constructor injection, so you can inject the SignalRClient into your grain constructor. In your code you are already correctly registering the client using services.AddSingleton(SignalRClient), so I will focus on how to inject the type into your grain.
I do not know what the type the SignalR client object is, but in this example I assume that the type is "SignalRClient":
[StatelessWorker]
[Reentrant]
public class NotifierGrain : Grain, INotifierGrain
{
private readonly SignalRClient signalRClient;
public NotifierGrain(SignalRClient signalRClient)
{
this.signalRClient = signalRClient;
}
public async Task NotifyClients(object message, MessageType type)
{
var registerUserNotification = (RegisterUserNotificationModel)message;
await this.signalRClient.SendAsync(
MessageMethods.RegisterUserToMultipleGroups,
registerUserNotification.UserId,
registerUserNotification.infoIds);
}
}
Depends how you're thinking to use SignalR Server, if you're going to host your SignalR server with Microsoft Orleans for sure you need to have backplane to handle the Orleans cluster communications.
You can use SignalR Orleans which has everything done out of the box for you :)
Also if you need a reactive SignalR library for the frontend, you can use Sketch7 SignalR Client
PS I m one of the authors of both libraries.
I googled a bit and searched this forum before posting this, since I presumed it had been beaten to death - but since I didn't see any results that seemed clearly asking this, I figured I'd give it a shot. There's a pretty high chance it's been answered before, but I didn't stumble upon a clear page about it.
When using dependency injection, which is considered the better practice? Injecting the entire IDocumentStore and then spawning a session from it as needed, or injecting the appropriate IDocumentSession or IAsyncDocumentSession?
In the past, I've injected IAsyncDocumentSession everywhere - but it's come up that I actually need to use a non async session in a few places. This got me to thinking if I was just approaching injecting Raven wrong altogether.
So, using the IDocumentStore might be like ...
public AsHandler(IDocumentStore store) { RavenStore = store; }
private IDocumentStore RavenStore { get; set; }
public async Task Handle() {
using(var session = RavenStore.OpenAsyncSession()) {
... // do stuff with an async session
}
}
But then the more specific session usecases would appear such as ...
public AsHandler(IAsyncDocumentSession session) { RavenSession = session; }
private IAsyncDocumentSession RavenSession { get; set; }
public async Task Handle() {
// do stuff with an async session
}
or respectively ...
public AsHandler(IDocumentSession session) { RavenSession = session; }
private IDocumentSession RavenSession { get; set; }
public async Task Handle() {
// do stuff with a non-async session
}
Is there even any difference other than preference? My initial thought is that using the IDocumentSession and IAsyncDocumentSession is better lifecycle management, but I could be wrong.
I am using .NET Core 2.0.3 with StructureMap with Raven DB 4.0 (40023) specifically, but I would posit that this could apply to any configuration and any version.
Not sure this has changed with 4.0 but so far the creation of the DocumentStore was considered a rather expensive/heavy operation and therefore the suggested approach is to create it only once per application (singleton; for futher details please see RavenDb Documentation).
Sessions on the other hand are rather cheap to create and therefore can be created as needed.
You could still inject both objects (store and session) with DI and just use different lifecycles (singleton vs. transient).
Of course you can also setup DI to provide either the sync- or the asnyc-version of the session as needed.
Below I present a part of an Azure Web App that handles a device notification logic. What I'm doing is invoking the code shown below from a ASP MVC Controller.
But when I run it I get an hung (ever-pending) request from the browser.
I thought I've found a workaround by wrapping the SendAsync call in a BackgroundWorker thread. It's better, but I doesn't work right. For first couple of times (one or two) it works ok, but then it happens again, the wrapped thread hangs.
The code is not far different from the one on MSDN for a console application. What am I missing?
using System.Web.Configuration;
using Microsoft.Azure.Devices;
namespace MyTest
{
public class Sender
{
private readonly string connectionString;
private readonly Microsoft.Azure.Devices.ServiceClient serviceClient;
public Sender()
{
connectionString = WebConfigurationManager.AppSettings["ConnectionString"];
serviceClient = ServiceClient.CreateFromConnectionString(connectionString);
}
public async void SendRequest(string deviceId, string msgText)
{
var message = new Message();
message.Properties.Add("text", msgText));
await serviceClient.SendAsync(deviceId, message);
}
}
}
The problem was caused by inappropriate usage of ASP MVC framework.
It turned out that AsyncController has to be used instead of just Controller when a long running async\await is utilized. The pipeline must be async all the way.
The definition of my interface is as follows:
public interface IApplicationSettings
{
string LoggerName { get; }
string NumberOfResultsPerPage { get; }
string EmailAddress { get; }
string Credential { get; }
}
The implementation of this interface is given below:
public class WebConfigApplicationSettings : IApplicationSettings
{
public string LoggerName
{
get { return ConfigurationManager.AppSettings["LoggerName"]; }
}
public string NumberOfResultsPerPage
{
get { return ConfigurationManager.AppSettings["NumberOfResultsPerPage"]; }
}
public string EmailAddress
{
get { return ConfigurationManager.AppSettings["EmailAddress"]; }
}
public string Credential
{
get { return ConfigurationManager.AppSettings["Credential"]; }
}
}
I also created a factory class to obtain the instance of the concrete implementation of WebConfigSettings as follows:
public class ApplicationSettingsFactory
{
private static IApplicationSettings _applicationSettings;
public static void InitializeApplicationSettingsFactory(
IApplicationSettings applicationSettings)
{
_applicationSettings = applicationSettings;
}
public static IApplicationSettings GetApplicationSettings()
{
return _applicationSettings;
}
}
Then I resolved dependency as follows:
public class DefaultRegistry : Registry {
public DefaultRegistry() {
Scan(
scan => {
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.With(new ControllerConvention());
});
For<IApplicationSettings>().Use<WebConfigApplicationSettings>();
ApplicationSettingsFactory.InitializeApplicationSettingsFactory
(ObjectFactory.GetInstance<IApplicationSettings>());
}
}
Now when i running my application it throw me following exception:
Exception has been thrown by the target of an invocation.
and the Inner Exception is
No default Instance is registered and cannot be automatically determined for type 'Shoppingcart.Infrastructure.Configuration.IApplicationSettings'\r\n\r\nThere is no configuration specified for Shoppingcart.Infrastructure.Configuration.IApplicationSettings\r\n\r\n1.) Container.GetInstance(Shoppingcart.Infrastructure.Configuration.IApplicationSettings)\r\n
I am using StructureMap for MVC5
The reason your code isn't working is because when you call ObjectFactory.GetInstance<IApplicationSettings>(), your registry hasn't been registered and thus, StructureMap's configuration is incomplete.
I believe what you're trying to do is the following (tested and works):
public class ApplicationSettingsFactory
{
public ApplicationSettingsFactory(WebConfigApplicationSettings applicationSettings)
{
_applicationSettings = applicationSettings;
}
private static IApplicationSettings _applicationSettings;
public IApplicationSettings GetApplicationSettings()
{
return _applicationSettings;
}
}
With your registry configured like this:
public DefaultRegistry() {
Scan(scan => {
scan.TheCallingAssembly();
scan.WithDefaultConventions();
scan.With(new ControllerConvention());
});
this.For<IApplicationSettings>().Use(ctx => ctx.GetInstance<ApplicationSettingsFactory>().GetApplicationSettings());
}
I can't really tell you why your registration fails in StructureMap, but if you allow me, I would like to feedback on your design.
Your design and code violates a few basic principles:
You are violating the Interface Segregation Princple (ISP).
The ISP describes that interfaces should be narrow (role interfaces) and should not contain more members than a consumer uses. You however defined an application wide IApplicationSettings interface and your intention is to inject into any consumer that needs some configuration settings. Changes are really slim however that there is a consumer that actually needs all settings. This forces the consumer to depend on all members, it makes the API more complex, while it just needs one.
You are violating the Open/Closed Principle (OCP).
The OCP describes that it should be possible to add new features without making changes to existing classes in the code base. You will however find yourself updating the IApplicationSettings interface and its implementations (you will probably have a fake/mock implementation as well) every time a new setting is added.
Configuration values aren't read at startup, which makes it harder to verify the application's configuration.
When a consumer makes a call to a property of your IApplicationSettings abstraction, you are forwarding the call to the ConfigurationManager.AppSettings. This means that if the value isn't available or incorrectly formatted, the application will fail at runtime. Since some of your configuration values will only be used in certain cases, this forces you to test every such case after you deployed the application to find out whether the system is configured correctly.
Solution
The solution to these problems is actually quite simple:
Load configuration values at start-up.
Inject configuration values directly into a component that needs that exact value.
Loading the configuration values directly at start-up, allows the application to fail fast in case of a configuration error, and prevents the configuration from being read over and over again needlessly.
Injecting configuration values directly into a component, prevents that component from having to depend on an ever-changing interface. It makes it really clear what a component is depending upon, and bakes this information in during application start-up.
This doesn't mean though that you can't use some sort of ApplicationSettings DTO. Such DTO is exactly what I use in my applications. This basically looks as follows:
public static Container Bootstrap() {
return Bootstrap(new ApplicationSettings
{
LoggerName = ConfigurationManager.AppSettings["LoggerName"],
NumberOfResultsPerPage = int.Parse(
ConfigurationManager.AppSettings["NumberOfResultsPerPage"]),
EmailAddress = new MailAddres(
ConfigurationManager.AppSettings["EmailAddress"]),
Credential = ConfigurationManager.AppSettings["Credential"],
});
}
public static Container Bootstrap(ApplicationSettings settings) {
var container = new Container();
container.RegisterSingle<ILogger>(
new SmtpLogger(settings.LoggerName, settings.EmailAddress));
container.RegisterSingle<IPagingProvider>(
new PagingProvider(settings.NumberOfResultsPerPage));
// Etc
return container;
}
In the code above you'll see that the creation of the ApplicationSettings DTO is split from the configuration of the container. This way I can test my DI configuration inside an integration test, where the start-up projects configuration file is not available.
Also note that I supply the configuration values directly to the constructors of components that require it.
You might be skeptic, because it might seem to pollute your DI configuration, because you have dozens of objects that require to be set with the same configuration value. For instance, your application might have dozens of repositories and each repository needs a connection string.
But my experience is that is you have many components that need the same configuration value; you are missing an abstraction. But don't create an IConnectionStringSettings class, because that would recreate the same problem again and in this case you aren't really making an abstraction. Instead, abstract the behavior that uses this configuration value! In the case of the connection string, create an IConnectionFactory or IDbContextFactory abstraction that allows creation of SqlConnection's or DbContext classes. This completely hides the fact that there is a connection string from any consumer, and allows them to call connectionFactory.CreateConnection() instead of having to fiddle around with the connection and the connection string.
My experience is that makes the application code much cleaner, and improves the verifiability of the application.
Thanks every one for responses. I found my solution. The solution is instead of using Default Registry I created another class for resolve the dependencies. Inside the class I used
ObjectFactory.Initialize(x =>
{
x.AddRegistry<ControllerRegistry>();
});
instead of
IContainer Initialize() {
return new Container(c => c.AddRegistry<ControllerRegistry>());
}
Then inside ControllerRegistry I resolved dependencies as follows:
// Application Settings
For<IApplicationSettings>().Use<WebConfigApplicationSettings>();
Then I called that class inside Global.asax as follows:
Bootstrap.ConfigureDependencies();
Finally inside Global.asax I resolved dependency for Factory class as follows:
ApplicationSettingsFactory.InitializeApplicationSettingsFactory
(ObjectFactory.GetInstance<IApplicationSettings>());
My entire code is given below:
Bootstrap class (newly created)
public class Bootstrap
{
public static void ConfigureDependencies()
{
ObjectFactory.Initialize(x =>
{
x.AddRegistry<ControllerRegistry>();
});
}
public class ControllerRegistry : Registry
{
public ControllerRegistry()
{
// Application Settings
For<IApplicationSettings>().Use<WebConfigApplicationSettings>();
}
}
}
Global.asax
Bootstrap.ConfigureDependencies();
ApplicationSettingsFactory.InitializeApplicationSettingsFactory
(ObjectFactory.GetInstance<IApplicationSettings>());