I am having a a method which listens continuously to a stream from a server and writes that data to datastore in google app which is later on retrieved by other methods.
How can i do that in google app engine i.e calling that method one time during the starting of app and having it running for unlimited time without affecting other things.
I am new to java world,So please help from that point of view also.How's that done in Java?
Specific for the google app engine you would use a task. However, on google app engine tasks are limited to 30 seconds execution time or anything that runs on appengine, like a http request. This means you are limited in running long running tasks.
See: http://code.google.com/appengine/docs/java/taskqueue/overview.html
Related
In Azure DevOps Pipeliens, when deploying an app to Functions, the app may restart during the process of the app.
Is there a way to monitor if the Functions app is running in the pipeline, make sure it's done, and then deploy the app?
Conditions
Functions runtime: Java
Trigger: Service Bus Trigger
I tried to check the lock status of Service Bus messages or the processing status of the Functions app with the Azure CLI, but it seems that there is no interface to check the processing status.
https://learn.microsoft.com/en-us/cli/azure/functionapp?view=azure-cli-latest
https://learn.microsoft.com/en-us/cli/azure/servicebus/queue?view=azure-cli-latest
You should never rely on that better build your functions to execute fast.
When Azure function sends signal to stop in c# we have CancellationToken this way we can have extra code to implement shutdown, otherwise as soon as AF get signal to stop it will not accept new events from service bus but will continue to execute current functions, and if they wont stop for some time they can be terminated (cant find exact time but will update answer )
I would also suggest you to utilise deployment slots this way you can minimise your downtime.
I've been studying App Engine for a work assignment which is to implement a chat service similar to Facebook's desktop page chatting. I had previously implemented something similar but since it ran on proprietary servers where there was no limit to traffic and technologies, I'm not sure that same implementation will work on App Engine.
Some things to notice:
This is for a web page/app. There is no specific messaging client application
App Engine doesn't support websockets
App Engine doesn't allow threads to outlive their requests (meaning I can't hold a background thread that awaits for new messages and pushes them to the user)
App Engine wants to service requests in a matter of seconds. I had thought of using long polling like facebook does but I'm not sure if this will be allowed
Is long polling every 30 seconds even an option? I'm afraid it massively increases my traffic costs...
I looked at XMPP but I think it doesn't really apply to web applications. Also I think I read somewhere in the docs that it is not/will not be supported anymore?
I'd like some advice on how I should go about this. I'm going to use Cloud Datastore for storage and I was hoping to implement this as a simple RESTful microservice to be honest but I'm not sure anymore.
You can merge goole app engine with google firebase to easily achieve a realtime chat application
you can access the realtime database on firebase using only javascript to update and display chats
I have my App which downloads & uploads data from/on the server (I have my WebApp written in Java & hence, used SOAP webservice for the communication between my Android App & Java Web App).
Up till now I've been using
AsyncTask
for calling WebServices to download/upload data.
So far so good with small amount of data being downloaded.
But when I download the large amount of data from the server the App crashes.
In reference with the android ref doc.
AsyncTasks should ideally be used for short operations (a few seconds at the most.) If you need to keep threads running for long periods of time, it is highly recommended you use the various APIs provided by the java.util.concurrent pacakge such as Executor, ThreadPoolExecutor and FutureTask.
So I think this is the problem with the AsyncTask being used for longer time interval.
Here is a similar old post
But I am not able to figure it out how to call web services using other threading techniques such as : Thread Pool Executor,Future Task or Executor
Below is my LogCat:
Hey, now there is one more problem . I have used IntentService for those long running Network operations (Downloading). Now As My data is big enough while downloading .Hence, in middle of downloading if internet connection is lost then I have to stop the IntentService which I think I can do using.
stopService(new Intent(MainActivity.this, IntentServiceClass .class));
which calls ,
onDestroy()
of the service. But the Code written in ,
onHandleIntent(Intent intent)
will keep on executing. (Which should not happen).
Any long task of this sort should use a android service. The basic problem is the application life-cycle in Android. Any activity and associated threads can be stopped by the operating system. A service by contrast runs background until it suspends or finishes or whatever.
Also good reliable ways to communicate status etc exist to communicate between services and activities.
For details on how to get the service and activity to communicate this question has a lot of very useful information
I have two threads, each of which handle syncing data one way either from the server or to the server. The thread for getting data off the server needs to run once a day. The other sending data to the server needs to run every 15 mins. I am currently using an Alarm Manager to create repeating alarms for each of these threads. This is then received by a BroadcastReceiver, from which i call an activity, which then according to the data passed into the activity either runs the to server syncing thread or the from server syncing thread. I am using the activity to display a dialog box, to prevent the user from using the application until the syncing has been completed as they both access the database required by the application. Is this the correct way to accomplish this task, or are there better alternatives?
Thank you in advance
This question is not really fit for SO... This is more a debate without any details on how your app works.
Anyway I would use an Android Service to do so. You do not need to bother the user just to upload data. Also why block the use of the app for uploading? Since for uploading you only need to read, just make a snapshot of the current data and upload it. Any changes the user is making right now will be uploaded in next upload, so that's not a problem.
For downloading, you most likely do need to block the app use, but maybe not. This depends on how the app works. You could start DB transactions to avoid doing that.
I am an experienced application developer who now has to develop a web application which I don't have a lot of experience in.
I am working on a project that has a number of distributed server components. It currently has a client application that monitors these components, view alarms and logs etc. The state of each of the server machines is delivered via a proprietary protocol over tcp/ip.
The current UI based app has a thread that continually monitors the socket connection for messages and once received stores in-memory the current state of everything and then displays this to the user.
My question is how do I achieve something similar in a web application environment. My first thought was to create a similar comms thread on server start and then when the user requests data the response is built up from the in-memory data but reading about web applications starting your own threads is bad practise.
I have read a little about using Quartz or TimerTask to run periodic schedule tasks in web applications but this task is more continuous. Is it still the way to go?
I'm developing the web app in Java using JSF running Tomcat on Linux. Oh and the application will have a low number of concurrent users. (25 max but more likely 2 or 3)
Approach 1
Using Quartz is good. It is advised not to use TimerTask.
Approach 2
I am assuming that the web application has some sort of database. Since you need to display the states on user request, not real time what you can do is that write a standalone daemon application (not a web application) which reads for server states and updates a table which is visible to the web application. When the user request is made this table can be referred to produce output.
Why make this a server concern? In your client (the browser) you can poll the current state and adjust the display according. Doing this removes a lot of complexity.
As to how your client will be updating, that's dependent on your app. If you can allow for only modern browsers, you could look into HTML5 WebSockets. Other options are using AJAX for partial update of the screen or a complete screen refresh.