Archive for category JBoss AS

Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach

Polecenie twiddle.sh udostępnia polecenia, które umożliwiają uzyskanie informacji o istniejących ziarnach, ich metodach oraz parametrach.

List wszystkich wpisów z tej serii:

  1. Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS
  2. Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach
  3. Polecenie twiddle: operacje na na zasobach serwera

Lista dostępnych poleceń

Aby uzyskać listę dostępnych poleceń należy wywołać polecenie twiddle.sh z przełącznikiem --help-commands:

$ twiddle.sh --help-commands
twiddle.sh commands:
    jsr77          Print out JSR77 related information
    xmbean         Print out mbean metadata as an xmbean descriptor
    info           Get the metadata for an MBean
    get            Get the values of one or more MBean attributes
    invoke         Invoke an operation on an MBean
    create         Create an MBean
    setattrs       Set the values of one or more MBean attributes
    unregister     Unregister one or more MBeans
    queryMethod    Query the server for a list of matching methods of MBeans
    listDomains    Query the server for a list of available domains
    query          Query the server for a list of matching MBeans
    set            Set the value of one MBean attribute
    serverinfo     Get information about the MBean server

Polecenie to także udostępnia krótką pomoc do każdej z tych komend:

$ twiddle.sh -H query
Help for command: 'query'

Query the server for a list of matching MBeans

usage: query [options] <query>
options:
    -c, --count    Display the matching MBean count
    --             Stop processing options
Examples:
 query all mbeans: query '*:*'
 query all mbeans in the jboss.j2ee domain: query 'jboss.j2ee:*'

Zerknijmy na jedno z częściej wywoływanych poleceń pobranie danych z drzewa JNDII:

$ twiddle.sh invoke jboss:service=JNDIView list true
<h1> Other components with java:comp namespace</h1>
<h1>java: Namespace</h1>
<pre>
  +- securityManagement (class: org.jboss.security.integration.JNDIBasedSecurityManagement)
  +- comp (class: javax.namingMain.Context)
  +- XAConnectionFactory (class: org.jboss.jms.client.JBossConnectionFactory)
  +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
  +- TransactionPropagationContextImporter (class: com.arjuna.ats.internal.jbossatx.jta.PropagationContextManager)
  +- policyRegistration (class: org.jboss.security.plugins.JBossPolicyRegistration)
  +- ClusteredConnectionFactory (class: org.jboss.jms.client.JBossConnectionFactory)
....

Polecenie to składa się z kilku części:

  • twiddle.sh – wywołanie polecenia twiddle
  • invoke – komenda, jak ma zostać wykonana (w tym przypadku wywołanie metody na wybranym ziarnie)
  • jboss – domena, w której znajduje się wybrane ziarno
  • service=JNDIView – nazwa ziarna, jakie ma zostać wywołane
  • list – akcja na wybranym ziarnie
  • true – parametr przekazany do ziarna

Jak widać, trzeba podać sporo rożnych danych, aby wywołać dowolne zarządzane ziarno. Odpowiednie parametry można poznać używając np. aplikacji WWW JMX Console, ale także można je uzyskać przy użyciu polecenia twiddle.sh.

Lista dostępnych domen: listDomains

Polecenie listDomains pozwala na wyświetlnie listy wszystkich grup, na jakie podzielone są ziarna zarządzane:

$ twiddle.sh -H listDomains
Help for command: 'listDomains'

Query the server for a list of available domains

usage: listDomains [options]
options:
    -c, --count    Display the domain count
    --             Stop processing options

Przykładowe użycie:

$ twiddle.sh listDomains
jboss.security
jboss.jdbc
jboss.remoting
jboss.mq
jboss.classloader
jboss.admin
jboss.j2ee
jboss
...

Jak widać zostały wyświetlone tylko grupy. Ale jest to jednocześnie pierwsza część nazwy ziarna.

Lista dostępnych ziaren: query

Aby uzyskać informacje zarejestrowanych ziarnach należy użyć polecenia query:

$ twiddle.sh -H query
Help for command: 'query'

