🚀 go-pugleaf

On 10/17/2011 07:57 PM, Michal wrote:

> jezeli wrzoce jakas klase do katalogu tomcat/lib i jezeli odpale dwie aplikacje(dwa wary), ktore korzystaja z tej klasy
> to czy kazda aplikacja zaladuje do pamieci swoja wersje tej klasy, czy zostanie on zaladowana tylko raz.

Plik .class będzie załadowany tylko raz, przez classloader tomcata.

> Pytanie wynika z tad, iz mam zestaw aplikacji, ktore kozystaja z wielu wspolnych bibliotek i odpalane sa na
> tym samym serwerze. Po pewnym czasie wylatuje znany wyjatek ...OutOfMemory: PermGen... i zastanawiam sie czy
> jezeli zaleznosci te przeniose z plikow war do tomcat/lib to czy beda one ladowane tylko raz, a tym samym
> czy zajma mniej pamieci PermGen.

To jest nic innego jak proszenie się o kłopoty.
Aby poradzić sobie z PermGen: daj Tomcatowi więcej pamięci, podaj 
explicite rozmiary odpowiednich stert, nie używaj hotdeploya (czyli 
restart tomcata po podmianie wara).

I zainwestuj w słownik ortograficzny!

W dniu 2011-10-17 21:21, Mikolaj Rydzewski pisze:
> On 10/17/2011 07:57 PM, Michal wrote:
>
>> jezeli wrzoce jakas klase do katalogu tomcat/lib i jezeli odpale dwie
>> aplikacje(dwa wary), ktore korzystaja z tej klasy
...
>
> To jest nic innego jak proszenie się o kłopoty.
> Aby poradzić sobie z PermGen: daj Tomcatowi więcej pamięci, podaj
> explicite rozmiary odpowiednich stert, nie używaj hotdeploya (czyli
> restart tomcata po podmianie wara).

Zgodził by się.

Wtykałem kiedyś do ogólnego "lib" czy to driver JDBC, czy kompletne bazy 
embeded H2, Derby, EhCache itp. One trzymają pliki, robią jakieś 
singletony czy ki ciort, undeploy się nie udaje do końca.
Motywowałem się wtedy a) rozmiarem WAR, b) nadzieją na jakąś oszczędność 
połączeń. Z czasem przestałem, mam to w WAR (łącznie z driverem JDBC 
MSSQL na co ortodoksi się pewnie pokrzywią). Najmniej mnie zaskoczy z 
jakąś plątającą się starszą wersją itp. Etap przejścia w jeden większy 
WAR zbiegł się z konsekwentnym stosowanie Mavena w developerce.

Na hotdeploy w środowisku Tomcat stosuję tzw 'antiJarLocking' (obie 
filozofie miały ten problem, choć z innym natężeniem) ale ja to robię z 
zupełnie innych motywacji, akurat nie o RAM chodzi, bo przypuszczam ta 
metoda jest raczej rozrzutna. A pełny restart przynajmniej co 2-3 x jest 
najpewniejszy.

Więc zgadza się, że pomysł kolegi to problemy.
Dość niedawno skopała mnie zapomniana biblioteka w starszej wersji 
(żadna zjadająca zasoby czy pliki, zwykła biblioteka), tam zapomniana.

On 10/18/2011 11:18 AM, Jacek Czerwinski wrote:

> Na hotdeploy w środowisku Tomcat stosuję tzw 'antiJarLocking'

Ww jest sens używać w Windows - bo tam używane jary są blokowane (tzn. 
jest lock na plikach i nie można ich usunąć). Na Linuksie nie ma tego 
ficzeru.
Co nie zmienia faktu, że problem wyciekających zasobów (wiszące 
classloadery zapychające PermGen) nadal występuje.

Jak widze wiekszosc osob odradza taki sposob, rozumiem zagroznia. Jednak w projekcie jest duzo bibliotek
wspoldzielonych i zajmuja one po spakowaniu okolo 100MB, wiec po rozpakowaniu bedzie okolo 400-700MB (tak wynika
z szybkiej estymacji). To jest niestety duzo jak na sam kod aplikacji, wiec wypada cos z tym zrobic. Szukam, wiec
najlepszych sposobow.

