Temat: Dlaczego GenericServlet jest serializowalny?

Witam!
Właśnie zdałem sobie sprawę że klasa javax.servlet.GenericServlet - czyli podstawa wszystkich servletów - jest serializowalna:
GenericServlet javadoc


Czy ktoś może mi wyjaśnić jaka jest powód ku temu?
Ja jakoś nie mogę znaleźć sytuacji gdzie kontener chciałby serializować servlet - już raczej widzę to tak że kontener niszczy i tworzy servlet od nowa.

Będę wdzięczny za wszelkie komentarze.

Pozdrawiam,
Tomasz Kokoszka

Temat: Dlaczego GenericServlet jest serializowalny?

Choćby z tego powodu, aby mechanizmy wyrównywania obciążenia/klastrowania javowych serwerów aplikacji sensowanie działały.

Dla przykładu, żądanie HTTP przychodzące do procesu kontrolnego, może być kierowane do odpowiedniego kontenera serwletów. Utworzona instancja serwletu przemieszczana (poprzez serializację) do odpowiedniego kontenera obsługującego żądanie w ramach klastra.

W innym przypadku, aby zapamiętać stan serwletu, gdy serwlet nie jest używany (obsługa puli wewnątrz serwera aplikacji). Poprzez serializację, kontener serwletów szybciej przywróci stan serwletu.

Temat: Dlaczego GenericServlet jest serializowalny?

Paweł Grotowski:
Dla przykładu, żądanie HTTP przychodzące do procesu kontrolnego, może być kierowane do odpowiedniego kontenera serwletów. Utworzona instancja serwletu przemieszczana (poprzez
serializację) do odpowiedniego kontenera obsługującego żądanie w ramach klastra.
W innym przypadku, aby zapamiętać stan serwletu, gdy serwlet
nie jest używany (obsługa puli wewnątrz serwera aplikacji).
Poprzez serializację, kontener serwletów szybciej
przywróci stan serwletu.

Czy jesteś pewien że jakiś kontener serializuje serwlety?
Przyznam że dla mnie brzmi to trochę dziwnie: po co przepychać instancję serwleta do innnej instancji? Prościej utworzyć nową instancję, nie mówiąc o tym że taki serwlet może już istnieć na innej instancji więc nie ma potrzeby go tworzyć - lepiej użyć ponownie istniejącej instancji.
Podobnie z pulą - po co serializować (zwłaszcza że GenericServlet.config jest transient).

Dla testu zbudowałem aplikacje web w której serwlet implementuje Servlet interface zamiast rozszerzać HttpServlet - załadowałem do Tomcata i działa.

Temat: Dlaczego GenericServlet jest serializowalny?

Tomasz K.:

Czy jesteś pewien że jakiś kontener serializuje serwlety?
Przyznam że dla mnie brzmi to trochę dziwnie: po co przepychać instancję serwleta do innnej instancji? Prościej utworzyć nową

Load balancing, stan servletu.

Temat: Dlaczego GenericServlet jest serializowalny?

Tomasz K.:

Paweł Grotowski:
Dla przykładu, żądanie HTTP przychodzące do procesu kontrolnego, może być kierowane do odpowiedniego kontenera serwletów. Utworzona instancja serwletu przemieszczana (poprzez
serializację) do odpowiedniego kontenera obsługującego żądanie w ramach klastra.
W innym przypadku, aby zapamiętać stan serwletu, gdy serwlet
nie jest używany (obsługa puli wewnątrz serwera aplikacji).
Poprzez serializację, kontener serwletów szybciej
przywróci stan serwletu.

Czy jesteś pewien że jakiś kontener serializuje serwlety?

Witaj. Nie jestem pewien. Jestem pewien, że jakiś producent serwera aplikacji, może to zrobić. Dla przykładu, instancja serwletu poprzez serializację może krążyć między różnymi JVM (każdy serwant w ramach klastra ma swój JVM).

Przyznam że dla mnie brzmi to trochę dziwnie: po co przepychać instancję serwleta do innnej instancji? Prościej utworzyć nową

