Posts Tagged JBoss

Zarządzalne ziarna (MBeans) w JVM i serwerze aplikacji JBoss

Kwi 5

Posted by Łukasz Stelmach in JBoss AS | Comments off

Serwer aplikacji JBoss udostępnia poprzez szereg ziaren możliwość zarówno sprawdzenia stanu w jakich one się znajdują, jak i wykonywanie różnych operacji na nich. Dostać się do nich można poprzez konsolę JMX.

Poniżej znajduje się lista tych bardziej interesujących (ale w żadnym wypadku nie jest to lista ani pełna, ani wyczerpująca):

  • java.lang:type=OperatingSystem
    Pozwala na wyświetlenie informacji o systemie operacyjnym na którym jest uruchomiony serwer aplikacji. Można tu odczytać takie informacje o ilości otwartych plików, ilości i zużyciu pamięci, architekturze serwera, obciążeniu serwera, ilości procesorów.
  • java.lang:type=ClassLoading
    Informacje o załadowanych klasach w JVM: ilość załadowanych klas, ilość usuniętych klas, całkowita ilość załadowanych klas. Można także włączyć opcję Verbose, która spowoduje, że w momencie ładowania jakiejś klasy zostanie wypisany na standardowe wyjście komunikat o tym. Może to być przydatne podczas debugowania aplikacja, w przypadku problemów z ładowaniem klas.
  • java.lang:type=Compilation
    Informacje o kompilatorze oraz czasie jaki został poświęcony na kompilację kodu do bytecodu.
  • java.lang:type=GarbageCollector,name=nazwa kolektora
    Informacje o odśmiecaczu, takie jak ile razy był uruchomiony, ile czasu potrzebował do działania, nazwy przestrzeni na zmienne używane przez grabage collector.
  • java.lang:type=Memory
    Informacje o aktualnym stanie pamięci w JVM. Istnieje możliwość włączenia trybu Verbose, dzieki któremu można się dowiedzieć o pamięci zwalnianej przez odśmiecacz. Można także wymusić wywołanie garbage collectora poprzez metodę gc(). Funkcjonalnie odpowiada to wywołaniu metody System.gc().
  • java.lang:type=Runtime
    Szereg informacji o maszynie wirtualnej Javy, takie jak: ścieżka klas, właściwości JVM, argumenty wejściowe dla JVM, nazwa producenta JVM, wersja JVM, lista bibliotek dla JVM, czas działania.
  • java.lang:type=Threading
    Interfejs ten pozwala na zapoznanie i zarządzanie wątkami uruchomionymi w ramach maszyny wirtualnej Javy. Przy jego pomocy można uzyskać zarówno informacje o ilości uruchomionych wątków, ich numerach ID oraz informacje o poszczególnych wątkach.
    Dostępna jest także metoda, pozwalające na sprawdzenie czy nie ma wątków zablokowanych (findDeadlockedThreads).
  • jboss:type=Service,name=SystemProperties
    Pozwala na wyświetlenie informacji systemowych. Posiada metodę showAll, która wyświetla wszystkie właściwości w kolejności alfabetycznej. Można się dowiedzieć co kryje się pod systemowymi właściwościami używanymi przez serwer aplikacji, takimi jak: jboss.server.data.dir czy jboss.server.name.
  • jboss:service=JNDIView
    Pozwala na wyświetlenie obiektów zarejestrowanych w JNDI. Posiada dwie metody list oraz listXML, które pozwalają wyświetlić informacje o poszczególnych obiektach i ich nazwach zarejestrowanych w JNDI. Przydatne w przypadku problemów z obiektami pozyskiwanymi z katalogu, takimi jak brak nie rozpoznana nazwa, problem z rzutowaniem klas.
  • jboss.system:type=Log4jService,service=Logging
    Pozwala na konfigurację logowania serwera JBoss. Logowanie odbywa się przy użyciu biblioteki Log4j a to ziarno pozwala na bezpośrednią modyfikację jej konfiguracji: zmianę poziomu logowania, zmianę sposobu logowania poszczególnych komponentów, konfigurację czy przechwytywać komunikaty wypisywane na standardowe wyjście, plik konfiguracyjny i okres jego sprawdzania.
  • jboss.system:service=ThreadPool
    Pozwala na sprawdzanie oraz zarządzanie rozmiarem puli wątków. Można sprawdzić ilość połączeń oczekujących na obsługę (parametr QueueSize) i w razie potrzeby zwiększyć ilość działających wątków (parametr MaximumPoolSize).
  • jboss.system:type=Server
    Podstawowe informacje o serwerze aplikacji JBoss: wersja, data zbudowania, data uruchomienia. Pozwala także na wyłączenie serwera, uruchomienie odśmiecacza.
  • jboss.system:type=ServerConfig
    Lokalizacja szeregu katalogów używanych przez JBossa, takich jak katalog domowy, tymczasowy i inne. Pozwala także na konfigurację sposobu opuszczania JVM w momencie kończenia pracy przez serwer aplikacji (czy JVM także ma kończyć swoją pracę w momencie zamykania JBossa).
  • jboss.system:type=ServerInfo
    Wyświetlenie informacji o JVM oraz systemie operacyjnym. Posiada oprócz tego metody pozwalające na wyświetlenie informacji o zużyciu poszczególnych obszarów pamięci GC (listMemoryPools), wyświetlenie informacji o wybranym pakiecie (displayPackageInfo), zużyciu procesora przez poszczególne wątki (listThreadCpuUtilization), zrzut informacji o wątkach (listThreadDump).