-- 
Michal

W dniu 2011-10-26 19:12, Michal pisze:
> Jak widze wiekszosc osob odradza taki sposob, rozumiem zagroznia. Jednak w projekcie jest duzo bibliotek
> wspoldzielonych i zajmuja one po spakowaniu okolo 100MB, wiec po rozpakowaniu bedzie okolo 400-700MB (tak wynika
> z szybkiej estymacji). To jest niestety duzo jak na sam kod aplikacji, wiec wypada cos z tym zrobic. Szukam, wiec
> najlepszych sposobow.
> 

ja mam trochę inne zdanie niż przedmówcy, no ale to grupa dyskusyjna,
więc jeśli ktoś się nie zgadza to tym lepiej :)
jeśli masz dwie aplikacje nad którymi masz całkowite panowanie to
zrobienie customizowanej instalacji tomcata z bibliotekami w lib nie
powinno przynieść problemów. pomijając kwestie współdzielenia pamięci
rozwiązywaliśmy kiedyś w ten sposób problem przesyłania dużych warów
przez vpna klienta, który był wyjątkowo parszywy :) (robiłem to na jboss
tak dokładnie)
do liba najlepiej wrzucić biblioteki, które się nie zmieniają (jakieś
zewnętrzne twory przykładowo), bo tu można natknąć się na problemy typu
coś działa inaczej niż powinno :)
w ten sposób utrzymywanie bibliotek więcej problemów może przynieść w
serwerach aplikacji typu jboss jak używamy jakiś ejb itp ale w czystym
tomcacie imho można spróbować

On 10/26/2011 09:03 PM, Tomek Łabuz wrote:

> do liba najlepiej wrzucić biblioteki, które się nie zmieniają (jakieś
> zewnętrzne twory przykładowo), bo tu można natknąć się na problemy typu
> coś działa inaczej niż powinno :)

Jaką masz gwarancję, że w taka 'uwspólniona' biblioteka nie używa swoich 
singletonów bądź innych wynalazków? Wtedy dopiero będziesz miał 
prawdziwego singletona - jeden dla całego Tomcata. A raczej nie tego byś 
się spodziewał...
Nie chciałbym potem diagnozować problemów w takim środowisku.

On 10/26/2011 07:12 PM, Michal wrote:
> Jak widze wiekszosc osob odradza taki sposob, rozumiem zagroznia. Jednak w projekcie jest duzo bibliotek
> wspoldzielonych i zajmuja one po spakowaniu okolo 100MB, wiec po rozpakowaniu bedzie okolo 400-700MB (tak wynika
> z szybkiej estymacji). To jest niestety duzo jak na sam kod aplikacji, wiec wypada cos z tym zrobic. Szukam, wiec
> najlepszych sposobow.

Dlaczego to ma być dużo? Bo tak Ci się wydaje, czy jest to tylko 
niewygodne (np. aby przy codziennym deployu przepychać na serwer w stanach)?
Można zoptymalizować sam proces budowania wara - np. przesyłać za ocean 
tylko 'twoje' klasy, a całość spakować już zdalnie?

Jeśli już chcesz odchudzać aplikację, to zrób to jak należy. Wyodrębnij 
moduły, określ API, zrób z nich odrębne komponenty (które można jako 
osobne wary uruchomić), połącz wszystko jak należy (WS, RMI, znajdzie 
się trochę technologii do wyboru). Jeśli nic nie zepsujesz, to przy 
okazji otrzymasz niezłe rozproszone środowisko.
Tylko może od razu lepiej zacznij migrację do EJB? :-)

A tak z innej beczki: biblioteki po spakowaniu (to one nie są już w 
jarach?) zajmują x MB. To po co je rozpakowywać? Przecież chyba nie 
liczysz zajętości pamięci poprzez rozmiar plików class?