Nie bardzo rozumiem. Tak jak napisałem wyżej. W ramach jednej JVM instancja danego serwletu jest jedna, więc istnieje też hipotetyczna możliwość, że w celach optymalizacyjnych np. użycia miejsca na stercie, nieużywany serwlet jest zrzucany do puli jako strumień binarny i odtwarzany w momencie gdy znowu będzie potrzebny (serwer pracuje non-stop więc instancja serwletu będzie ciągle ta sama).

instancję, nie mówiąc o tym że taki serwlet może już istnieć na innej instancji więc nie ma potrzeby go tworzyć - lepiej użyć ponownie istniejącej instancji.

Nie rozumiem tego zdania

Podobnie z pulą - po co serializować (zwłaszcza że GenericServlet.config jest transient).

j/w

Dla testu zbudowałem aplikacje web w której serwlet implementuje Servlet interface zamiast rozszerzać HttpServlet - załadowałem do Tomcata i działa.

Przeglądnij JSR-000154 SRV 2.3.1 "servlet lifecycle - loading and instantiation".Paweł Grotowski edytował(a) ten post dnia 04.12.07 o godzinie 14:56

Temat: Dlaczego GenericServlet jest serializowalny?

Rzeczywiscie jest to troche dziwne. Serwlety jako takie sa / powinny byc bezstanowe wiec serializowanie servletu dla load balancingu wydaje sie bzdura (prosze mnie poprawic jesli sie myle). Dodajmy do tego fakt, ze w J2EE 1.3 mogla byc wiecej niz jedna instacja servletu na JVM (np. w wypadku SingleThreadModel). Dalej - jezeli np. brakuje zasobow to servlet nie jest serializowany, nastepuje natomiast jego pelna destrukcja (z wywolaniem destroy()), i w razie potrzeby tworzenie nowej instacji (rowniez z callbackiem dla init()).
Koniec koncow bardzo ciekawy jestem jakie jest logiczne wytlumaczenie tej serializowalnosci servletu.

Temat: Dlaczego GenericServlet jest serializowalny?

Pawel Dolega:
Rzeczywiscie jest to troche dziwne. Serwlety jako takie sa / powinny byc bezstanowe wiec serializowanie servletu dla load

Załóżmy taką sytuację. Serwlet startuje, w metodzie init tworzymy
sobie instancję klienta SOAP, wywołujemy jakąś czasochłonną usługę
Web. Po wywołaniu usługi, dostajemy jakiś obiekt transferowy.
Referencję do tego obieku trzymamy jako składową klasy przez cały
czas życia serwletu (nie potrzebujemy tej referencji w innych
serwletach, więc nie umieszczamy jej jako atrybut kontekstu serwletu). W metodzie doPost lub doGet, korzystamy z tych danych. Czy trzymanie stanu serwletu i serializacja nie ma tutaj sensu, np. gdy kontener serwletów ma bardzo mało pamięci do dyspozycji (np. urządzenia elektroniki domowej ?).

balancingu wydaje sie bzdura (prosze mnie poprawic jesli sie

Możesz uzasadnić dlaczego jest bzdurą ?

myle). Dodajmy do tego fakt, ze w J2EE 1.3 mogla byc wiecej niz jedna instacja servletu na JVM (np. w wypadku SingleThreadModel).

Mogą, albo nie mogą. Zależy od implementacji kontenera.
Albo wątki sekwencyjnie wywołują metodę service, albo faktycznie,
istnieje pula wątków dla modelu SingleThreadModel (który od j2ee 1.4 jest niezalecany w użyciu). Ale jeśli się nie mylę, jest to raczej stosowane w przypadkach, kiedy serwery/aplikacje są rozproszone.

Temat: Dlaczego GenericServlet jest serializowalny?

Wydawaloby mi sie, ze kazdy JVM w clustrze ma wlasna instancje servletu i co za tym idzie wlasny obiekt transferowy. Przynajmniej tak to rozumiem wg punktu 2.2 specyfikacji servletow w wersji 2.4 (mowimy o servletach nie implementujacych SingleThreadModel).

Temat: Dlaczego GenericServlet jest serializowalny?

heh kolejna dyskusja z gatunku dlaczego okrąg niema kątów...
GenericServlet jest serializowalny ponieważ takie było widzimisię autora i nie jest podyktowane niczym konkretnym.