Źródła

Tags: , , , ,

Zmiana wewnętrznej bazy danych JBossa (HSQLDB) na MySql

Kwi 3

Posted by Łukasz Stelmach in JBoss AS | Comments off

W domyślnej instalacji JBoss używa wewnętrznie bazy danych HSQLDB. Jest to baza danych napisana w 100% w Javie. Całkiem dobrze sprawdza się w prostych zastosowaniach jako baza danych wbudowana, ale bywają z nią problemy jeżeli nasze wymagania rosną.

W przypadku serwera JBoss baza ta posiada kilka zalet:

  • bardzo dobrze sprawdza się w środowisku deweloperskim
  • jest skonfigurowana do działania od razu po instalacji serwera, nie wymaga żadnej konfiguracji
  • prosta w użyciu

Ale jest także szereg wad, które uniemożliwiają jej używanie w systemie produkcyjnym, charakteryzującym się potrzebą dużej wydajności i niezawodności:

  • brak izolacji transakcji
  • problemy z wyciskania wątków czy socketów
  • występowanie błędów w przypadku błędnego zamknięcia bazy danych
  • problemy ze stabilnością w przepadku dużego obciążenia serwerów

Zaleca się, aby w systemach produkcyjnych zmienić bazę danych HSQLDB na inną, bardziej stabilną i o większych możliwościach. Zmiana konfiguracji po stronie serwera JBoss nie jest bardzo skomplikowana, należy wykonać kilka kroków. Poniższy opis odnosi się do bazy danych MySql, ale nie powinno sprawić wielkich trudności przerobienie go na dowolną inna bazę danych.

Krok 1: Instalacja serowników bazy danych

Pierwszym krokiem powinna być instalacja odpowiednich sterowników bazy danych. Należy skopiować je do katalogu $JBOSS_HOME/common/lib. W tym katalogu znajdują się biblioteki dostępne we wszystkich profilach, więc będzie można w każdym z nich ich używać.

W przypadku bazy danych MySql odpowiednie sterowniki można pobrać ze strony producenta: Download Connector/J. Pobrane archiwum należy rozkompresować i skopiować znajdujący się tam plik mysql-connector-java-*.jar do katalogu $JBOSS_HOME/common/lib lub też katalogu [lib] danego profilu.

Krok 2: Konfiguracja bazy danych

Kolejnym krokiem jest utworzenie bazy danych oraz odpowiedniego użytkownika. Należy połączyć się z bazą danych i wydać odpowiednie polecenia:

$ mysql -u root

Teraz wystarczy utworzyć bazę danych i odpowiedniego użytkownika:

1
2
CREATE DATABASE jboss_server;
GRANT ALL PRIVILEGES ON jboss_server.* TO jboss_user@'localhost' IDENTIFIED BY 'haslo';

Oczywiście nazwa bazy danych, użytkownika oraz hasło należy sobie odpowiednio dobrać. Jeżeli baza danych nie znajduje się na tym samym serwerze co serwer aplikacji, to także należy odpowiednio zmodyfikować ten wpis (czyli zmienić localhost na odpowiednią nazwę hosta).

Krok 3: Konfiguracja domyślnego źródła danych

