Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm attempting to build a Java Servlet task that has a runtime of about ~15-20 minutes that takes arguments from a HTML form. I have a couple of questions regarding this:
Will the task continue to run even after the user closes the browser? I Googled this and it seems the process will continue to execute even after browser close. I just want to confirm this.
While searching for the answer for the above question, I came across a post (or a couple of them) that stated that for such 'intensive' (I would consider mine intensive as it takes around 15-20 minutes to complete) tasks, it's better to have a separate program run the task than containing it in the servlet program. So, do I just execute another Java program from the servlet class?
And now for my final question, will multiple user requests be processed independent of each other? As in, will the servlet have a separate thread or instance for each request? If so, will my execution of another Java program from the servlet class lead to any problems?
There are a few items to discuss, each with their own (part of a) solution:
Do you really want the task to continue if the browser closes? Spawn a new thread for the task (Trying to write to the browser outputstream when browser is already closed will make the thread die in an exception) See Executor
Do you want concurrent requests to be handled in parallel? How many in parallel? See ThreadPoolExecutor
Do you want feedback to the browser (user) during the long running task? See Async servlets
The servlet container will make sure that parallel requests are handled concurrently, each in their own thread. But they will share the instance of the Servlet class. Therefore, you have to make your code thread safe.
About running a 'separate java program' or keeping the task in the servlet: it is best practice to separate different tasks in a program in different sections. Creating a new class for your long running task is better than keeping it in the servlet class. See Separation of concerns.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In an enterprise back-end Java application, I have a requirement where some part of code calls various API which are independent of each other. On receiving response, I am utilizing them and passing data to requester.
For this, I have implemented callable based multi-threading (using Executor). But a colleague is stating that implementing multi-threading would make my code responsible for managing resources and not the Web App Container which can lead to performance issues.
So I wanted to know, what is the impact of implementing multi-threading in my code? And how can I make sure that resources are managed properly without impacting overall application.
There are a some different aspectes mixed together in your question. Creating threads on an application server is not prohibited because it could cause performnce issues. It's more that the server itself is responsible to manage the system resources. Spawning own threads, of which the server is unaware of, can not be managed by the server. See this page for more info about the topic.
Using an thread-executor that is provided by the platform, is very valid an could be used to implement multi-threading nevertheless. See here for example.
Another aspect of multi-threading is indeed performance. Creating threads comes with a certain cost and creating too many of them may lead to an overhead in conext-switching. The trade-off between pralellism and having to manage a lot of threads has to be consireded by the developer. Again this is why application servers, manage their own thread-pools.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
The target computers have either MySQL or SQL Server running on.
We get JDBC drivers for MySQL and SQL Server in our project.
When the users start the application they select which of the 2 databases to use.
One thread handles the GUI CRUD buttons and another handles the CRUD logic.
We get everything into .jar file(including the JDBC drivers) and convert it to .exe to be executed on the target computers.
Is this plan correct or it doesn't work this way?
Just include both the drivers, that's totally ok. As long as you only load one there definitely won't be any problems.
You may implement a simple detection of the databases at their standard paths / check if it is already running on the default port. If there's only one database avaiable, just work with that.
If you use Swing, there's the SwingWorker class to encapsulate (long running) CRUD operations. The gui is managed by the main thread / EDT, there's no need to exactly create 2 threads, if you're doing it right. (Although internally there will be multiple threads, but I'm talking about explicit Thread creation here.) Otherwise you would produce them busy wait scenario which could be really cpu consuming.
You can produce runnable jar files, which can be double clicked and executed on most systems, there's no need to convert it to exe-files.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I read lot of blogs and articles that ask to take care while coding for synchronization. They ask to use concurrentHashMap, synchronizedList etc.
As per my understanding, in java web application, Application server (e.g. jboss, weblogic, tomcat), every request run under a separate thread.
e.g. I have sequence of method execution method1--> method2--> method3, then every request will have its own execution stack. Then why do we need to think more about synchronization?
Either my understanding about concurrent request is not correct or I am missing something about synchronization scenarios.
Please advise.
Because in most applications, processing a request involves accessing some shared data that may also be accessed by other threads handling other requests at the same time.
HTTP sessions are a prime example: all requests in the same session share the same HttpSession object, so if a browser sends two requests at the same time, the two threads handling those requests may try to access the same HttpSession object at the same time. You need synchronization to avoid corrupting the session.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
Is it possible to send a Java thread instance in an HTTP request?
No. A Java thread cannot be serialized, and therefore it cannot be sent outside of the JVM in which it was originally created.
(For a moment, just imagine what would be involved in moving a thread from one JVM to another. What about the static variables it might refer to? What about the other threads that it might to interact with? The problem is intractable.)
Actually I am working on clustered servers and want to execute my some threads(defined Jobs and other heavy task) on one server(called it back office node). So is there any way to do that.
OK, so that's a different problem. You actually need to execute tasks remotely, not pass threads. ('Cos you can't pass threads.)
Yes, there are many ways to send tasks to be executed elsewhere ... in the general sense. What you need to do is to express the task or task description in a form that can be serialized in some way (Java Object serialization, JSON, XML, etcetera) and then pass the serial form to the server that is going to execute it. The server would be responsible for managing the thread that does the execution.
Caveat: This is not going to work well if the task is needs to refer to a whole lot of data / objects on the machine where you formulated the task. That is going to involve serializing / passing all of the data OR figuring out some way for the backend to "call back" to get the specific data items that a task needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Assuming that launching threads from a servlet is something not recommended, I'd like to know what can make this thread, created and launched from a servlet, to stop unexpectedly.
For example, reuse of the servlet thread can cause the child thread to be destroyed?.
I need clear arguments showing that the life of a thread from a servlet generated is not assured to the end, or reasoning to support otherwise.
I do not want a discussion, I want clear and definitive examples.
Threads created from a servlet will not be terminated by the container (as long as the container is running), because of two reasons:
The container does not have references to the threads created inside the servlets, therefore it cannot invoke e.g. Thread.stop() on them (Yes, this is a deprecated method and definitely not a good way of terminating threads, more details).
Only the thread itself can know how to properly unlock the monitors that it has locked so forcing a thread termination will result in inconsistent state of the monitors.
Notes:
This behavior is not covered by the Servlet specification so there is no guarantee how it will work on your web container.
Servlets should not be spawning threads as this is the resource managed by the web container.