On Thu, 24 Jan 2002, Cristian Ion wrote:

> Merci de raspuns!
>
> Da, insa aici vroiam sa jung, diferenta intre request  si sesiune &
> implicatia asupra unui child:
>

> Mai exact, sa luam urmarorul scenariu: Eu ma conectez la un web-server. In
> acest moment eu seschid o sesiune iar pe parcursul acestei sesiuni eu o sa
> cer mai multe pagini (pentru simplitate http simplu, nimic dinamic servlets
> & stuff.). Un child process va prelua sesiunea mea de la inceput. De aici
> mai departe el va raspunde cererilor mele de pagini (intrebare: doar el va
> face asta?). Fiecare cerere de pagina va conta in couterul
> MaxRequestsPerChild ca un request sau intreaga sesiune pana la disconnect-ul
> din tcp-ip va conta ca un request?
>
nu man
:)
daca tu te referi la acele sesiuni simulate prin cookies sau
session-id-uri stocate in url, unde se stocheaza variabile server side pe
parcursul "vizitei" unui client, alea nu prea au nici o treaba cu
apache-ul direct

adica acele sesiuni se fac in software, prin rularea programelor server
side ce initializeaza sesiunea, citeste din ea, scrie in ea si mai ales o
identifice pe baza de session id

cu alte cuvinta o sesiune cum ii spui tu nu e altceva decat un numar de
requesturi trimise httpd-ului
iar apache-ul NU va pastra nici un child special pentru sesiunsea ta ci va
aloca requesturile tale childurilor existe in functie de schedulerul lui

in schimb se poate intampla ceva asemanator daca browserul tau stie de
keepalive http (in rfc-ul lui 1.1)
adica in http normal browserul realizeaza cate o conexiune tcp pentru
fiecare request iar dupa ce primeste raspunsul in urma requestului ,
conexiunea este inchisa chiar de httpd
dar, daca sttie keepalive, cand trimite requestul trimite si un header
numit KeepAlive care ii zice httpd-ului sa NU termine conexiunea aceasta
dupa aceste request ci sa o lasa deschisa pana o inchide clientul sau o
inchide serverul in functie de cum l-ai vonfigurat (keepalive timeout mai
ales)

asta poate sa aiba legatura cu sesiunile tale software in sensul ca daca
un client acceseaza repede paginile de pe server, si browserul lui mentine
conexiunea cu keepalive, atunci DA, ai un child care sta pentru acest
client... dar in general nu rea au legatura sesiunile client cu
conexiunile tcp (sesiunile tcp/http)

>
> Merci de lamurirea cu fpre-fork!
>
> " There are two types of pilots: curageous and alive!"
>
> Cristi
>
> ----------------------------------------------------------------
>
> deci apache este un server pre-fork
> regula de baza este ca fiecare request este servit de unul si numai un
> child la un moment dat
> pre-forking inseamna ca initial el face fork la 10 spare childs sa zicem
> apoi pe masura ce vin requesturile face forkuri sa le poata servi (cu
> conditia sa nu depaseasca MaxClients) si cand numarul de requesturi scade
> el nu mai omoara din childs decat cand isi depasesc limitele
> (MaxRequestsPerChild etc...)
> adica un child va servi mai multe requesturi in viata lui
>
> >   La fel in Tomcat, in servers.xml putem specifica nr maxim de threads ale
> > serverului. Ce se intelege aici prin thread, UN servlet care este
> executat?
> > Daca acesta cheama alte obiecte din alte servlet-uri fiecare ulterior
> > deschide cate un thread? Sau este vorba de o sesiune intre apache si
> tomcat,
> > in care un client cere Apache-ului anumite pagini, iar toate servleturile
> > din aceasta sesiune trec printr-un singur thread de executie al
> > tomcat-ului!?
> >
>
> eh aci nu stiu ca am pus o singura data tomcat si nu m-am agitat prea tare
> cu el
>
>
> ----------------------------
> Mihai RUSU
> "... and what if this is as good as it gets ?"
>
> ---
> Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
> unsubscribe from this list.
> ---
> Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
> unsubscribe from this list.
>
>

----------------------------
Mihai RUSU
"... and what if this is as good as it gets ?"

---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to 
unsubscribe from this list.

Raspunde prin e-mail lui