Replies: 8 comments 4 replies
-
|
Would this be mitigated by having |
Beta Was this translation helpful? Give feedback.
-
|
You can use the On the The producer will use the current implementation by default; otherwise, it will delegate to the user what to do. |
Beta Was this translation helpful? Give feedback.
-
|
something like this #294 |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, looks like exactly what we need. Would also play well with |
Beta Was this translation helpful? Give feedback.
-
|
@ricsiLT Per conversation with @Zerpet and @acogoluegnes, we decided that exposing the function to handle the disconnection is out of the scope of the If you need a different behaviour, you should use the We are working to reproduce the issue btw since we consider it a bug, so instead of rewriting a new Producer I suggest waiting. In the meantime, let me know if you have any news about how to reproduce the issue. |
Beta Was this translation helpful? Give feedback.
-
|
@ricsiLT when the connection is restored, is the producer able to reconnect? or the Producer is just blocked in an unknow status? |
Beta Was this translation helpful? Give feedback.
-
|
Producer did reconnect! But as far as I can tell I just didn't receive any nacks. Maybe my logic around it is busted... Will have to review. |
Beta Was this translation helpful? Give feedback.
-
|
I can reproduce the situation but not the problem: Code: var confirmed = 0;
var notConfirmed = 0;
var producer = await Producer.Create(new ProducerConfig(system, stream)
{
ConfirmationHandler = async confirmation =>
{
if (confirmation.Status == ConfirmationStatus.Confirmed)
{
confirmed++;
}
else
{
notConfirmed++;
}
Console.WriteLine($"Confirmed {confirmed} NotConfirmed {notConfirmed} total {confirmed + notConfirmed}");
await Task.CompletedTask;
}
}, producerLogger);
const int msgs = 200;
for (var i = 0; i < msgs; i++)
{
await producer.Send(new Message(Array.Empty<byte>()));
await Task.Delay(100);
}while running I block the remote RabbitMQ IP to simulate a network error: @ricsiLT have you checked the |
Beta Was this translation helpful? Give feedback.
-
|
Will have to check, got distracted by operational issues :( |
Beta Was this translation helpful? Give feedback.
-
|
@ricsiLT client library version? Asking because the stack lines code doesn't match |
Beta Was this translation helpful? Give feedback.
-
|
1.5 I think. |
Beta Was this translation helpful? Give feedback.
-
|
Please have a look the version |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
Encountered this during publishing of messages that coincided with network gear change.
I assume messages were published mid-change as I see a socket exception in the logs.
I expected to still receive all messages, albeit with a timeout status.
Instead, I got a hanging process :(
Relevant logs:
Reproduction steps
No clue how you'd repro this :/
Expected behavior
Messages that were queued for publishing should just be returned to me with a timeout/other status, indicating failure.
Additional context
@Gsantomaggio sorry for not responding on Slack. Corporate recently banned all external comms and I have yet to copy my user/psw to home workstation to reply :(
Beta Was this translation helpful? Give feedback.
All reactions