Per la domanda come posta, una coda funzionerebbe OK. Anche se il monitoraggio dovrebbe includere anche il numero totale di eventi in coda. Il monitoraggio dei timestamp della testa e della coda è facoltativo, forse un bel-to-have. Un Java BlockingQueue offre la maggior parte delle cose di cui abbiamo bisogno. Il lato rete può utilizzare [ offer ] ( link , long, java.util.concurrent.TimeUnit)) metodo per accodare nuovi elementi. Il lato codice server utilizza poll se questa è l'unica coda che serve.
Tuttavia, l'implementazione dovrebbe tenere traccia indipendentemente della dimensione poiché il metodo size() esistente restituisce sempre zero. Quindi dovresti anche proteggere il membro dei dati di dimensione con un mutex.
Non scriveremo il codice per te, questo non è il punto di questo forum StackExchange.
Ma la premessa della domanda è, molto sottilmente, sbagliata. Il contesto è che siamo preoccupati per il sovraccarico (ad esempio troppi eventi sono in coda). Supponendo che le richieste in arrivo abbiano una scadenza, se si utilizza una coda, ogni evento che viene offerto dalla coda è sempre l'evento più vecchio nella coda, in base alla progettazione. Questo massimizza la possibilità di superare la scadenza prima ancora di guardarla.
Se il tuo server non è sovraccarico (cioè sta elaborando eventi con la stessa rapidità con cui arrivano) ci saranno zero eventi nella tua struttura dati. Pertanto, la progettazione e il dimensionamento della struttura dei dati sono davvero rilevanti solo per la gestione delle condizioni di sovraccarico.
Ci sono due semplici correzioni per il nostro problema, una utile dove gli eventi devono essere elaborati in ordine, e l'altro dove questa restrizione non esiste.
Per garantire un'elaborazione in ordine, è sufficiente ridurre di molto la lunghezza della coda. Puoi utilizzare la Legge di Little per capire quale coda di dimensioni usare dato il tempo medio per servire una richiesta, le richieste 'la scadenza abituale e il throughput obiettivo. L'unico vero scopo della coda è gestire i picchi nelle richieste in entrata (nota: la legge di Little non è valida per i transienti). Il vantaggio della coda più breve è che quando una richiesta arriva dopo che la coda è già piena, il server non dà l'impressione fuorviante che avrà a che fare con esso. A seconda del livello di trasporto, il cliente potrebbe anche ricevere una notifica che il proprio evento non può essere servito in questo momento. In ogni caso, chiameresti semplicemente raiseAlert quando non riesci ad accodare un evento.
Se l'elaborazione in ordine non è richiesta, c'è una tecnica migliore, ma meno intuitiva: usa uno stack invece di una coda . Che differenza fa? Assente quando il server elabora gli eventi con la stessa velocità con cui arrivano. Se ci sono zero eventi, non importa se si tratta di una coda o di uno stack, si comporta allo stesso modo (dal momento che non fa nulla). Non appena abbiamo un sovraccarico, con uno stack abbiamo un invariante che il server elabora sempre l'evento più recente , che è l'evento con la minima possibilità di aver già superato la sua scadenza. Ciò massimizza la percentuale di richieste client che non scadono.
Se è economico distruggere gli oggetti richiesta (in particolare: molto più economico della gestione effettiva della richiesta), puoi implementare lo stack con un dequante e eseguire il polling bottom dello stack per gli eventi scaduti, in per scartarli. Ciò consente di controllare in qualche modo la pressione della memoria in condizioni di sovraccarico.