Gratuluje jednemu z przedmówców pomysłu żeby load balance robić przez serializacje serwletów to największa bzdura jaką od dawna słyszałem wymyśloną w celu uzasadnienia czegoś na siłę :) EJB też byś serializował i przerzucał między serwerami ?

Nie dopisujcie sobie panowie własnej specyfikacji, gdyż cykl życia servletów jest jasno określony. Jak sobie dany kontener poczyna z instancjami, ile ich ma , jakich i co z nimi robi jest w dokumentacji kontenera i niema nic wspólnego z GenericServlet który jest tylko klasą pomocniczą powstałą dla wygody developera i zupełnie przypadkowo jest Serializable.

Temat: Dlaczego GenericServlet jest serializowalny?

Łukasz Woźniak:
Gratuluje jednemu z przedmówców pomysłu żeby load balance robić przez serializacje serwletów to największa bzdura jaką od dawna słyszałem wymyśloną w celu uzasadnienia czegoś na siłę :)

Chyba źle zrozumiałeś (jeśli chodzi o mój komentarz). Jeśli tak, to ja nie pisałem, żeby "load balance robić przez serializację serwletów". W sumie, to raczej chodzi o to, czy w mechanizmie balancingu AS można wykorzystać serializację.

EJB też byś serializował i przerzucał między serwerami ?

bez komentarza...

Nie dopisujcie sobie panowie własnej specyfikacji, gdyż cykl
życia servletów jest jasno określony. Jak sobie dany kontener poczyna z instancjami, ile ich ma , jakich i co z nimi robi jest w dokumentacji kontenera i niema nic wspólnego z GenericServlet który jest tylko klasą pomocniczą powstałą dla wygody developera i zupełnie przypadkowo jest Serializable.

No jest. I co ? Specyfikacja jest dość luźna i nie określa jak realizować pewne rzeczy od strony technicznej.Paweł Grotowski edytował(a) ten post dnia 06.12.07 o godzinie 00:42

Temat: Dlaczego GenericServlet jest serializowalny?

Paweł Grotowski:

Łukasz Woźniak:
Gratuluje jednemu z przedmówców pomysłu żeby load balance robić przez serializacje serwletów to największa bzdura jaką od dawna słyszałem wymyśloną w celu uzasadnienia czegoś na siłę :)

Chyba źle zrozumiałeś (jeśli chodzi o mój komentarz). Jeśli tak, to ja nie pisałem, żeby "load balance robić przez serializację serwletów". W sumie, to raczej chodzi o to, czy w mechanizmie balancingu AS można wykorzystać serializację.

Hymmm przerzucanie stanu (sic!) servletu miedzy JVM... hymm hymmm

EJB też byś serializował i przerzucał między serwerami ?

bez komentarza...

;-)

Nie dopisujcie sobie panowie własnej specyfikacji, gdyż cykl
życia servletów jest jasno określony. Jak sobie dany kontener poczyna z instancjami, ile ich ma , jakich i co z nimi robi jest w dokumentacji kontenera i niema nic wspólnego z GenericServlet który jest tylko klasą pomocniczą powstałą dla wygody developera i zupełnie przypadkowo jest Serializable.

No jest. I co ? Specyfikacja jest dość luźna i nie określa jak realizować pewne rzeczy od strony technicznej.

No właśnie jest luźna, kontener niech sobie robi co chce i jak chce w specyfikacji niema słowa o serializacji więc jej tam nie wkładajmy, zwłaszcza gdy nie jest potrzebna. Jeśli komuś jest potrzebna to niech się poważnie zastanowi nad architekturą swojej aplikacji i jeśli dalej będzie chciał serializować swoje servlety to niech się przestawi na coś gdzie nie będą się czepiać takich pomysłów np .NET

//Edit: typoŁukasz Woźniak edytował(a) ten post dnia 06.12.07 o godzinie 21:37

Temat: Dlaczego GenericServlet jest serializowalny?

Łukasz Woźniak:

Paweł Grotowski:

