I have a WCF service with NetTcpBinding and DuplexChannel self hosted in the console app. Clients 'subscribe' to the WCF service and i gather callbacks to the list. On client side I have attached handlers to the Faulted and Closed events and when I receive them I just reconnect the client again.
I have a strange behavior (as for me) when testing the crash of service:
When both client and service are tested on localhost I just kill the WCF Service process and clients receive the Faulted event and then try to reconnect all the time until the service is alive again.
When I deploy service on the production server and client is on another comp (over the internet, not in the same domain) when I kill the hosting process - clients don't receive any notification about the fault, although I have proper way to close the app when the Abort is sent to all of the callbacks in the list, when i close it in proper way - clients get the fault event and properly try to resubscribe.
So the question is, why this is happening? The question is not HOW to maintain the alive connection, i think i found how to do that in another way (reliable session or pinging the service)
I just want to know WHY the behavior of the event is different when deployed? The configuration is the same - i didn't change anything.
Related
I have inherited an azure service bus solution - C#, Web Api with Singleton service implementing the queue. Running locally on my PC, I can publish a message to my Dev queue and see that event consumed by my service bus receiver. No problem.
In our staging environment however my receiver is not firing so my code never processes the messages. I found an instance where a different environment was pointing to the staging queue purely by luck which makes me think "what else is using this queue". We have no application logging (useless I know) of when events are published or consumed so I wondered, is there a way from within Azure to see either
What is consuming the events published to the queue, or
What is currently connected to the queue so I can validate each connection and make sure a dev in a far flung office isn't running test programs using the queue.
Thanks
Create application insights instance
Connect your web app in azure to the created AI
after some time you will be able to see requests to other systems sent by your app (in application map you'll see fancy diagram of requests, in logs you can query requests to service bus)
Drop the AI instance if you don't need it anymore
I am using latest SignalR version 2.3.0 with C# client.
The problem I am facing is kind of mentioned here on stackoverflow. But that issue is few years old and it is already closed on github.
The issue I am facing is that whenever a request timeout from client to server then client starts reconnecting to server and then keeps on reconnecting. I tried defining the WebSocket protocol also in connection but result is still same.
_connection.Start(new Transports.WebSocketTransport()).Wait(TimeSpan.FromSeconds(10));
I am looking for a persistent connection between server and client.
I have added an event handler on StateChanged event to capture the state changes of SignalR client.
Here's the screenshot of reconnecting state
Does anybody have any idea why it's happening and how it can be prevented?
The reason might be because your OnReconnect even doesn't fire and then again your OnDisconnected doesn't fire when the client calls the `stop method as described here:
If the client goes into reconnecting mode but can't establish a
transport connection within the disconnect timeout limit, the server
terminates the SignalR connection. When that happens, the server
executes the Hub's OnDisconnected method and queues up a disconnect
message to send to the client in case the client manages to connect
later. If the client then does reconnect, it receives the disconnect
command and calls the Stop method. In this scenario, OnReconnected is
not executed when the client reconnects, and OnDisconnected is not
executed when the client calls Stop.
This is referring to SignalR version 2, But I believe that it will of help to you as well.
Worth mention as well, that you will contentiously try to reconnect if you call start from your closed event (or disconnect in JavaScript`) as said:
In some applications you might want to automatically re-establish a
connection after it has been lost and the attempt to reconnect has
timed out. To do that, you can call the Start method from your Closed
event handler (disconnected event handler on JavaScript clients). You
might want to wait a period of time before calling Start in order to
avoid doing this too frequently when the server or the physical
connection are unavailable. The following code sample is for a
JavaScript client using the generated proxy.
anyway, the simplest way to disconnect your client from the server up until version 2 is to implement the disconnect method on the client an call it from the server as mentioned:
SignalR version 2 does not have a built-in server API for
disconnecting clients. There are plans for adding this functionality
in the future. In the current SignalR release, the simplest way to
disconnect a client from the server is to implement a disconnect
method on the client and call that method from the server.
As far as I know BasicHttpBinding doesn't support ReliableSession feature. So, this means that when request is received by server (wcf host) then it will be executed wether the client is disconnected afterwards or not. I hope I'm right on this?
The problem is:
I have a WCF service with BasicHttpBinding. We tested this service by calling it 10 times with different threads on the client side. And these requests are all made at the same time (almost). Right after the callings of the thread we're terminating the program by killing the process. As a result 6 out of 10 requests are executed but the 4 of the requests aren't executed. We've checked network traffic with wireshark and saw that 10 of the requests are received by the wcf service host. However, we know that 4 of them didn't executed.
(Timeout values are not configured on binding: that means they're all setted to their defaults. Also the wcf service is hosted on iis).
What's the problem here? Where can I check? What can we do to achieve 10 execution out of 10 even if the client disconnects?
What can we do to achieve 10 execution out of 10 even if the client disconnects?
You can make it the default behavior. Use [OperationContract(IsOneWay=true)] to create a one-way contract where the client does not wait for a reply, but simply disconnects after sending the message.
Since you really need the service to be completed even if the client disconnects i think there is a database transaction that you need to be done.
In case the WCF is connecting to a database, this would be normal especially if you are using the same database user and password, if this is the case try to connect once for all WCF instances.
either way you have to make sure that your WCF provide concurrent access. click here for more information of concurrent WCF access.
I have a WCF service hosted on IIS, where during application initialization it start listening to the RabbitMQ and it subscribed to the Q say Q1, after long run of the service, we are seeing that the service is fetching the messages and it fails to processing it.
But we do have the different windows service which is also interested in the same events which is subscribed to the different Q say Q2, was able to process all the events even after a long run.
Why does the WCF is failing after long run, is there a thread pool sealing which will be imposed on Apppool ? Need help in debugging this.
Note: Both Queues (Q1 and Q2) are subscribing to the same message rout keys which is connected to the exchange.
Well I'm not sure about processing, but by default IIS-hosted anything AppPools recycle/expire after 20 minutes so it's entirely possible your WCF service is no longer running if its service methods have not been invoked.
Try setting your IIS AppPool timeout to 0 to disable timeout.
I'm creating a WCF service (to be run in IIS) that a client can talk to. Periodically I want my server to send a heartbeat to a Master server.
At the moment the only way I see to do this is to create a second Windows Service that will send out the heartbeat.
Is there any way to get my original WCF service to run an event periodically so that I can get everything done with just one service?
Not really a good way in a WCF service
If the service is going to get some use you may be able to store the NextHeartBeat timestamp and every request check if it's time to send out a message to the master server.
What you want to do may be achieved with server push or full-duplex approaches. But for heartbeat you might get around with a simple http ping using a WebClient as described here. When self-hosting (non IIS) you can override ServiceBase.OnStart/OnStop and start/stop a timer to periodically trigger the ping.
However, hosting a WCF service in IIS usually means that your service is instantiated on a per-request basis so there is no service instance hanging around to send an enduring ping.
It depends on the purpose you need the heartbeat to the Master Server. Could you instead let the master server periodically do a request on the WCF service?
If you really are in the need for a long running service then hosting WCF in a Windows Service instead of IIS might be an option.