Hallå.

Jag sitter och filar på en arkitektur för ett "batch-köringssystem". Det är helt enkelt ett system där man kan lägga in små kodsnuttar (Adapters) som skall aktiveras vid olika premiser (AdaptersActivators).

Man skall typ kunna välja AdapterActivators som aktiveras på specifkt klockslag, med jämna intervaller, om en fil ändras, osv osv...

Först hade jag tänkt att lägga varje AdaptersActivator i en egen tråd och när dessa Activators uppnår sitt kritera skulle de signalerar att det var dags att köra Adaptern som då skulle köra sin kodsnutt. Sedan skulle Activatorn börja om på nytt.

Det lät ju jättesmart och enkelt, till jag började tänka på hur många Activators som man skulle kunna hantera och hur många trådar det skulle innebära för applikationen att hålla reda på. Så nu funderar jag på om det finns något smart sätt att samla upp dessa olika activators och få dem att fungerar även om de inte ligger i sin egen tråd.

Man skulle ju kunna ha en tråd som kontrollera ALLA Activators som skall exekvera på ett specifiktklockslag om detta klockslag har uppnåts. Helt enkelt en lista som man travserar sig igenom varje sekund/minut för att se om just denna activators har detta klockslag som sitt kritera.

Nytt liknande skulle man kunna ha med Polling Activators, men knappast med activators som skall aktiveras om en fil ändras eller om ett meddelande landar i en MQ-kö.

Någon som har någon annan ide på hur man skulle kunna lösa det, utan att varje activators får sin egen tråd att leva i...

- M

Om du ska använda .NET så kan det vara värt att titta på ThreadPool:
http://msdn2.microsoft.com/en-us/library/system.threading.threadpool(VS.80).aspx

Nja..

Threadpoolen är bra om man vill ha många tillfälliga trådar. Alltså om jag vid många tillfällen använder mig av trådar kortare stunder.

I mitt fall så skulle trådarna leva kvar så länge applikationen lever. Vilket betyder att jag ganska snart hade kommit upp i de 25 trådar som finns i trådpoolen...

- M

Varför inte lägga batchjobben i en SQL-databas?
Du vill väl ändå att batchjobb som läggs upp ska sparas och inte försvinna om applikationen startar om?
Sen kan du ha ett program eller en Service som vid jämna mellanrum läser av tabellen och startar de jobb som är schemalagda vid varje tidpunkt (jobben startas i en egen tråd).

Som du beskriver kan du ha en tråd som kollar igenom efter uppnåda tider och sedan startar en arbetstråd som utförarbetet. Eventuellt använder dig av trådpoolningen.

Problemet som trådskaparen vill få ordning på att det går åt för många trådar för scheduleringen. Körningen sedan borde kunna klaras av med en (eller ett fåtal) trådar.

En lösning är att du för alla strikt tidsberoende aktiveringar så gör du en scheduleringsklass där klienterna lägger in tidpunkter eller schema för när jobbet skall köras samt en delegat som kan utföra jobbet (jag har gjort en sådan för en kund, så så hemskt svårt är det inte om man gjort en del trådprogrammering innan). På så sätt så kan du ha en enda tråd för alla tidsberoende Activators. Filberoende Activators löser du sedan med klassen FileSystemWatcher.

Körningarna sedan bör naturligtvis köras i en annan tråd/ar (ThreadPool, lägg gärna till en prioritet på dina batchjobb så att du kan hantera fallet med alla upptagna trådar på ett någorlunda förutsägbart sätt) för att inte störa scheduleringen.

/Andreas

"Varför inte lägga batchjobben i en SQL-databas?"

Givetviss så kommer ju information om själva batchjobbet att sparas ner i databasen, så som var finns assemblyn som skall köras, vilket activeringstyp är kopplad till detta job osv osv..

Problemet blir att activatorerna skall kunna vara plugin. Jag kan ju se ett par olika aktiveringsmöjligheter: Polling, Scheduled, Dependent, FileWatcher, MQEvent... Och dessa kan man ju skapa nu, men man kanske sälje produkten och kunden själv vill lägga till en activator som jag inte ens tänkt på. Kanske lyssnar efter ett event på en COM-port eller något. Så det är ju mer än bara tidsbaserade händelser som skall få jobbet att starta.

- M

"Problemet som trådskaparen vill få ordning på att det går åt för många trådar för scheduleringen. Körningen sedan borde kunna klaras av med en (eller ett fåtal) trådar."

Japp. Det är till och med så att jag funferar på att flytta ut exekveringe av jobbet, till andra processor på andra maskiner, så att jag har en "controller" som kontrollerar när det är dags att starta jobbet, och sedan skickar man ut ett "broadcast" meddelande till andra maskiner att det är dags att köra jobbet, om jobbet kan köras parallellt, annars så skickar man ut meddelandet till en slummässig vald maskin som kör jobbet.

"En lösning är att du för alla strikt tidsberoende aktiveringar så gör du en scheduleringsklass där klienterna lägger in tidpunkter eller schema för när jobbet skall köras samt en delegat som kan utföra jobbet (jag har gjort en sådan för en kund, så så hemskt svårt är det inte om man gjort en del trådprogrammering innan). På så sätt så kan du ha en enda tråd för alla tidsberoende Activators. Filberoende Activators löser du sedan med klassen FileSystemWatcher."

Ja det lutar att det bli någonsådan lösning, med olika trådar för att kontrollera de olika typerna av aktiveringarna. Så alla PollingActivators kontrolleras i en tråd, alla ScheduledActivators kontrolleras i en tråd osv osv... Nu kan jag ju inte ta höjd för eventuella Activators som skrivs senare och "plugas-in" så då måste den som skriver den lösa det problemet, och få det att fungerar kräver nog en stunds tanke, eller så tar jag bort "plug-in" tänket där och man bara kan välja aktivators som är definerade med produkten...

- M