Bidding sites like quibids and ebay has a countdown showing how much time left for the auction. I know this can be taken care on FE and should be fairly easy. What I want to know is how to do this on server side? like sending an email to people participate but didn't win and updating database when times up. I've thought about two approaches to do this.
keep the timer on client side and do updates when the first request hit
open a new thread and make it sleep for x amount of time then wake up to do the updates.
Both approaches don't sound right to me and will lead to issues I think. Like user will likely not getting the updates on time, or server will have lots of sleeping beauty waiting.
What I want to know is how to do this on server side? like sending an
email to people participate but didn't win and updating database when
times up.
The best way may vary depending of technology stack of your server side.
You if are running from a Servlet container (e.g.: Tomcat, Jboss...), you
probably want to do something similar to this: Background timer task in JSP/Servlet web application
If you are running a Spring application (e.g.: Spring Boot or Spring MVC), then I recommend #Scheduled or other Task Execution and Scheduling
For advanced scenarios you may want to go with Quartz
Something else, then you should try hooking it up with Java Timer Task
To schedule a task, use a ScheduledExecutorService.
Related
I was reading about background service limitation in Android 8 and from what I read it seems that you can't run your service in the background for a long time. This seems reasonable but because I use background service to keep connection to server - currently pooling new stuff, sending location and responses I am a bit confused. The responses are OK, I can respond only when interacting with the app, but the pooling new stuff is problematic because it needs to get an stuff from server and if something new come present the user with a notification to respond to it.
If I understand it correctly I can use JobScheduler to schedule some job every several seconds. I can basically schedule the pooling. For the background locations, well there are those restrictions so only foreground service is an option to get updates in requested time.
I will be migrating to websockets and then the pooling is off, the connection to server will be persistent and the app will get updates from server, I was planing to do this in the background service so something would receive stuff from server everytime. However it seems I can't since Android 8. How would you solve this? Should I use foreground service for location and server connection? Or is there a better way to do background networking in an android app on android 8?
Thanks
Here are a few options for performing background work on Android O:
Use JobScheduler. You already seem to have a good grasp on this one- the downside is that it is periodic, not persistent.
Use GCM/FCM or a similar push service to push data to your app when it is relevant instead of constantly holding a connection to your server.
Use a foreground service. This will allow you to continue performing your background work without your app being in the foreground, but will put a notification in the status bar to inform your user that you are doing that work.
Before you select one of these methods, you should take a moment to step back and look at the data that you need from your server and determine why you need a persistent connection and whether the first or second options might be sufficient.
If you absolutely need a persistent connection to your server, the last option is your best option. The idea behind the changes in O is to still allow background work such as what you are describing, but to make it painfully obvious to the user that your app is doing so. That way if they don't think your data is as important as you do, they can take action.
I am using java(Servlets, JSPs) since 2 years for web application development. In those 2 years I never required to use multithreading(explicitly - as I know that servlet containers uses threading to serve same servlet to different requests) in any project.
But whenever I attend an interview for Web Developer position(java), then there are several questions related to threads in java. I know the basics of java threading so answering the questions is not a problem. But sometimes I get confused whether I am missing something while developing web application by not using mutithreading?
So my question is that what is the role of multithreading in Web Application? Any example where multithreading can be used in web application will be appreciated.
Thanks in advance.
Multi-threading can be used in Web Apps mainly when you are interested in asynchronous calls.
Consider for example you have a Web application that activates a user's state on a GSM network (e.g activate 4G plan) and sends a confirmatory SMS or email message at the end.
Knowing that the Web call would take several minutes - especially if the GSM network is stressed - it does not make sense to call it directly from the Web thread.
So basically, when a user clicks "Activate", the Server returns something like "Thanks for activating the 4G plan. Your plan will be activated in a few minutes and you will receive a confirmation SMS/email".
In that case, you server has to spawn a new thread, ideally using a thread pool, in an asynchronous manner, and immediately return a response to the user.
Workflow:
1- User clicks "Activate" button
2- Servlet receives request and activates a new "Activate 4G Plan" task in a thread pool.
3- Servlet immediately returns an HTML response to the user without waiting for the task to be finalized.
4- End of Http transaction
.
.
.
Asynchronously, the 4G plan gets activated later and the user gets notified through SMS or email, etc...
Speaking about a real-world example, there are several reasons to use multi-threading, and I wouldn't hire a web-developer who doesn't know about it. But in the end, the reasons to use multi-threading are the same for standard- and web-development: you either want something that take a while (aka blocking) done in the background to give the user some response in between, or you have a task that can be speed up by having it run on several cores. When multi-threading is actually useful is however a different question.
Situation 1: A web server that does require some processing and has low hits/second
Here multi-threading (if applicable to the algorithm) is a good thing, as idle cores are utilized and threading can result in a faster response to the user.
Situation 2: A web server that does require some processing and has high hits/second
Here multi-threading is possible, but as cores are usually busy with other requests, there are no resources left to use it properly. Actually spreading out the task to several threads can even have a negative impact on the response time, as the task is now fragmented and all parts need to complete, but the order of execution with threads is undefined. So one client could immediately receive a response, while others might wait into time-out till their last fragment eventually gets processed.
Situation 3: A web server has to do some processing that takes a very long time
Here multi-threading is required, there is no way around it. A client cannot wait minutes or probably hours till it receives the response. In this case a callback system is usually implemented, so basically each task has an "API" that can be queried for the current state. Most online-shops are an example for this: you order something and later you can query your order status.
The alternative to threading is process-forking, as Apache does in its standard configuration. The benefit is that load is spread across cores (mostly applicable to situation 2), and the web-code itself doesn't have to do anything to use all those cores, as the OS handles that automatically. However if you have imbalanced load, some cores can be idle and resources are not used in an optimal way. A threading situation is almost always the better solution, if it is done right. But the Apache/Tomcat standard configuration uses a very outdated threading model, by spawning one thread for each request. Effectively given a certain amount of hits/second, the CPU is more busy with threading than with actually processing those requests.
Well this is a nice question and I think most of the developers who work in web application development don't use multithreading explicitly.
The reason is quite obvious since you are using a application server to deploy your application, the application server internally manages a thread pool for incoming requests.
Then why use multithreading explicitly? What is need a web application developer expose himself to multithreading?
When you work on a large scale application where you have to server many request concurrently it is difficult to serve every kind of request synchronously because particular kind of request could have been doing a lot processing which could bring down the performance your application.
Lets take an example where a web application after serving particular kind of request has to notify users through email and SMS. Doing it synchronously with the request thread could bring down the performance of your web application. So here comes the role of mutlithreading.
In such cases it is advisable to develop a stand alone multithreaded application over the network which is responsible for sending email and SMS only.
Multi-treading in web application can be used when you are interested in parallel action, e.g., fetching data from multiple addresses.
As I understand, multi-threading is used in different situation from thread-pool, which can be used to handle requests from multiple clients.
I wrote a REST server application using Jersey, and I deployed on CloudBees. Since I have a free account the server will go to sleep after 2 hours of inactivity. Before this happens I would like to save data on a database; how could I detect the sleep event on the cloudbees server? Thanks for your answers!
Getting application to hibernate is a standard servlet container shutdown, so a ServletContextListener can handle this. Another option is for you to have a periodic Timer task to store data on DB, as application may also just crash for various reason, and you'd them have data lost
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.
We have a system where we set up the quartz thread count to 1, indicating 1 thread at a time. This works fine on our local servers and kicks of 1 thread at a time (trigger based on link from web ui),even though the user clicks the same trigger multiple times(the triggers are put in a queue).
However, we are migrating to a new cloud server and this trigger when clicked multiple times tends to click off multiple threads(without actually putting the eventual threads in queue).
We are using Tomcat6 and Java 6.There is no clustering/load balancing on the server. Any ideas/input would of great help.
Thank you
I've never used Quartz, but in Java you can use a thread pool with an ExecutorService. There are different executor services so you will need look at documentation and see which ones meets your needs. (Perhaps try newFixedThreadPool(int))