java.lang.IllegalMonitorStateException

Hvor bliver isFinished sat ?

i slutningen af Job´s run

Det virker temmelig underligt. IllegalMonitorStateException smides sædvanligvis som følge af manglende synkronisering ved brug af wait eller notify, og i dette tilfælde er metoden synkroniseret på this, som wait kaldes på. Det ser ud som om den brokker sig over, er at der mangler synkronisering ved kald af wait, men det gør der ikke...

En løsning kunne måske være at kigge lidt på alternative og måske mere afprøvede design-mønstre; det virker umiddelbart underligt at jobbet har behov for en status der indikerer at jobbet er færdiggjort, men nu kender jeg heller ikke systemets dybere virkemåde.

Selv har jeg arbejdet meget med servere og førhen anvendt pool-mønstre (designmåden kan varieres). Efterhånden er jeg så småt gået væk fra at anvende worker-pools, da det ofte er ineffektivt, så længe resten af serveren er designet rigtigt, f.eks. event-baseret. Hvis du er interesseret, kan jeg give nogle forslag til designmåder, men så må jeg vide lidt mere om systemet, f.eks. I/O; anvender du java.nio.*?

Ud fra den viste kode er der ikke meget at komme efter, det ser ud som det skal synes jeg...

well.

grunden til workerthread er flere workers skal deles om arbejdet, de fleste opgaver er simple sql statements en worker fint kan klare alene, men engang imellem kommer der en tung en, og der kommer de flere workers ind, så de korte opgaver stadig udføres.

min klient laver et job, og kalder derefter getResult() getResult venter til isFinished er true, og sender så resultatet tilbage

Det der giver mest mening er at have en worker pr. tilgængelig database-forbindelse, og udover det kun have nok tråde til at servicere klienterne, altså læse fra netværksforbindelserne, udføre arbejde forbundet med modtaget data (lige pånær database-arbejde), og skrive data tilbage til klienterne. Men newer mind, det er ikke dit problem.

Din klient laver et job; har du en eller to tråde pr. klient? I stedet for at at kalde getResult() efter klienten har lavet et job (og lade tråden vente og spilde sin tid), vil det være bedre at have en callback-metode på Job, som kan workeren kan kalde, når database-kaldet er udført. På denne måde sparer du også ventemekanismen, der giver problemet.

Hver worker har en forbindelse, men til samme database ?

prøver med callback lidt senere :)

Hvis vi skal finde ud af hvad der er galt i den eksisterende kode, så
må vi se noget mere kode.

Der er ikke imiddelbart noget galt.

Følgende eksempel ligner dit i logok (og det kører fint):

package worker;

public interface Job {
    public void execute();
}

package worker;

public class TestJob implements Job {
    private int v;
    private String lst[];
    public TestJob(int v, String[] lst) {
        this.v = v;
        this.lst = lst;
    }
    public void execute() {
        lst[v] = Thread.currentThread().getName();
    }
}

package worker;

import java.util.*;

public class Queue {
    private LinkedList q;
    public Queue() {
        q = new LinkedList();   
    }
    public synchronized void enqueue(Job j) {
        q.addLast(j);
        notifyAll();
    }
    public synchronized Job dequeue() throws InterruptedException {
        while(q.isEmpty()) {
            wait();
        }
        return (Job)q.removeFirst();
    }
    public synchronized boolean isDone() {
        return q.isEmpty();
    }
}

package worker;

public class Worker extends Thread {
    private Queue q;
    public Worker(Queue q) {
        this.q = q;
    }
    public void run() {
        boolean done = false;
        while(!done) {
            try {
                q.dequeue().execute();
            } catch (InterruptedException e) {
                done = true;
            }
        }
    }
}

package worker;

public class WorkerPool {
    private Worker[] wrk;
    public WorkerPool(int n, Queue q) {
        wrk = new Worker[n];
        for(int i = 0; i < wrk.length; i++) {
            wrk[i] = new Worker(q);
            wrk[i].start();
        }
    }
    public void killAll() {
        for(int i = 0; i < wrk.length; i++) {
            wrk[i].interrupt();
        }
    }
}

package worker;

import java.io.*;

public class Test {
    private final static int N = 10000;
    public static void main(String[] args) throws Exception {
        String[] t = new String[N];
        Queue q = new Queue();
        WorkerPool pool = new WorkerPool(100, q);
        for(int i = 0; i < N; i++) {
            q.enqueue(new TestJob(i, t));
        }
        while(!q.isDone()) {
            Thread.sleep(10);
        }
        pool.killAll();
        PrintWriter pw = new PrintWriter(new FileOutputStream("C:\\t.lis"));
        for(int i = 0; i < t.length; i++) {
            pw.println(t[i]);
        }
        pw.close();
    }
}

Har ladt Job indeholde mit id og et client objekt.

så worker kalder job.getowner().jobdone(job) når et job er færdigt
det virker, selvom job nok har lidt for mange info :)

Det er meget normalt at et objekt Job indeholder nogle info, sådan er det. Derimod er det meget mere værd, hvis man kan undgå at tråde venter på at nogle betingelser bliver opfyldt, men i stedet kan lave noget andet i mellemtiden. Husk at det klient-objekt Job-instancerne får med ikke er et objekt, men en  reference til et objekt. Måske har du forøget en Job-instans' størrelse med 4-8 bytes, og det er virkelig ikke alverden.

Job repræsenterer jo en event i din server, som ændrer tilstand undervejs, hvilket betyder at nogle data må ændre værdier. Desuden er det pænt design, at Job indeholder alle de oplysninger der skal til for at jobbet kan fuldføres.

Og ja, det kan ofte være effektivt at mere end én forbindelse til samme database. Når du udfører et SQL-kald fra din Java-server til en database (f.eks. en query), hentes alle data i det returnerede ResultSet ikke med det samme, men løbende, efterhånden som ResultSet.next() kaldes. Det gør at flere forbindelser til samme database med fordel kan udnyttes. Husk at forbindelsen til databaser i Java er realiseret med en Socket, der somme tider vil være blokkeret i en eller anden I/O operation, imens har serveren mulighed for at kommunikere med databasen gennem andre forbindelser. Derved opnås bedre performance i forbindelse med database-kommunikationen.