I am using swing and in my application i needed to run many threads in parallel like checking the internet connectivity after every 5 secs, monitoring the filesystem changes, sycing files from server.
All the time consuming tasks like above are running in SwingWorker so that my GUI should not freeze.
Same time i need to run some other time consuming tasks such as uploading file to server. for this purpose i also used swingWorker. and then i submit all these swingworker to executerService for thread pooling so that they should not effect each other.
My executer service is like this. i thought 30 threads will be enough for me.
static ExecutorService threadExecutor;
threadExecutor = Executors.newFixedThreadPool(30);
and then i submit threads in the same service.
threadExecutor.submit(monitorinternetconnectivity); //submitting swingworker obejct
Some of the threads i submit at the start and some i add runtime, when i add at runtime, it does not complete the job or stop running their job, like monitoring internet connectivity.
Is there any way to have the same functionality like swing worker, or some best way to use multiple swingworker. and we should be able to add new swingwokers at runtime to executer service
SwingWorker uses it's own ThreadPool.
SwingWorker should be used for a long running task after (i.e. anything that required more than a couple of milliseconds) after which a GUI update is required.
No calls to update gui elements outside the EDT should be done (i.e. from the SwingWorker.done() method)
If you generally follow the rules of accessing Swing components form inside the EDT (look here) then you shouldn't have a problem with locking. I suspect that the problem rather lies in your code but to be sure of that we should see it.
Related
Is it possible to create a multithreaded Java EE Glassfish container?
My intention is to create an application where users can capture data launch a social network, then each user would launch a new thread with the parameters he wants to retrieve information from the social network.
all these threads would be limited in number to avoid memory server.
As I can create multiple threads in java ee and that these once the user exits the application to remain running in the background until the user closes them?
One solution may be the job of glassfish?
Your question is pretty broad, but in general I understand you need to execute a thread for each user, which runs in background even when user stops using the application (logs out), does some repetitive task, and is terminated by user when required.
First, I would point out that this can be accomplished in cleaner way using timer service - you can schedule a periodical background job, which will do everyting you need. It can read the list of user and their tasks, perform them at a given interval. Then, a user may request to cance their tasks - they will remove their task from the list.
In this way, the number of users having the background task running would not be limited. They also can run sequentially in a single thread, but you may tweak that, see the rest of my answer.
More into on shceduling a timer in Java EE tutorial: https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples004.htm.
In case you really need a separate thread per user, there are several ways how to execute a thread separately from the request-handling thread. You might use asynchronous EJB method invocation, using #Asynchronous annotation. You may also inject ManagedExecutorService and use it to execute a Runnable asynchrnously using submit method. In both ways, you would not loose context and dependency injection will continue to work.
See more details about asynchronous eecution in Java EE tutorial about Concurrency utilities
You may also execute runnables asynchronously from a timer, but you may not need that, if you execute only a single task from within a timer handler, as timer handler will be executed when timer triggers in a new thread, if the previous handler did not complete yet.
is Eclipse 3.0 Jobs API using any internal thread pool for executing jobs?
or is it creating a new thread each time a job is scheduled (about to be started)?
if it doesn't use any thread pooling, is it somehow possible to use Jobs with Java's ExecutorService so that scheduled jobs will reuse existing threads from the Executor's pool?
if not then last question, is there a chance to provide progress feedback in the Eclipse progress view (as I'd do with Jobs IProgressMonitor) but from within a regular Java Thread?
I really like the features Jobs API provides (especially progress monitoring and cancellation) but I'm a bit concerned about the overhead it may introduce to the main UI thread if it doesn't use thread pooling and the jobs are scheduled really often.
thanks in advance!
regards,
jb.
Eclipse Jobs do use a fixed number of worker threads. Jobs are allocated to these worker threads, based on the priorities.
I cannot find any documentation stating that, but if you start your Eclipse instance in debug mode, you can see some worker threads in the thread list - these are the threads jobs are executed in.
Abstract Question
What is the best way to load resources into memory that will be shared across servlets in a Java application server?
What I am actually doing
I want to create a daemon thread that monitors a queue. This queue could have objects added to it from servlet threads. The thread would wait until a set period of time and check the queue to see if it had items in it, if so then it would process them and remove them. This thread would need to be started somewhere at sometime. I was thinking that a servlet with only the init method implemented would work for this task or is there a better place to put startup code like this in an application server? Am I approaching the problem all wonky?
Updates
I found this question and the accepted answer was to use the LifeCycle Listener. Is this a portable way of doing things or is my code going to be tied to a single application server. A bit more investigation led me to a find a few posts on message boards saying that I could do this in a ServletContextListener implementation.
I usually start these kinds of worker threads indirectly from a Servlet using the method you describe (usually they exist inside some other object that does the queue extraction and controls the processing).
For pulling objects off the thread, you don't need to do it based on time, you could have your thread wait() on the queue object and when an object is put onto the queue by some other thread, that thread would call notify() on the queue to release the watching 'worker' thread.
Google 'java worker thread wait notify' for many examples.
i have build a java clock with using timer,which works fine for a single task to alarm on next given/setted time, but i am having problem in scheduling multiple tasks(alarms for diff. times) with this timer, as two times can clash each other(same times for two different works) how to synchronize between such conditions, please help....
Thanks and Regards
Alok Sharma
I'm not sure what you're trying to do, but if you use quartz scheduler, you can resolve just about any scheduling/synchronisation task:
http://www.quartz-scheduler.org/
I agree with Lukas that you can use quartz. It is the best, scalable and robust solution.
But if you need something relatively small you can continue using timer based solution. As javadoc of Timer class indicates your tasks should take very few time. In this case you can forget about time clash. If your tasks take more then 0.1 seconds run them in separate thread. I mean use Timer as a trigger that just makes task to start in separate thread.
The thread may be done as following:
Create thread yourself. If you are in J2EE container it is bad practice. If you are in Tomcat it is ... not so bad.
Use thread pool. Comments about container are relevant here too.
Use JMS: Timer just pushes message to JMS. MDB or its equivalent receives message and performs task.
Using Timer itsef in J2EE container is a bad practice too. If you are there and wish to be "clean" use JCA to to run Timer.
I need to run some method in Swing application in separate thread. What is the difference between using SwingWorker and SwingUtilities.invokeLater. Which one should I use to run a thread in Swing application? I couldn't find exact info in the tutorial at
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html
SwingUtilities.invokeLater is used if you have something that must run in the EDT.
If you have a long-running task, you instead need to use a SwingWorker, since it does not run on the EDT and therefore does not cause the GUI to freeze while it runs.
It looks like you would want to:
use SwingWorker when you need to monitor the status of a long-running background process
use SwingUtilities.invokeLater if you just want a short task to run but do not need feedback on it. Sort of like a fire-and-forget. Just keep in mind it will run in the AWT event dispatching thread, so your application would not be getting any events handled while the task is running.