Request Reply deadlocking coming from WPF application
See original GitHub issueDescription
Hello, I am currently attempting to use the NATS Request/Reply functionality from within a WPF app. The behavior I am currently seeing however, is that once my request goes into the NATSConnection, my application deadlocks until the timeout is completed. The subscriber never receives the message. Below is an example of the basic WPF I have spun up to recreate the issue, have tried both async and sync.
namespace TestWPFNats
{
/// <summary>
/// Interaction logic for MainWindow.xaml
/// </summary>
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
private async void Button_Click(object sender, RoutedEventArgs e)
{
var guid = Guid.NewGuid().ToString();
var clientId = Guid.NewGuid().ToString();
var configurationRetriever = new MessagingConfigurationRetriever();
var natsConnectionOptions = NatsOptionsFactory.Create().Build(configurationRetriever.HostsAndPorts, clientId);
var natsConnection = new ConnectionFactory().CreateConnection(natsConnectionOptions);
var proto = new RandomProtoObject();
var response = await natsConnection.RequestAsync("my_topic_name", proto.ToByteArray(), 60000);
}
private void Button_Click(object sender, RoutedEventArgs e)
{
var guid = Guid.NewGuid().ToString();
var clientId = Guid.NewGuid().ToString();
var configurationRetriever = new MessagingConfigurationRetriever();
var natsConnectionOptions = NatsOptionsFactory.Create().Build(configurationRetriever.HostsAndPorts, clientId);
var natsConnection = new ConnectionFactory().CreateConnection(natsConnectionOptions);
var proto = new RandomProtoObject();
var response = natsConnection.Request("my_topic_name", proto.ToByteArray(), 60000);
}
}
}
Any help would be greatly appreciated, not sure where else to look. I suspected at first it may have had to do with the InFlightResponse TaskCompletionSource, but unsure if thats the case, since the message is never even being sent out.
Versions
C# nats.net (0.12.0) nats-server (2.5.0) nats-c (2.4.0)
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (5 by maintainers)
Top Results From Across the Web
WPF Thread dead lock [closed]
You're blocking on async code, which is a sin that causes deadlocks. Normally the solution is to replace blocking waits with await s,...
Read more >Understanding Async, Avoiding Deadlocks in C# | by Eke ...
To write proper async C# code and avoid deadlocks you need to understand a few ... The application needs to request some data...
Read more >Threading Model - WPF .NET Framework
We don't want to call blocking methods from event handlers because the application will appear to freeze up. We can use a separate...
Read more >C# Deadlocks in Depth – Part 2
The is a simple WPF application; OnButtonClick is an event-handler of a Button Click, that executes on the UI Thread; Task.
Read more >Why is .GetAwaiter().GetResult() bad in C#?
It ends up boiling down to deadlocks and threadpool starvation. This post gives a gentle, high up look at why this may happen....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@kharkins-23 That looks like nobody is responding to your message. Your message (request) is published on subject
safetysettings.upsert.click
, awaiting a response on_INBOX.uHgt21IfmyJOZiwF3EyTv2.1
. But apparently the server never receives a response message.I think the missing
->> [MSG safetysettings.upsert.click ...]
line afterMSG_PAYLOAD
indicates that there is no subscriber. Can you double check that Request/RequestAsync does not throw a NATSNoRespondersException?True, the async error handler is only for NATS related errors/exceptions today. I can see how the exception being swallowed could make it difficult to debug. I think that’d be a good addition, and will open an issue to track that. Thanks!