W dniu 2011-10-27 20:22, Mikolaj Rydzewski pisze:
> On 10/26/2011 09:03 PM, Tomek Łabuz wrote:
> 
>> do liba najlepiej wrzucić biblioteki, które się nie zmieniają (jakieś
>> zewnętrzne twory przykładowo), bo tu można natknąć się na problemy typu
>> coś działa inaczej niż powinno :)
> 
> Jaką masz gwarancję, że w taka 'uwspólniona' biblioteka nie używa swoich
> singletonów bądź innych wynalazków? Wtedy dopiero będziesz miał
> prawdziwego singletona - jeden dla całego Tomcata. A raczej nie tego byś
> się spodziewał...
> Nie chciałbym potem diagnozować problemów w takim środowisku.

a jaką ja mam gwarancję na cokolwiek przy zewnętrznych bibliotekach?
btw - odpalając np jbossa przy okazji współdzielisz milion klas
zewnętrznych ze stajni jbossa i innych, masz gwarancję, że czegoś nie
spieprzyli? specjalnie to się nie różni od tego co tu rozpatrujemy
czy współdzieląc np takie richfaces na tomcacie zrobię coś innego niż
zrobili to twórcy JBossa? czy współdzieląc hibernate zrobię coś innego
niż własna "implementacja jpa" w środowisku serwera aplikacyjnego?
mam wątpliwości (zdarza mi się czytać doc albo nawet pokukać w kod :) )
albo środowisko nie pozwala nie współdzielę, ale zdarzyło mi się zrobić
takie coś hmmmm, dwa razy i póki co większe problemy miałem w swoim
kodzie niż z powodu takiego współdzielenia...

> Dlaczego to ma być dużo? Bo tak Ci się wydaje, czy jest to tylko
> niewygodne (np. aby przy codziennym deployu przepychać na serwer w
> stanach)?
> Można zoptymalizować sam proces budowania wara - np. przesyłać za ocean
> tylko 'twoje' klasy, a całość spakować już zdalnie?
> 
> Jeśli już chcesz odchudzać aplikację, to zrób to jak należy. Wyodrębnij
> moduły, określ API, zrób z nich odrębne komponenty (które można jako
> osobne wary uruchomić), połącz wszystko jak należy (WS, RMI, znajdzie
> się trochę technologii do wyboru). Jeśli nic nie zepsujesz, to przy
> okazji otrzymasz niezłe rozproszone środowisko.
"jeśli nic nie zepsujesz"... no właśnie
imho idealny przepis żeby z prostej aplikacji zrobić enterprajsowego
potworka, już widziałem takie aplikacje, w których żeby dopisać jedną
prostą metodę trzeba było zrobić najpierw doktorat a potem ostro
zastanowić się ile jeszcze trzeba przebudować elementów żeby to zaczęło
działać po tej zmianie....
potem się dziwić, że opinia na "mieście" jest taka, że java to się tylko
do duuuużych rzeczy nadaje, bo mniejsze to się pisze tak samo długo jak
te duże, to po co... można wziąć coś innego i będzie szybciej....

On 10/27/2011 08:57 PM, Tomek Łabuz wrote:

> "jeśli nic nie zepsujesz"... no właśnie
> imho idealny przepis żeby z prostej aplikacji zrobić enterprajsowego
> potworka, już widziałem takie aplikacje, w których żeby dopisać jedną
> prostą metodę trzeba było zrobić najpierw doktorat a potem ostro
> zastanowić się ile jeszcze trzeba przebudować elementów żeby to zaczęło
> działać po tej zmianie....
> potem się dziwić, że opinia na "mieście" jest taka, że java to się tylko
> do duuuużych rzeczy nadaje, bo mniejsze to się pisze tak samo długo jak
> te duże, to po co... można wziąć coś innego i będzie szybciej....

Czyżby więc najlepszą odpowiedzią było: dołożyć RAMu? :-)

On 10/27/2011 08:42 PM, Tomek Łabuz wrote:

