-
-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Durable In/Outbox behavior seems to keep messages in SQL forever. #689
Comments
I honestly don't know, I haven't seen that behavior before. There's a little bit of a delay on the inbox to use completed messages in idempotency checks, but the outgoing messages should be deleted as soon as they are sent out. Are you seeing any error messages? Are you doing anything like running under a debugger and shutting down the app through the debugger where it's not shutting down gracefully by chance? |
@mhartwig22 The pic up there of the inbox table is normal operation, see how the status says "Handled"? So that's fine. The outgoing behavior is a problem though. So back to my question, how are you shutting down your app? You might try running in the "Solo" mode in development: https://wolverine.netlify.app/guide/durability/leadership-and-troubleshooting.html#solo-mode |
Hi Jeremy, Thanks for getting back on this.
While running these tests under the debugger, I'm always trying to make sure I'm shutting down the application gracefully. I just rerun a test with WolvFx DB recreated, brand new kafka topic - basically everything reset.
Upon restarting the app, the messages get re-delivered to both, kafka and the application.
This leads to all messages being replayed and when finished, the messages again remain in the outgoing table.
Now its about incoming messages. Starting the app yet again results in all outgoing re-processed yet again:
There are no errors to be seen in the log anywhere. I dont know if there is an issue with the housekeeping code somewhere not being executed or something. It's hard to tell as I dont know the internals of WolverineFx. |
I have the same exact situation where the outbox does not get cleared, and the messages in the outbox keep getting pushed to the queue. The configuration I am trying is very similar to OP's. Program.cs: var builder = WebApplication.CreateBuilder(args);
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddResourceSetupOnStartup();
var connectionString = builder.Configuration.GetConnectionString("SqlServer")!;
builder.Host.UseWolverine((context, opts) =>
{
opts.PersistMessagesWithSqlServer(connectionString);
opts.UseEntityFrameworkCoreTransactions();
opts.ConfigureKafka("localhost:19092")
.ConfigureClient(config =>
{
config.BootstrapServers = "localhost:19092";
config.BrokerAddressFamily = BrokerAddressFamily.V4;
});
opts.PublishMessage<OrderCreated>().ToKafkaTopic(nameof(OrderCreated))
.TelemetryEnabled(true);
opts.ListenToKafkaTopic("OrderInventoryAllocated")
.UseDurableInbox();
opts.Policies.UseDurableOutboxOnAllSendingEndpoints();
opts.Policies.AutoApplyTransactions();
if (context.HostingEnvironment.IsDevelopment())
{
opts.Durability.Mode = DurabilityMode.Solo;
}
});
builder.Host.ApplyOaktonExtensions();
builder.Services.AddDbContextWithWolverineIntegration<OrderDbContext>(x => x.UseSqlServer(connectionString));
var app = builder.Build();
await app.Services.GetRequiredService<OrderDbContext>().Database.EnsureCreatedAsync();
app.MapWolverineEndpoints();
app.UseSwagger();
app.UseSwaggerUI();
await app.RunOaktonCommands(args); Handler: public class CreateOrderRequestHandler
{
[WolverinePost("/order")]
[Transactional]
public async Task<OrderCreated> Handle(CreateOrder command,OrderDbContext dbContext, IMessageBus messageBus)
{
var items = command.Items
.Select(item => new OrderLineItem(item.ProductId, item.Amount))
.ToList();
var order = new Order(DateTimeOffset.UtcNow, items);
dbContext.Add(order);
var orderCreated = new OrderCreated(order.Id);
await messageBus.PublishAsync(orderCreated);
return orderCreated;
}
} Sending one request to my handler results in an infinite processing of the outboxmessage:
Environment:
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="8.0.1">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="8.0.1" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="6.5.0"/>
<PackageReference Include="WolverineFx" Version="2.3.0"/>
<PackageReference Include="WolverineFx.EntityFrameworkCore" Version="2.3.0"/>
<PackageReference Include="WolverineFx.Http" Version="2.3.0"/>
<PackageReference Include="WolverineFx.SqlServer" Version="2.3.0"/>
<PackageReference Include="WolverineFx.Kafka" Version="2.3.0"/> |
I run into the same problem with the outbox and spent some time troubleshooting. The reason for the problem is the If the service is restarted, Wolverine begins to resend all stuck messages. Unfortunately, Wolverine doesn't provide any options to replace [HarmonyPatch(typeof(KafkaSenderProtocol), nameof(KafkaSenderProtocol.SendBatchAsync))]
#pragma warning disable
public class Patch
{
public static void Postfix(ref Task __result, ISenderCallback callback, OutgoingMessageBatch batch)
{
__result.ContinueWith(x => callback.MarkSuccessfulAsync(batch));
}
}
public static class Patcher
{
[ModuleInitializer]
public static void Patch()
{
var harmony = new Harmony("wolverine-outbox-fix");
var assembly = Assembly.GetExecutingAssembly();
harmony.PatchAll(assembly);
}
} I'm going to create a merge request with the fix. |
Pfft, @ilya-edrets got it. I'm pushing that change in Wolverine 2.6. Running the tests right now. Feeling more than a little bit embarrassed over this one... |
…r records from the durable inbox. Closes GH-689
…r records from the durable inbox. Closes GH-689
Can we get this fix in the 1.20.x version too plz ? I have to use .Net 6 on my project, and unfortunately I can't use the proposed Harmony fix as it makes the application generate InvalidProgramExceptions when published in production. |
Hi,
Describe the bug
I'm currently testing wolverine 1.13.2 in conjunction with Kafka and SQL Server/EFC integration.
The message transport is working great and as expected so far, messages arrive in the corresponding Kafka topic and also get consumed from the topic correctly.
When I turn on the durable in- and outbox, it would seem that messages which have been published successfully, get persisted in the wolverine_outgoing_envelopes table in Sql server and never deleted.
To Reproduce
Wolverine startup configuration:
Message publishing code (outside of a handler, MVC model)
This is whats stored in SQL server wolverine_outgoing_envelopes table
![image](https://private-user-images.githubusercontent.com/19185396/296615669-162fa9e2-4301-4359-9f12-a73bc7b11bb2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE0MDEzOTAsIm5iZiI6MTcyMTQwMTA5MCwicGF0aCI6Ii8xOTE4NTM5Ni8yOTY2MTU2NjktMTYyZmE5ZTItNDMwMS00MzU5LTlmMTItYTczYmM3YjExYmIyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzE5VDE0NTgxMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQwNDNlMDYyOGQxMThjMjNiMWZhM2ZkOGI5MGQ5MzkyNjgxZDZhNmVkZDZhNTc1NzExNGY0Y2FjZWJlODI0NWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.rqughrhtL-L3ywEoUjGS4JbSivThIDfMMRazrq_HrN4)
Equally, when receiving messages with DurableInbox enabled (and handling them successfully), they seem to remain in the wolverine_incoming_envelopes table:
![image](https://private-user-images.githubusercontent.com/19185396/296617378-34f9a1c3-7d0f-4f2b-8a35-5a4c4865f63e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE0MDEzOTAsIm5iZiI6MTcyMTQwMTA5MCwicGF0aCI6Ii8xOTE4NTM5Ni8yOTY2MTczNzgtMzRmOWExYzMtN2QwZi00ZjJiLThhMzUtNWE0YzQ4NjVmNjNlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzE5VDE0NTgxMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWVkOTRiZTM1NWZkYzA2MDRhOTc3YWY0NzhmYjlkZTZlZTIzYzA2NzA4YzBjOWJmYzQ1YTE4MzA2ZjA0N2QyNzAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.d5G2OWaPlQiomjlXiATeq90woVg5Ve2DJ9keDQhY9Pg)
When I then stop the application gracefully, I get the below log entry:
on app startup, these messages are all picked up again, reassigned and replayed (as duplicates). The replay (re-assignment) doesn't happen every time though and is harder to reproduce but my main question is why these messages remain persisted in the first place (which they always seem to do).
Expected behavior
Messages persisted in in- and outbox, but deleted once sent successfully to subscriber (or successfully received and handled).
Is there a time limit of when these messages get deleted? I waited 12 hours now and the messages are still there and I'm concerned about replays and database filling up in this scenario.
Environment
Local Development under VStudio (Win 10). Local SQL Server 15.0.2104. Single node/app.
The text was updated successfully, but these errors were encountered: