从两个单独的客户端调用服务时WCF死锁

时间:2022-12-29 19:35:50

I have a WCF service(hosted in a WPF application) that handles the communication between clients(WPF). There's a scenario, where one client sends a message to the servuce, who broadcasts it to the other clients but the message results in the other client sending a new message back and they all freeze. After some reading I suspect that the second client tries to make a call to the service while the service's call still hasn't finished (using the same channel). However, I'm not sure is my assumption correct and if so how to overcome it.

我有一个WCF服务(托管在WPF应用程序中),用于处理客户端(WPF)之间的通信。有一种情况,一个客户端向servuce发送一条消息,然后将消息广播给其他客户端,但消息导致另一个客户端发回新消息并且它们都冻结。经过一些阅读后,我怀疑第二个客户端尝试拨打服务,而服务的呼叫仍未完成(使用相同的通道)。但是,我不确定我的假设是否正确,如果是这样,如何克服它。

In a bit more detail: the clients are text editors. If you write in one, operations that represent the changes are sent to the service and from there to the other clients. When I try to send operations about the others' caret movements though, it freezes. I assume it's because the InsertOperation that the second client receives causes a caret movement and it tries to send a CaretMoveOperation back in the event handler making a call using the same channel the service uses for sending the message, causing a deadlock.

更详细一点:客户端是文本编辑器。如果您编写一个,则表示更改的操作将发送到服务,并从那里发送到其他客户端。当我尝试发送关于其他人的插入动作的操作时,它会冻结。我假设这是因为第二个客户端接收的InsertOperation导致插入符号移动,它尝试在事件处理程序中使用服务用于发送消息的相同通道发送CaretMoveOperation,从而导致死锁。

What do you think? Can you suggest something?

你怎么看?你能提出什么建议吗?

2 个解决方案

#1


0  

I would check two things

我会检查两件事

  1. is the CPU levels on your app spiking when you invoke the call? Are you getting an infinite loop that is giving the appearance of a lock?
    1. Are you using synchronous messages that wait for termination? because then you will get into a loop. Make sure you aren't calling back on the same thread with a synchronous operation. You should use an asynch messaging design, possibly on separate tasks from your event handler
    2. 您是否正在使用等待终止的同步消息?因为那样你就会进入一个循环。确保您没有使用同步操作回调同一个线程。您应该使用异步消息传递设计,可能使用事件处理程序中的单独任务

  2. 当您调用呼叫时,应用程序上的CPU级别是否会增加?你是否得到一个无限循环,给出一个锁的外观?您是否正在使用等待终止的同步消息?因为那样你就会进入一个循环。确保您没有使用同步操作回调同一个线程。您应该使用异步消息传递设计,可能使用事件处理程序中的单独任务

#2


0  

You have to look at your service behavior attribute. When things look like only one message is processed at a time (it probably means single threaded).

您必须查看您的服务行为属性。当事情看起来一次只处理一条消息时(它可能意味着单线程)。

An excerpt from MSDN

来自MSDN的摘录


The ConcurrencyMode property interacts with some other settings. For example, if the InstanceContextMode value is set to Single the result is that your service can only process one message at a time unless you also set the ConcurrencyMode value to Multiple. This property also produces behavior in combination with the ServiceContractAttribute.SessionMode property. For details, see Sessions, Instancing, and Concurrency.

#1


0  

I would check two things

我会检查两件事

  1. is the CPU levels on your app spiking when you invoke the call? Are you getting an infinite loop that is giving the appearance of a lock?
    1. Are you using synchronous messages that wait for termination? because then you will get into a loop. Make sure you aren't calling back on the same thread with a synchronous operation. You should use an asynch messaging design, possibly on separate tasks from your event handler
    2. 您是否正在使用等待终止的同步消息?因为那样你就会进入一个循环。确保您没有使用同步操作回调同一个线程。您应该使用异步消息传递设计,可能使用事件处理程序中的单独任务

  2. 当您调用呼叫时,应用程序上的CPU级别是否会增加?你是否得到一个无限循环,给出一个锁的外观?您是否正在使用等待终止的同步消息?因为那样你就会进入一个循环。确保您没有使用同步操作回调同一个线程。您应该使用异步消息传递设计,可能使用事件处理程序中的单独任务

#2


0  

You have to look at your service behavior attribute. When things look like only one message is processed at a time (it probably means single threaded).

您必须查看您的服务行为属性。当事情看起来一次只处理一条消息时(它可能意味着单线程)。

An excerpt from MSDN

来自MSDN的摘录


The ConcurrencyMode property interacts with some other settings. For example, if the InstanceContextMode value is set to Single the result is that your service can only process one message at a time unless you also set the ConcurrencyMode value to Multiple. This property also produces behavior in combination with the ServiceContractAttribute.SessionMode property. For details, see Sessions, Instancing, and Concurrency.