Query the server for a list of matching MBeans

usage: query [options] <query>
options:
    -c, --count    Display the matching MBean count
    --             Stop processing options
Examples:
 query all mbeans: query '*:*'
 query all mbeans in the jboss.j2ee domain: query 'jboss.j2ee:*'

Aby poznać jakie ziarna należą do domeny jboss należy użyć takiego polecenia:

$ twiddle.sh query 'jboss:*'
...
jboss:type=Service,name=SystemProperties
jboss:service=KeyGeneratorFactory,type=UUID
jboss:service=proxyFactory,target=ClientUserTransactionFactory
jboss:service=invoker,type=http,target=Naming
jboss:service=JNDIView
jboss:service=invoker,type=pooled
...

Jak widać, na liście znalazło się ziarno JNDIView.

Można łatwo także uzyskać informacje o wszystkich ziarnach, jakie znajdują się na serwerze JBoss wstawiając znak * w miejsce domeny:

$ twiddle.sh query '*:*'

Lista dostępnych metod dla wybranego ziarna: info

Posiadamy już nazwę ziarna, należałoby teraz uzyskać informacje o tym jaki akcje możemy na nim wykonać, czyli poznań metody oraz ich argumenty. Służy do tego polecenie info.

$ twiddle.sh -H info
Help for command: 'info'

Get the metadata for an MBean

usage: info <mbean -name>
  Use '*' to query for all attributes

Oto co wyświetli pytanie o ziarno JNDIView:

$ twiddle.sh info jboss:service=JNDIView
Description: JNDIView Service. List deployed application java:comp namespaces,
the java: namespace as well as the global InitialContext JNDI namespace. Also
list HA-JNDI namespace in a cluster environment.
+++ Attributes:
 Name: Name
 Type: java.lang.String
 Access: r-
 Name: State
 Type: int
 Access: r-
 Name: StateString
 Type: java.lang.String
 Access: r-
 Name: HANamingService
 Type: java.lang.String
 Access: rw
+++ Operations:
 java.lang.String list(boolean verbose)
 java.lang.String listXML()
 void create()
 void start()
 void stop()
 void destroy()
 void jbossInternalLifecycle(java.lang.String method)

Jak widać poza informacjami o samym ziarnie można zobaczyć listę metod jakie ono udostępnia. Jedną z nich jest list przyjmująca jeden argument typu boolean.

Tym sposobem właśnie udało się uzyskać informacje o wszystkich składowych, które były użyte w wywołaniu polecenia invoke.

Lista dostępnych metod: queryMethod

Istnieje jeszcze jeden sposób na odszukanie ziarna oraz metody. Komenda queryMethod pozwala na odszukanie wszystkich ziaren oraz metod, które zawierają w sobie podany ciąg znaków.

$ twiddle.sh -H queryMethod
Help for command: 'queryMethod'

Query the server for a list of matching methods of MBeans

usage: queryMethod [options] <query>
options:
    -c, --count    Display the matching method count
    -f, --filter   Filter by domain
    --             Stop processing options
Examples:
 query methods of all MBeans: queryMethod list
 query all methods of all MBeans in the jboss domain: queryMethod -f "jboss:*" list

