Could not close a JDBC result set
Piotrek_20
Testuje wlasnie swoja aplikacje jmeterem. Aplikacja napisana w Seamie
2.1.1GA, JSF 1.2, Facelets, EJB 3.0 + postgres.
Tworze sobie w jmeterze 100 sesji i klikam w kazdej sesji po w
linkach.
Puscilem serwer na ok 30min i wszystko niby dziala, ALE jak daje Stop
w jmeterze, zeby wylaczyc testowanie jboss nagle pluje mi stacktracem
ze nie moze zamknac zapytan do bazy. I tak pluje nonstop przez
5,10,20min to polki sam go nie wylacze recznie.
W metodach obslugujacych te 2 kliki tylko zwykle native sql oraz
EJBQL'owe zapytania:
getEM().createNativeQuery.
List cos = query.getResultlist().
Nie wiem co moze byc spowodowane tym ze nie moze zamknac statement'ow.
oto moj stacktrace:
2009-01-25 11:23:20,375 WARN [org.hibernate.jdbc.AbstractBatcher]
Could not close a JDBC result set
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841)
at java.util.HashMap$KeyIterator.next(HashMap.java:877)
at org.hibernate.jdbc.AbstractBatcher.closeStatements
(AbstractBatcher.java:314)
at org.hibernate.jdbc.ConnectionManager.afterTransaction
(ConnectionManager.java:297)
at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion
(JDBCContext.java:221)
at org.hibernate.transaction.CacheSynchronization.afterCompletion
(CacheSynchronization.java:85)
at
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion
(SynchronizationImple.java:136)
at
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion
(TwoPhaseCoordinator.java:340)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end
(TwoPhaseCoordinator.java:93)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate
(TransactionImple.java:1382)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit
(BaseTransaction.java:135)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit
(BaseTransactionManagerDelegate.java:87)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit
(ServerVMClientUserTransaction.java:140)
at org.jboss.seam.transaction.UTTransaction.commit(UTTransaction.java:
52)
at org.jboss.seam.util.Work.workInTransaction(Work.java:58)
at org.jboss.seam.transaction.TransactionInterceptor.aroundInvoke
(TransactionInterceptor.java:89)
at org.jboss.seam.intercept.SeamInvocationContext.proceed
(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke
(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed
(SeamInvocationContext.java:68)
at org.jboss.seam.async.AsynchronousInterceptor.aroundInvoke
(AsynchronousInterceptor.java:52)
at org.jboss.seam.intercept.SeamInvocationContext.proceed
(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke
(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation
(JavaBeanInterceptor.java:185)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke
(JavaBeanInterceptor.java:103)
at sun.reflect.GeneratedMethodAccessor875.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:
144)
at org.jboss.seam.async.AsynchronousInvocation$1.process
(AsynchronousInvocation.java:62)
at org.jboss.seam.async.Asynchronous$ContextualAsynchronousRequest.run
(Asynchronous.java:80)
at org.jboss.seam.async.AsynchronousInvocation.execute
(AsynchronousInvocation.java:44)
at org.jboss.seam.async
Ponizej przedstawiam przyklad metody:
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void buildings() {
if (buildingsList == null)
buildingsList = new LinkedList<Construction>();
buildingsList.clear();
try {
long a = System.currentTimeMillis();
//=================================================
if (isTokenReady()) {
time = 0;
calcPlanetResources(idPlanet);
StringBuilder personPlanetBuffer = new StringBuilder("SELECT p
FROM Planets as p " +
"join fetch p.buildings as b " +
"join fetch p.resources as r " +
"join fetch p.galaxy as g " +
"WHERE p.id = " + idPlanet);
Query personPlanetQuery = getEM().createQuery
(personPlanetBuffer.toString());
Planets userPlanet = (Planets)personPlanetQuery.getSingleResult();
getEM().lock(userPlanet, LockModeType.WRITE);
getEM().refresh(userPlanet);
minPop = calcMinPop(userPlanet);
loadProduction(userPlanet);
enableToken();
}
//=================================================
long b = System.currentTimeMillis();
logError(currentPerson, (b - a), "buildingsAction", "buildings");
} catch (EJBException e) {
}
}
czy ktos moze ma rade gdzie moge szukac winy tego?
Gdybym uzywal jdbc to wiadomo ze zle zamknalem statement, ale tutaj?
Witold Szczerba
> Witam,
> Testuje wlasnie swoja aplikacje jmeterem. Aplikacja napisana w Seamie
[...]
> Ponizej przedstawiam przyklad metody:
>
> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
> public void buildings() {
[...]
> try {
[...]
> } catch (EJBException e) {
> }
Co to za dziwaczna konstrukcja, żeby wewnątrz metody komponentu
sesyjnego robić:
try {
...
} catch (EJBException e) {
}
Nie dość, że starasz się przechwycić wyjątek, którego raczej nie
powinieneś przechwytywać, to jeszcze jak już to się uda (zdaje się, że
wyjątek źródłowy opakowywany jest w EJBException przeważnie po
opuszczeniu metody), to go ignorujesz!? Skąd takie rozwiązanie
wytrzasnąłeś?
Piotrek_20
pare informacji, ktore loguje do pliku dizennika. dlatego mam catch
(EJBException)
ale nie odpowiedziales mi na moje pytanie?
Piotrek_20
Czy moglbys mi wytlumaczyc co jest zlego w tym co robie:
try {
....
} catch (EJBException e) {
log.error(...)
}
??
Witold Szczerba
> to jest znacznie uproszczony kod, dla przykladu. w bloku catch mam
> pare informacji, ktore loguje do pliku dizennika. dlatego mam catch
> (EJBException)
OK, logujesz czy nie logujesz, nigdy nie widziałem, żeby wewnątrz
metody EJB przechwytywać wyjątki kontenera.
> ale nie odpowiedziales mi na moje pytanie?
Niewiele z tego wszystkiego wynika, może oprócz tego, że niechlujnie
to wygląda... Co to w ogóle za konstrukcja:
"Select blablabla WHERE cośtam = " + jakiśID
Nie widziałeś nigdy konstrukcji:
"Select blablabla WHERE cośtam = ?1"
setParameter(1, jakiśID)
Do tego odwołania do metod, których nie ma, więc nie wiadomo co za
kwiatki w nich siedzą.
Uprość sobie kod do zupełnego minimum i sprawdź testem. Potem dodaj
coś i testuj. I tak dalej. W pewnym momencie zacznie się wywalać i
będziesz miał odpowiedź gdzie przyczyna problemów.
Tomek Łabuz
bo to wyjątek runtime'owy, który raczej nie powinien być przechwytywany,
polecam poczytanie specyfikacji EJB, to raz, dwa - za pierwszym razem w
przykładzie nawet tego log.error nie podałeś czyli założenie zostało iż
go tam nie ma a za to już się powinno iść na kolanach do Częstochowy...
następna sprawa, kolega słyszał kiedyś o SQLInjection?
Pozdrowienia
Tomek
Tomek Łabuz
może to coś pomoże?
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
Witold Szczerba
> bo to wyjątek runtime'owy, który raczej nie powinien być przechwytywany,
> polecam poczytanie specyfikacji EJB, to raz, dwa - za pierwszym razem w
> przykładzie nawet tego log.error nie podałeś czyli założenie zostało iż
> go tam nie ma a za to już się powinno iść na kolanach do Częstochowy...
> następna sprawa, kolega słyszał kiedyś o SQLInjection?
> Pozdrowienia
> Tomek
Nie chodzi o to, że to wyjątek typu Runtime albo że nie powinien być
przechwytywany.
Chodzi o to, że takie wyjątki generuje kontener pakując do środka
przyczynę problemu. Jeśli między try...catch nie odwołujemy się do
innych usług kontenera, to i tak nigdy nic tam nie złapiemy. Poza tym
do EJBException często pakowane są problemy dotyczące bazy danych, a
one z kolei są zgłaszane w chwili zamykania transakcji. Jak wiadomo,
transakcja zamykana jest po wyjściu z naszej metody, więc o złapaniu
tego do naszego bloku catch możemy jedynie pomarzyć.
Tak więc łapanie EJBException nie jest złe samo w sobie, ale to ma
sens bardzo rzadko i widząc nawet fragment kodu jestem przekonany, że
autor nie do końca zdaje sobie sprawę z tego co robi. Jeśli się mylę
to proszę o wskazanie linii kodu, która jest w stanie wyprodukować ten
wyjątek.
Pozdrawiam,
Witold Szczerba
Tomek Łabuz
> On Jan 25, 5:04 pm, Tomek Łabuz <sa...@poczta.onet.pl> wrote:
>> bo to wyjątek runtime'owy, który raczej nie powinien być przechwytywany,
>> polecam poczytanie specyfikacji EJB, to raz, dwa - za pierwszym razem w
>> przykładzie nawet tego log.error nie podałeś czyli założenie zostało iż
>> go tam nie ma a za to już się powinno iść na kolanach do Częstochowy...
>> następna sprawa, kolega słyszał kiedyś o SQLInjection?
>> Pozdrowienia
>> Tomek
>
> Nie chodzi o to, że to wyjątek typu Runtime albo że nie powinien być
> przechwytywany.
przepraszam, źle się wyraziłem (umieściłem przecinki czy co tam się w
mowie pisanej robi :) ), nie chodziło mi o to, że to wyjątek runtimowy
ale, że ten konkretny runtime-owy wyjątek nie powinien być przechwytywany
[...]
> Tak więc łapanie EJBException nie jest złe samo w sobie, ale to ma
> sens bardzo rzadko i widząc nawet fragment kodu jestem przekonany, że
> autor nie do końca zdaje sobie sprawę z tego co robi. Jeśli się mylę
> to proszę o wskazanie linii kodu, która jest w stanie wyprodukować ten
nikt nie wskaże, nie wiemy co robi reszta kodu np inne wywoływane
metody, kto wie co w nich siedzi??
Witold Szczerba
> > to proszę o wskazanie linii kodu, która jest w stanie wyprodukować ten
>
> nikt nie wskaże, nie wiemy co robi reszta kodu np inne wywoływane
> metody, kto wie co w nich siedzi??
To było skierowane do autora, a on w sumie to wie co robi reszta
kodu :)
Tomek Łabuz
myślisz??
;)
Piotrek_20
sesyjnego. Wszystko co zwiazane jest z zarzadzaniem encjami i EJB
tutaj sie znajduje.
Tak slyszalem o EJB injection, ale czepiacie sie nie sedna sprawy.
Tomek Łabuz
> te metody w zasadzie nie robia nic tylko wypelniaja pola komponentu
że przepraszam się zapytam, to komponent stanowy czy bezstanowy?
> sesyjnego. Wszystko co zwiazane jest z zarzadzaniem encjami i EJB
> tutaj sie znajduje.
> Tak slyszalem o EJB injection, ale czepiacie sie nie sedna sprawy.
O SQLInjection, to jak słyszałeś to czemu takie coś generujesz?
Piotrek_20
ad2. w tym przypadku wg. mnie injection nie zadziala to to zwykly int,
ale masz racje ze niepoprawnie to jest zrobione. tak czy siak nie ma
to zwiazku z tematem.
A.L.
wrote:
>Witold Szczerba pisze:
>> On Jan 25, 5:04 pm, Tomek Łabuz <sa...@poczta.onet.pl> wrote:
>>> bo to wyjątek runtime'owy, który raczej nie powinien być przechwytywany,
>>> polecam poczytanie specyfikacji EJB, to raz, dwa - za pierwszym razem w
>>> przykładzie nawet tego log.error nie podałeś czyli założenie zostało iż
>>> go tam nie ma a za to już się powinno iść na kolanach do Częstochowy...
>>> następna sprawa, kolega słyszał kiedyś o SQLInjection?
>>> Pozdrowienia
>>> Tomek
>>
>> Nie chodzi o to, że to wyjątek typu Runtime albo że nie powinien być
>> przechwytywany.
>
>przepraszam, źle się wyraziłem (umieściłem przecinki czy co tam się w
>mowie pisanej robi :) ), nie chodziło mi o to, że to wyjątek runtimowy
>ale, że ten konkretny runtime-owy wyjątek nie powinien być przechwytywany
Jakies pomieszanie z poplataniem. KAZDY wyjatek moze byc
pzrechwytywany, i do decyzji pzrechwytujacego nalezy zdecydowac co z
nim zrobic. Niewatpliwie bledem jest "polkneicie" wyjatku, czyli pusty
handler.
Mozna oczywiscie zalogowac problem, ale z reguly z wyjatkiem cos
tzrena potem zrobic. Na ogol robi sie "re-throw"
Patrz tutaj
http://www.codeguru.com/java/tij/tij0098.shtml
Rethrowing an exception
Sometimes you’ll want to rethrow the exception that you just caught,
particularly when you use Exception to catch any exception. Since you
already have the handle to the current exception, you can simply
re-throw that handle:
catch(Exception e) {
System.out.println("An exception was thrown");
throw e;
}
Rethrowing an exception causes the exception to go to the exception
handlers in the next-higher context. Any further catch clauses for the
same try block are still ignored. In addition, everything about the
exception object is preserved, so the handler at the higher context
that catches the specific exception type can extract all the
information from that object.
i dalej
A.L.
Tomek Łabuz
w innym poście podałem Ci linka do jakiegoś wpisu w JIRA o podobnym
wydźwięku,
<gdybanie> gdzieś współdzielisz tego beana na kilku wątkach i jeden coś
zmienia równocześnie z drugim i coś się sypie?
</gdybanie>
Tomek Łabuz
>>> przechwytywany.
>> przepraszam, źle się wyraziłem (umieściłem przecinki czy co tam się w
>> mowie pisanej robi :) ), nie chodziło mi o to, że to wyjątek runtimowy
>> ale, że ten konkretny runtime-owy wyjątek nie powinien być przechwytywany
>
> Jakies pomieszanie z poplataniem. KAZDY wyjatek moze byc
> pzrechwytywany, i do decyzji pzrechwytujacego nalezy zdecydowac co z
> nim zrobic. Niewatpliwie bledem jest "polkneicie" wyjatku, czyli pusty
> handler.
ależ oczywiście, że masz rację, jednak ten wyjątek w kontenerze EJB
niesie ze sobą pewne informacje być może ważne dla niego dlatego
przechwytywanie tego akurat wyjątku trzeba robić z rozmysłem
>
> Mozna oczywiscie zalogowac problem, ale z reguly z wyjatkiem cos
> tzrena potem zrobic. Na ogol robi sie "re-throw"
w tym przypadku re-throw byłby wskazany ale też łapanie tego wyjątku w
komponencie tylko w celu zalogowania i wyrzucenia wyżej wg mnie jest
średnio sensowne, kontener go obsłuży i zaloguje, chyba, że mamy jakieś
inne wskazania co do prowadzenia logów, ale to już inny temat,
przechwycenie tego wyjątku w komponencie i nie wyrzucenie dalej (co
gorsza wygaszenie go) jest wg mnie błędem
Witold Szczerba
> ależ oczywiście, że masz rację, jednak ten wyjątek w kontenerze EJB
> niesie ze sobą pewne informacje być może ważne dla niego dlatego
> przechwytywanie tego akurat wyjątku trzeba robić z rozmysłem
On Jan 25, A.L. wrote:
> > Mozna oczywiscie zalogowac problem, ale z reguly z wyjatkiem cos
> > tzrena potem zrobic. Na ogol robi sie "re-throw"
Nie czytacie co napisałem. Nie chodzi o to czy łapać czy nie łapać i
czy logować i rzucać czy nie, tylko o to, że łapanie EJBException
wewnątrz metody, która taki wyjątek rzuca klientowi nie znaczy, że go
w ogóle złapiemy. To jest wyjątek generowany przez kontener EJB, i
konstruowany jest zazwyczaj po wyjściu z metody. Jedyna sytuacja, że
taki wyjątek złapiemy wewnątrz tego session bean'a to jest wtedy,
kiedy uruchamiamy inną metodę komponentu poprzez kontener (i tylko
poprzez kontener). Wtedy powinniśmy jednak obwarować raczej konkretne
wywołanie, a nie całą metodę. Na dodatek, jak wspomniałem, często on
powstaje na skutek działań na bazie danych, wtedy nawet "grzechy"
innych komponentów będą złapane i zapakowane do EJBException poza
naszym try-catch. Ponieważ serwer i tak zaloguje ten błąd, może nam
się wydawać, że to nasze logi są widoczne, nie mając świadomości, że
nasz catch {....} się w ogóle nie wykonał (a tam może być coś więcej
niż samo logowanie i wtedy jest konsternacja).
Co do problemu Piotrka_20, to faktycznie prościej by było, gdyby od
razu zdradził, że to Stateful Session Bean (chociaż w sumie, skoro to
Seam, to przecież on na stanowych operuje). To dość częsty błąd, gdy
jedna instancja SFSB jest wykorzystana równolegle, czy to może być to?
Tomek Łabuz
> On Jan 25, 6:36 pm, Tomek Łabuz <sa...@poczta.onet.pl> wrote:
>> ależ oczywiście, że masz rację, jednak ten wyjątek w kontenerze EJB
>> niesie ze sobą pewne informacje być może ważne dla niego dlatego
>> przechwytywanie tego akurat wyjątku trzeba robić z rozmysłem
>
> On Jan 25, A.L. wrote:
>>> Mozna oczywiscie zalogowac problem, ale z reguly z wyjatkiem cos
>>> tzrena potem zrobic. Na ogol robi sie "re-throw"
>
> Nie czytacie co napisałem.
czytamy, przynajmniej ja czytam
> Nie chodzi o to czy łapać czy nie łapać i
> czy logować i rzucać czy nie, tylko o to, że łapanie EJBException
> wewnątrz metody, która taki wyjątek rzuca klientowi nie znaczy, że go
> w ogóle złapiemy. To jest wyjątek generowany przez kontener EJB, i
> konstruowany jest zazwyczaj po wyjściu z metody. Jedyna sytuacja, że
> taki wyjątek złapiemy wewnątrz tego session bean'a to jest wtedy,
> kiedy uruchamiamy inną metodę komponentu poprzez kontener (i tylko
> poprzez kontener).
tak, masz rację
> Wtedy powinniśmy jednak obwarować raczej konkretne
> wywołanie, a nie całą metodę.
a to już wchodzimy w temat jak i gdzie łapać wyjątki a tego nie
rozpatrywałem
> Na dodatek, jak wspomniałem, często on
> powstaje na skutek działań na bazie danych, wtedy nawet "grzechy"
> innych komponentów będą złapane i zapakowane do EJBException poza
> naszym try-catch. Ponieważ serwer i tak zaloguje ten błąd, może nam
> się wydawać, że to nasze logi są widoczne, nie mając świadomości, że
> nasz catch {....} się w ogóle nie wykonał (a tam może być coś więcej
> niż samo logowanie i wtedy jest konsternacja).
jak najbardziej masz rację
>
> Co do problemu Piotrka_20, to faktycznie prościej by było, gdyby od
> razu zdradził, że to Stateful Session Bean (chociaż w sumie, skoro to
> Seam, to przecież on na stanowych operuje). To dość częsty błąd, gdy
> jedna instancja SFSB jest wykorzystana równolegle, czy to może być to?
<gdybanie>
pojawienie się czegoś takiego java.util.ConcurrentModificationException
na to by wskazywało
</gdybanie>
A.L.
<pljos...@gmail.com> wrote:
>On Jan 25, 6:36 pm, Tomek Łabuz <sa...@poczta.onet.pl> wrote:
>> ależ oczywiście, że masz rację, jednak ten wyjątek w kontenerze EJB
>> niesie ze sobą pewne informacje być może ważne dla niego dlatego
>> przechwytywanie tego akurat wyjątku trzeba robić z rozmysłem
>
>On Jan 25, A.L. wrote:
>> > Mozna oczywiscie zalogowac problem, ale z reguly z wyjatkiem cos
>> > tzrena potem zrobic. Na ogol robi sie "re-throw"
>
>Nie czytacie co napisałem. Nie chodzi o to czy łapać czy nie łapać i
>czy logować i rzucać czy nie, tylko o to, że łapanie EJBException
>wewnątrz metody, która taki wyjątek rzuca klientowi nie znaczy, że go
>w ogóle złapiemy.
A co sie z nim stanie ze go nei zlapiemy? Wyparuje?...
A.L.
Tomek Łabuz
> On Sun, 25 Jan 2009 11:40:27 -0800 (PST), Witold Szczerba
> <pljos...@gmail.com> wrote:
>
> A co sie z nim stanie ze go nei zlapiemy? Wyparuje?...
Kolega Witold ma na myśli taką sytuację, że deklarujemy try catch w
metodzie komponentu i "łapiemy" EJBException a tak naprawdę powstaje on
na poziomie kontenera po wyjściu z tej metody, więc może nam się wydawać
iż złapaliśmy jakiś wyjątek i tam szukać błędu mimo iż tam go nie ma.
Jeśli błąd pojawi się w bloku try gdyż faktycznie został wyrzucony przez
metodę np innego komponentu, którą wywołujemy wewnątrz bloku try to
zostanie on oczywiście złapany normalnie
A.L.
wrote:
>A.L. pisze:
Przepraszam, moze kiepsko znam jave, ale jezeli mamy try-catch i blad
powstal wewnatrz try-catch, to zostanie obsluzony przez handler
zwiazany z tym blokiem. Wiec jezeli zostanie, to go zlapiemy. Jezeli
wyjatek powstanie po opuszczeniu bloku try-cach to oczywiscie nie
zostanie obsluzony przez TEN handler, ale handler bloku zawierajacego
nasz try-cach. Oczywiscie jezeli nasz blok try-catch nigdy nei
wygeneruje tego wyjatku, to nei ma po co go przechwytywac
Cos mi to pachnei jakims mysleniem magcznym
A.L.
Tomek Łabuz
> powstal wewnatrz try-catch, to zostanie obsluzony przez handler
> zwiazany z tym blokiem. Wiec jezeli zostanie, to go zlapiemy. Jezeli
> wyjatek powstanie po opuszczeniu bloku try-cach to oczywiscie nie
> zostanie obsluzony przez TEN handler, ale handler bloku zawierajacego
> nasz try-cach. Oczywiscie jezeli nasz blok try-catch nigdy nei
> wygeneruje tego wyjatku, to nei ma po co go przechwytywac
> Cos mi to pachnei jakims mysleniem magcznym
to kwestia środowiska w jakim pracują komponenty czyli kontenera EJB,
wywołanie metody komponentu nie jest bezpośrednie a opakowane dodatkowymi
elementami dodawanymi przez komponent, w tych warstwach może zostać
wygenerowany
EJBException. Jeśli w metodzie komponentu nie wywołujemy metod innych
komponentów to taki
wyjątek wewnątrz metody komponentu wystąpić w zasadzie nie ma
możliwości, więc
robienie try catch w jej ciele w takim wypadku pozbawione jest sensu,
jeśli jednak są wywoływane to taki wyjątek może zostać przechwycony,
tylko czy ma to sens to już inna sprawa i wymaga przemyślenia w
konkretnej sytuacji
Piotrek_20
ciągu nie wiem jak naprawic moj blad.
widze ze to dosc nietypowy blad z informacji jakie podal Tomek:
może to coś pomoże?
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006
mam dokładnie to samo co opisane w ww linku. Aplikacja podczas
zamykania sesji w jmeterze np. z 200 dochodzi do 3x, i nagle bach,
rozpada sie caly serwer. pluje stacktracem nonstop jak gdyby wpadl w
petle while az nie zapcha dysku.
zostawilem serwer na ok 1h. po porwocie wygenerowalo mi ponad 100GB
logow w jbossie!
Wrocmy moze do tematu, prosze.
Co zatem mam zrobic zeby naprawic ten blad?
Tomek, rzucił zdanie:
"<gdybanie>
pojawienie się czegoś takiego
java.util.ConcurrentModificationException
na to by wskazywało
</gdybanie> "
czy moglbys rozwinac swoj pomysl, czy mam sprobowac taki wyjatek
wylapac, bo nie bardzo rozumiem.
pozdrawiam i dziekuje za pomoc, duzo już mi pomogliscie:)
Witold Szczerba
> mam dokładnie to samo co opisane w ww linku. Aplikacja podczas
> zamykania sesji w jmeterze np. z 200 dochodzi do 3x, i nagle bach,
> rozpada sie caly serwer. pluje stacktracem nonstop jak gdyby wpadl w
> petle while az nie zapcha dysku.
A czy wszystko działa dobrze jak ustawisz zamiast 200, np. 2, 5 albo
10 jednoczesnych wątków testujących?
Tomek Łabuz
> "<gdybanie>
> pojawienie się czegoś takiego
> java.util.ConcurrentModificationException
> na to by wskazywało
> </gdybanie> "
>
> czy moglbys rozwinac swoj pomysl, czy mam sprobowac taki wyjatek
> wylapac, bo nie bardzo rozumiem.
> pozdrawiam i dziekuje za pomoc, duzo już mi pomogliscie:)
nie znam seama, więc nie wypowiem się czy błąd leży po stronie jego
właściwości czy Twojego kodu (szczególnie, że całości i tak nie widzieliśmy)
Wyjątek wskazywałby na wykonanie jakiejś operacji modyfikującej
kolekcję/mapę w trakcie wykonywania na niej iteracji np przez inny wątek
ale nie jest to reguła, może być to również w tym samym wątku np:
List<MyObject> list;
...
for(MyObject o : list){
list.add(new MyObject());
}
Jeśli Twój komponent jest współdzielony w wielu wątkach a dostęp do
kluczowych dla tego przypadku zasobów nie jest synchronizowany to
potencjalnie może coś takiego wystąpić. Ponieważ to komponent sesyjny i
przetrzymujesz jakieś elementy w polach to dostęp do nich może
potencjalnie otrzymać wiele wątków (np referencja do komponentu
przechowywana w sesji web i rownoległe wykonywanie żądań korzystających
z tego samego komponentu).
Seama dobrze nie znam, w zasadzie wcale, więc nie wiem jak obsługuje
dostęp do komponentów, ale opierając się na tym co podesłałeś szukałbym
takich przyczyn błędu.
Tomek
Piotrek_20
Piotrek_20
1. rezultat zwracany przez moje zapytanie to jedne encja, wiec nie ma
tu mowy o grzebaniu w niej przez inna transakcje.
2. zalozony jest na nią lock wiec inna transakcja nie moze na niej nic
zrobic do momentu az ta sie nie wykona.
3. w moim beanie sesyjnym mam kilka pol, ktore nie są wynikowymi
stworzonymi na podstawie wartosci pol beana. Nie trzymam nawet pola
encji w komponencie sesyjnym.
co do twojej sugestii, a czy nie jest tak ze dla kazdej osobnej sesji
nie jest tworzona osobna instancja komponentu sesyjnego, jak w
servletach? nie wiem czy dobrze zrozumialem, ale wydaje mi sie ze
chcesz powiedziec, ze inny komponent sesyjny chce w trakcie
"zarzadzania danymi wyciagnietymi z bazy" podpiac sie do nich i je
zmodyfikowac.
dobrze zrozumialem? Czy zatem mam zrobic jakas synchronizacje?
Witold Szczerba
> dokladnie tak, dopiero powyzej 50 sesji zaczyna mi padać serwer.
Mi to wygląda na jakiś błąd po stronie serwera lub jego błędnej
konfiguracji. Nie napisałeś jaki to serwer, ale po stacktrace
wnioskuje, że JBoss, powinieneś się do nich zgłosić z tym przypadkiem
(tym bardziej, że Seam też jest ich, więc będą mieli łatwiejsze
zadanie). Może np. pula dostępnych session beanów się kończy i serwer
zaczyna wariować? Skoro to się dzieje dopiero powyżej 50 równoległych
połączeń, to jest prawdopodobne, że kod aplikacji masz dobry.
Tomek Łabuz
> Co do Twojego przykladu Tomku, to nie jestem pewien, a to dlatego, ze:
>
> 1. rezultat zwracany przez moje zapytanie to jedne encja, wiec nie ma
> tu mowy o grzebaniu w niej przez inna transakcje.
> 2. zalozony jest na nią lock wiec inna transakcja nie moze na niej nic
> zrobic do momentu az ta sie nie wykona.
> 3. w moim beanie sesyjnym mam kilka pol, ktore nie są wynikowymi
> stworzonymi na podstawie wartosci pol beana. Nie trzymam nawet pola
> encji w komponencie sesyjnym.
nie twierdzę, że to jest w Twoim kodzie (którego notabene nie widziałem
w całości) jednak cytując "te metody w zasadzie nie robia nic tylko
wypelniaja pola komponentu sesyjnego" można przyjąć założenie, że są tam
jakieś pola i są jakoś wypełniane, czym i jak? nie wiem, wyjątek leci
gdzieś na poziomie hibernate, możliwe, że sypie się coś w seamie
> co do twojej sugestii, a czy nie jest tak ze dla kazdej osobnej sesji
> nie jest tworzona osobna instancja komponentu sesyjnego, jak w
> servletach?
tzn co masz na myśli?
> nie wiem czy dobrze zrozumialem, ale wydaje mi sie ze
> chcesz powiedziec, ze inny komponent sesyjny chce w trakcie
> "zarzadzania danymi wyciagnietymi z bazy" podpiac sie do nich i je
> zmodyfikowac.
nie, mam na myśli, że jedna instancja komponentu sesyjnego stanowego
(ponoć mamy tutaj z takim doczynienia) jest współdzielona przez kilka
wątków czyli mógłby to być przypadek kliknięcia guzika na stronie,
wysłania żądania, które zaczyna korzystać ze SFSB i kliknięcie od razu
drugi raz i wygenerowanie drugiego żądania, które korzysta z tego samego
SFSB i jego pól itp.
ale wcale nie jest pewne iż to jest tutaj problemem, może po prostu nie
wyrabia serwer? seam?
Piotrek_20
> zaczyna wariować? Skoro to się dzieje dopiero powyżej 50 równoległych
> połączeń, to jest prawdopodobne, że kod aplikacji masz dobry.
Tak uzywam jbossa 4.2.1GA, mowisz o ilosci maxThreads w server.xml?
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
compressableMimeType="text/html,text/xml,text/plain,text/css,text/
javascript,application/xhtml+xml,application/x-javascript,application/
javascript,text/xhtml"
compression="on" />
Witold Szczerba
> nie, mam na myśli, że jedna instancja komponentu sesyjnego stanowego
> (ponoć mamy tutaj z takim doczynienia) jest współdzielona przez kilka
> wątków czyli mógłby to być przypadek kliknięcia guzika na stronie,
> wysłania żądania, które zaczyna korzystać ze SFSB i kliknięcie od razu
> drugi raz i wygenerowanie drugiego żądania, które korzysta z tego samego
> SFSB i jego pól itp.
Serwer zgodny z EJB albo do czegoś takiego nie dopuści, np. poprzez
kolejkowanie wywołań tak, żeby każde kolejne żądanie było wykonywane
na SFSB dopiero po zakończeniu poprzedniego, albo _musi_ rzucić
wyjątek javax.ejb.ConcurrentAccessException.
Pozdrawiam,
Witold Szczerba
Tomek Łabuz
może tak, może nie.... osobiście spotkałem serwer, który w momencie
działania metody ejbCreate pozwalał innemu wątkowi na wywołanie metody
biznesowej tej instancji beana.... to zdaje się też nie powinno się zdarzyć?
Tomek Łabuz
a tak mnie natchnęło, jak wspomniałem nie znam dobrze seama ale tyle co
o nim słyszałem i to co podaliście tak mnie pikło, jeśli źle to mnie
poprawicie, seam ponoć potrafi zachować stan sesji hibernate i potem ją
udostępnia (wszystko w celu zachowania stanowości), dostęp do niej jest
serializowany, może ten mechanizm się sypie, bo wyjątek leci gdzieś na
poziomie hibernate, jakby na jednym połączeniu grzebało kilka wątków czy
coś podobnego?
Tomek Łabuz
>> Serwer zgodny z EJB albo do czegoś takiego nie dopuści, np. poprzez
>> kolejkowanie wywołań tak, żeby każde kolejne żądanie było wykonywane
>> na SFSB dopiero po zakończeniu poprzedniego, albo _musi_ rzucić
>> wyjątek javax.ejb.ConcurrentAccessException.
>>
>
> może tak, może nie.... osobiście spotkałem serwer, który w momencie
> działania metody ejbCreate pozwalał innemu wątkowi na wywołanie metody
> biznesowej tej instancji beana.... to zdaje się też nie powinno się
> zdarzyć?
acha, i wszystko właśnie w momencie jak go się "docisnęło"
Witold Szczerba
>> zaczyna wariować?
> Tak uzywam jbossa 4.2.1GA, mowisz o ilosci maxThreads w server.xml?
Miałem na myśli raczej coś w stylu puli wątków dla SFSB a nie dla
servletów, ale to tylko strzał. Zapytaj się na grupie JBossa. Opisz
problem, pokaż stack trace, podkreśl, że wszystko jest OK aż nie
zwiększysz ilości równoległych testów powyżej 50... Jeśli to jest to,
to powinieneś tam błyskawicznie otrzymać odpowiedź.
Nie wiem jak to wygląda w JBoss, ale np. na moim Glassfish w
konfiguracji EJB Container jest coś takiego:
Initial and Minimum Pool Size (Minimum and initial number of
connections maintained in the pool)
Maximum Pool Size (Maximum number of connections that can be created
to satisfy client request)
Pool Resize Quantity (Number of connections to be removed when pool
idle timeout expires)
Pool Idle Timeout (w sekundach)
Nie wiem czy one są tylko dla SLSB, czy do SFSB także, Poza tym w
panelu administracyjnym jest jeszcze wiele różnych gałęzi i zakładek,
ta mi najbardziej pasuje. Jak mówiłem, nie ma co gdybać o JBossie,
tylko zapytać u jego specjalistów.
Witold Szczerba
Piotrek_20
uzywam zwyklej sesji, nic sie nie dzieje w konwersacji.
Tomek Łabuz
> tak, jest takie cos, mozna to uzyskac w kontekscie konwersacji, ale ja
> uzywam zwyklej sesji, nic sie nie dzieje w konwersacji.
podrzuć jeszcze konfigurację źródła danych
Tomek Łabuz
albo inaczej
wyciąg z kodu AbstractBatcher czyli tam gdzie leci wyjątek
catch ( ConcurrentModificationException e ) {
// this has been shown to happen occasionally in rare cases
// when using a transaction manager + transaction-timeout
// where the timeout calls back through Hibernate's
// registered transaction synchronization on a separate
// "reaping" thread. In cases where that reaping thread
// executes through this block at the same time the main
// application thread does we can get into situations where
// these CMEs occur. And though it is not "allowed" per-se,
// the end result without handling it specifically is infinite
// looping. So here, we simply break the loop
Piotrek_20
Tomek Łabuz
> oki, podesle pod wieczor, bo teraz w pracy jestem.
przyjrzyj się temu co podesłałem w innym poście, może to Cię naprowadzi
na problem
Brzezi
> Czy moglbys mi wytlumaczyc co jest zlego w tym co robie:
>
> try {
> ....
> } catch (EJBException e) {
> log.error(...)
> }
>
> ??
Jezeli to ma byc tylko log.error, to jest to bez sensu, bo jezeli
rzeczywiscie wyjatek wystapi, to i tak zostatnie zalogowany przez sam server
Pozdrawiam
Brzezi
--
[ E-mail: brz...@gmail.com ][ GEEK CODE [Version: 3.12]: GCM dpu s+:- ]
[ Ekg: #3781111 ][ a--- C+++ UL++ P+ L+++ E--- W+++ N+++ ]
[ LinuxUser: #249916 ][ o-- K- w--- O-- M- V- PS PE Y PGP--- t+ ]
[ 5- X++ R* tv+ b- DI- D+ G+ e- h! r y-- ]