Źródło problemu Plan prezentacji Technologia Java EE

Prezentacja na temat: "Źródło problemu Plan prezentacji Technologia Java EE"— Zapis prezentacji:

1 Monitorowanie i badanie wydajności aplikacji biznesowych bazujących na technologii Java EE

2 Źródło problemu Plan prezentacji Technologia Java EE
Monitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

3 Źródło problemu System zapisów na egzaminy Wymogi projektowe:
Ograniczony dostęp do zasobów CK Wymogi projektowe: JSF/Facelets WebServices (WS) JDBC Zapis informacji o działaniu aplikacji do dziennika zdarzeń Problemy: Wpływ zapisu informacji na pracę aplikacji Powtórzenia kodu

4 Powtórzenia kodu Uzyskanie/zwolnienie połączenia bazodanowego
Zwolnienie przygotowanych zapytań (ang. prepared statements) Obsługa wyjątków Zapis komunikatów do dzienników zdarzeń o: Rozpoczęciu/zakończeniu działania metody WS Rozpoczęciu/zakończeniu działania metod aplikacji JSF Rzuconym wyjątku

5 Technologia Java EE Plan prezentacji Źródło problemu
Monitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

6 Ważniejsze technologie Java EE
Java EE nie jest jednolitą specyfikacją. Jest raczej zbiorem technologii, które ze sobą współpracują: Serwlety i JSP/JSF (Kontener WEB) Enterprise Java Beans (Kontener EJB) JMS (Java Message Service) Contexts and Dependency Injection (JSR 299) JAX-WS i XML JTA (Java Transaction API) JPA (Java Persisence API) JCA (Java Connector Architecture)

7 Ważniejsze technologie Java EE
JEE WEB EJB JMS JAX-WS XML JPA/JTA JCA JSR 299 Contexts and Dependency Injection

8 Java EE – zarządzanie i monitorowanie
Aplikacje Serwer aplikacji Java EE MBeans MxBeans Java Management eXtensions JVM System operacyjny Logger (java.util.Logger, log4j) MBeans, MxBeans i Java Management eXtensions Interceptory dla komponentów EJB Filtry dla serwletów ActionListener-y dla JSP/JSF Aspekty: AspectJ modyfikacja kodu (ASM) Sprzęt

9 Java EE – zarządzanie i monitorowanie
Aplikacje Serwer aplikacji Java EE Logger (java.util.Logger, log4j) Narzędzie serwera aplikacyjnego Konsola administracyjna JVM System operacyjny Sprzęt

10 Java EE – zarządzanie i monitorowanie
Logger (java.util.Logger, log4j) Interceptory dla komponentów EJB Filtry dla serwletów ActionListener-y dla JSP/JSF Metody cyklu życia komponentów Matody cyklu życia encji Dynamiczne proxy Modyfikacja kodu binarnego AspectJ ASM Aplikacje Serwer aplikacji Java EE JVM System operacyjny Sprzęt

11 Źródła problemów Błędy Błędy w kodzie serwera aplikacji Błędy konfiguracji serwera aplikacji Błędy w kodzie aplikacji Błędy konfiguracji aplikacji Nie są brane problemy związane z infrastrukturą sprzętową i dostępem do bazy danych Wiele problemów nie wynika z błędów w aplikacji, ale problemami konfiguracyjnymi. Np. zbyt mała pula połączeń do bazy danych W większości przypadków problem da się usunąć bez wyłączania aplikacji, poprzez prostą rekonfigurację serwera.

12 Monitorowanie aplikacji Java EE
Plan prezentacji Źródło problemu Technologia Java EE Monitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

13 Logger Standardowy mechanizm pozwalający zapisywać komunikaty do dziennika zdarzeń Zalety: Poziomy - ograniczenie ilości informacji Możliwość konfiguracji, włączania i wyłączania w locie Wady: Wymagane jest umieszczenie wywołań Logger-a w kodzie, przeważnie w kilku miejscach Wpływa na wydajność działania aplikacji, nawet gdy jest wyłączony (test isLoggable). W przypadku konieczności zapisu dużej ilości informacji/konieczności jej wytworzenia wpływ może być nawet istotny

