Thread beendet sich "einfach so"?

  • Themenstarter Themenstarter tuxedo
  • Beginndatum Beginndatum
Status
Nicht offen für weitere Antworten.
T

tuxedo

Gast
Hallo zusammen,

ich hab hier ne Klasse mit der ich kleine Tasks in eine Liste Stecke und die von einem Thread sequentiell abgearbeitet wird.

Java:
import java.util.ArrayList;
import java.util.List;

import foundation.logging.Logger;

public class TaskProcessor extends Thread {
    
    private static Logger mLogger = Logger.getLogger(TaskProcessor.class);
    // instantiates the taskprocessor on class-load via classloader
    private static final TaskProcessor processor  = new TaskProcessor(); 
    // the list with tasks that have to be executed asynchronously
    private static List<Task> taskList = new ArrayList<Task>(); 
    
    /**
     * Starts the TaskProcessor
     * 
     */
    private TaskProcessor()
    {
        setName("TaskProcessor");
        setDaemon(true);
        start();
    }
    
    /**
     * @see java.lang.Thread#run()
     */
    @Override
    public void run ()
    {
        mLogger.info("TaskProcessor running ...");
        while (true) { // this is a daemon thread, so it ends when JVM terminates...
            if (taskList.isEmpty()) {
                synchronized (taskList)
                {
                    try
                    {
                        taskList.wait(1000);
                    }
                    catch (InterruptedException anException)
                    {
                        // nothing to do
                    }
                }
            } else {
                Task first = taskList.remove(0);
                mLogger.trace("Calling task [",first.getTaskName(),"]");
                long start = System.currentTimeMillis();
                try {
                    first.run();
                } catch (Exception e) {
                    StringBuffer sb = new StringBuffer();
                    StackTraceElement[] stackTrace = e.getStackTrace();
                    for (int i=0; i<stackTrace.length; i++){
                        sb.append("\tat ");
                        sb.append(stackTrace[i].getClassName());
                        sb.append(".");
                        sb.append(stackTrace[i].getMethodName());
                        sb.append("(");
                        sb.append(stackTrace[i].getFileName());
                        sb.append(":");
                        sb.append(stackTrace[i].getLineNumber());
                        sb.append(")\n");
                    }
                    mLogger.error("Exception occured while running task [",first.getTaskName(),"] on "+
"TaskProcessor:   class: ",e.getClass()," msg: ",e.getMessage(),"\n",sb.toString());
                }
                long end = System.currentTimeMillis();
                mLogger.trace("task [",first.getTaskName(),"] done. duration=",(end-start)," ms.");
            }
        }
//        taskList.clear();
//        mLogger.info("TaskProcessor shutting down ...");
    }
    
    
    
    
    
    /**
     * Executes a given {@link Runnable} in the taskprocessor
     * 
     * @param runnable the runnable to execute asynchronously
     * @param name a name that is used to track the duration in the logs
     */
    public static void execute(Runnable runnable, String name) {
        
        mLogger.trace("execute(): enqueuing task [",name,"] ...");
        synchronized (taskList)
        {
            taskList.add(new Task(runnable, name));
            taskList.notify();
        }
        mLogger.trace("execute(): enqueuing task [",name,"] ... *DONE* ");
        
    }
    

}

Ich nutze die Klasse hauptsächlich um Events zu entkoppeln: Ein Event wird ausgelöst, im Eventhandler gefangen und eine entsprechende Aktion getriggert. Diese Aktion soll aber nicht aus dem Thread heraus gestartet werden die das Event getriggert hat. Und um das zu entkoppeln benutze ich obige Klasse.

Prinzipiell funktioniert das prima. Aber im Dauertest versagt das ganze:

