-
Notifications
You must be signed in to change notification settings - Fork 143
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
AlreadyClosedException
during message sequences in 2.0
#226
Comments
Hello @videege 👋 , I tried to reproduce this in the Looking at the log entries, everything seems to go well. Early on the sequences completes (Sequence '8998c39c-c797-4552-869e-4f9c52e7a0dd' completed), and then it looks like the http request also completes (Request finished in 163.8095ms). It is a bit strange that the exception is thrown after the execution is done. I wonder if:
If possible, you could share your code and I'll try to run it locally! |
@videege is this still an issue for you? |
I can confirm I'm still seeing this but it doesn't seem to negatively impact execution at all. I can't share code but let me try to get you some logs. |
Hi @pardahlman, sorry for the long delay on this. This seems to be causing some actual problems in our application now. Let me see if I can describe the sequence of events:
When I hook up to the default_error_exchange, I can see that the error being logged is the
Here are the logs of Service B:
The thing that concerns me is that the sequence ID
Does this hose up the original sequence, which has not yet completed, with this same GUID (Service A -> Service B)? I might just be misinterpreting this, but it seems like it is impossible to nest message sequences, i.e., A -> B -> C. |
Hello @videege, thanks for taking moving this forward 👍 I'm trying to recreate what you describe in a unit test. Based on my understanding, this is what you are trying to do (message name/number indicates "flow order") await serviceB.SubscribeAsync<FirstMessage>(async message =>
{
var nestedSequence = serviceB.ExecuteSequence(s => s
.PublishAsync(new SecondMessage())
.Complete<ThirdMessage>());
await nestedSequence.Task;
await serviceB.PublishAsync(new ForthMessage());
}
);
await serviceC.SubscribeAsync<SecondMessage>(message =>
{
return serviceC.PublishAsync(new ThirdMessage());
});
var mainSequence = serviceA.ExecuteSequence(s => s
.PublishAsync(new FirstMessage())
.Complete<ForthMessage>()
);
await mainSequence.Task; Is this close to what you're doing? |
@pardahlman I'm also seeing these 'already closed' exceptions. They seem fairly benign - our requests complete without issue. Our scenario differs very slightly - rather than the typical request/response pattern for our request command handlers we're currently using the pub/sub model instead - so we're not really doing fully nested sequences. If I flip the code back to the Request/Response pattern obviously the issue doesn't occur. The consistent issue appears to be that publishing messages within the context of an existing handler causes this exception to be thrown. |
I think I've narrowed down to where the problem is. Stateless fires of an event that appears to be running in a different thread than the rest of the execution. That part of the code disposes the subscription(s) and channel for the sequence, at the same time as RawRabbit tries to use the same channel to ack the message that completes the sequence. That is, I don't think it has to do with the nested sequences. I'll need to look in to this a bit further, now that I've found a way to repro it. |
This issue has been resolved in the just released beta8. Closing this ticket now, but feel free to re-open if you experience any related problems. |
I was experimenting with 2.0 (beta 6) and I noticed that I encounter this error when handling the completion of a message sequence.
My setup is
Everything works fine but in the debug output for the ASP.NET app I see logs like this:
Is this output to be expected, or am I doing something wrong? I basically copied from the sample app in the 2.0 branch.
The text was updated successfully, but these errors were encountered: