1 2 Previous Next 18 Replies Latest reply on Feb 22, 2008 1:15 AM by 800351 Go to original post
      • 15. Re: Spawn Thread should be kept alive indefinitely
        I might be reinventing the wheel, but it is working.
        I do not know if the Executors.newFixedThreadPool(1) can make my code simpler, I have to investigate how it works.

        Common request in the first thread:

        try {    
        catch (RemoteException e) {
             SingletonThread.getInstance().serialize(_iNFOFile, impl, inputMessageRequest.getHeaderInfo().getClaimNumber());      //


        public class SingletonThread extends Thread{
             private static SingletonThread instance;
             public synchronized static MidasSingletonThread getInstance(){
                  if(instance == null){
                       instance = new MidasSingletonThread();
                       // initialize other variables
                  return instance;
             private MidasSingletonThread() {

             public void run() {     
                       deserialize(); //the files in directory
                       }catch(Exception e){
             public void serialize(....){          
             public void deserialize(){
                  //desirialize and FTP the file, if succesful, delete it
             public boolean sendByFTP(Object _iNFOFile, String filename){
             public void deleteFile(String filename){

        Thanks for your support.

        Edited by: pbasil on Feb 21, 2008 5:45 AM
        • 16. Re: Spawn Thread should be kept alive indefinitely
          pbasil wrote:
          If the Singleton is useless, what is the right approach to have an instance of the thread and just one that is
          always working?
          One's thought is not always right but I think I finally see your app level requirement which you have provided only very scarce description.

          And the solution for that might be:
          Start a resumer thread, or a daemon, which is not needed to be a singleton but practically only one instance runs throughout your whole app lifetime. The resumer thread runs an infinite loop in its run() method picking up file from a queue and doing FTP send task for the file. The resumer thread does wait() when the queue is empty. App main thread, your thread A, simply puts file which does need FTP resuming onto the queue and notifies the resumer thread in the place of the code where you previously called thread's run() and serialize() method(in the reply #3 code).
          • 17. Re: Spawn Thread should be kept alive indefinitely
            Yes, sorry, I didn't make myself clear at the beginning.

            I don�t seem to understand how both threads in your description can communicate.

            Let me explain the scenario I am facing:
            I am running on a web service enabling layer, so many incoming requests from outside
            send me information via SOAP that I should forward as a text file over FTP.

            If the FTP server is down, I have to provide a contingency plan. Thus I serialize files in a directory
            and try to FTP them later on (waiting 30 minutes for instance).

            That is why I came out with the idea of a Singleton Thread (static) I can call from any thread request.
            Therefore Thread A, B, C, that are all those requests I receive, should communicate with the Singleton thread.
            I use A (the first of all incoming requests) to instantiate the Singleton.
            The next ones just check whether it is running and request the single instance JUST in case the FTP server
            is down and they have to serialize the file that failed.

            I hope it clarifies the requirements I need to implement, many thanks.

            PS. Someone mentioned Executors.newFixedThreadPool(1), however I am running on JDK 1.4 and not 1.5,
            I think java.util.concurrent is not available until 1.5
            • 18. Re: Spawn Thread should be kept alive indefinitely
              how both threads in your description can communicate
              Well, thread A, B, C et al put the file onto the singleton queue, no, a single instance of a queue should suffice, and noify() your FtpLater thread which was doing wait() while the queue was empty. The FtpLater thread is a single instance of a thread, not needed to be a singleton.
              1 2 Previous Next