Die Anwendung läuft das ganze Wochenende über. Pro 30sek werden in etwa 8-16 Events bzw. Tasks mit dieser Klasse "verarbeitet". Also nicht wirklich viel.
Aus bisher ungeklärten Gründen beendet sich der TaskProcessor Thread "einfach so", ohne Exception, ohne Fehler ???:L Und das ist natürlich verheerend. Denn unter anderem müssen auf viele Events Aufräumarbeiten ausgeführt werden die Threadpools abräumen, Netzwerkverbindungen schließen etc. etc... Ohne den TaskProcessor stirbt die Anwendung recht schnell. ;(

Ich könnte nun anfangen am Code rumzuschrauben und mit try&error den Fehler suchen. Aber ich will das Problem vorher in kleinerem Rahmen reproduzieren damit ich weiß wo's klemmt. Andernfalls muss ich immer >8h warten bis der Fehler in der Anwendung auftritt.

Also hab ich eine Test-Klasse gebastelt die 500 Threads erzeugt. Jeder Thread fügt 100 Tasks dem ThreadProcessor hinzu. Mit genug Heap läuft das Problemlos. Keine Exception, nix. Läuft prima. Kein Fehler.

Da ich das entfernen von Tasks aus der Liste nicht synchronisiert habe, hätte ich erwartet dass meine Testklasse eine "ConcurrentModificationException" hervorbringt. Aber nix dergleichen. Läuft problemlos.

Hier mal noch die Testklasse:

Java:
public class TaskProcessorStressTest
{
    
    public static void main (String[] args) throws InterruptedException
    {
        Thread.sleep(10000); // time needed to attach jconsole
        
        System.out.println("Start");
        
        final int threadCount = 500;
        final int taskCount = 100;
        
        Thread[] threads = new Thread[threadCount];

        // simple "final counter" class
        class Count {
            public volatile int i = 0;
        }
        final Count counter = new Count();
        
        for (int t=0; t<threadCount;t++) {
            
            final int tt = t;
            
            threads[t] = new  Thread() {
                /**
                 * @see java.lang.Thread#run()
                 */
                @Override
                public void run ()
                {
                    for(int i=0; i<taskCount; i++){
                        final int num = i;
                        TaskProcessor.execute(new Runnable(){
                            
                            @Override
                            public void run ()
                            {
                                System.out.println("Doing something#"+num+" on "+Thread.currentThread().getName());
                                counter.i++;
                            }
                            
                        }, "Runnable#"+i);
                        
                        
                    }
                    
                    System.out.println("Worker#"+tt+" terminated");
                    
                }
            };
        }
        
        for (int t=0; t<threadCount;t++) {
            
            threads[t].setName("Worker#"+t);
            threads[t].start();
        }
        
        
        Thread.sleep(120000); // waiting for completion
        System.err.println("total: "+counter.i); // should be taskCount*threadCount ...
    }

}

Ich hab das Gefühl ich seh den Wald vor lauter Bäumen nicht mehr. Sieht jemand spontan nen Fehler? Oder hat jemand die Muse ne Testklasse zu basteln mit der das Problem reproduzierbar ist?

Gruß
Alex
 
Zuletzt bearbeitet von einem Moderator:
Spontan nicht direkt, aber bei
} catch (Exception e) {
werden nur Exceptions gefangen, und nicht etwa Errors (wie z.B. ein OutOfMemoryError - was bei einer so lange laufenden Anwendung ja selbst mit einem kleinen Speicherleckchen leicht mal passieren kann). Man würde dann zwar auf der Konsole was sehen, aber vielleicht wäre ein
} catch (Throwable e) {
in diesem Sinne "sicherer"....
 
Ja, das hat mir ein Kollege auch schon gesagt. Werd' ich für den nächsten "über nacht test" aber einbauen. Auf der Console hab ich bis jetzt aber nix gesehen. Leider.


Bin also weiter am Rätsel-Raten ...

- Alex
 
Warum benutzt du eigentlich ne Arraylist und synchronized die selber? Wäre ein Vector, bzw die Conncourentirgetwaslisten nicht praktischer? Weil die Java-Doc sagt das die ConcourencyExceptions nicht immer auftreten und man sich in keinem Fall auf sie verlassen soll.

Andere idee wäre noch das setDaemon, kann es evtl sein das unter bestimmten umständen einfach kein anderer Thread außer Daemons läuft? das würde das Verhalten auch gut erklären.
 
Dass der Code nicht "perfekt" ist weiß ich schon. Bzgl. der Liste werde ich da auch nochmal was ändern. Aber vielmehr fuchst es mich dass ich das Problem nicht reproduziert krieg ...

setDaemon ist nicht das Problem. Hab noch zwei dutzend anderer Threads (RMI, SWT, diverse Threadpools, ...) die nach wie vor laufen. Nur dieser eine Thread beendet sich "einfach so".

- Alex
 
So, nochmal alle antworten durchgelesen ....


Warum benutzt du eigentlich ne Arraylist und synchronized die selber? Wäre ein Vector, bzw die Conncourentirgetwaslisten nicht praktischer?

Wenn ich ein "notify()" machen möchte dann brauch ich einen synchronized block. Da hilft mir eine bereits Synchronisierte LIste oder ein Vektor wenig.

Weil die Java-Doc sagt das die ConcourencyExceptions nicht immer auftreten und man sich in keinem Fall auf sie verlassen soll.

Das ist ja interessant und könnte auch das Verhalten erklären. Das Einfügen in die Liste ist ja synchronisiert. Das Herausholen aber nicht. Erwartet hätte ich hier in meinem Test eine Exception wenns da Probleme gibt. Wenn aber nicht sichergestellt ist dass eine ConcurrentModificationException auftritt, dann ist das wohl des Rätsels Lösung.

Geändert hätte ich die Stelle mittlerweile so oder so. Aber beweisen konnte ich's eben nicht (und kann ich auch jetzt noch nicht...).

Werde meinen Test mit der verbesserten Synchronisation nochmal laufen lassen und auch die JavaDoc nochmal durchforsten.

Weitere Ideen sind natürlich willkommen.
 
Ja, ist schwierig - jetzt auf "gut Glück" irgendwelche Umstrukturierungen zu machen, in der Hoffnung, dass der Fehler dann weggeht, ist auch ungünstig (das kann ja OK sein 😀 aber nicht wenn es 36 Stunden dauert, bis man vermuten kann (!) dass er weg ist ...).

Vielleicht solltest du trotzdem bei der "InterruptedException anException" noch was auf der Konsole ausgeben - schon aus Prinzip. Eigentlich sollte da wohl sowas stehen wie
Code:
catch (InterruptedException anException)
{
    Thread.currentThread().interrupt();
}

Aber wenn du etwas umbauen willst: Diese Funktionalität mit der Taskliste (also dieses Klassische Producer-Consumer-Ding) ist mit BlockingQueue (Java 2 Platform SE 5.0) eigentlich sehr schön abgebildet... kannst du ja mal in Erwägung ziehen...
 
Das hatte Empire Pheonix aber mit "Conncourentirgetwaslisten" schon angedeutet 😀

Angedeutet ... Ja. Mir ist da aber nur Collections.synchronizedList() eingefallen. Aber wie ich schon erwähnt hatte, hätte das nix gebracht.

Die BlockingQueue kannte ich bis dato noch nicht.
 
Mit der BlockingQueue scheint's nun reibungsfrei zu funktionieren. Das System hat den overnight Test überlebt.
 
Eigentlich sollte da wohl sowas stehen wie
Code:
catch (InterruptedException anException)
{
    Thread.currentThread().interrupt();
}
Wenn Du das ohne [c]break;[/c] da stehen lässt, führt's zu ziemlich hoher CPU-Last, wenn der Thread einmal interrupted wurde. ;-)

Ebenius
 
Den Codeteil konnte ich nun mit der BlockingQueue komplett entsorgen 🙂

Die blockiert selbst beim aurrufen von "take()" wenn noch nix in der Liste ist...

- Alex
 
Wie verhält sich denn die Queue, wenn der Thread interrupted wird, während die Queue blockiert? Wirft die auch eine Exception? Wenn ja, musst Du das Problem natürlich genauso beachten. Wenn nicht, was macht sie dann?

Ebenius
 
Status
Nicht offen für weitere Antworten.

Neue Themen


Zurück
Oben