iBaffiPro ha scritto:
Se invece di 36 secondi servissero 36 minuti? Se invece di 36 minuti, 36 ore? Cosa accadrebbe? C'è un tempo massimo di attesa? Si può gestire questo tempo massimo? In che modo?
I timeout esistono ovviamente a livello di networking (e anche HTTP di conseguenza). E la questione è che ci sono timeout preimpostati non solo a livello del "server" ma anche per ciascuno dei vari browser. Per Firefox ad esempio ci sono vari timeout configurabili, quelli che trovi documentati qui
https://kb.mozillazine.org/About:config_entries#Networ. denominati "
network.****.timeout".
Quindi i timeout in generale esistono e per ovvi buoni motivi. E sono cose che in generale NON puoi controllare solo dalla tua webapp. Quindi l'obiettivo non dovrebbe essere quello di "controllare" questi timeout ma di ragionare diversamente a livello di architettura.
Se c'è un lavoro "lungo" (molti secondi ... minuti ... ore) lo si fa eseguire in modo
asincrono, ovvero il lavoro gira in "background" sul server e la response arriva subito al client. Magari si può generare un identificativo del lavoro e la pagina potrebbe fare una logica di "polling" ogni tot di tempo per dare l'aggiornamento all'utente.
Il polling potrebbe essere fatto in automatico (con request asincrone) se fosse possibile usare cose tipo JQuery, Angular, ecc... Se invece l'utilizzo di Javascript non è contemplato, il polling lo potrebbe fare comunque "a mano" l'utente. Ad esempio, alla richiesta del lavoro, si genera es. un UUID e si fa un redirect alla pagina blabla/stato-lavoro.html?id=4a1e93ff-f179-49b6-b680-094fba5746d0 e nella pagina si dice all'utente qualcosa tipo "fai refresh quando vuoi per verificare lo stato del lavoro". Ovviamente lato server servono delle apposite strutture dati per tracciare questi lavori.
Se i lavori fossero molti e di tipi diversi, si potrebbe anche pensare di fare una gestione persistente dei job, con una tabella su DB che traccia i lavori indicando data/ora di inizio, lo stato, chi l'ha richiesto, ecc... Che sarebbe utile anche come "storico" e per eventuale
troubleshooting. E poi predisporre magari un pagina dove l'utente possa vedere lo stato dei lavori.
Se poi i lavori fossero davvero molti e/o lunghi, tali che una singola macchina non è in grado di gestirli tutti, allora si può ragionare ancora di più a livello di architettura, predisponendo altre macchine su cui far girare i lavori e mettendole in comunicazione con la webapp tramite sistemi di messaggistica tipo RabbitMQ, Apache ActiveMQ, ecc... Si tratta ovviamente di architetture ben più complesse di cui presumo non sai assolutamente nulla e che richiedono ovviamente molte più risorse hw/sw.
In definitiva, l'obiettivo dovrebbe essere quello di cambiare la strategia di gestione dei lavori "lunghi" .... NON cercare di andare "contro" i timeout!