laurar181 ha scritto:
se nella calsse del job di esecuzione imposti DisallowConcurrentExecution vuol dire che più schedulazioni dello stesso job non possono essere eseguite simultaneamente.
Se imposto che deve partire ogni minuto e l'esecuzione durà di più avro n schedulazioni in coda.
Io devo sapere esattamente quante ne ho in coda e non solo l'attuale e la successiva.
Potrei sbagliarmi, ma non penso che Quartz vada a creare una coda con i trigger che dovrebbero eseguire simultaneamente.
E' più probabile che, nel momento in cui il trigger è destinato a essere eseguito, se ce n'è un altro in esecuzione il primo venga "posticipato", ossia valutato in un secondo momento, assieme a tutti gli altri che dovessero trovarsi nella stessa condizione, andando a rivalutare successivamente la necessità di eseguirlo e ripetendo l'operazione fino a quando non si presenta uno spazio libero.
In breve, il motore di Quartz presumo valuti continuamente le schedulazioni da lanciare e verifichi le precondizioni di lancio: quando giunge il momento, la policy è favorevole, non vi sono ostacoli al lancio ed è possibile eseguire il trigger, allora questo parte.
Quello che mi sento di escludere è che Quartz vada a valutare il momento di avvio di un trigger e, nel caso ve ne sia un altro, inizi a creare una coda di tutti i trigger che non possono essere eseguiti in quel momento... con il protrarsi della condizione, la coda potrebbe crescere esponenzialmente, inoltre in certi casi il trigger potrebbe essere configurato per non dover essere eseguito più se un altro lo ha sostituito (dipende tutto dalla policy).
Il fatto di non aver mai sentito menzionare una simile coda e che non vi sia apparentemente una API dedicata mi fa sospettare che la logica sia questa. Poi, se dovessi essere smentito, avrò imparato qualcosa di nuovo.
Ciao!
