2012-02-24 41 views
5

Mamy aplikacji WWW przy użyciu następujących technologii: JSF 2.0, EJB 3.1, JPA 2.0, JBoss AS 7.1 Końcowegonie wejście Cache używany

Czasami otrzymujemy następujący wyjątek znikąd:

09:46:29,664 ERROR [org.jboss.ejb3.invocation] (http-10.99.0.10-10.99.0.10-8080-14) JBAS014134: EJB Invocation failed on component VehicleServiceBean for method public abstract java.util.List com.hji.common.service.VehicleService.findVehiclesBySearchCriteriaAndImporterIds(com.hji.common.domain.repository.VehicleRepository$VehicleSearchCriteria,java.lang.String,java.util.List,boolean): java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, 
-104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use 
      at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:134) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:56) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:76) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:39) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:197) ... 
**Caused by: java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, -104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use** 
      at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:134) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:56) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:76) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] 
      at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:39) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final] ... 

Od pewnego czasu szukam w Internecie, ale nie mogłem znaleźć rozwiązania. Czy ktokolwiek zna ten rodzaj błędu?

Odpowiedz

3

Rozglądam się, bo mam podobny problem. Znalazłem tylko dwa możliwe wyjaśnienia: albo twoja fasola stanowa przekroczyła limit czasu (domyślnie 5000 sekund na AS7.1), albo przekazujesz odniesienie do SFSB z jednego wątku do drugiego - który (jest sugerowany na the jboss forum jest niedozwolone, jeśli ten pierwszy, zwiększ limit czasu lub złap wyjątek.Jeśli to drugie, niech jboss wstrzykuje stanową fasolę wszędzie tam, gdzie jest ona potrzebna, zamiast ją przepuszczać

Problem, który mam, polega na tym, że to nie jest żadna z tych rzeczy dla mnie, mam tylko jedną stanową fasolę w konfiguracji testowej, która jest wstrzykiwana osobno do różnych bezstanowych komponentów - i mogę wygenerować wyjątek w ciągu kilku sekund od uruchomienia testu. wyśledzić, gdzie się nie mylę - jeśli znalazłeś alternatywne rozwiązanie problemu, możesz to opublikować?

Rgds, James

Zawęziłem - do równoczesnego dostępu - Mogę wykonać wiele kolejnych żądań, ale tylko kilka "równoległych", zanim to nastąpi. (Umieszczam jednocześnie cytaty, ponieważ synchronizuję się z blokadą przechowywaną przez @ sessionScoped ejb, więc jedynym możliwym równoczesnym wywołaniem jest metoda getLock(), którą na niej stworzyłem).

Jestem całkowicie zdezorientowany, czy Weld pozwala lub zapobiega równoczesnemu dostępowi do @SessionScoped @ State EJBs. Czytałem, że Seam serializuje dostęp (i Weld powstaje z Seam), ale nie wiem, czy tak rzeczywiście jest. Jeśli tak, to coś innego powoduje, że moja fasola umiera. Jest łatwy do odtworzenia przez jednoczesny dostęp z osobnej fasoli @Stateless.

+0

Tak, masz rację.Doszliśmy do tego samego wniosku i refaktoryzowaliśmy niektóre z naszych metod, aby komponent bean sesji nie był wywoływany więcej niż raz. Co więcej, teraz dezaktywujemy przyciski po tym, jak użytkownik naciśnie je, aby zapobiec jednoczesnym połączeniom. – Primi

0

OK Mogę podać, co teraz uważam za dokładniejszą odpowiedź. Nie mogłem zrezygnować z zezwalania na równoczesny dostęp do stanu ejb, ponieważ moja aplikacja używa ajax, więc jednoczesne połączenia są nieuniknione. Nie pamiętam, gdzie znalazłem odnośnik, ale rozumiem, że współbieżny dostęp do komórki stanowej powinien być serializowany przez kontener w EJB3.1 - więc powinienem być w porządku.

Skończyłem próbując prześledzić drogę przez źródło JBoss AS7 i sądzę, że znalazłem problem (obecnie omawiany tutaj on the jboss AS7 forum). Wygląda na to, że to błąd - jboss synchronizuje tylko dostęp, jeśli twoje połączenie jest w ramach aktywnej transakcji (BMT lub CMT). Jeśli tak nie jest, synchronizacja kończy się niepowodzeniem - i nie jest możliwe (o ile mogę to sobie wyobrazić) zsynchronizować lub zablokować siebie, ponieważ dostęp do serwerów proxy, a nie samej instancji, uzyskuje się tylko wtedy. Synchronizacja na serwerze proxy jest bezużyteczna dla niczego innego niż wątek, w którym istnieje proxy.

Obecnie obejście problemu polega na zapewnieniu, że wszystkie połączenia, które mogą być współbieżne, są zawijane w transakcję. Byłem mile zaskoczony, gdy okazało się, że nakład pracy związany z otwieraniem i zamykaniem transakcji tak często na EXTENDED PersistenceContext był bardzo mały - ale tak naprawdę nie pchałam go bardzo mocno :)

Podejrzewam, że problem dotyczy wszystkich wersji AS7 , ale tylko potwierdził to na AS7.1.

+0

W naszym przypadku mamy wiele metod opatrzonych adnotacją @TransactionAttribute (TransactionAttributeType.NOT_SUPPORTED). Więc jeśli dobrze rozumiem, zmiana typu na REQUIRES_NEW powinna zapobiec wyjątkowi? (fyi wstrzykniemy większość SFSB do fasoli zarządzanej przez JSF) – Primi

+0

Tak, oczywiście. Pobiegłabym z REQUIRED zamiast REQUIRES_NEW, wtedy metoda weźmie udział w istniejącej transakcji, jeśli taka istnieje, lub utworzy własną, jeśli nie. Spędziłem wiele dni na zastanawianiu się nad tym - nie bardzo lubię refaktoryzować moją domenę kodową, aby nękać narzędzia, wolę zginać narzędzia. Powiedział, że jestem kompletnym amatorem, więc prawdopodobnie mógłbym lepiej wybrać moje bitwy! – user1180316