Servizio api rest

[angman]

Ciao a tutti, dovrei scrivere un servizio api rest json da attivare tramite un demone.
La domanda è: come faccio a chiuderlo quando fermo  il demone?

Grazie per l'aiuto

[xinyiman]

Scusa ma non ho capito la domanda. Se il servizio è integrato nel demone, buttando giù il demone butti giù anche il servizio.

[DragoRosso]

Probabilmente @angman voleva intendere come deve chiudere la sua parte di elaborazione "REST" ...

Non sò se stai lavorando in Linux o Windows, ma ora parlo per Windows:

Windows ha il concetto di servizio, ossia una particolare applicazione che risponde in maniera standardizzata al sistema operativo. Ha delle interfacce che espongo dei metodi e delle proprietà che consentono l'iterazione con il SO ed eventuali azioni utente (sempre legati al SO): in particolare quattro metodi sono i prinicpali.

1) Start;

2) Pause;

3) Resume;

4) Stop;

Questi quattro metodi sono delle procedure / funzioni che devono essere implementate e che sono necessarie solo ed esclusivamente per le richieste del sistema operativo. A partire da queste si deve creare tutto il contorno per il vero servizio (ad esempio "rest"") che coinvolgerà la creazione di thread / task ed altro.

Nessuna elaborazione di funzione come "rest" o altro deve essere gestita nelle 4 procedure indicate. Esse devono solo sospendere / terminare / avviare i thread / task che implementano le funzionalità "rest" ad esempio.

Quindi per rispondere ad @angman, dovrai usare la procedura "Stop" ad esempio (che di fatto è un evento) per terminare tutti i tuoi thread / task o altro.
Per le altre funzioni le operazioni sono quelle appropriate. Non tutte e 4 le procedure devono essere gestite (ad esempio "Pause" e "Resume" sono molto spesso non implementate in tanti servizi di Windows).

P.S.: IN UN SERVIZIO NON E' POSSIBILE USARE ALCUNA ITERAZIONE GRAFICA NE AUTONOMA NE ASSISTITA VERSO L'UTENTE. E' possibile elaborare qualsiasi cosa, anche la grafica, ma senza alcuna iterazione utente ... quindi niente Form, niente Dialogs, niente ShowMessage o MessageBox o altro e in generale qualsiasi oggetto legato alla LCL (anche se ci sono alcune eccezioni sulle LCL).

[angman]

probabilmente non mi sono spiegato bene. Quello che vorrei fare è realizzare una applicazione Con LazWeb che risponda alle chiamate su una porta http. Tale applicazione dovrebbe però essere controllata tramite un demone che sia in grado di lanciarla allo start ma anche di chiuderla in modo controllato (attendendo che un eventuale thread interno venga terminato) alla chiusura del demone.

[xinyiman]

Concettualmente devi generare un percorso nel server "http application" che vai a creare che butti giù l'applicazione.

Qui spiega come: https://wiki.freepascal.org/fpWeb_Tutorial#Terminating

Poi dal demone lanci la chiamata al suddetto URL che si occupa della chiusura.

[DragoRosso]

Sicuramente il suggerimento di @xinyman è il più "pulito".

Però, forse chiudere il processo dal suo "handle" (in Linux ci sono "TProcess" e "Shell" per gestire le applicazioni lanciate) potrebbe essere una ulteriore soluzione. Se per qualsiasi motivo la chiusura tramite richiesta HTTP non avvenisse, ci si ritroverebbe con un blocco insanabile.

Quando il demone lancia il processo (la web app) dovrebbe comunque verificare che una ulteriore istanza non stia già girando, anche perchè se no il binding alle porte TCP fallirebbe. E dovrebbe buttare giù l'istanza probabilmente tramite un handle e non tramite HTTP (che potrebbe non avere funzionato precedentemente), per poi riavviare l'applicazione.

Sulla chiusura delle applicazioni WEB, in ambito Windows ma anche in quel poco di gestione sperimentale di un servizio cloud "autocostruito" in Linux che ho testato ho riscontrato alcune "ritrosie" alla chiusura delle applicazioni server che lavorano su TCP/IP. Non è certo la normalità, ma se accade anche solo una volta ti blocca tutto se non prendi le contromisure da subito.

Oltre questa chiaccherata non posso andare perchè non ho domestichezza con lo sviluppo in Linux.

Ciao

[Mimmo]

probabilmente non mi sono spiegato bene. Quello che vorrei fare è realizzare una applicazione Con LazWeb che risponda alle chiamate su una porta http. Tale applicazione dovrebbe però essere controllata tramite un demone che sia in grado di lanciarla allo start ma anche di chiuderla in modo controllato (attendendo che un eventuale thread interno venga terminato) alla chiusura del demone.

Se ti interessasse integrare il webserver dentro il demone, posso fornirti un piccolo esempio.

[xinyiman]

Mimmo, condividilo comunque, può tornare utile a chi in futuro leggerà la conversazione.

[angman]

Si Mimmo grazie. Credo che mi sarebbe molto utile

[Mimmo]

Questo è un esempio di un webserver incapsulato dentro un demone. Non è specifico per LazWeb.
L'idea è quella di avere 3 attori: il demone, il webserver (con tutti i suoi bei thread e le sue logiche e che abbia un metodo per essere attivato e un metodo per disattivarsi) e un thread di controllo che farà da ponte tra il demone e il webserver.
Devi orchestrare un po' di comunicazioni tra tutti e 3.
Il demone è comandato chiaramente da fuori. Possiede un TSimpleEvent che servirà da callback tra lui e il thread di controllo durante la fase di spegnimento. L'istanza dell'evento dovrà essere passata dal demone al costruttore del thread di controllo.
Il thread di controllo si salverà il puntatore all'evento/callback del demone e creerà un altro evento (che deve essere esposto) per funzionare da start/stop del thread stesso. Il thread di controllo creerà anche il webserver vero e proprio.
Quando il thread di controllo partirà, farà partire anche il webservice e poi si metterà in attesa indefinitamente sull'evento interno.
Se il demone dovesse ricevere da fuori (l'utente) il comando di spegnersi, attiverà l'evento del thread di controllo (per svegliarlo) e poi si metterà in attesa sull'evento/callback (in attesa che il thread di controllo abbia ucciso il webserver). Il thread di controllo appena risvegliato chiederà al webserver di chiudersi e poi attiverà l'evento/callback del demone per comunicare che lui ha finito.
A questo punto il demone dovrebbe riprendere la propria esecuzione e spegnersi definitivamente.

Codice: [Seleziona]

TWebServiceDaemon = class(TCustomDaemon) 
private
    FDaemonWorkerThread : TDaemonWorkerThread;
    FDieDaemon : TSimpleEvent;

    procedure ThreadStopped (Sender : TObject);
  public
    function Start : Boolean; override;
    function Stop : Boolean; override;
    Function ShutDown : Boolean; override;
  end; 

procedure TWebServiceDaemon.ThreadStopped(Sender: TObject);
begin
  FreeAndNil(FDaemonWorkerThread);
  FreeAndNil(FDieDaemon);
end; 

function TWebServiceDaemon.Start: Boolean;
begin
  Result:=inherited Start;

  // Service started
  FDieDaemon := TSimpleEvent.Create;
  FDaemonWorkerThread := TDaemonWorkerThread.Create(FDieDaemon);
  FDaemonWorkerThread.OnTerminate:=@ThreadStopped;
  FDaemonWorkerThread.FreeOnTerminate:=False;
  FDaemonWorkerThread.Start;
end;

function TWebServiceDaemon.Stop: Boolean;
begin
  Result:=inherited Stop;
  //Service stopped
  FDaemonWorkerThread.LetsGoEvent.SetEvent;
  FDieDaemon.ResetEvent;
  FDaemonWorkerThread.Terminate;
  FDieDaemon.WaitFor(5000);
end;

function TWebServiceDaemon.ShutDown: Boolean;
begin
  Result:= Stop;
end;

questo lato demone, lato worker/server http:

Codice: [Seleziona]

  TDaemonWorkerThread = class (TThread)
  private
    FServer: TIlmioserverHTTPConLaSuaBellaImplementazione;
    FLetsGoEvent : TSimpleEvent;
    FLetsDieEvent : TSimpleEvent;
  protected
    procedure Execute; override;
  public
    constructor Create (aLetsDieEvent : TSimpleEvent); reintroduce;
    destructor Destroy; override;

    property LetsGoEvent : TSimpleEvent read FLetsGoEvent;
  end;

constructor TDaemonWorkerThread.Create(aLetsDieEvent : TSimpleEvent);
begin
  inherited Create(false);

  FLetsGoEvent := TSimpleEvent.Create;
  FLetsGoEvent.ResetEvent;
  FLetsDieEvent := aLetsDieEvent;

  FServer := TIlmioserverHTTPConLaSuaBellaImplementazione.Create(...);
  FServer.InizializzoQuelloCheServe;
end;

destructor TDaemonWorkerThread.Destroy;
begin
  FLetsGoEvent.Free;
  FreeAndNil(FServer);
  inherited Destroy;
end;


procedure TDaemonWorkerThread.Execute;
begin
  // Daemon worker thread executing
  while not Terminated do
  begin
    if not FServer.Attivo then
    begin
      FServer.VoglioCheTiAttivi;

      // Server running
    end;
    if not Terminated then
    begin
      // Daemon worker thread waiting...
      FLetsGoEvent.WaitFor(INFINITE);
      FLetsGoEvent.ResetEvent;
      // Daemon worker thread resumed!
    end;
  end;
  if FServer.SeiAttivo? then
  begin
    FServer.VoglioCheTiChiudi;
    // server closed
  end;
  Sleep (500); // questo alle volte aiuta se il server impiega un po' a tirarsi giù.... ma devi valutare tu, magari puoi passare una callback al server...
  FLetsDieEvent.SetEvent;
  // Daemon worker thread terminated
end;

[nomorelogic]

grazie dell'esempio Mimmo
veramente interessante

nomorelogic

[DragoRosso]

@Mimmo

Un consiglio per la parte di codice che indico qui sotto:

Codice: [Seleziona]

function TWebServiceDaemon.Stop: Boolean;
begin
  (* Originale
  Result:=inherited Stop;
  //Service stopped
  FDaemonWorkerThread.LetsGoEvent.SetEvent;
  FDieDaemon.ResetEvent;
  FDaemonWorkerThread.Terminate;
  FDieDaemon.WaitFor(5000);
  *)
  //Service stopped
  //Prima imposta il TERMINATE al THREAD
  FDaemonWorkerThread.Terminate;
  //Poi SETTA l'evento come hai fatto (visto che il THREAD ha un Wait all'infinito)
  //Se lo fai con la sequenza che avevi impostato originarimente, il TERMINATE poteva "arrivare" in ritardo e teoricamente il thread poteva ritornare ad attendere all'infinito
  //(in fondo hai uno sleep, quindi l'ipotesi è molto rara ... però).
  //in questo modo, come sente l'evento sei certo che il THREAD è già in stato di Terminate e si chiuderà dopo avere svolto il suo codice.
  FDaemonWorkerThread.LetsGoEvent.SetEvent;
  FDieDaemon.ResetEvent;
  //Perchè attendi questo ?
  //FDieDaemon.WaitFor(5000);
  //Attendi invece direttamente la fine del Working Thread
  FDaemonWorkerThread.WaitFor(5000);
  //Normalmente questa è l'ultima istruzione, però magari in Linux deve essere effettuata prima.
  Result := inherited Stop;
end;

[Mimmo]

@Mimmo

Un consiglio per la parte di codice che indico qui sotto:

Ciao,
grazie per le ottimizzazioni. Hai assolutamente ragione sul fatto che il Terminate è meglio metterlo prima. A questo punto anche ResetEvent è meglio anticiparlo. Invece il WaitFor sul thread lo eviterei perchè non c'è la possibilità di mettergli un timeout (o almeno non so come fare...), nel codice fpc del TThread fa un wait su un tempo "INFINITE" e non prende parametri. E' difficile valutare se c'è un rischio che poi rimanga tutto appeso in chiusura del demone/servizio. Il Result possiamo pure buttarlo a True alla fine, tanto l'inherited non ha logica dentro..

Alla luce delle osservazioni, rimescolando di nuovo il codice, alla fine farei così:

Codice: [Seleziona]

function TWebServiceDaemon.Stop: Boolean;
begin
  FDaemonWorkerThread.Terminate;
  FDieDaemon.ResetEvent;
  FDaemonWorkerThread.LetsGoEvent.SetEvent;
  FDieDaemon.WaitFor(5000);
  Result:=true;
end;

Che ne dici?

[DragoRosso]

Ciao,
Invece il WaitFor sul thread lo eviterei perchè non c'è la possibilità di mettergli un timeout (o almeno non so come fare...), nel codice fpc del TThread fa un wait su un tempo "INFINITE" e non prende parametri. E' difficile valutare se c'è un rischio che poi rimanga tutto appeso in chiusura del demone/servizio.

Hai ragione sul fatto che non si possa inserire un timeout sul wait di un thread. Il codice l'ho scritto senza verificarlo.
Comunque che ci sia il wait o no il demone non terminerà se il thread rimane "appeso". Avrai il tuo processo comunque "orfano" in attesa del kill da parte dell'utente (sia in Windows che in Linux).

Quindi a mio parere conviene lasciare il wait "infinito" sul thread e assicurarsi che il thread termini di morte propria. Al limite puoi inserire dei messaggi di log da qualche parte in modo che se accade che si "inchiodi" vedi l'ultimo messaggio e sai il perchè.

Se c'è qualche thread che "deve" terminare, è necessario attendere che termini. E' inutile cercare di chiudere l'applicazione ignorando la cosa perchè comunque l'applicazione non si chiuderà.

Inoltre c'è da dire che se la fase di "destroy" segue una ben determinata sequenza (che molte volte è necessario per liberare le risorse in ordine) saltare un elemento per paura dell'attesa non è una buona mossa.

L'esempio tipico, che ho visto diverse volte accadere in altri software è che si libera ad esempio un evento o un semaforo in uso ad un thread (sono oggetti globali normalmente) senza attendere di liberare prima il thread stesso ... e opppppsssss l'applicazione non si chiude o crasha.

Come sempre ciò è un mio punto di vista.

P.S.: c'è comunque una super scorciatoia se si vuole bypassare tutto (la maggior parte delle volte funziona pure) ... exitprocess(0) ... e liberi come il vento. 

Ciao

EDIT: a proposito, in Windows se non vado errato dopo uno STOP il servizio viene comunque terminato dal sistema operativo se non risponde entro tot tempo (non ricordo quanto sia il tempo ma ho vago ricordo di un timing 45 secondi). Penso che anche in Linux sia così, quindi a maggior ragione puoi attendere con fiducia la sequenza di chiusura corretta al limite ci pensa mamma OS.
Se qualcuno conosce i timing per la chiusura dei servizi in Windows o in Linux risponda che è sempre utile saperlo.