Domyślna baza danych nazywa się DefaultDS i jej konfiguracja (dla wbudowanej bazy danych) znajduje się w pliku deploy/hsqldb-ds.xml dla danej konfiguracji serwera JBoss. Aby używać innej bazy danych, należy:

  • usunąć plik hsqldb-ds.xml z katalogu deploy (najlepiej przenieść do go innej katalogu)
  • utworzyć nową definicję domyślnej bazy danych specyficzną dla wybranego serwera bazodanowego

Warto pamiętać, że przykładowe konfiguracje źródeł danych dla różnych baz danych można znaleźć w katalogu $JBOSS_HOME/docs/examples/jca.

Czyli należy usunąć plik hsqldb-ds.xml a następnie utworzyć plik default-ds.xml dla bazy danych MySql:

1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <local-tx-datasource>
    <jndi-name>DefaultDS</jndi-name>
    <connection-url>jdbc:mysql://localhost:3306/jboss_server</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>jboss_user</user-name>
    <password>haslo</password>
    <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name>
  </local-tx-datasource>
</datasources>

Krok 4: Konfiguracja JMS

W domyślnej konfiguracji JMS korzysta z wbudowanej bazy danych. Zakłada, że tą bazą danych jest HSQLDB. Konfiguracja dostępu znajduje się w pliku deploy/messaging/hsqldb-persistence-service.xml. Należy zamiast tego pliku przygotować konfigurację specyficzną dla bazy danych. Przykładowe konfiguracje można znaleźć w katalogu $JBOSS_HOME/docs/examples/jms.

W podanej konfiguracji wystarczy skopiować plik $JBOSS_HOME/docs/examples/jms/mysql-persistence-service.xml do katalogu deploy/messaging/ oraz usunąć plik hsqldb-persistence-service.xml.

Po tych operacjach wystarczy uruchomić ponownie serwer aplikacji JBoss i jeżeli nie wystąpiły żadne błędy, powinniśmy mieć już zdefiniowaną zewnętrzną bazę danych dla serwera.

Źródła

Tags: , , , , ,

Zarządzanie instalacją aplikacji w JBoss AS

Mar 31

Posted by Łukasz Stelmach in JBoss AS | Comments off

Jeżeli JBoss AS zostanie uruchomiony w domyślnej (default) konfiguracji to jest wstępnie skonfigurowany tak, że automatycznie instaluje wszelkie aplikacje jakie pojawią się w katalogu deploy. Podobnie, jeżeli jakąś aplikacja zostanie usunięta z tego katalogu, to automatycznie zostanie ona także odinstalowana z serwera. Zachowanie takie jest bardzo przydatne w momencie gdy tworzymy lub testujemy aplikację, ale niekoniecznie porządne na systemie produkcyjnym. Automatyczna instalacja aplikacji może się wiązać z takimi problemami jak:

  • ciągle jest uruchomiony specjalny wątek, który sprawdza czy nowa aplikacja nie pojawiła się w katalogu deploy;
  • trzeba pamiętać, że aktualizacja aplikacji wiąże się w w praktyce z usunięciem aplikacji z serwera i jej ponowną instalacją, więc jeżeli z jakiś powodów zaktualizujemy aplikację, nastąpi jej usunięcie, co w konsekwencji może przeszkodzić w pracy użytkownikom korzystającym z aplikacji;
  • przypadkowa (czy też nawet zamierzona) edycja plików deskryptora aplikacji także powoduje jej restart.

Konfiguracja skanowania zmian w katalogu deploy

Za konfigurację mechanizmu skanującego zmiany w katalogu deploy odpowiada klasa HDScanner. Konfiguracja usługi znajduje się w pliku deploy/hdscanner-jboss-beans.xml:

10
11
12
13
14
15
16
17
18
19
<!-- Hotdeployment of applications -->
<bean name="HDScanner" class="org.jboss.system.server.profileservice.hotdeploy.HDScanner">
    <property name="deployer"><inject bean="ProfileServiceDeployer"/></property>
    <property name="profileService"><inject bean="ProfileService"/></property>
    <property name="scanPeriod">5000</property>
    <property name="scanThreadName">HDScanner</property>
<!--
   <property name="scanEnabled">false</property>
-->
</bean>