> a jaką ja mam gwarancję na cokolwiek przy zewnętrznych bibliotekach?
> btw - odpalając np jbossa przy okazji współdzielisz milion klas
> zewnętrznych ze stajni jbossa i innych, masz gwarancję, że czegoś nie
> spieprzyli? specjalnie to się nie różni od tego co tu rozpatrujemy
> czy współdzieląc np takie richfaces na tomcacie zrobię coś innego niż
> zrobili to twórcy JBossa? czy współdzieląc hibernate zrobię coś innego
> niż własna "implementacja jpa" w środowisku serwera aplikacyjnego?
> mam wątpliwości (zdarza mi się czytać doc albo nawet pokukać w kod :) )
> albo środowisko nie pozwala nie współdzielę, ale zdarzyło mi się zrobić
> takie coś hmmmm, dwa razy i póki co większe problemy miałem w swoim
> kodzie niż z powodu takiego współdzielenia...

Wg mnie skórka niewarta wyprawki.
Zyskujemy trochę pamięci/dysku. Tracimy na kosztach utrzymania, 
debugowania, testowania.

Zresztą temat zaczął się od 'OutOfMemory: PermGen'. Nie wiemy czy 
jakikolwiek tuning ustawień pamięci był przeprowadzony. A zaczynanie 
optymalizacji od rewolucji w classloaderach to jest kiepski pomysl.

W dniu 2011-10-27 21:20, Mikolaj Rydzewski pisze:
> On 10/27/2011 08:57 PM, Tomek Łabuz wrote:
> 
>> "jeśli nic nie zepsujesz"... no właśnie
>> imho idealny przepis żeby z prostej aplikacji zrobić enterprajsowego
>> potworka, już widziałem takie aplikacje, w których żeby dopisać jedną
>> prostą metodę trzeba było zrobić najpierw doktorat a potem ostro
>> zastanowić się ile jeszcze trzeba przebudować elementów żeby to zaczęło
>> działać po tej zmianie....
>> potem się dziwić, że opinia na "mieście" jest taka, że java to się tylko
>> do duuuużych rzeczy nadaje, bo mniejsze to się pisze tak samo długo jak
>> te duże, to po co... można wziąć coś innego i będzie szybciej....
> 
> Czyżby więc najlepszą odpowiedzią było: dołożyć RAMu? :-)

można, czemu nie, zresztą nie wiem tak do końca czy takie współdzielenie
bibliotek daje wymierne oszczędności w zużyciu pamięci (przecież
wielkość jarów nie przekłada się 1:1 na RAM a do tego najwięcej zżera
zazwyczaj nasz program :) )
ja tylko nie wykluczałbym próby takiego rozwiązania, osobiście jak
pisałem zdarzyło mi się użyć ale w zupełnie innym celu i zużycia pamięci
nie sprawdzałem
do tego zdaje się RAM tańszy niż praca programisty :)

W dniu 2011-10-27 21:41, Mikolaj Rydzewski pisze:
> On 10/27/2011 08:42 PM, Tomek Łabuz wrote:
> 
>> a jaką ja mam gwarancję na cokolwiek przy zewnętrznych bibliotekach?
>> btw - odpalając np jbossa przy okazji współdzielisz milion klas
>> zewnętrznych ze stajni jbossa i innych, masz gwarancję, że czegoś nie
>> spieprzyli? specjalnie to się nie różni od tego co tu rozpatrujemy
>> czy współdzieląc np takie richfaces na tomcacie zrobię coś innego niż
>> zrobili to twórcy JBossa? czy współdzieląc hibernate zrobię coś innego
>> niż własna "implementacja jpa" w środowisku serwera aplikacyjnego?
>> mam wątpliwości (zdarza mi się czytać doc albo nawet pokukać w kod :) )
>> albo środowisko nie pozwala nie współdzielę, ale zdarzyło mi się zrobić
>> takie coś hmmmm, dwa razy i póki co większe problemy miałem w swoim
>> kodzie niż z powodu takiego współdzielenia...
> 
> Wg mnie skórka niewarta wyprawki.
> Zyskujemy trochę pamięci/dysku. Tracimy na kosztach utrzymania,
> debugowania, testowania.

