We are using a cloud based system that after we have signed out found out that there are massive downtime windows a few times per year to the amount of 30+ hours of downtime to do an upgrade. We are a 24 hour service and cannot be down for that long.
The front end UI is also horrible functionally, visually and accessibility wise which led us to think of building our won front end UI. The idea being we would submit the requests to the system from a custom front end via API calls.
If the backend system goes down for an upgrade, I am trying to think of how we could sync the requests that come in throughout the outage into the front end. I could add something to sync all that haven't been sent, or have the backend platform look at the front end and create any objects that haven't been created.
Is there anything else that could be down to keep the systems in sync?
Any thoughts or ideas are appreciated.
Related
This question has been asked many times over the years, so apologies for trying again ... but maybe progress has occurred since the last time it was considered insoluble.
I have a web application on IIS 7.5 where users may interact for long periods of time. Occasionally, I need to do heavy maintenance lasting around ten minutes, and certain user requests during the maintenance would cause problems. I could, of course, pause the app using its admin features, and restart the website in IIS, killing all user sessions. Everyone would be forced to log in again, and those affected by the maintenance could be forced to wait until the maintenance was finished before they were allowed to log in again. But sometimes this would cause inconvenience to lots of users not affected by the maintenance. It would be great to be able to end just selective user sessions, only the ones affected. Is that possible with IIS? IIS is obviously capable of ending individual sessions when they time out, after N minutes of inactivity, and it would be great to have the ability to trigger that time-out selectively ahead of schedule when needed.
I can't even find a way to get a list of live sessions, much less selectively end them.
I have an application that needs to stay in sync with google drive. To that end, I'm using the Changes feed that is described on this page.
I know the idea is to poll the changes feed so that I don't have to request a list of files and do a comparison. Right now I have it set to query every 30 seconds, and initiate a sync operation when the latest change number is updated. But, to make the application feel a little more responsive, I would like to query API more frequently (but still initiate a sync only when necessary)
Given that, I was wondering if requests against the Changes feed count toward the API quota? I don't want to query more frequently if it's going to double my quota consumption rate.
It looks like requests to the changes API do count toward the quota. I found the Reports section in the cloud console. It gives a detailed breakdown of requests by user, location, method, and more. Looking through the methods, I found that drive.changes.list accounts for the majority of my usage.
It's unfortunate, but better than burning through the quota with multiple calls to get the status of every file.
In my windows phone 8 application, I would like to refresh/load some data periodically (less than 10 minutes) from server, while application running in background (ie, in dormant and tombstoned). I tried scheduled task agent and resource intensive task agent, but they are called at rate of 30 minutes gap. Please let me know is there any other solution for implementing the above said requirement.
Thanks and Regards
#nish
If you need to get data more frequently than the default available in Windows Phone, you should think about using push notifications. This won't be suitable for a full data push, but if you use it correctly, you can get a user experience that you can live with.
One common approach to this is to set up your server to send a notification to the device when there is something new to report instead of pushing a "nothing has changed" message every 10 minutes or so. If you push out a tile update notification to say, for example, "You have x unread items", the user may then click on the tile for your app and you can poll the server for new items on launch/resume. If you want a more intrusive option, you can send a toast notification as well, but in most cases the tile update will be sufficient.
This method has a few advantages.
You won't be burning through battery power polling every 10 minutes while the user is asleep
Your server will have significantly less load since it is not having to process full data requests every 10 minutes per client.
This fits in with the design philosophy of Phone apps - you are surfacing the required data to the user, while at the same time preserving battery life.
Do I understand correctly that your primary goal is to keep some host session alive by having the phone make a query periodically? If so...
I would not recommend this approach: 1) you cannot count on the phone having network connectivity when it tries to send its query. If the user puts the phone away in a pocket or purse, the odds worsen. 2) it's probably bad from a security perspective, and wasteful from a host resources perspective.
You might instead add logic to your app to resume a timed-out host session as seamlessly as possible. This would add real utility value to the mobile app value proposition over raw HTTP access to the same host.
I have a web app idea which will require AJAX requests to function. Its crucial that AJAX requests are running as long as the user is on the site.
My question is, if the user left the site up (my ajax requests will be running) for say 4/5 hours, will these AJAX requests still run, my concerns are screen dimming, screensavers, computer sleep states. Will all or none of these affect the performance of my web app?
Unfortunately, it's very client dependent. For example, mobile devices may stop processing JS when going into a sleep state (e.g., to save battery life). However, on an image rotator application I wrote some time ago, which sent regular requests to the server to retrieve images (there was good reason not to cache them, I swear), accessed primarily by non-mobile clients, I observed that requests continued for hours, even days. While I can't know if the client machine ever entered a sleep state, I'm pretty confident it did.
Long story short - I think you can't be sure, but for some target audiences, you can be reasonably sure. I would recommend investigating your audience.
If in your site users require to login simple keep a session time out option to lets say 15 mins. That means after 15 mins of idle time the session will be destroyed and the ajax requests automatically truncated.
If you do not have login this becomes difficult but still can be achieved via ip tracking or similar mechanisms but these will never be as full proof as the first one.
I must agree with Sean in that it it's very client side orientated. If the client stays active, be it through human interaction our not, then the AJAX should keep going.
We have an application that pulls in about 50 records from a database with about 13 data points for each record. Each record needs to be reviewed for accuracy, sometimes edited, and then 'approved' or 'rejected'.
It seems as if the process of running an approval or rejection takes some time before another approval or rejection can occur (yes this backend could be optimized).
Im looking for techniques or suggestions to make the front end of the application much quicker while the back end continues to process the previous approval or rejection. This would help speed our team of record reviewers go through each record.
Would a messaging service like RabbitMQ apply here?
All help, links, feedback is appreciated.
-=Vin
Tabbed browsing.