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.
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 have one application which is continuously checking one wcf service response, and this service is hosted in IIS.
When I run this application and service is already running in background, at that time application is getting the response from the service for n-number of time.
But when I recycle the app pool, application is not getting any response from service. At this point of time I have to restart the application, and then it works.
Please suggest me a way or any changes I should do in service to get the response from it even after recycling the app pool. I don't want to restart the application.
Or if there is any workaround that I can do in application, so that it will come to know that new session is created or app pool is recycled.
I suspect you are storing the client proxy somewhere rather than periodically re-creating it. Once a WCF proxy has faulted, it cannot be re-used. Re-create it. If your WCF service is session-based rather than per-call you will run into such problems.
I have a WCF service that reads messages from MSMQ and writes messages to MSMQ. This is hosted in IIS. I have enabled net.msmq and http protocols on the WCF service in IIS. I have also given full permission on MSMQ for app pool I am running this service.
Once I have deployed this on the win server 2012 and I queue messages, WCF service does not pick up the messages. If my service name is myservice, Once I hit http://machinename/site/myservice.svc in the browser then on messages gets auto picked up.
Could you please know what is causing this behaviour.
Your problem is that your WCF service needs to listen to a queue, but it cannot do that until IIS decides to start the application.
This happens only when IIS needs to handle an HTTP request. Once it receives the request it will start your application, which can then start listening on the queue.
The easiest way you can fix this is not to use IIS to host a queue listener. Use a windows service instead.
If you're stuck with IIS, but you're using 7.5 or above, you can configure the application pool settings to make the application start when IIS starts:
<applicationPools>
<add name="appPool1"
startMode="AlwaysRunning" />
</applicationPools>
You also will need to ensure that Windows Activation Service is installed and running: https://msdn.microsoft.com/en-us/library/ms731053(v=vs.110).aspx
I was wondering if it's safe to host an NServiceBus endpoint that serves as an event publisher inside IIS?
To clarify, we use an application hosted in IIS as our CRM system (Microsoft Dynamics CRM), and I want to use NServiceBus to publish an event when a contact's information is updated.
MS CRM allows the use of custom plugins to react on a contact update, and I intend to create a plugin that publishes a 'ContactUpdated' event through NServiceBus for that situation. Hence, this will effectively mean that my NServiceBus event publishing endpoint is hosted in IIS.
Now, I know that a self-hosted NServiceBus endpoint will create its own worker thread
to monitor incoming messages (in this case subscription messages) from the queue. Because IIS is free to unload a worker process if there are no more incoming web requests, it's usually not a good idea to use IIS to host long-running processes in.
However, I'd say that the NServiceBus queue monitoring thread does not qualify as a long-running process because it doesn't do any processing and can be stopped at any time: new subscription requests
will then simply be queued until the web application is restarted again.
I'm just wondering if the way IIS cleans up this NServiceBus thread is safe, from an NServiceBus perspective?
(Incidentally, I also found this article, but I have to admit that only the Scaling out argument resonates with me, and that is not relevant in our situation.)
Yes, it is safe to host an NServiceBus publishing endpoint in IIS.
As you said, if IIS were to unload your worker process then any pending subscription requests would be waiting in the queue. This is reasonable - as long as you don't make any assumptions about the order in which a subscription request would be handled and a new event published.
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.