które i tak zazwyczaj realizujemy, czy nie? :)
to robimy sobie zawczasu środowisko i można testować
> 
> Zresztą temat zaczął się od 'OutOfMemory: PermGen'. Nie wiemy czy
> jakikolwiek tuning ustawień pamięci był przeprowadzony. A zaczynanie
> optymalizacji od rewolucji w classloaderach to jest kiepski pomysl.

tak, z tym się zgodzę, masz rację, czasem trzeba coś zmienić tylko w
ustawieniach pamięci - np na standardowej konfiguracji ostatnie dwie
aplikacje jakie popełniłem tylko kwikły i od razu się zwinęły :) dwa
pstryczki i działają :)
ja tylko jestem zdania, że takie współdzielenie to nie jest z definicji
problem, ważne co i jak się współdzieli, generowanie problemów to się
zaczyna w momencie napisania pierwszej linijki kodu :D :D

Widze, ze to goracy temat.
Dzisiaj robilem test i okazuje sie, ze przeniesienie bibliotek do tomcat/lib 
daje kolosalne oszczednosci na permgenie.

Do testów sluzyla mi prosta aplikacja z uzyciem springa 3 oraz 
JSF2/PrimeFacesM3. Kazdy deploy zajmowal nieco ponad 20 MB perm gena, po 3 
deployach tej samej aplikacji w róznych kontekstach przy standardowych 
ustawienich JVM (cos kolo 70MB) dostawalem out of memory. Po przeniesieniu 
wszystkich bibliotek z liba aplikacji do liba tomacatowego, po 5 deployach 
zajetosc permgena wynosila okolo 40MB.
Wiec jesli masz model, kiedy np. deployujesz na serwerze te sama aplikacje 
dla róznych klientów i zakladasz, ze wszystkie aplikacje zawsze beda 
dzialaly z taka sama wersja jarów, to przeniesienie
ma gleboki sens. Poza tym, nie musisz przenosic wszystkiego.
Pomijam kwestie szybkosci deployu bo tego nie testowalem.

Pewnie jestescie ciekawi jak testowalem. Ot, jak to pogromcy mitów - na oko. 
Odpalilem tomcata
i visualvm. Deployowalem aplikacje i obserwowalem co sie dzieje z permgenem.

pozdrawiam
robson

> jezeli wrzoce jakas klase do katalogu tomcat/lib i jezeli odpale dwie 
> aplikacje(dwa wary), ktore korzystaja z tej klasy
> to czy kazda aplikacja zaladuje do pamieci swoja wersje tej klasy, czy 
> zostanie on zaladowana tylko raz.
>
> Pytanie wynika z tad, iz mam zestaw aplikacji, ktore kozystaja z wielu 
> wspolnych bibliotek i odpalane sa na
> tym samym serwerze. Po pewnym czasie wylatuje znany wyjatek 
> ...OutOfMemory: PermGen... i zastanawiam sie czy
> jezeli zaleznosci te przeniose z plikow war do tomcat/lib to czy beda one 
> ladowane tylko raz, a tym samym
> czy zajma mniej pamieci PermGen.
>
> -- 
> Michal 

W dniu 2011-10-27 22:46, smiejta_sie_z_tego pisze:
> Widze, ze to goracy temat.

dlaczego jak dwie osoby mają inne zdania to od razu gorący temat?
szczególnie, że jeśli Mikołaj to ten Mikołaj o którym myślę to chętnie z
nim ten temat omówię przy jakimś płynie w dowolnym kolorze? :D

> Dzisiaj robilem test i okazuje sie, ze przeniesienie bibliotek do tomcat/lib 
> daje kolosalne oszczednosci na permgenie.

no i good
jeszcze posprawdzaj czy tam coś na wielu wątkach się nie sypie, itp i
kto wie, może będzie działać
ale 40MB oszczędności to mnie na kolana nie powala, Twoja aplikacja
pewnie po paru minutach działania zassie dużo więcej :)

> jeszcze posprawdzaj czy tam coś na wielu wątkach się nie sypie, itp i
> kto wie, może będzie działać
dlaczego mialoby sie sypac?

> ale 40MB oszczędności to mnie na kolana nie powala, Twoja aplikacja
> pewnie po paru minutach działania zassie dużo więcej :)
nie powala bo zle policzylesz:
3 deploye wywalało 70MB permgena, 5 deploi zajęło 40MB permgena

