We have an UCWA App that runs as part of a ASP.NET Web Application (as a singleton), and we're using a scheduled job which every two minutes performs reportMyActivity as per documentation; to maintain the application alive and Online.
What we observe, looking at our server logs, is that the application is anyway regularly being shut down by the server, approximately always in about 20 minutes after it was created. During these 20 minutes reportMyActivity returns correctly 204 - NoContent, after that (when going offline), reportMyActivity returns 404 - NotFound instead.
We're also now dumping every event coming through the event channel, and looking at them I don't see any event or evidence being raised; corresponding with the time when UCWA App is being shut down from the server.
We're targeting an on-premises multi-tenant environment.
Any idea or suggestion?
Related
I have an application that mimics an equity market. One part of it, generates price changes and POSTS them to a consumer sending roughly 100 price changes roughly ten times a second. The second part of the market exchange takes in orders, executes them randomly and asynchronously sends execution reports back to the same consumer of the price changes.
I want to put this on a App Service, but here's the issue:
I want the price generator to start immediately and run continuously.
The order execution only needs to run when orders are sent (asynchronously) and all the orders have been executed or cancelled. Then it can shut down until another order is received.
It seems like I'm forced into one of two buckets and neither applies to what I want to do. A Web Job appears to work like a Service in Windows 11. It will start up immediately and run until you shut it down, but it doesn't have the logic to handle an ASP-type controller.
Deploying as an App Service works as long as I wake it up by POSTing an order, but the price feed doesn't start until I send the order.
So here's the question: How do you deploy a .NET Core application as an App Service and have it start automatically (without waking it up with an initial HTTP call)?
According to your description, I suggest you could consider modifying the price feed as a background service inside the .net core application. The background tasks can be implemented as hosted services. A hosted service is a class with background task logic that implements the IHostedService interface.
It contains the StartAsync method. The StartAsync(CancellationToken) contains the logic to start the background task. StartAsync is called before:
The app's request processing pipeline is configured.
The server is started and IApplicationLifetime.ApplicationStarted is triggered.
More details, you could refer to this article.
Besides, I suggest you could also set the Azure web app's configuration as alwayson.
may be this is a dump question but please bear with me and help understand the concept.
There are two servers interacting using REST APIs, there is a default timeout of 2 minutes.
System A is trying to call System B using REST API and System B is in fault state due to database issue- means getting requests but not responding but System A keep sending hundreds of requests and eventually complaining of slowness.
My understanding is - System A - reserves/consumes some resource while making each request which is waiting at least 2 min until timeout on System B - so if hundreds of requests queued then will slow system down.
I have .net core app running on IIS. Please suggest if this understanding is correct or can be other factors? When System B came back to normal state both system behave correctly.
I'm developing an intranet site using asp.net mvc4 to manage some of our data. One important feature of this site is to trigger import/export jobs. These jobs can take anywhere between 5 minutes to 1 hour. Users of the site need to be able to determine whether a job is currently running as well as the status of prior jobs. Many jobs will often include warning messages concerning duplicate data and these warnings need to be visible on the site.
My plan is to implement these long running processes as a WCF Workflow Service that the asp.net site will interact with. I've got much of the business logic implemented via activities and have tested it using a simple console application. I should note I'm using a correlation handle in order to partition the service based on specific "Projects" on the site.
My problem is how do I go by querying the status of an active job (if one exists) as well as the warning messages of previous jobs. I suspect the best way to do this would be to use the AppFabric tracking service and have my asp.net query a SQL monitoring store and report back on the current status. After setting up AppFabric and adding custom tracking messages, I ran into a few issues. My first issue is that I cannot figure out how to filter out workflow instances that were not using the correct correlation handle as I'd like to show only workflows for a specific project. The other issue is that the tracking database can be delayed quite a bit which causes issues for me trying to determine if a workflow is currently running.
Another possible solution could be to have the workflow explicitly update a database with its current status and any error messages. I'm leaning towards this solution but could use some expert advice.
TL;DR: I need to know the best way to query the execution status and any warning messages of a WCF Workflow service.
As you want to query workflow status and messages even after the workflow is finished I would start by creating a table where you can convert the correlation values a client send to the related workflow ID. I would create a custom activity to do that and drop it right after the receive that creates the workflow.
Next I would create a regular WCF service the client app uses to query the status. This WCF service can query the WF persistence store to see if a given workflow is still running. If so the active bookmarks column will tell you what SOAP messages the workflow is currently waiting for.
As far as messages go you can either use the AppFabric tracking infrastructure to store and retrieve them or you could create a custom activity and store them in your own database. It really depends if you are also interested in the standard WF tracking messages generated.
Update on cheking for running workflow instances:
There are several downsides to adding an IsRunning message to your workflow. For one you would need to make sure one branch keeps looping and waiting for the message but stops as soon as the other real workflow branch is done. Certainly possible but it complicates the workflow and is a possible source of errors. And as it is not part of the business problem it really has no place in the workflow as far as I am concerned. It also means that you will have to load a workflow from disk and persist it back just to tell you that it is there. If it was finished you will need to wait for a fault to indicate there was no workflow instance. And that usually means you get a timeout exception after, by default, 60 seconds. Add throttling to that and you request might be queued because there are too many other workflow instances or SOAP request being processed. So a timeout might mean that a workflow instance exists but is unreachable due to system constraints. Instead I would opt for the simple thing and check if the record in the instance store is still available. The additional info from the active bookmarks column will tell you what the workflow is waiting on, information I have used in the past to dynamically update the UI by enabling/disabling UI elements.
HelloA Windows Phone application need to connect to a server and get messages from it. This is done using WCF and long polling on the server. 3 minutes is the timeout defined on the server. Call from windows phone is done using HttpWebRequest.
The problem is that Windows Phone devices have a timeout of 60 seconds for get request (emulator have a different value, greater than 3 minutes).
Currently i can't decrease server timeout. Doing a new GetRequest after the 60 seconds doesn't get anymore messages.
Does anyone have an idea ?
Thanks
I don't think leaving a connection open is a good idea on mobile devices. I'm assuming that's what you're doing. In my app, I would just poll whenever needed by creating a new HttpWebRequest. But it made sense to do this in my app, because I would be updating train arrival status every 40 seconds.
If you're trying to pull data on a given schedule, put a timer in and just call the webserver every 3 minutes or whatever the requirement is.
If you want to be able to check things (when the app is closed) or if there's rarely fresh data on the server, then you'd need to implement a Push mechanism.
Update: Here's a good article on dealing with the timeout issue - http://blog.xyzzer.me/2011/03/10/real-time-client-server-communication-on-windows-phone-with-long-polling/
Update 2: What if you arranged it so that, you have cascading connections - what I mean is since you can't go beyond 60 seconds per connection, you can write a class that'll house two connections and once one of them is about to timeout, say several seconds before, you can start opening the other connection - you can pick the timing so that there's at most 5 seconds of overlap between them. This way you could have your always open connection.
Also see what these guys have done with the GChat app, they have their source code available at this link. This may provide a more proper design.
I am using Heroku to host a small app. It's running a screenscraper using Mechanize and Nokogiri for every search request, and this takes about 3 seconds to complete.
Does the screenscraper block anyone else who wants to access the app at that moment? In other words, is it in holding mode for only the current user or for everyone?
If you have only one heroku dyno, then yes it is the case that other users would have to wait in line.
Background jobs are for cases like yours where there is some heavy processing to be done. The process running rails doesn't do the hard work up-front, instead it triggers a background job to do it and responds quickly, freeing itself up to respond to other requests.
The data processed by the background job is viewed later - perhaps in a few requests time, or whenever the job is done, loaded in by javascript.
Definitely, because a dyno is single threaded if it's busy scrapping then other requests will be queued until the dyno is free or ultimately timed out if they hang for more than 30 seconds.
Anything that relies on an external service would be best run through a worker via DJ - even sending an email, so your controller puts the message into the queue and returns the user to a screen and then the mail is picked up by DJ and delivered so the user doesn't have to wait for the mailing process to complete.
Install the NewRelic gem to see what your queue length is doing
John.
If you're interested in a full service worker system we're looking for beta testers of our Heroku appstore app SimpleWorker.com. It's integrated tightly into Heroku and offers a number of advantages over DJ.
It's as simple as a few line of code to send your work off to our elastic worker cloud and you can take advantage of massive parallel processing because we do not limit the number of workers.
Shoot me a message if you're interested.
Chad