Aby odszukać metodę list w ziarnie JNDIView możemy użyć nastepujących poleceń:

  • nie wiemy do jakiej domeny należy ziarno z szukaną metodą
    $ twiddle.sh  queryMethod list
    jboss.deployment:id="SecurityConfig",type=Component  listAttachments boolean
    jboss.deployment:id="WebInfLibFilter",type=Component  listAttachments boolean
    jboss.deployment:id="TopicTemplateInfo",type=Component  listAttachments boolean
    ...

    W moim przypadku polecenie to znalazło ponad 1400 metod zwierających słowo list w swojej nazwie. Nie jest to do końca użyteczna informacja, ale zawsze jakaś :).

  • wiemy w jakiej domenie znajduje się interesujące nas ziarno
    $ twiddle.sh  queryMethod -f "jboss:*" list
    jboss:type=Service,name=SystemProperties  removeListener org.jboss.util.property.PropertyListener
    jboss:type=Service,name=SystemProperties  addListeners [Lorg.jboss.util.property.PropertyListener;
    jboss:type=Service,name=SystemProperties  addListener org.jboss.util.property.PropertyListener
    jboss:type=Service,name=SystemProperties  addListener java.lang.String
    jboss:service=JNDIView  list boolean
    jboss:service=JNDIView  listXML
    jboss:service=AttributePersistenceService  apmListAll
    jboss:service=AttributePersistenceService  apmListAllAsString
    jboss:service=invoker,type=unified  addListener org.jboss.remoting.callback.InvokerCallbackHandler
    jboss:service=invoker,type=unified  removeListener org.jboss.remoting.callback.InvokerCallbackHandler

    Tym raza lista jest krótsza i od razu widać jak nazywa się szukane ziarno łącznie z definicją metody potrzebną do wywołania akcji.

Polecenie queryMethod jako wynik podaje zarówno pełną nazwę ziarna, jak pełną definicję metody (łącznie z parametrami używanymi do jej wywołania).

Źródła

Tags: , , , , , , , , , , , ,

Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS

Twiddle jest to aplikacja, która pozwala na zdalne komunikowanie się z serwerem aplikacji JBoss AS. Przy jej pomocy można bezpośrednio wywoływać odpowiednie polecenia, akcje. W praktyce można robić to samo co przy użyciu konsoli JMX. Polecenie to można znaleźć w katalogu $JBOSS_HOME/bin.

List wszystkich wpisów z tej serii:

  1. Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS
  2. Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach
  3. Polecenie twiddle: operacje na na zasobach serwera

Podstawowe opcje jakie można podać w aplikacji twiddle

Podstawowy zestaw przełączników jest dostępny przy uzyciu opcji -h.

Polecenia pozwalające na uzyskanie pomocy

  • -h – pomoc o przełącznikach
  • –help-commands – lista dostępnych poleceń wraz z krótkimi opisami
  • -H – wyświetlenie dodatkowej pomocy o wybranym poleceniu

Definiowanie parametrów połączenie

Teraz czas na zestaw przełączników pomocnych do nawiązania połączenia z serwerem JBoss:

  • -s – adres IP oraz port na którym nasłuchuje serwer (domyślnie localhost:1099)
  • -u – nazwa użytkownika potrzeba do uwierzytelnienia (powinna zostać zdefiniowana w pliku $JBOSS_HOME/server/PROFIL/conf/props/jmx-console-users.properties)
  • -p – hasło użytkownika potrzebne do uwierzytelnienia (powinno zostać zdefiniowane w pliku $JBOSS_HOME/server/PROFIL/conf/props/jmx-console-users.properties)

Jeżeli serwer JBoss został zabezpieczony lub też nie został uruchomiony na innym interfejsie niż lokalny, to będzie trzeba używać tych przełączników przy każdym połączeniu z serwerem aplikacji. W poniższych przykładach nie będą one umieszczane, ale nie można o nich zapominać.

Lista poleceń

Listę dostępnych poleceń jakie można wydawać za pomocą narzędzia twiddle.sh można uzyskać przy użyciu przełącznika --help-commands:

$ ./twiddle.sh --help-commands
twiddle.sh commands:
    jsr77          Print out JSR77 related information
    xmbean         Print out mbean metadata as an xmbean descriptor
    info           Get the metadata for an MBean
    get            Get the values of one or more MBean attributes
    invoke         Invoke an operation on an MBean
    create         Create an MBean
    setattrs       Set the values of one or more MBean attributes
    unregister     Unregister one or more MBeans
    queryMethod    Query the server for a list of matching methods of MBeans
    listDomains    Query the server for a list of available domains
    query          Query the server for a list of matching MBeans
    set            Set the value of one MBean attribute
    serverinfo     Get information about the MBean server

Polecenia te pozwalają na wykonanie już konkretnych akcji po stronie serwera aplikacji.

Przykładowe użycie polecenia

Uzyskanie pomocy o poleceniu serverinfo:

$ ./twiddle.sh -H serverinfo
Help for command: 'serverinfo'

Get information about the MBean server

usage: serverinfo [options]

options:
    -d, --domain    Get the default domain
    -c, --count     Get the MBean count
    -l, --list      List the MBeans
    --              Stop processing options

W podobny sposób można uzyskać krótkie informacje o wszystkich poleceniach dostępnych w twiddle.sh

Uzyskanie informacji o domyślnej domenie serwera (bez autentykacji, serwera aplikacji pracuje na domyślnym interfejsie sieciowym):

$ ./twiddle.sh serverinfo -d
jboss

Dodanie autentykacji do połączenia:

$ ./twiddle.sh -u admin -p admin serverinfo -d
jboss

Dodanie informacji o interfejsie sieciowym na którym znajduje się JBoss (lub zdalne łączenie z inną maszyną):

$ ./twiddle.sh -u admin -p admin -s SERWER:PORT serverinfo -d
jboss

Trzeba pamiętać, że przełączniku określające sposób łączenia należy podawać przed nazwą polecenia jakie ma zostać wykonane.

W pozostałych przykładach pominę już autentykację użytkownika i serwer do którego chcemy się podłączyć. W razie potrzeby należy te informacje odpowiednio dodać do polecenia.

Pobranie informacji o MBeanach pasujących do zapytania:

$ ./twiddle.sh query 'jboss:service=invoker,*'
jboss:service=invoker,type=local
jboss:service=invoker,type=jrmp
jboss:service=invoker,type=http,target=Naming
jboss:service=invoker,type=pooled
jboss:service=invoker,type=http
jboss:service=invoker,type=unified
jboss:service=invoker,type=http,target=Naming,readonly=true

Pobranie informacji o atrybutach danego ziarna:

$ ./twiddle.sh get jboss:service=invoker,type=jrmp
Name=JRMPInvoker
ServerAddress=jboss1
RMIClientSocketFactory=null
StateString=Started
Backlog=200
State=3
RMIServerSocketFactory=null
RMIServerSocketFactoryBean=org.jboss.net.sockets.DefaultSocketFactory@ad093076[bindAddress=null]
RMIObjectPort=4444
EnableClassCaching=false
RMIClientSocketFactoryBean=null
SecurityDomain=null

Wyświetlenie drzewa JNDI:

$ ./twiddle.sh invoke jboss:service=JNDIView list true
<h1> Other components with java:comp namespace</h1>
<h2>java:comp namespace of the component jboss.j2ee:ear=eBikes.ear,jar=jboss-seam.jar,name=EjbSynchronizations,service=EJB3 :</h2>
<pre>
  +- EJBContext (class: javax.ejb.EJBContext)
  +- TransactionSynchronizationRegistry[link -> java:TransactionSynchronizationRegistry] (class: javax.naming.LinkRef)
  +- UserTransaction (class: org.jboss.ejb3.tx.UserTransactionImpl)
  +- env (class: org.jnp.interfaces.NamingContext)
  +- ORB[link -> java:/JBossCorbaORB] (class: javax.naming.LinkRef)
</pre>
<h2>java:comp namespace of the component jboss.j2ee:jar=Common.jar,name=InventoryDAOImpl,service=EJB3 :</h2>
<pre>
  +- EJBContext (class: javax.ejb.EJBContext)
....

Przykłady jak instalować aplikację przy użyciu twiddle.sh można znaleźć w tym wpisie: Zarządzanie instalacją aplikacji w JBoss AS.

Źródła

Tags: , , , , , , , ,

Automatyczne uruchamianie serwera JBoss podczas startu systemu operacyjnego

Jeżeli używamy serwer JBoss na serwerze produkcyjnym, powinien on zostać skonfigurowany tak, aby uruchamiał się podczas startu aplikacji i zatrzymywał podczas jego wyłączanie.

Opis powstał w oparciu o Ubuntu, ale raczej nie powinno być większych problemów z przystosowaniem go do działania na innych systemach linuksowych. Prawdopodobnie wystarczy odpowiednio zmodyfikować ścieżki dostępu oraz skonfigurować odpowiednie linki uruchamiające JBossa w odpowiednim poziomie startu.

Skrypt startowy

JBoss przychodzi ze skryptami pozwalającymi na jego automatyczne uruchamianie. Można je znaleźć w katalogu $JBOSS_HOME/bin:

  • jboss_init_hpux.sh
  • jboss_init_redhat.sh
  • jboss_init_solaris.sh

Jak widać istnieją trzy skrypty przygotowanie do użycia w rożnych systemach operacyjnych. Nam potrzebny będzie jboss_init_redhat.sh

Pierwszym krokiem będzie skopiowanie pliku jboss_init_redhat.sh do katalogu /etc/init.d pod nową nazwą jboss:

# cp $JBOSS_HOME/bin/jboss_init_redhat.sh /etc/init.d/jboss

Teraz należy skrypt startowy odpowiednio zmodyfikować i dostosować do konfiguracji naszego systemu operacyjnego. Wszelkie modyfikacje powinny być wprowadzane w pliku /etc/init.d/jboss.

Utworzenie nieuprzywilejowanego użytkownika

Serwer aplikacji JBoss w swojej standardowej konfiguracji nie wymaga ani dostępu do uprzywilejowanych miejsc w systemie operacyjnym ani nie używa żadnych uprzywilejowanych portów. Z tego powodu powinien być on uruchamiany jako na uprawnieniach nieuprzywilejowanego użytkownika. Należy więc utworzyć odpowiedniego użytkownika i użyć go do uruchomienia serwera aplikacji:

# useradd -M jboss

Polecenie to spowoduje utworzenie użytkownika jboss wraz z grupą jboss ale bez tworzenia katalogu domowego, oraz bez definiowania hasła czy innych parametrów użytkownika.

Należy jeszcze odpowiednio zmienić uprawnienia katalogu z serwerem JBoss:

# chown -R jboss.jboss $JBOSS_HOME

Dostosowanie skryptu startowego

Teraz trzeba odpowiednio dostosować skrypt startowy do naszego systemu operacyjnego. Poniżej omówię konfigurację potrzebnych zmiennych środowiskowych, należy pamiętać aby odpowiednie modyfikacje wprowadzić w pliku /etc/init.d/jboss.

  • katalog domowy
    Konfiguracja katalogu domowego znajduje się w zmiennej $JBOSS_HOME. Należy ją zmodyfikować tak, aby wskazywała na katalog, gdzie znajduje się serwer aplikacji JBoss:

    18
    JBOSS_HOME="/opt/jboss-5.1.0.GA"
  • użytkownik nieuprzywilejowany
    Nazwa użytkownika na prawach którego ma zostać uruchomiony serwer aplikacji znajduje się w zmiennej $JBOSS_USER:

    21
    JBOSS_USER="jboss"

    Jeżeli nazwa użytkownika zostanie ustawiona na wartość RUNASIS to wtedy serwer JBoss zostanie uruchomiony bez zmiany użytkownika, czyli na uprawnienia tego użytkownika, który wywoła skrypt uruchomieniowy.

  • ścieżka do Javy
    Ścieżka dostępu do maszyny wirtualnej Javy znajduje się w zmiennej $JAVAPTH. Należy w niej podać katalog, w którym znajduje się aplikacja java.

    24
    JAVAPTH="/usr/lib/jvm/java-6-openjdk/bin"
  • definicja konfiguracji
    Kolejnym elementem jest podanie konfiguracji, która ma zostać uruchomiona.

    27
    JBOSS_CONF="default"
  • konfiguracja interfejsu sieciowego
    W domyślnej konfiguracji JBoss nasłuchuje na przychodzące połączenia tylko na lokalnym interfejsie sieciowym. Aby to zmienić, należy go odpowiednio o tym poinformaować. W skrypcie startowym służy do tego zmienna $JBOSS_HOST. Nie jest ona zdefiniowana w skrypcie, należy utworzyć ją samodzielnie. Należy dodać następującą linię (powinna być umieszczona przed linią 30, która zawiera definicję zmiennej $JBOSS_BIND_ADDR, w której $JBOSS_HOST jest wykorzystywana):

    28
    JBOSS_HOST="192.168.1.10"

Teraz pozostaje tylko sprawdzić, czy wszystkie wartości zostały zdefiniowane poprawnie i spróbować uruchomić serwera aplikacji:

# /etc/init.d/jboss start

Automatyczne uruchamianie serwera JBoss

Ostatnim krokiem jest zdefiniowanie w jakich poziomach startu ma być automatycznie uruchamiany serwera aplikacji, czy należy utworzyć odpowiednie linki z pliku /etc/init.d/jboss. W systemach opartych o Debiana można w tym celu użyć komendy update-rc.d:

# update-rc.d jboss defaults

Spowoduje to utworzenie odpowiednich linków pozwalających na uruchomienie serwera w trakcie uruchamianie komputera oraz zatrzymanie go w trakcie wyłączania systemu operacyjnego.

W przypadku systemów z rodziny RedHata należy dodać jeszcze dwie linijki do pliku /etc/init.d/jboss:

7
8
# chkconfig: - 90 10
# description: Run JBoss Server

Pozwalają one na możliwość utworzenia odpowiednich linków przez polecenie chkconfig:

# chkconfig jboss on

Problem z wyłączeniem serwera

Może wystąpić błąd podczas próby wyłączenia serwera przy użyciu komendy:

# /etc/init.d/jboss stop

Błąd jest następujący:

Exception in thread "main" javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:1099 [Root exception is javax.naming.CommunicationException: Failed to connect to server localhost/127.0.0.1:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost/127.0.0.1:1099 [Root exception is java.net.ConnectException: Connection refused]]]
        at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1763)
        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:693)
        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
        at javax.naming.InitialContext.lookup(InitialContext.java:409)
        at org.jboss.Shutdown.main(Shutdown.java:219)