Łukasz Woźniak:
Gratuluje jednemu z przedmówców pomysłu żeby load balance robić przez serializacje serwletów to największa bzdura jaką od dawna słyszałem wymyśloną w celu uzasadnienia czegoś na siłę :)

Chyba źle zrozumiałeś (jeśli chodzi o mój komentarz). Jeśli tak, to ja nie pisałem, żeby "load balance robić przez serializację serwletów". W sumie, to raczej chodzi o to, czy w mechanizmie balancingu AS można wykorzystać serializację.

Hymmm przerzucanie stanu (sic!) servletu miedzy JVM... hymm hymmm

Dalej nie do końca moje przesłanie zostało odebrane poprawnie :) Mam na myśli jedną i jedyną sytuację w jakiej miałoby to sens. Mianowicie, poprzedni przykład czasochłonnej operacji w init. W tym sensie stan serwletu można by przerzucać pomiędzy JVM i nie mam na myśli operacji tożsamej z tworzeniem nowej instancji.
Dla przykładu WebSphere w wesji ND (Network Deployed - mam doświadczenie z tym na z/OS), równoważenie obciążenia obsługuje na tej samej partycji. Jest to jeden serwer aplikacji podzielony na węzły i cele. Jest jeden proces kontrolny który zarządza kierowaniem żądań do odpowiednich serwantów. Każdy serwant ma swoją JVM. Ponieważ jest to fizycznie jeden serwer aplikacji, przerzucanie bieżącej instancji do innej JVM może być stosunkowo szybkie.

EJB też byś serializował i przerzucał między serwerami ?

bez komentarza...

;-)

Nie dopisujcie sobie panowie własnej specyfikacji, gdyż cykl
życia servletów jest jasno określony. Jak sobie dany kontener poczyna z instancjami, ile ich ma , jakich i co z nimi robi jest w dokumentacji kontenera i niema nic wspólnego z GenericServlet który jest tylko klasą pomocniczą powstałą dla wygody developera i zupełnie przypadkowo jest Serializable.

No jest. I co ? Specyfikacja jest dość luźna i nie określa jak realizować pewne rzeczy od strony technicznej.

No właśnie jest luźna, kontener niech sobie robi co chce i jak chce w specyfikacji niema słowa o serializacji więc jej tam nie wkładajmy, zwłaszcza gdy nie jest potrzebna. Jeśli komuś jest potrzebna to niech się poważnie zastanowi nad architekturą swojej aplikacji i jeśli dalej będzie chciał serializować swoje servlety to niech się przestawi na coś gdzie nie będą się czepiać takich pomysłów np .NET

Tutaj się nie zgodzę; a serializacja obiektów wkładnych do sesji ? To jest w zasadzie wymóg implementacji w środowisku rozproszonym. Czyli serwer jest w stanie obsługiwać przerzucanie obiektów z użyciem serializacji. Serwlet jest normalnym obiektem, tylko działającym w innym kontekście. No i nie chodziło mi o to, że ktoś miałby sobie sam serializować serwlety - tym oczywiście powinien zajmować się serwer (gdyby tak rzeczywiście było ;)).Paweł Grotowski edytował(a) ten post dnia 06.12.07 o godzinie 22:46

Temat: Dlaczego GenericServlet jest serializowalny?

Servlety jako takie z zalozenia zdaje sie sa bezstanowe (choc to raczej dobra praktyka niz requirement). A tak sobie pomyslalem, ze przy serializacji trzeba by tez chyba serializowac ServletContext (poprzez ServletConfig) prawda? A jak sie to ma do specyfikacji i czy nie byloby to czyms w rodzaju "inconsistency" ?

Temat: Dlaczego GenericServlet jest serializowalny?

Paweł Grotowski:

Łukasz Woźniak:

Paweł Grotowski:

Łukasz Woźniak:
Gratuluje jednemu z przedmówców pomysłu żeby load balance robić przez serializacje serwletów to największa bzdura jaką od dawna słyszałem wymyśloną w celu uzasadnienia czegoś na siłę :)

Chyba źle zrozumiałeś (jeśli chodzi o mój komentarz). Jeśli tak, to ja nie pisałem, żeby "load balance robić przez serializację serwletów". W sumie, to raczej chodzi o to, czy w mechanizmie balancingu AS można wykorzystać serializację.

