Maybe I didn't explain this correctly. We start up multiple threads when our web application starts up to process some things. These threads periodically wake up check for work and process, they won't die unless we tell them to stop. So the thread hasn't died or been garbage collected. The collection of threads is a static variable. We want to iterate through the collection of threads to get some information from an object in the thread. Hopefully this helps.
BTW Thanks for the complement or kick in the shorts... "You really belong in the Java in General (beginner) forum." Tom
you are saying and putting that object in the collection. It is really ambigious what you wanted to do. Because, by now, thread starts executing the run method. and you are keeping that object and passing some where.
If we look into the for loop where you wanted to access your thread object,
How do you get Object obj = element...? here element is Thread object and which is already executing the run method. I am not sure what you wanted to do here.
Can you explain a bit more? and I dont think this is good way of doing as well.
First, look into working with Runnables instead of Threads. You aren't writing new kinds of Threads, but new kinds of Tasks that can be run on Threads.
If you wait for them all to finish, join is a good technique:
If you don't wait for the Thread to finish, how do you know when to inquire? The result might not be ready yet, right? Can we replace polling with event publishing? I'd rather have the Runnables tell me when something interesting happens.
If you have more tasks than you can run at once, you could replace new Thread with Executor.add pretty easily.
BTW: It does no harm at all to look at a Thread or Runnable after it is done. It's a perfectly valid object as long as you have a reference to it, though the Thread will have an interesting ThreadState.
Any of that help?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
He's putting the Thread object into the collection. He assumes the
is still part of the Thread object. No way.
When the code exits the run() method, this obj no longer has a live reference and is eligible for gc.
There is a basic misunderstanding here.
As far as referencing a Thread object after it has exited the run method: While it is true that as long as he holds a reference to the thread in the collection it won't be gc'ed, this is not professional. Actually, its quite awful.
We start multiple threads to communicate with machines over sockets from our web application. This done via ContextListener. These threads process then sleep and repeat. We have a collection of threads. Now I added a collection of these objects to check their status. We also need to dynamically create new threads as more machines want to communicate with our web application as well as stop threads.
What would be a better way to accomplishing this? I am open to any suggestions.
I've only skimmed this topic, but if you're using JDK 5 or later, you should probably look into how to use the java.util.concurrent.Future interface (along with things like ExecutorService). The Future interface lets you combine (a) a run() method describing what you want a thread to do, plus (b) a get() method that lets you retrieve the result. You shouldn't need to iterate the Threads themselves - and after all, Thread doesn't have an existing method to retrieve your result anyway. There are various other ways you can accomplish this prior to JDK 5, but if you've got JDK 5 then using Future is probably the best way, and much of the owrk is already done for you.
What are some ways to do this with 1.4? We are currently on Websphere 5. Although we should be on Websphere 6 by 3-6 months. So I maybe able to use the Future interface in our next release. Thanks, Tom
Originally posted by Edward Harned: As far as referencing a Thread object after it has exited the run method: While it is true that as long as he holds a reference to the thread in the collection it won't be gc'ed, this is not professional. Actually, its quite awful.
This puts it rather too strongly, I feel ... though not as much too strongly as your earlier post.
A Thread object is not an OS thread. So holding on to a reference to a Thread object, after the OS thread has finished running, is no mortal sin. At worst, it might be a little bit wasteful.
However, I would agree with previous posters, who said that storing task end-state in a subclass of Thread is generally not the best approach. Writing your task as a class implementing Runnable is better. Put the task end-state in that class, and use plain Thread objects.
Or, even better, avoid ever dirtying your hands with actual Thread objects, by using concurrency utilities, thread pools etc.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
[Tom Henricksen:] What would be a better way to accomplishing this? I am open to any suggestions.
I realize the fundamental misunderstanding here, and a lot of posters will argue effectively for some contemporary tools and design suites, but in order to have an object do something you have to trap the thread in a do or while and if you do that, you get a virtual flock of ravin Ravens all over the place. Thread Pool management really belongs in jvm and implementation code, not in userland. Grudgingly, I agree with PC: Or, even better, avoid ever dirtying your hands with actual Thread objects, by using concurrency utilities, thread pools etc., but that's if concurrency utilities are available in whatever implementation you are using.
Write your data object as you would normally write in java, put a run() method in it and have that run method do whatever work it is that you need to have done to get the object in a state that is useable. Keep a ref to it in ( possibly ) some sort of collection and iterate to get useable data. Call run as described in Thread.java, not in any other way than that described in Thread.java -> otherwise use some fancy tool. EE has plenty of fancy tools and you would be able to find something there that works.
JavaTM 2 Platform Enterprise Edition, v 1.4 has ServletContextListener as being an interface, reading farther, it becomes apparent that the event comes in as a ServletContextEvent, what that means is that you do not use Threads, as you are understanding them and trying, somewhat valliantly in the face of Crocodile Alley, to implement them. The Thread, as you are calling it, comes in as getServletContext(), which then proceeds ( after a few links ) to ServletResponse, which is described in Marty Hall's book rather effectively.
Java Server Pages, if you read Marty Hall's book, will do what you are trying to do without getting into messes like Peter Chase's citation of Edward Harned and ensuing discussions.
Don't try to implement run() methods, nor do as I say at the outset of this post, just write some jsp, and let the jsp and server do the threading. There are init() methods in jsp that will allow you to do the setup and placing of data objects as you need them.
What, in general terms, do you need to access in the iterator ?