Hvordan spores en GenServer-henrettelse? Elixir

Aktivér sporing ved hjælp af fejlfindingsindstillingen.

Denne artikel er til begyndere, især der er begyndt at spille med GenServer.

I dag skal du bygge en OTP-server, og du vil spore serveren ved hjælp af enkel teknik. Dette er ikke en teknik, det er en mulighed, mens du kalder funktionen start_link / 3.

Tal er billig, lader kode det.

Hvad gør vi her?

Vi implementerer sammen STACK-serveren og sporer denne server.
Som du ved, er stack en datastruktur baseret på begrebet først i sidste ud eller sidst til først ud.

Jeg vil prøve at holde dette så enkelt som muligt uden at bo i over-engineering. Vores ultimative mål er at forstå konceptet.

stack.ex

Opret en fil stack.ex ved hjælp af din yndlingseditor. Her bruger jeg vim

$ vim stack.ex

I Elixir navngiver vi normalt vores modul med filnavnet. Det er en generel konvention for at undgå forvirring. Så opret et modul med navnet Stack med følgende kode.

Vores Stack-server er meget enkel. Stadig et par ord om beskrivelsen af ​​kode.

Bemærk venligst, at det ikke er en produktionskvalitetskode. Jeg brugte en sammenkædning af listen i slutningen af ​​listen. Det udføres bedre ved at tilføje element til hovedsektionen som [new_elem | tilstand]. Du skal dog ændre nogle kodelogikker. Så jeg gjorde det med vilje for at bringe ideen om element tilføjer i sidste position, og det bliver først dukket op. I produktionskode skal du vende logikken, da lister i elixir implementerer linked_lists opførsel.

Tak til Hubert Pompecki for at have bemærket dette, da det kan resultere i, at guiden begynder.

Den allerførste kodelinie GenServer tilføjer normalt OTP GenServer opførsel til vores modul Stack. Det betyder også, at vi ikke behøver at definere alle tilbagekald i vores modul - adfærden definerer standarder for dem alle. Vi kan bare tilsidesætte de ting, vi har brug for.

Når klienten fremsætter en synkron anmodning ved hjælp af GenServer.call, udløses det mønster matchede call_ call callback i vores GenServer. Serveren modtager tre parametre og sendte dem videre til callback-definitionen.

  1. Klientmeddelelse
  2. Kundens pid
  3. Serverens aktuelle tilstand i rækkefølge.

Vi returnerer simpelthen en tuple med tre elementer {: svar, , } til OTP. Otp returnerer til klienten.

Sådan er flowet.

klient -> GenServer -> OTP -> klient

Der er andre tilbagekaldsfunktioner. Jeg kan ikke forklare dem her. Du kan læse dem selv.

Udførelse og sporing

Inden du kører følgende kommando, skal du sikre dig, at du er i det samme bibliotek, hvor filen stack.ex findes.

$ iex stack.ex

Det åbner det interaktive shell-miljø sammen med indlæsning af vores modul Stack.

Start af serveren og aktiver sporing ved hjælp af debug-indstilling

iex> {: ok, pid} = GenServer.start_link (Stak, [1,2,3,4,5], [debug: [: trace]])

Den tredje parameter GenServer.start_link tager nogle få indstillinger. Så vi bruger debug: [: trace] til fejlsøgning. Denne mulighed logger alle meddelelser flyder til konsollen. Det giver dig tydeligt oplysninger om, hvem der sender meddelelsen, og til hvem den blev sendt.

Prøv med at ringe til serveren.

Få stat

iex> GenServer.call pid,: få

Pop besked

iex> GenServer.cast pid,: pop

Sæt besked

iex> GenServer.cast pid, {: put, 6}

Sporing af eksisterende server

I ovenstående sporingsstil tilføjede vi en option debug: [: trace] som den tredje parameter, mens vi kalder definitionen GenServer.start_link.

Nu opretter vi processen uden denne mulighed. Så det vil være den eksisterende server og spore denne server manuelt.

Vi vil følge den samme proces undtagen at kalde GenServer.start_link

$ iex stack.ex

Det indlæser modulet i iex-session.

iex> {: ok, pid} = GenServer.start_link (Stak, [1,2,3,4,5])

Hvis du observerer, passerer vi ikke den tredje mulighed her.

Lad os ringe til serveren

iex> GenServer.call pid,: få
[1,2,3,4,5]

Det returnerer bare staten uden fejlfinding.

Sporing manuelt

Nu sporer vi den eksisterende server ved hjælp af: sys.trace

iex>: sys.trace pid, sandt
:Okay

Den: sys.trace tager to parametre pid på den eksisterende server til at spore, og den anden parameter er et boolesk sandt middel aktiverer sporing og falske midler deaktiverer sporing.

Nu skal du ringe til de andre serveropkald, så ser du fejlfindingsoplysningerne, som vi gjorde i første afsnit af sporing ved hjælp af option som tredje parameter.

Deaktiver sporing

iex>: sys.trace pid, falsk

Kontroller følgende skærmbillede

Dette er bare en anden måde at aktivere og deaktivere sporing af den eksisterende server ved hjælp af pid.

Håber du kan lide dette. Du er velkommen til at dele og lade andre få fordel af dette.

hvis værd at_clapping, skal du gøre: CLAP, ellers: nul

Happy Coding :) & Bliv altid smilende.