Limitazione del numero di richieste a un servlet

Question

Abbiamo un servlet che occupa più memoria virtuale sul server a causa della logica che ha. Per questo motivo, vorremmo limitare le richieste simultanee a questo server, ad esempio vorremmo elaborare solo 10 richieste simultanee. Le altre richieste devono attendere in coda.

È possibile creare un pool di thread personalizzato e assegnarlo a questo servlet per gestire questo scenario? Stiamo utilizzando il server WebLogic 9.2. O c'è qualche altro approccio migliore per farlo? Apprezzo qualsiasi pensiero.

Answer 1

  

È possibile creare un pool di thread personalizzato e assegnarlo a questo servlet per gestire questo scenario? Stiamo utilizzando il server WebLogic 9.2. O c'è qualche altro approccio migliore per farlo? Apprezzo qualsiasi pensiero.

Sì, questo è possibile. Invece di utilizzare il gestore lavori di automazione predefinito (a partire da Weblogic 9.x, le code di esecuzione sono sostituite dai gestori del lavoro per i pool di thread ¹ ), è possibile creare un gestore del lavoro con vincoli come il limite massimo di thread e possibilmente la capacità . È quindi possibile assegnare un Servlet a un responsabile di lavoro specifico utilizzando wl-dispatch-policy del file descrittore di distribuzione weblogic.xml .

---

¹ Nota che è ancora possibile abilita il modello di pool di thread di WebLogic 8.1 e per utilizzare le code di esecuzione.

Answer 2

Hai bisogno di qualcosa davanti o la macchina che ospita il servlet perché quando le richieste arrivano alla macchina, è un po 'troppo tardi: le risorse sono già in uso. Non puoi controllare la domanda : puoi solo reagire ad essa e pianificarla.

Probabilmente avrai bisogno di un bilanciamento del carico software o hardware a seconda delle esigenze del tuo target. Il bilanciamento del carico del software può essere semplicemente un "servlet dispatcher" con controllo di sessione (ad es. 10 simultaneo alla servlet X).

C'è un'altra possibilità: tu " throttle " i richiedenti emettendo un codice HTTP appropriato. Ovviamente, questo significa logica aggiuntiva sul lato richiedente ... e consuma ancora alcune risorse sul lato server.

Answer 3

È possibile bilanciare il carico in modo che esista un server secondario che elabora tutte le richieste per il servlet costoso.

Answer 4

Potresti avere un contatore statico e un servlet che funge solo da gateway per la costosa chiamata del metodo. Devi solo affrontare una probabile condizione di gara su questo contatore statico.

Quindi, trasformeresti il ??servlet corrente in una chiamata di metodo.

Quindi, il servlet gateway riceverà la richiesta, controlla se il contatore è abbastanza basso e quindi incrementa. Se superiore a 10, restituisce un messaggio di errore.

Questa non è una situazione ideale, ma se metti le cose in coda, i browser inizieranno a scadere dopo un po 'di tempo, o gli utenti diventano impazienti e fanno clic ripetutamente sul pulsante di invio, poiché sta impiegando troppo tempo.

Se potessi usare javascript per inviare la richiesta, allora ci sono alcune soluzioni migliori che potrebbero aiutarti.

Answer 5

Senza usare i sistemi di bilanciamento del carico ecc., mi sembra che tu voglia separare la richiesta dall'elaborazione.

es.

1. il browser invia una richiesta. Il servlet lo prende, lo mette in coda e restituisce un biglietto.
2. Il servlet funzionerà su questa richiesta di lavoro quando le risorse lo consentono (utilizzando un pool di thread separato che estrae gli elementi di lavoro dalla coda).
3. Il browser può aggiornare (ri-RICEVERE) utilizzando quel ticket e il servlet restituirà un risultato appropriato (ad es. non elaborazione, elaborazione, elaborazione).

Questo è un modello abbastanza comune. Si noti che il browser non è bloccato, ma invia semplicemente la richiesta e quindi esegue regolarmente controlli per vedere se l'elemento di lavoro è completo. L'ho usato con successo (per esempio) nella situazione in cui ho avuto utenti che chiedevano grafici che impiegavano 5 minuti o più per l'elaborazione e che utilizzavano una libreria nativa che non era thread-safe. In quello scenario, dovevo limitare l'elaborazione a un singolo thread, indipendentemente dal numero di richieste simultanee.

Answer 6

Mi piace l'idea di utilizzare il contatore statico e il reindirizzamento per mostrare un messaggio di errore quando il contatore ha superato un limite.

Potremmo configurare un servlet separato e configurare il pool di thread per consentire solo il numero X di richieste simultanee, tutte le altre richieste verrebbero messe in coda per utilizzare il servlet successivo disponibile. Questo approccio genera un errore di timeout? Potete per favore condividere maggiori dettagli in merito? Grazie

http://download.oracle.com /docs/cd/E13222_01/wls/docs92/perform/appb_queues.html