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

2 Źródło problemu Plan prezentacji Technologia Java EEMonitorowanie 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 bazodanowegoZwolnienie 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 problemuMonitorowanie aplikacji Java EE Problem i cel Założenia systemu monitorowania

6 Ważniejsze technologie Java EEJava 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 EEJEE WEB EJB JMS JAX-WS XML JPA/JTA JCA JSR 299 Contexts and Dependency Injection

8 Java EE – zarządzanie i monitorowanieAplikacje 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 monitorowanieAplikacje 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 monitorowanieLogger (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 EEPlan 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 BeansStandardowy 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ściachPeł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ładMierzenie 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ładAdnotacja @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ładpublic 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 HandlersLifecycle 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 HandlersNie 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 WSZależ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 ActionListeneryTypowy 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ązaniaMoż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ąceGlassbox 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 ProjektJednostka instalacyjna Narzędzia Aplikacja JMS, JDBC, Mail Serwer aplikacyjny JVM JMX/JConsole Agent JMX MBeans

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

40 Włączenie monitorowania – Splatanie koduPodczas: 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 aplikacjiJednostka instalacyjna Klienci Aplikacja JMS, JDBC, Mail Narzędzia JVM JMX/JConsole Agent JMX MBeans

42 Przyszłość – Java EE6 i JSR299JBoss 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 selektywneMoż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).