No i mam jeszcze wazny komunikat: nie ssie!

pozdrawiam
robson

Użytkownik "Tomek Łabuz" <javatrainings@gmail.com> napisał w wiadomości 
news:j8cgv6$rbp$1@news.onet.pl...
>W dniu 2011-10-27 22:46, smiejta_sie_z_tego pisze:
>> Widze, ze to goracy temat.
>
> dlaczego jak dwie osoby mają inne zdania to od razu gorący temat?
> szczególnie, że jeśli Mikołaj to ten Mikołaj o którym myślę to chętnie z
> nim ten temat omówię przy jakimś płynie w dowolnym kolorze? :D
>
>> Dzisiaj robilem test i okazuje sie, ze przeniesienie bibliotek do 
>> tomcat/lib
>> daje kolosalne oszczednosci na permgenie.
>
> no i good
> jeszcze posprawdzaj czy tam coś na wielu wątkach się nie sypie, itp i
> kto wie, może będzie działać
> ale 40MB oszczędności to mnie na kolana nie powala, Twoja aplikacja
> pewnie po paru minutach działania zassie dużo więcej :)
>
> 

W dniu 2011-10-27 23:10, smiejta_sie_z_tego pisze:
>> jeszcze posprawdzaj czy tam co� na wielu w�tkach si� nie sypie, itp i
>> kto wie, mo�e b�dzie dzia�a�
> dlaczego mialoby sie sypac?
> 

nie twierdzę, że będzie, akurat ja nie jestem przeciwny opcji
współdzielenia bibliotek ale  tak zazwyczaj już jest z tymi
aplikacjami... "u mnie działa" przeradza się "ale się sypie" jak tylko
przyjdzie jakieś obciążenie :) bo coś się nie synchronizuje, bo ktoś coś
za dużo współdzieli albo za mało... ot takie tam drobnostki :)

>> ale 40MB oszcz�dno�ci to mnie na kolana nie powala, Twoja aplikacja
>> pewnie po paru minutach dzia�ania zassie du�o wi�cej :)
> nie powala bo zle policzylesz:
> 3 deploye wywala�o 70MB permgena, 5 deploi zaj�o 40MB permgena
> 

ojej, złapałeś mnie... możesz się cieszyć


> No i mam jeszcze wazny komunikat: nie ssie!

a kto albo co nie ssie i dlaczego? :)

On 10/27/2011 10:46 PM, smiejta_sie_z_tego wrote:

> Wiec jesli masz model, kiedy np. deployujesz na serwerze te sama aplikacje
> dla róznych klientów i zakladasz, ze wszystkie aplikacje zawsze beda
> dzialaly z taka sama wersja jarów, to przeniesienie
> ma gleboki sens.

Oszczędność pamięci w tym przypadku bierze się z tego, że klasa jest 
ładowana raz przez kontener, a nie przez każdą z aplikacji z osobna. W 
szczególności jej pola statyczne także są wspólne między aplikacjami.
W świetle powyższego byłbym ostrożny z opinią, że operacja taka ma 
głęboki sens (i jeszcze dla różnych klientów)...
Choćby z tego powodu, że nie mam zamiaru analizować każdej z bibliotek 
pod kątem takiego sposobu jej używania, to wolę mieć je w osobnych 
classloaderach.

A tak z zupełnie innej beczki, to parę razy widziałem już taki schemat:
1. Firma spłodziła aplikację, hostuje ja u siebie,
2. Zdobywa się nowego klienta,
3. Zakłada mu się nową bazę, do istniejącego już tomcata dogrywa się 
nowego wara różniącego się od poprzedniego tylko JDBC URLem.

I tu jest pies pogrzebany - bo zamiast mieć jedną aplikację 
przystosowaną do pracy dla wielu klientów, uruchamiamy n-kopii 
zaśmiecając pamięć i marnując zasoby.

