We are using NServiceBus 4.6.1 and there is a blocking activity that takes about 2 minutes.
I know that with NServiceBus 6, async await is the solution, but we don’t have time to upgrade NServiceBus now, so what is the recommended approach for NServiceBus 4.6.1?
Or is it possible to use async await even in NServiceBus 4.6.1?
Thanks,
Miguel
Related
When IIS Server is the outage, the server is restarted and all applications and web APIs are restarted as well, the problem I'm facing that some Web API depends on BUS. Could we let site/app wait until BUS ready before starting from IIS without touching the application code? In Docker, we can use the WAIT command or other third parties to wait until service is available before starting a container.
The Web API we are built on .Net Core 3.1
Any help is appreciated.
During the startup could you use something like
https://github.com/App-vNext/Polly to enter a period of retry
(https://github.com/App-vNext/Polly#retry). This would allow you to
retry the call to the API until it's hopefully it's available.
Use a windows service to monitor heartbeats of the applications and trigger application pool restarts on applications not working correctly. This should help you get into a running state.
Ultimately I'd try and remove this dependency, if you could give a little more information around the webapi requirements I'd be happy to suggest more ideas.
We are building Workflow Foundation service with .NET 4.5 and are attempting to use MSMQ to deliver messages that Workflow Service should process.
We have enabled Allow Buffered Receive in order to have messages wait for Workflow to be able to process them.
However, we've ended up with some weird kind of locks in our message folders (see the pictures).
There is no documentation whatsoever to explain this. What is this? Is it related to WF, WCF, MSMQ? Where to look for solution?
I have no idea about the locks but I decided to implement my own queuing solution within my workflow outside of MSMQ due to past issues with MSMQ. I found the following article that helped me implement a queuing solution using SQL Server Implementing Message Queues in Relation Databases
Using a variant of this technique, IIS 7.5 AutoStart, WWF bookmarks and Context Based Correlation I was able to implement a persistent queue within my workflow without using MSMQ. The nature of workflow makes queuing within the workflow very doable.
I have a synchronous legacy WCF service with a potentially long running operation. For some clients, this operation seems to cause network timeouts - not at the client or service end, but somewhere in the middle at some proxy server in a network topology that is opaque to me.
The question is: Could I solve this problem by using the event based asynchronous pattern on the service side (using IAsyncResult / BeginXXX(), EndXXX())?
I am puzzled about how the callback mechanism of async services actually works on the network level. Does the client do periodic polling, or some kind of long polling, or something completely different? Unless I am simply bad at using Google (I believe I am not), the MSDN documentation seems to be completely lacking in that respect.
In only keeps going on about how async programming helps you to build responsive GUIs and whatnot.
The question is: Will it prevent proxies from timing out requests that they believe to be taking too long?
EDIT: To clarify: The service in question uses basicHttpBinding.
There are no callbacks at the network level. Async IO is all about not blocking threads on a single machine. Both communication parties can independently decide to use sync or async IO as they please. Neither party can even detect what the other chose.
You are using the SOAP-based basicHttpBinding. SOAP has no notion of asynchronous invocation. Neither does any of the other bindings.
Async IO can do nothing to resolve your timeout problem. Those timeouts are caused by something on the network (as you said). The network has nothing to do with how a service is implemented. It cannot even find out and respond to it.
The timeout things are at the http stack, and have nothing to do with the async things in programming. Google "windows http stack" you may find out why.
"In only keeps going on about how async programming helps you to build responsive GUIs and whatnot." this helps you not to block the UI thread with a long running operation like a http request/response.
A WCF service is by default multi-threading -- upon one request, a new thread is created.
On the client side if you are using .NET 4.5, you may find the client proxy classes generated support async operations, however, this has nothing to do with http timeout. These functions make asynchronous/parallel programming easier on the client side.
In short, the timeout is determined by the http stacks on both server and client. If you have controls over both server and client, you may increase timeout values on both side, as quick and dirty solution.
I don't think it prevent the timeout as the asynchronous development is on the client side independent of the protocol and the network configuration. For HTTP this is likely a registry setting.
My understanding is that windows I/O is by nature asynchronous so I don't think there will be any polling, rather once the IO is complete some sort OS level interrupt will occur. You may find this article by Stephen Cleary helpful. Also the books Windows Internals might be a good reference as well.
I have my workflow hosted in a WorkflowServiceApplication running on IIS5 (production environment will be IIS6) with a persistence database. It's a request/approval service so there's a delay (a few days) whilst waiting for approval and if that delay passes with no approval the workflow sends an e-mail to the approver. I've noticed that the pending workflows only "wake up" and send their e-mails if I kick off a new request (i.e. new workflow instance). I assume that in starting a new flow something checks the instance store for instances that are due to resume and resumes them. I've only just noticed the problem because I was previously testing with delays that were just a few minutes rather than days. I haven't tried it on IIS6 yet but I expect it would be the same.
q1) do I need to write a console app or something to periodically check and resume the flows and if so can someone advise how to do it? Or have I just done something wrong?
q2) Assuming that the answer to Q1 is "yes, you need to write something" if I was to use IIS7 and AppFabric (which may be possible) would the sleep/resume just work without me having to write any code to check and resume the flows? i.e. just deploy the workflow service into AppFabric and it works?
Thanks in advance.
The answer to q1 is yes. After an IIS AppDomain recycles it is not restarted until there is an external request for it. As a result the WorkflowServiceHost is not active and expired Delay activities will not be resumed. With versions of IIS before 7 you need to create an external request to make sure the WorkflowServiceHost is available. The easiest way of doing so is just have a windows service periodically retrieve the WSDL page.
If your upgrade to IIS7 and AppFabric you can configure a service to automatically start as soon as IIS is running and that will take care of the same problem. I would prefer this option as AppFabric gives you a lot of extra benefits like tracking.
Yes Windows Server AppFabric's Workflow Management Service will wake up workflows with pending timers. You get this for free as well as other goodies.
We have a WCF Service using a wsHttpBinding. When it recieves many requests in a short period of time (25 per second for a few minutes) it stops working and our other asp.net applications and pages to stop responding as well. Some of them timeout and eventually we see the following in the event viewer:
ISAPI 'c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.
Often we get calls about the problem first and restart IIS to solve the problem.
How can we configure our WCF service to handle this many transmissions or at least configure it to not take down our other applications when it can't handle the load. Our classic asp applications run without issues during this time, it's only our .net apps that are effected.
are you running all your asp/wcf sites in the same AppPool? if so, I'd suggest creating a new one and running the WCF service just in that. That in itself might be enough to solve the problem from a practical perspective.
Also can you target a more recent version of the framework with your WCF app? (and leave the other apps the same) It will isolate it much better.