We use Service stack, and run using the InProcess model on .net core.
We have some longer running requests, which we would like to timeout - however, I am struggling to do this. Before .net core, you could configure the httpRuntime's "executionTimeout" however, this is unavailable in .net core. The new way of doing this (I believe) is to use the "requestTimeout" in the config - but Microsoft's website claims this is not supported with the InProcess model. If feels like the only solution left is to configure this in Service Stack somewhere, but I am not seeing anywhere obvious.
Am I missing something here? Is there a ServiceStack option to force the thread to finish on a timeout, or is this just not not possible?
There are other timeout options via IIS, but none which will stop the execution
Thanks
ServiceStack operates as a library handler on the .NET HTTP Worker Request thread, i.e. it doesn't spawn or manage any of its own threads. Any request quota limits or timeouts would need to be configured on the underlying HTTP Server, i.e. just as any other ASP.NET Core App would need to do.
If you're using IIS, you can still configure ASP.NET Core Request Timeouts in Web.config in the <aspNetCore/> tag. If you're using the default Kestrel HTTP Server you can configure its limits when configuring your Web Host.
Related
I have an ASP.net Core web API running the ASP.net Core Web Host.
In the ServiceCollection, I register a HostedService to run a worker that subscribes to a message bus.
Some messages come from web API. Some messages come from the message bus through the worker.
They all get written to a database.
Presently I'm having problems where when I write messages coming from the worker to the database I get System.ObjectDisposedException on my dependency injected data access Scoped service.
It feels like my worker is somehow using the HTTP request scopes for the DI injected services.
So, could this be caused by using a Hosted Service in the ASP.NET Core Web Host
Do not read messages in a ServiceHosted, you should read it seperately (maybe in a singleton scenario)
If you're reading messages from service-bus manually you should not have that problem otherwise you should not use scoped services for that. for example in RabbitMQ the best practice is to open a connection for each app
I have followed the instructions here and here to setup SignalR in a ASP.NET Core web app. Then replicated the same code in a Service Fabric ASP.NET Core service only to find that the 100% working code when hosted outside of service fabric did not work when hosted on Service Fabric. When I open the html client included in both of these samples and turn on developer tools in the browser I see what appears to be the WebSocket handshake failing with HTTP 410 GONE errors.
In the Service Fabric documentation for ASP.NET CORE I found that the ServiceFabric Middleware can return HTTP 410 GONE if the identifier that validates each request does not match. But I guess I don't understand the inner workings of SignalR to know how to properly configure Service Fabric to unblock this.
I am running on a local single node cluster so I figured that I wouldn't have any issues until I needed to do multi-node cluster deployment, at which point I would need to figure out the SignalR backplane I'm going to use.
Any idea what would cause this to be?
I needed to disable Service Fabric Integration in the WebHost Builder. Simply replacing this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
with this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
allowed it to start working.
I'm implementing profiler to track http requests coming to .net core applications hosted in IIS. I'm using coreclr profiling api to hook method enter/exit.
Which method I should track to know a new http request coming into my application.
Create a middle ware and configure ASP.NET Core to use it. It should receive requests, process it, then pass it along with the pipeline.
For more information see here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-2.2
Currently I maintain an application that runs as a Windows service, reads messages from a message queue server, processes them and puts the result back into the message queue server. But it also contains a health monitoring component that is accessible through a web API.
It is implemented as a console app that uses Katana to self-host the health monitoring sub-system.
I'm now trying to figure out if we can move this to .NET Core and ASP.NET Core once they RTM. I know the Windows Service part cannot be ported, but I could also run the console app as a detached Docker container to basically achieve the same thing, in terms of main functionality.
But how will the health monitoring work? From what I can see the Katana project has been updated to ASP.NET 5 (which I guess is ASP.NET Core 1 before the big rename), but it does not run on the .NET Core CLR. Katana will require the full CLR. So that means Katana is out.
Does this mean that the way we build our app is impossible with .NET Core? Or does hosting the app through Kestrel not rule out the possibility of running code before the first request? With IIS the app does not live until the first request (unless you use the auto-start, but it's more of a speed-optimisation than have the app behave like an "allways-running-app") and generally the app is request-based and not continually running. Background threads in a IIS hosted app are a really bad idea.
Is this the same with Kestrel? Or will DNX start your app and keep it running until it's shutdown, much like a console app, so we can run all the background threads we want?
It follows the console app model. Katana is actually more the spiritual predecessor to kestrel. It is invoked for normal ASP.NET Core projects from the Main method with a normal method call. There are countless tutorials how to setup a server in RC1 (see Startup.cs Main method) and some for the upcoming RC2 (there is a builder for it). That would allow you to do both, your app code and your web api based monitoring, in a console app. Kestrel and DNX are not at all an application server like IIS. Kestrel is a plain HTTP server library and nothing more. You start it up and it listens from that moment on.
Nevertheless, you have to adjust your WebApi 2 and Katana based application to the new ASP.NET Core interfaces and middleware concept. But that should be easy compared to your message queuing adaption.
I've implemented an OData service using ASP.NET WebAPI. I also have some existing web methods in a seperate WCF project which is hosted in an ASP.NET Web Application.
By copying some bits of web config around and copying a couple of code files I've managed to get the WCF methods hosted in the WebAPI project.
Everything seems to be working but I've got a nagging doubt I'm doing something horribly wrong that's going to break when I least expect it.
Is this a good idea?
Depends on your anticipated call volume. The only problem I can think of with this is that incoming WCF requests will be serviced from the same dispatcher thread pool as the OData service. This makes it more likely that you will suffer availability based issues on either endpoint.