> A tak z zupełnie innej beczki, to parę razy widziałem już taki schemat:
> 1. Firma spłodziła aplikację, hostuje ja u siebie,
> 2. Zdobywa się nowego klienta,
> 3. Zakłada mu się nową bazę, do istniejącego już tomcata dogrywa się
> nowego wara różniącego się od poprzedniego tylko JDBC URLem.
> 
> I tu jest pies pogrzebany - bo zamiast mieć jedną aplikację
> przystosowaną do pracy dla wielu klientów, uruchamiamy n-kopii
> zaśmiecając pamięć i marnując zasoby.

no ale nie każdą aplikację od razu piszesz tak żeby była dla n klientów,
czasem się trafia ten drugi czy trzeci kompletnie przypadkiem :)

ja widziałem jeszcze ciekawsze rozwiązanie
były sobie 3 aplikacje składające się na jeden system
uruchamiane były na jednej fizycznej maszynie na 3 osobnych instancjach
jbossa na 32bit win serwer i komunikowały się miedzy sobą za pomocą web
service
zaorało to win na amen ale ponieważ nie było innej koncepcji system
rozwinął się w 6 sklastrowanych takich samych serwerów (przepraszam,
zestawów 3 jbossów) i nadal się sypało... a win ledwo zipał przy prawie
zerowym obciążeniu :)

On 2011-10-28 00:03, Tomek Łabuz wrote:
> ja widziałem jeszcze ciekawsze rozwiązanie
> były sobie 3 aplikacje składające się na jeden system
> uruchamiane były na jednej fizycznej maszynie na 3 osobnych instancjach
> jbossa na 32bit win serwer i komunikowały się miedzy sobą za pomocą web
> service
> zaorało to win na amen ale ponieważ nie było innej koncepcji system
> rozwinął się w 6 sklastrowanych takich samych serwerów (przepraszam,
> zestawów 3 jbossów) i nadal się sypało... a win ledwo zipał przy prawie
> zerowym obciążeniu :)

To zamowienia publiczne?

Pytam, bo oni czesto maja tak, ze kupuja system, ktory nikomu do niczego 
nie jest potrzebny, wiec nie ma zadniego znaczenia, czy dziala.

-- 
Michal

W dniu 2011-10-28 08:07, Michal Kleczek pisze:
> On 2011-10-28 00:03, Tomek Łabuz wrote:
>> ja widziałem jeszcze ciekawsze rozwiązanie
>> były sobie 3 aplikacje składające się na jeden system
>> uruchamiane były na jednej fizycznej maszynie na 3 osobnych instancjach
>> jbossa na 32bit win serwer i komunikowały się miedzy sobą za pomocą web
>> service
>> zaorało to win na amen ale ponieważ nie było innej koncepcji system
>> rozwinął się w 6 sklastrowanych takich samych serwerów (przepraszam,
>> zestawów 3 jbossów) i nadal się sypało... a win ledwo zipał przy prawie
>> zerowym obciążeniu :)
> 
> To zamowienia publiczne?

si

> 
> Pytam, bo oni czesto maja tak, ze kupuja system, ktory nikomu do niczego
> nie jest potrzebny, wiec nie ma zadniego znaczenia, czy dziala.

ten był potrzebny wg mnie i nie tylko :)

> I tu jest pies pogrzebany - bo zamiast mieć jedną aplikację przystosowaną 
> do pracy dla wielu klientów, uruchamiamy n-kopii zaśmiecając pamięć i 
> marnując zasoby.

No właśnie! Czym jest, jak nie marnowaniem pamięci i zasobów, deployowanie
tych samych jarów w róznych kontekstach?

Czyli przeniesienie wspólnych bibliotek do tomcat/lib ma sens, a czy głeboki 
niech kazdy
rozstrzygnie to w ramach swojego projektu.

Nie twierdze, ze to eleganckie rozwiązanie i nie zalecam przenoszenia w 
ciemno wszystkiego
z liba aplikacji do tomacata ale odpowiedni wybór bobliotek, które zostaną
przeniesione do tomcat/lib może dać wymierne korzysci.

 pozdrawiam
 robson