Hymmm przerzucanie stanu (sic!) servletu miedzy JVM... hymm hymmm

Dalej nie do końca moje przesłanie zostało odebrane poprawnie :) Mam na myśli jedną i jedyną sytuację w jakiej miałoby to sens. Mianowicie, poprzedni przykład czasochłonnej operacji w init. W tym sensie stan serwletu można by przerzucać pomiędzy JVM i nie mam na myśli operacji tożsamej z tworzeniem nowej instancji.
Dla przykładu WebSphere w wesji ND (Network Deployed - mam doświadczenie z tym na z/OS), równoważenie obciążenia obsługuje na tej samej partycji. Jest to jeden serwer aplikacji podzielony na węzły i cele. Jest jeden proces kontrolny który zarządza kierowaniem żądań do odpowiednich serwantów. Każdy serwant ma swoją JVM. Ponieważ jest to fizycznie jeden serwer aplikacji, przerzucanie bieżącej instancji do innej JVM może być stosunkowo szybkie.

Przesłanie jest jasne, wymyślasz jak kontener może za ciebie rozwiązać problem z czasochłonnym initem, gdzie rozwiązaniem nie jest jak ten servlet przenieść do innego JVM tylko jak naprawić init ;-)
To zupełnie jak rozwiązanie problemu "Mój czołg nie pływa" przez wymianę pancerza na styropianowy...

EJB też byś serializował i przerzucał między serwerami ?

bez komentarza...

;-)

Nie dopisujcie sobie panowie własnej specyfikacji, gdyż cykl
życia servletów jest jasno określony. Jak sobie dany kontener poczyna z instancjami, ile ich ma , jakich i co z nimi robi jest w dokumentacji kontenera i niema nic wspólnego z GenericServlet który jest tylko klasą pomocniczą powstałą dla wygody developera i zupełnie przypadkowo jest Serializable.

No jest. I co ? Specyfikacja jest dość luźna i nie określa jak realizować pewne rzeczy od strony technicznej.

No właśnie jest luźna, kontener niech sobie robi co chce i jak chce w specyfikacji niema słowa o serializacji więc jej tam nie wkładajmy, zwłaszcza gdy nie jest potrzebna. Jeśli komuś jest potrzebna to niech się poważnie zastanowi nad architekturą swojej aplikacji i jeśli dalej będzie chciał serializować swoje servlety to niech się przestawi na coś gdzie nie będą się czepiać takich pomysłów np .NET

Tutaj się nie zgodzę; a serializacja obiektów wkładnych do sesji ? To jest w zasadzie wymóg implementacji w środowisku rozproszonym. Czyli serwer jest w stanie obsługiwać przerzucanie obiektów z użyciem serializacji. Serwlet jest normalnym obiektem, tylko działającym w innym kontekście. No i nie chodziło mi o to, że ktoś miałby sobie sam serializować serwlety - tym oczywiście powinien zajmować się serwer (gdyby tak rzeczywiście było ;)).Paweł Grotowski edytował(a) ten post dnia 06.12.07 o godzinie 22:46

Nie powinien a mógłby, ale całe szczęście tego nie robi, a problem dużych obiektów rozwiązuje się przez użycie narzędzi w rodzaju Terracotta a nie przez serializacje serwletów ;-)

Temat: Dlaczego GenericServlet jest serializowalny?

.Paweł Grotowski edytował(a) ten post dnia 26.12.07 o godzinie 02:06

Temat: Dlaczego GenericServlet jest serializowalny?

Pawel Dolega:
Servlety jako takie z zalozenia zdaje sie sa bezstanowe (choc to
raczej dobra praktyka niz requirement). A tak sobie pomyslalem, ze przy serializacji trzeba by tez chyba serializowac ServletContext (poprzez ServletConfig) prawda? A jak sie to ma do specyfikacji i czy nie byloby to czyms w rodzaju "inconsistency" ?

Atrybut config (typu ServletContext) w klasie GenericServlet jest "transient".