Caused by: javax.naming.CommunicationException: Failed to connect to server localhost/127.0.0.1:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost/127.0.0.1:1099 [Root exception is java.net.ConnectException: Connection refused]]
        at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:335)
        at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1734)
        ... 4 more
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server localhost/127.0.0.1:1099 [Root exception is java.net.ConnectException: Connection refused]
        at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:305)
        ... 5 more
Caused by: java.net.ConnectException: Connection refused
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:310)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:176)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:163)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
        at java.net.Socket.connect(Socket.java:546)
        at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:97)
        at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:82)
        at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:301)
        ... 5 more

Pojawia się on wtedy, gdy serwer JBoss będzie nasłuchiwał na innym interfejsie sieciowym niż localhost. Spowodowany on jest błędem w skrypcie startującym, który podczas próby wywoływania w serwerze akcji jego zamknięcie nie bierze pod uwagę zawartości zmiennej $JBOSS_HOST. Rozwiązanie jest proste, wystarczy wskazać odpowiedniej komendzie adres IP na którym nasłuchuje serwer.

Definicja komendy wywołującej zamknięcie serwera wygląda następująco:

62
JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown --shutdown"}

Wystarczy teraz dodać do niej następujący ciąg -s jnp://${JBOSS_HOST}:1099, tak aby ta linia miała następującą postać:

62
JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown --shutdown -s jnp://${JBOSS_HOST}:1099"}

Teraz wywołania akcji stop powinno już działać bez problemów.

Nie należy tej zmiany wprowadzać, gdy nie została zdefiniowana zmienna $JBOSS_HOST.

Należy także pamiętać, że jeżeli dostęp do konsoli JMX został zezwolony tylko autoryzowanym użytkownikom, to należy jeszcze do powyższego skryptu dodać parametry określające nazwę użytkownika oraz jego hasło. W takie sytuacji powyższa linia powinna wyglądać następująco:

62
JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown --shutdown -s jnp://${JBOSS_HOST}:1099 -u UZYTKOWNIK -p HASLO"}

Źródła

Tags: , , , ,

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

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

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: , , , , ,