14 Logger – przykład public void usunTerminEgzaminu(Integer terminId) throws EgzaminyWyjatek { if (LOGGER.isLoggable(Level.FINER)) { LOGGER.entering(getClass().getName(), "usunTerminEgzaminu", terminId); } ... try { if (result == 0) { LOGGER.log(Level.SEVERE, "Nie udało się usunąć terminu egzaminu o id <" + terminId + ">"); throw new EgzaminyWyjatek(NIEUDANE_USUNIECIE_TERMINU); } catch (SQLException e) { obslugaSqlException(e); } finally { zwolnijPolaczenie(connection); LOGGER.exiting(getClass().getName(), "usunTerminEgzaminu");

15 JMX i MBeans Management Beans
Standardowy mechanizm maszyny wirtualnej Java Instalacja MBeans podczas uruchamiania aplikacji Razem z aplikacją Osobno ( w przypadku kontenerów aplikacyjnych) Podobnie jak w przypadku logger-a, konieczne jest dodanie do kodu aplikacji instrukcji zapisujących informację w MBean-ach

16 JMX

17 JMX

18 JMX

19 MBean - przykład public class WsCounter implements WsCounterMBean{ private int counter=0; public int getWSCounter() { return counter; } public void incrementCounter() { counter++; public void resetCounter() { counter=0;;

20 MBean - przykład Uzyskaj dostęp do MBean Kiedy instalować MBean?
ObjectName objectName =new ObjectName ("pl.performance:type=WsCounterMBean"); final MBeanServer platformMBeanServer = ManagementFactory.getPlatformMBeanServer(); mbean=(WsCounterMBean) MBeanServerInvocationHandler. newProxyInstance(platformMBeanServer, objectName, WsCounterMBean.class,false); Kiedy instalować MBean? Java EE 6 @Singleton – inicjalizacja parametrów dla aplikacji Synchronizacja dostępu do sesyjnych komponentów typu singleton

21 Interceptory EJB Narzędzie o największych możliwościach
Pełny dostęp do komponentu poprzez refleksję: Pola Metody, argumenty i wartości przez nie zwracane Wyjątki Adnotacje Transakcje Wątek w którym komponent się znajduje (komponenty EJB nie mogą być współdzielone przez wątki) Implementowane poprzez: Dynamiczne proxy (Glassfish) Modyfikację kodu podczas ładowania (OpenEJB)

22 Interceptory EJB – przykład
Mierzenie czasu wykonania metody Tworzenie przy pomocy adnotacji pułapek informujących o zbyt długim czasie wykonywania metody Nazywanie wątków. Domyślna nazwa nic nie mówi Ułatwia także proces debug-owania

23 Interceptory EJB – przykład
Adnotacja @Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented Threshold {public int time();} Komponent EJB @Stateless @Interceptors(ExecutionTime.class) public class BusinessComponent implements BusinessComponentRemote { @Threshold(time=5) public String monitoredMethod(String name) {...} @PostConstruct public void init(){...} }

24 Interceptory EJB – przykład
public class ExecutionTime { @AroundInvoke Object measureExecutionTime(InvocationContext ic) throws Exception { long startTime = System.currentTimeMillis(); Method method = ic.getMethod(); try { return ic.proceed(); } finally { Threshold threshold = method.getAnnotation(Threshold.class); long endTime = System.currentTimeMillis() - startTime; if (threshold != null && endTime > threshold.time()) ... }

25 EJB Lifecycle Callback Event Handlers
Lifecycle callback handlers: javax.annotation.PostConstruct javax.annotation.PreDestroy javax.ejb.PostActivate javax.ejb.PrePassivate Brak możliwości bezpośredniej komunikacji pomiędzy wywołaniami metod Komunikacja przez pola komponentu EJB

26 SFSB (Stateful Session Bean)
javax.ejb.SessionSynchronization Rozszerzenie cyklu dla komponentów stanowych afterBegin beforeCompletion/afterCompletion(true) afterCompletion(false) Transakcji nie da się monitorować interceptorem z uwagi na to, że on sam stanowi cześć transakcji.

27 JPA Lifecycle Callback Event Handlers
@javax.persistence.PrePersist @javax.persistence.PostPersist @javax.persistence.PostLoad @javax.persistence.PreUpdate @javax.persistence.PostUpdate @javax.persistence.PreRemove @javax.persistence.PostRemove

28 JPA Lifecycle Callback Event Handlers
Nie istnieje Object obj=new Object() Usunięcie w DB @PostRemove Nowy EntityManager.persist(obj) @PrePersist insert @PostPersist EntityManager.remove(obj) @PreRemove Rozpoczęcie usuwania w DB Odłączony Zarządzany Usunięty @PreUpdate update @PostUpdate EntityManager.refresh(obj) @PostLoad

29 Tube 1 Tube 2 Tube 3 Interceptory dla WS
Zależne od implementacji JAX-WS Dla JAX-WS „Metro” jest to tzw. „tubeline assembler” Typowy interceptor Serwer aplikacji Tube 1 Tube 2 Tube 3 Klienci WS Żądanie/Odpowiedź SOAP

30 Filtry i ActionListenery
Typowy interceptor @Override public void processAction(ActionEvent arg0) throws AbortProcessingException { try { ... super.processAction(arg0); } catch (Exception e) { LOGGER.log(Level.SEVERE, "WYJĄTEK APLIKACJI WEB", e); }

31 Skoro jest tak dobrze, to dlaczego jest źle?

32 Problem i cel Brak jednolitego mechanizmu pozwalającego monitorować aspekty działania aplikacji biznesowej w technologii Java EE Stworzenie mechanizmu działającego z każdym typem komponentów technologii Java EE

33 Cechy poszukiwanego rozwiązania
Możliwość monitorowania (nawet zdalnego) działania aplikacji Kod monitorujący nie powinien być częścią kodu logiki aplikacji Instalacja razem z logiką aplikacji Możliwość (zdalnego) włączania/wyłączania monitorowania aplikacji, bez konieczności jej przebudowy/przeładowania Podczas budowy aplikacji kod monitorujący powinien podlegać testom !!! Określenie obiektu monitorowania Przeładowanie – dotyczy np. usunięcia z konfiguracji aplikacji interceptorów i ponowne załadowanie aplikacji. Zamieniana jest tylko więc konfiguracja, źródła nie są ponownie kompilowane Splatanie kodu podczas ładowania klas niestety nie pozwala na testowanie. Jak działa aplikacja, jesteśmy w stanie się przekonać dopiero po uruchomieniu aplikacji

34 Rozwiązania istniejące
Glassbox Zestaw narzędziowy rozpoznający popularne framework-i Osobna aplikacji instalowana na serwerze aplikacyjnym AspectJ JBoss AOP Modyfikacja łańcucha interceptorów (Javassist) Pracuje jako samodzielny kontener lub jako część JBossAS

35 Proces W działającej aplikacji pojawia się problem, np.:
Nieprawidłowe działanie Mała wydajność Zbyt duża zajętość zasobów Trwale zablokowane wątki Włączany jest system monitorujący pracę aplikacji (bez jej wyłączania – wymóg biznesowy), inaczej: Konieczność projektowania systemu pod względem zapamiętywania stanu podczas wyłączania Klastry Analiza komunikatów Naprawienie błędów

36 Proces Nieprawidłowe działanie Mała wydajność
Zbyt duża zajętość zasobów Trwale zablokowane wątki

37 Architektura Agent JMX MBeans Konsola JMX Komponenty narzędziowe
Ładowany podczas uruchomienia maszyny wirtualnej MBeans Instalowane podczas instalacji aplikacji wraz z komponentami narzędziowymi Konsola JMX Komponenty narzędziowe Podsystem składowania komunikatów

38 Architektura i Projekt
Jednostka instalacyjna Narzędzia Aplikacja JMS, JDBC, Mail Serwer aplikacyjny JVM JMX/JConsole Agent JMX MBeans

39 Tryb normalny pracy aplikacji
Jednostka instalacyjna Klienci Narzędzia Aplikacja JMS, JDBC, Mail JVM JMX/JConsole Agent JMX MBeans

40 Włączenie monitorowania – Splatanie kodu
Podczas: Kompilacji (Compile–time) Ładowania klas (Class loading–time) Działania (Run–time) Uruchomienie narzędzia monitorującego powoduje wplecenie kodu narzędziowego w kod aplikacji Punkty splatania identyfikowane są poprzez adnotacje

41 Tryb monitorowania pracy aplikacji
Jednostka instalacyjna Klienci Aplikacja JMS, JDBC, Mail Narzędzia JVM JMX/JConsole Agent JMX MBeans

42 Przyszłość – Java EE6 i JSR299
JBoss Seam (WebBeans) JSR Contexts and Dependency Injection Dekoratory Interceptory Zatarcie różnicy pomiędzy komponentem EJB a dowolnym innym bean-em zarządzanym, np. JSF Managed Beans

43 Podsumowanie Monitorowanie selektywne
Możliwość „wyłączenia” kodu monitorującego podczas normalnej pracy Szybsze działanie aplikacji Zmniejszenie zajętości zasobów Szybsze wywołanie kodu narzędziowego od techniki interceptorów EJB3 Możliwość monitorowania dowolnego obiektu należącego do aplikacji

44 Czas na dyskusję i dziękuję za uwagę

45 Do sprawdzenia Hierarchia ładowania klas może stanowić problem.
Dynamiczne proxy do przechwytywania wywołań APM – Application Perfomance Management W przypadku klastrowanych aplikacji przeładowanie aplikacji na węźle może nastąpić bez utraty dostępu do usług (ale trzeba to zrobić na wszystkich węzłach po kolei).