smiejta_sie_z_tego <dodatkowo_zwracam@gazeta.pl> napisał(a)
>> I tu jest pies pogrzebany - bo zamiast mieæ jedn± aplikacjê przystosowan± 
>> do pracy dla wielu klientów, uruchamiamy n-kopii za¶miecaj±c pamiêæ i 
>> marnuj±c zasoby.
>
> No w³a¶nie! Czym jest, jak nie marnowaniem pamiêci i zasobów, deployowanie
> tych samych jarów w róznych kontekstach?
>
> Czyli przeniesienie wspólnych bibliotek do tomcat/lib ma sens, a czy g³eboki 
> niech kazdy
> rozstrzygnie to w ramach swojego projektu.
>
> Nie twierdze, ze to eleganckie rozwi±zanie i nie zalecam przenoszenia w 
> ciemno wszystkiego
> z liba aplikacji do tomacata ale odpowiedni wybór bobliotek, które zostan±
> przeniesione do tomcat/lib mo¿e daæ wymierne korzysci.
>

To może spróbujemy stworzyć listę bibliotek, które nie sprawiają
problemów, przy uwspólnianiu. Wiem, że nikomu nie da to 100% pewności,
ale może będzie jakąś wskazówką.



-- 
Tomek

Dnia 28-10-2011 o 12:24:48 Tomek Kańka <tom@tomkan.eu.org> napisał(a):

> To może spróbujemy stworzyć listę bibliotek, które nie sprawiają
> problemów, przy uwspólnianiu. Wiem, że nikomu nie da to 100% pewności,
> ale może będzie jakąś wskazówką.

WebSphere'owego klienta (com.ibm.ws.ejb.thinclient_7.0.0.jar,  
com.ibm.ws.sib.client.thin.jms_7.0.0.jar) trzeba wrzucić do tomcat/lib, bo  
wrzucony do aplikacyjnego classloadera wywala aplikację. Bez problemu  
działa jako biblioteka współdzielona.

-- 
Boguś

W dniu 2011-10-28 20:29, Michal pisze:
> Sterownik jdbc dla MySQL monza wzocic do tomcat/lib. Wrzocony do wara z aplikacja sprawia problemy
> -- nie pamietam doklanie jakie ale pamietam, ze uniemozliwialy one laczenie sie do tej bazy.
zależy - może chciałeś zrobić konfigurację datasource na poziomie
serwera? wtedy faktycznie nie będzie działać jeśli klasy są na poziomie
aplikacji

Sterownik jdbc dla MySQL monza wzocic do tomcat/lib. Wrzocony do wara z aplikacja sprawia problemy
-- nie pamietam doklanie jakie ale pamietam, ze uniemozliwialy one laczenie sie do tej bazy.


-- 
Michal

On 10/28/2011 08:29 PM, Michal wrote:
> Sterownik jdbc dla MySQL monza wzocic do tomcat/lib. Wrzocony do wara z aplikacja sprawia problemy
> -- nie pamietam doklanie jakie ale pamietam, ze uniemozliwialy one laczenie sie do tej bazy.

'Wzocic' to nic nie 'monza'.
Za to gdy poczyta się dokumentację Tomcata, to będzie wiadomo dlaczego 
drivery JDBC udostępniane przez JNDI mają być w serwerowym classloaderze.

On Fri, 28 Oct 2011 23:49:05 +0200
Mikolaj Rydzewski <miki@ceti.pl> wrote:

> On 10/28/2011 08:29 PM, Michal wrote:
> > Sterownik jdbc dla MySQL monza wzocic do tomcat/lib. Wrzocony do wara z aplikacja sprawia problemy
> > -- nie pamietam doklanie jakie ale pamietam, ze uniemozliwialy one laczenie sie do tej bazy.
> 
> 'Wzocic' to nic nie 'monza'.
> Za to gdy poczyta się dokumentację Tomcata, to będzie wiadomo dlaczego 
> drivery JDBC udostępniane przez JNDI mają być w serwerowym classloaderze.
> 


Panie polonisto w jezyku polskim nie ma takiego slowa jak "classloaderze", w jezyku angielskim zreszta tez nie.

-- 
Michal