Interesujące parametry:

  • scanPeriod
    Czas odstępu pomiędzy poszczególnymi skanowaniami wyrażona w milisekundach, domyślna wartość to 5000, czyli 5 sekund.
  • scanThreadName
    Nazwa wątka, który skanuje katalogu, domyślna wartość HDScanner. Można zmienić na inną wartość, jeżeli monitorujemy działające wątki serwera.
  • scanEnabled
    Zmienna określająca, czy skanowanie powinno być włączone (wartość true) czy też nie (wartość false). W domyślnej konfiguracji nie występuje w pliku XML. Próba dodanie jej z wartością true powoduje, że serwer wyrzuca szereg wyjątków:

    23:34:18,727 ERROR [AbstractKernelController] Error installing to Configured: name=HDScanner state=Instantiated
    java.lang.RuntimeException: Error configuring property: scanEnabled for HDScanner
            at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
            at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
    ...

    Prawdopodobnie jest to spowodowane błędem Setting HDScanner’s scanEnabled Attribute to True via XML Results In NPE lub też Setting HDScanner’s scanEnabled Attribute to True via XML Results In NPE

Jak widać, nie da się po prostu włączyć odpowiedniego przełącznika i wyłączyć automatyczną instalację aplikacji. W związku z tym, należy usunąć z katalogu deploy plik hdscanner-jboss-beans.xml[.

Po tym kroku przestanie działać usługa odpowiedzialna za skanowanie katalogu deploy, więc zmiany w nim będą sprawdzane tylko podczas startu serwera aplikacji.

Ręczna instalacja aplikacji

Jeżeli jest wyłączone automatyczne skanowanie katalogu deploy a trzeba zainstalować jakąś aplikację, można użyć polecenia twiddle.sh za pomocą którego można wywołać ziarno MainDeployer, które odpowiada za instalację aplikacji:

  • deploy – instalacja wybranej aplikacji
    twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" deploy "file:/ścieżka/do/pliku/do/instalacji"
  • undeploy – odinstalowanie wybranej aplikacji
    twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" undeploy "file:/ścieżka/do/pliku/do/instalacji"
  • redeploy – przeinstalowanie wybranej aplikacji
    twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" redeploy "file:/ścieżka/do/pliku/do/instalacji"
  • hdscanner-jboss-beans.xml – ponowna instalacja skanowania
    1. Skopiuj plik hdscanner-jboss-beans.xml z powrotem do katalogu deploy.
    2. Wykonaj polecenie:
      twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" redeploy "file:/ścieżka/do/pliku/xml"

Co trzeba jeszcze zapamiętać:

  • serwera aplikacji musi mieć dostęp do wskazanego pliku
  • aplikacja do zainstalowania zostanie zainstalowana bezpośrednio, nie będzie ona kopiowania do katalogu deploy, zostanie ona od razu rozkompresowana do katalogu tmp
  • zainstalowane aplikacje nie będę ponownie uruchamiane po restarcie serwera (chyba że zostaną one umieszczone w katalogu deploy ręcznie.

Lista zainstalowanych aplikacji

Można uzyskać listę zainstalowanych aplikacji, przy pomocy polecenie twiddle:

twiddle.sh invoke jboss.deployment:flavor=URL,type=DeploymentScanner listDeployedURLs | sed -e 's/,/\n/g'

Domyślnie poszczególne ścieżki z aplikacji są oddzielone od siebie znakiem ‚,’, polecenie sed zmienia je na znak nowej linii.

Źródła

Tags: , , , , ,

Jak uruchomić więcej niż jedną instancję serwera JBoss na jednej maszynie fizycznej?

Mar 29

Posted by Łukasz Stelmach in JBoss AS | Comments off

Czasami zachodzi potrzeba uruchomienia więcej niż jednej instancji serwera JBoss na jednym komputerze, czy to do celów testowych, deweloperskich czy nawet produkcyjnych. Aby było to możliwe, należy spełnić następujące warunki:

  • każda instancja serwera musi posiadać własny profil
  • należy skonfigurować odpowiednio serwer aplikacji oraz maszynę na której go uruchamiamy

W sumie największym problem jaki się pojawia w momencie uruchamiania kolejnych instancji serwera, jest konflikt wykorzystania tych samych portów na wybranej maszynie. Sposobów rozwiązania jest kilka, niektóre wymagają modyfikacji konfiguracji maszyny fizycznej, inne jedynie modyfikacji serwera JBoss AS.

Pierwszym krokiem będzie utworzenie dwóch profili w katalogu $JBOSS_HOME/server, które będą potem wykorzystywane do uruchomienia serwera. W dalszych części przyjmę, że profile te noszą nazwy profile1 oraz profile2 i są kopią profilu default.

Dodanie kolejnych aliasów IP do interfejsów sieciowych

Najprostszą metodą poradzenia sobie z konfliktem portów jest dodanie kolejnego (kolejnych) interfejsu sieciowego, będącego aliasem to już istniejącego. Czyli po prostu przyznanie sobie kolejnego numeru IP i przypięcie do niego konkretnej instancji serwera. Może to być spokojnie kolejny interfejs lokalny (loopback), jeżeli nie chcemy mieć dostępu do serwera z poza lokalnego komputera.

Jak utworzyć kolejne interfejsy? To zależy od używanego systemu operacyjnego:

I teraz nie pozostaje zrobić nic innego, jak uruchomić JBossa. Standardowo JBoss przypina się tylko interfejsu oznaczonego jako localhost (czyli adresu 127.0.0.1) oraz uruchamiania profil default. Aby to zmienić, należy użyć odpowiednich przełączników:

  • -c – nazwa konfiguracji do uruchomienia, a naszym przypadku profile1 lub profile2;
  • -b – nr IP, który ma wykorzystać JBoss do nasłuchiwania na połączenia;

Uruchomienie serwera z konfiguracją profile1 oraz nasłuchiwaniem na adresie 127.0.0.1:

$JBOSS_HOME/bin/run.sh -c profile1 -b 127.0.0.1

Uruchomienie serwera z konfiguracją profile2 oraz nasłuchiwaniem na adresie 127.0.0.2:

$JBOSS_HOME/bin/run.sh -c profile2 -b 127.0.0.2

Po tych operacjach powinniśmy otrzymać dwa uruchomione serwery JBoss, każdy nasłuchujący na innym adresie IP, w związku z czym nie wchodzących sobie w paradę. Sprawdzić można to przy użyciu polecenia netstat:

$ sudo netstat -tlpn | grep java
tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:8083          0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 0.0.0.0:51415           0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:51035         0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 0.0.0.0:60988           0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:4444          0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:58460         0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:4445          0.0.0.0:*               LISTEN      12789/java      
...

Zmiana portów (Service Binding Manger)

Drugim rozwiązaniem problemów konfliktu portów jest ich zmiana. Można to zrobić na albo przy użyciu specjalnej usługi zwanej Service Binding Manger lub też ręcznie

Od wersji 5.0 serwera aplikacji usługa ta jest domyślnie włączona i udostępnia 4 konfiguracje portów:

  • ports-default – domyślna konfiguracja portów
  • ports-01 – dodanie do każdego portu z domyślnej konfiguracji wartości 100
  • ports-02 – dodanie do każdego portu z domyślnej konfiguracji wartości 200
  • ports-03 – dodanie do każdego portu z domyślnej konfiguracji wartości 300

Jak widać konstrukcja jest całkiem prosta, definicja tych mapowań można znaleźć w pliku $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml. Tam znajduje się zarówno definicja wszystkich domyślnych portów, jak i definicje pozostałych konfiguracji (łącznie z offsetami).

Aby uruchomić JBossa z zadanym zestawem portów, należy ustawić w JVM zmienną jboss.service.binding.set na wartość odpowiadającej jednemu ze sposobów mapowań:

$JBOSS_HOME/bin/run.sh -c profile2 -Djboss.service.binding.set=ports-01

Można także zapisać zmiany w odpowiednim pliku konfiguracyjnym, nie będzie wtedy potrzeby konfigurowania zmiennej dla JVM. Plik, który należy edytować: $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml:

17
18
19
20
21
22
23
24
25
26
<!-- Provides management tools with a ProfileService ManagementView
interface to the SBM and its components -->
<bean name="ServiceBindingManagementObject"
class="org.jboss.services.binding.managed.ServiceBindingManagementObject">
 
<constructor>
 <!-- The name of the set of bindings to use for this server -->
 <parameter>${jboss.service.binding.set:ports-default}</parameter>
 
 <!--  The binding sets -->

W linii 24 znajduje się wpis wskazujący na domyślnie użyty zestaw portów. Wystarczy zmienić wpis ports-default na jedną z wartości: ports-01, ports-02 czy ports-03 i zrestartować serwer JBossa.

A oto jak wygląda mapowanie portów po uruchomieniu dwóch serwerów:

$ sudo netstat -tlpn | grep java
tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:8180          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:25460         0.0.0.0:*               LISTEN      15787/java
tcp        0      0 0.0.0.0:32885           0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:8183          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:51035         0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 0.0.0.0:60988           0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4446          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4544          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:4545          0.0.0.0:*               LISTEN      15787/java
...

Jak widać, są uruchomione dwa procesy JVM i można zaobserwować podobne mapowania portów z różnicą 100 pomiędzy nimi.

Zmiana portów (admin-console)

W wersji 5.0 JBoss AS istnieje możliwość zmiany portów przy użyciu aplikacji admin-console. Umożliwia ona zarówno zmianę profilu, który będzie użyty podczas tworzenia konkretnych mapować, jak i modyfikację zarówno profili jak i poszczególnych portów dla różnych usług.

Binding Manager in the Admin Console

Binding Manager in the Admin Console

Czyli najprościej otworzyć Service Binding Manager, a następnie zmienić właściwość

Active Binding Set Name

. Pozostaje jeszcze tylko zrobić restart serwera i powinno działać.

Zmiana portów (ręczna)

Jeżeli z jakiś powodów nie można użyć usługi Service Binding Manager do zmiany domyślnych portów, pozostaje jeszcze możliwość ich recznej konfiguracji. W przypadku JBossa 5.1 należy otworzyć plik $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml oraz przyjrzeć się dokładnie w jaki sposób jest zdefiniowany domyślne mapowanie. W przypadku mojego pliku początek tej definicji wygląda następująco:

99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
!-- Base binding metadata that ServiceBindingStore uses to create bindings for each set -->
<bean name="StandardBindings" class="java.util.HashSet">
<constructor>
 <parameter class="java.util.Collection">
    <set elementClass="org.jboss.services.binding.ServiceBindingMetadata">
    <!-- ********************* conf/jboss-service.xml ****************** -->

    <!-- Naming Service -->
    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=Naming</property>
       <property name="bindingName">Port</property>
       <property name="port">1099</property>
       <property name="description">The listening socket for the Naming service</property>
    </bean>

    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=Naming</property>
       <property name="bindingName">RmiPort</property>
       <property name="port">1098</property>
       <property name="description">Socket Naming service uses to receive RMI requests from client proxies</property>
    </bean>

    <!-- Remote classloading service -->
    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=WebService</property>
       <property name="port">8083</property>
       <property name="description">Socket for dynamic class and resource loading</property>
    </bean>

...

Jak widać, każda usługa posiada zdefiniowany jakiś port. Jeżeli mamy potrzebę, to możemy ten port zmienić, zrestartować serwer i powinno działać.

Podsumowanie

Wydaje mi się, że najlepszym sposobem uruchomienia kilku instancji serwera JBoss na jednej maszynie fizycznej jest użycie oddzielnych aliasów IP dla każdej z nich. Tylko jeżeli nie jest możliwe zastosowanie takiego sposobu, można zastanowić się nad zastosowaniem usługi Service Binding Manager. Jedynie ostatecznością powinna być ręczna modyfikacja portów, na jakich nasłuchują różne usługi uruchamiane przez serwera aplikacji:

Dlaczego warto używać oddzielnych adresów IP w zależności od instancji serwera:

  • łatwiej jest skojarzyć konkretną instancje JBossa z konkretnym numerem IP, niż pamiętać na jakie usługi na pracują na których niestandardowych portach
  • łatwiej jest skonfigurować zaporę ogniową
  • jeżeli istnieje na maszynie wiele usług, rośnie prawdopodobieństwo wystąpienia konfliktu portów nawet jeżeli używamy usługi SBM
  • łatwiejsza aktualizacja serwera aplikacji (brak problemów wynikających z nadpisaniem plików konfiguracyjnych, w szczególności w przypadku ręcznej edycji numerów portów)

Powyższe opisy działa w przypadku JBossa 5.1 i 5.0, w przypadku wcześniejszych wymagana jest trochę inna konfiguracja. Zmiana domyślnego adresu IP na którym nasłuchuje serwer jest taka sama, ale w przypadku JBossa 4.2 usługa SBM nie jest domyślnie włączona. Trzeba ją włączyć samodzielnie, co wymaga edycji odpowiednich plików. Podobnie inaczej się przypisuje ręcznie porty, na których nasłuchują poszczególne usługi (należy zmodyfikować pliki konfiguracyjne poszczególnych usług). Dokładniejszy opis można znaleźć w materiałach źródłowych.

Źródła

Tags: , , , , , , , , ,

Czym jest JBoss Microcontainer?

Mar 28

Posted by Łukasz Stelmach in JBoss AS | Comments off

JBoss Microcontainer jest to nowe jądro serwera aplikacyjnego JBoss AS 5. Powstało w wyniku prac nad poprzednim JXM Microkernel zmierzających do dodanie do niego wsparcia dla obiektów POJO. Nowe wydania jądra serwera aplikacyjnego może także być używane samodzielnie (jak zresztą większość pozostałych produktów JBossa). Oto jego najważniejsze cechy:

  • wsparcie dla wszystkich cech JMX Microcontainer
  • obsługa bezpośredniej instalacji komponentów POJO
  • obsługa wstrzykiwania zależności
  • poprawy w zarządzani cyklem życia
  • dodanie dodatkowych możliwości kontroli nad zależnościami
  • integracja z AOP
  • wprowadzenie Virtual File System (VFS)
  • ładowanie klas przy użyciu OSGI

Podstawowe moduły jądra

Moduły, jakie wchodzą w skład jądra JBossa oraz zależności między nimi:

Moduły JBoss Microcontainer

Moduły JBoss Microcontainer

  • Bootstrap – mechanizm pozwalający na aktywację jądra (jego załadowanie)
  • Controller – odpowiada za upewnienie się, że obiekty POJO zostaną załadowane, skonfigurowane oraz uruchomione w zależności od wybranego profilu, rozwiązywanie zależności i konfigurację oraz cykl życia rożnych systemów i usług
  • Registry – przechowywanie informacji o zainstalowanych obiektach POJO
  • Configurator – inicjalizuje i konfiguruje obiekty POJO
  • Deployer – proces instalacji obiektów
  • Bus –
  • Repository – przechowywanie metadanych o zainstalowanych oraz dostępnych (lecz nie zainstalowanych) obiektach POJO
  • Profile – pozwala na zdefiniowanie które systemy, podsystemy, obiekty POJO zostają zainstalowane, które usługi wystartują automatycznie a które będzie można uruchomić ręcznie

Proces startu serwera

Sam proces startu serwera jest obsługiwany przez oddzielaną bibliotekę, pochodząca z projektu JBoss Bootstrap. Start serwera typowo wygląda tak:

  • utworzenie serwera
  • wskazanie serwerowi, gdzie znajduje się konfiguracja, w przypadku JBossa jest to plik bootstrap.xml
  • uruchomienie serwera
  • zamrożenie konfiguracji, uniemożliwienie jej zmian w czasie działania serwera
  • serwer zostaje uruchomiony, uruchamia po kolei swoje usługi, zdarzenia
  • serwer przechodzi w stan „STARTED”
  • można działać
  • zamykanie serwera, uruchamianie zdarzeń związanych ze zmianą stanu
  • ewentualny restart serwera

Plik XML zawierający konfigurację procesu startu zawiera odnośniki do plików, które odpowiadają za konfigurcację poszczególnych usług serwera. W przypadku JBossa 5.1 wygląda on następująco (znajduje się on w pliku $JBOSS_HOME/server/default/conf/bootstrap.xml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
< ?xml version="1.0" encoding="UTF-8"?>
<!--
  The list of URLs for mc beans to load during bootstrap.
  $Id: bootstrap.xml 88109 2009-05-01 20:10:48Z bstansberry@jboss.com $
-->
<bootstrap xmlns="urn:jboss:bootstrap:1.0">

   <url>bootstrap/logging.xml</url>
   <url>bootstrap/vfs.xml</url>
   <url>bootstrap/classloader.xml</url>
   <url>bootstrap/aop.xml</url>
   <url>bootstrap/jmx.xml</url>
   <url>bootstrap/deployers.xml</url>
   <url>bootstrap/profile.xml</url>

</bootstrap>

Poszczególne pliki odpowiadają za konfigurację i inicjalizację odpowiedniego zestawu usług:

  • logging.xml
  • vfs.xml – inicjalizacja Virtual File System
  • classloader.xml – główny system ładowania klas oraz konfiguracja ścieżki dostępu do klas
  • aop.xml – inicjalizacja ziarna JBoss AOP AspectManager, wczytanie potrzebnych bibliotek
  • jmx.xml – inicjalizacja JMXKernel
  • deployers.xml – inicjalizacja szeregu ziaren odpowiedzialnych za aplikację rożnych usług lub aplikacji
  • profile.xml –

Źródła

Tags: , , ,