Quello che mi manca è avere tutti i trigger di questo job che sono in attesa di essere eseguiti in quanto in coda.
C'è un modo di interrogare lo scheduler?

Se crei un oggetto StdSchedulerFactory puoi accedere all'API di Quartz che ti mette a disposizione metodi per recuperare oggetti Scheduler, i Job configurati e i relativi Trigger.

Qualche esempio lo trovi nella documentazione di Quartz:
https://www.quartz-scheduler.net/documentation/quartz-3.x/tutorial/jobs-and-triggers.html

Il punto di ingresso dell'API dipende dal contesto in cui ti trovi e quali oggetti che fanno parte dell'ecosistema di Quartz hai a disposizione in quel momento: eventualmente aggiungi una parte del codice saliente così da poter valutare le opzioni disponibili nel contesto.

Ciao!

laurar181 ha scritto:

Ho cercato in tutta la documentazione ma non c'è nulla che ti permette di verificare quali trigger sono in coda.

Ma cosa intendi per essere in coda?

Che io sappia, generalmente un trigger ha una data/ora prevista per la prossima esecuzione, ma non esiste una "coda", anche perché non è chiaro a cosa servirebbe.

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!

La mia sensazione è che non dovremmo includere il passaggio che Quartz esegue per analizzare l'istante in cui viene attivato un trigger. Nel caso in cui ce ne sia un secondo, avvia il processo di creazione di una coda per tutti i trigger che non possono essere eseguiti in quel momento. Se la condizione può persistere, la lunghezza della coda può aumentare a una velocità esponenziale. Inoltre, il trigger potrebbe in alcune circostanze essere impostato in modo tale che non sia più necessario eseguirlo se un altro ha preso il suo posto.
Contact https://slope-game.io