Generalnie po tym co napisali poprzednicy nie widzę powodu dla którego servlet musiałby być serializowalny (wyjaśnienie z load-balancingiem i metodą init zupełnie do mnie przemawia).
Ale GenericServlet implementuje też interfejs ServletConfig - czy obiekty typu ServletConfig są serializowane przez kontener?

Pozdrawiam

Temat: Dlaczego GenericServlet jest serializowalny?

disclaimer: nie robie w J2EE, ani nie chce mi sie gleboko w to wnikac. imho GenericServlet jest Serializable przez przypadek, jak ktos na tym polega to wydaje sie to dosc sliskie.

W tekscie "servlet specification" nie znalazlem nic o serializacji przez kontener obiektow implementujacych Servlet. Podczas gdy o serializacji obiektow innego rodzaju jest. Zagadka dla dociekliwych - co to sa te inne obiekty - spec jest do sciagniecia ze stron Suna, potem wystarczy wyszukać w nim wystapienia ciagu znakow "serializ".

Temat: Dlaczego GenericServlet jest serializowalny?

Tomasz K.:

Pawel Dolega:
Servlety jako takie z zalozenia zdaje sie sa bezstanowe (choc to
raczej dobra praktyka niz requirement). A tak sobie pomyslalem, ze przy serializacji trzeba by tez chyba serializowac ServletContext (poprzez ServletConfig) prawda? A jak sie to ma do specyfikacji i czy nie byloby to czyms w rodzaju "inconsistency" ?

Atrybut config (typu ServletContext) w klasie GenericServlet jest "transient".

Generalnie po tym co napisali poprzednicy nie widzę powodu dla którego servlet musiałby być serializowalny (wyjaśnienie z load-balancingiem i metodą init zupełnie do mnie przemawia).

Chciałeś napisać "nie przemawia" :). Do mnie przemawia, bo serializacja w prosty sposób zapewnia szybkie zachowanie stanu obiektu jakim jest serwlet. Poza tym, nie chodzi tutaj o GenericServlet, tylko serwlety zaimplementowane pod konkretny protokół :). Kwestia wyobraźni jak to można zrobić.

"32) Why do GenericServlet and HttpServlet implement the Serializable interface?

GenericServlet and HttpServlet implement the Serializable interface so that servlet engines can "hybernate" the servlet state when the servlet is not in use and reinstance it when needed or to duplicate servlet instances for better load balancing. I don't know if or how current servlet engines do this, and it could have serious implications, like breaking references to objects gotten in the init() method without the programmer knowing it. Programmers should be aware of this pitfall and implement servlets which are stateless as possible, delegating data store to Session objects or to the ServletContext. In general stateless servlets are better because they scale much better and are cleaner code."
http://faqs.javabeat.net/servlet/java-servlets-intervi...

Spotkałem się także z tym, że po prostu serwlety mogą być serializowane do wykorzystania w różnych narzędziach developerskich albo do zrzucania stanu w celach analizy błędów.

Ale GenericServlet implementuje też interfejs ServletConfig - czy
obiekty typu ServletConfig są serializowane przez kontener?

Pozdrawiam

Paweł Grotowski edytował(a) ten post dnia 28.12.07 o godzinie 22:42

Temat: Dlaczego GenericServlet jest serializowalny?

Marcin Stefaniak:
disclaimer: nie robie w J2EE, ani nie chce mi sie gleboko w to wnikac. imho GenericServlet jest Serializable przez przypadek, jak ktos na tym polega to wydaje sie to dosc sliskie.

W tekscie "servlet specification" nie znalazlem nic o serializacji przez kontener obiektow implementujacych Servlet. Podczas gdy o serializacji obiektow innego rodzaju jest. Zagadka dla dociekliwych - co to sa te inne obiekty - spec jest do sciagniecia ze stron Suna, potem wystarczy wyszukać w nim wystapienia ciagu znakow "serializ".

Te inne obiekty, to np. obiekty umieszczane w sesji HTTP, kiedy aplikacja pracuje jako distributed.

Temat: Dlaczego GenericServlet jest serializowalny?

Te inne obiekty, to np. obiekty umieszczane w sesji HTTP, kiedy aplikacja pracuje jako distributed.

a czy można w tym zdaniu opuścić "np."?