Archive for Luty, 2010

Modyfikator dostępu protected i default Javie

W Javie możemy za pomocą odpowiednich modyfikatorów dostępu pozwalają decydować, jak dużo metod czy pól klasy udostępnimy innym klasom. Istnieją cztery modyfikatory dostępu:

  • public – pozwala na dostęp do danego elementu ze wszystkich klas
  • protected – pozwala na dostęp do danego elementu tylko dla klas dziedziczących oraz klas z tego samego pakietu
  • default – pozwala na dostęp do danego elementu tylko klasom z danego pakietu (nie istnieje słowo w Javie określające ten rodzaj dostępu, jeżeli chcemy go użyć to po prostu nie podajemy żadnego modyfikatora)
  • private – dostęp do danego elementu ograniczony tylko do klasy w którym jest zdefiniowany

Modyfikator public i private dużego problemu sprawiać raczej nie będzie. Pierwszy umożliwia dostęp do poszczególnej metody bądź pola z każdej klasy, drugi zabrania dostępu każdemu (i przy okazji powoduje, że dany element nie podlega dziedziczeniu). Trochę więcej problemów sprawiają elementy protected i default.

Poniżej znajduje się kod, który demonstruje, kiedy można odwoływać się do zmiennych o modyfikatorach protected i default. Pominąłem modyfikatory private i public, nic nie wnoszą a zaciemniłyby obraz.

KlasaA

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
//pakietA.KlasaA

package pakietA;

import pakietB.KlasaC;
import pakietB.KlasaD;

public class KlasaA {
    private   int zmiennaPrivate;
              int zmiennaDefault;
    protected int zmiennaProtected;
    public    int zmiennaPublic;
   
    public void zrobCos(KlasaA a, KlasaB b, KlasaC c, KlasaD d) {
        a.zmiennaDefault = 10;
        a.zmiennaProtected = 10;
       
        b.zmiennaDefault = 10;
        b.zmiennaProtected = 10;
       
//      c.zmiennaDefault = 10;
        c.zmiennaProtected = 10;
       
//      d.zmiennaDefault = 10;
        d.zmiennaProtected = 10;
    }
}

KlasaB

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//pakietA.KlasaB

package pakietA;

import pakietB.KlasaC;
import pakietB.KlasaD;

public class KlasaB extends KlasaA{
   
    public void zrobCos(KlasaA a, KlasaB b, KlasaC c, KlasaD d) {
        a.zmiennaDefault = 10;
        a.zmiennaProtected = 10;
       
        b.zmiennaDefault = 10;
        b.zmiennaProtected = 10;
       
//      c.zmiennaDefault = 10;
        c.zmiennaProtected = 10;
       
//      d.zmiennaDefault = 10;
        d.zmiennaProtected = 10;
    }
}

KlasaC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//pakietB.KlasaC

package pakietB;

import pakietA.KlasaA;
import pakietA.KlasaB;

public class KlasaC extends KlasaA {
    public void zrobCos(KlasaA a, KlasaB b, KlasaC c, KlasaD d) {
//      a.zmiennaDefault = 10;
//      a.zmiennaProtected = 10;
       
//      b.zmiennaDefault = 10;
//      b.zmiennaProtected = 10;
       
//      c.zmiennaDefault = 10;
        c.zmiennaProtected = 10;
       
//      d.zmiennaDefault = 10;
        d.zmiennaProtected = 10;
    }
}

KatalogD

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
//pakietB.KlasaD

package pakietB;

import pakietA.KlasaA;
import pakietA.KlasaB;

public class KlasaD extends KlasaC {
    public void zrobCos(KlasaA a, KlasaB b, KlasaC c, KlasaD d) {
//      a.zmiennaDefault = 10;
//      a.zmiennaProtected = 10;
       
//      b.zmiennaDefault = 10;
//      b.zmiennaProtected = 10;
       
//      c.zmiennaDefault = 10;
//      c.zmiennaProtected = 10;
       
//      d.zmiennaDefault = 10;
        d.zmiennaProtected = 10;
    }
}

Generalnie w odwołaniach można zaobserwować:

  • KlasaB możne odwołać się do wszystkich zmiennych KlasyA (ten sam pakiet, dziedziczenie)
  • KlasaC nie może odwołać się do zmiennych z modyfikatorem default
  • KlasaC może odwołać się do zmiennych oznaczonych jako protected, ale tylko poprzez referencje do KlasyC oraz klas potomnych, nie może się odwołać do tej zmiennej korzystając bezpośrednio z referencji do KlasyA.
  • KlasaA może się odwołać do zmiennych protected we wszystkich klasach potomnych

Źródła

Tags: , , , , ,

Instalacja aplikacji na żądanie w serwerze aplikacji JBoss 6

W wersji 6.0.0M2 serwera aplikacji JBoss pojawiła się nowa funkcja: ładowanie aplikacji serwera na żądanie, czyli dopiero wtedy, gdy przyjdzie zapytanie HTTP o adres, który jest obsługiwany przez daną aplikację.

Powód wprowadzenie tej funkcji jest prozaiczny: ma przyspieszyć czas startu serwera aplikacji. W trakcie tworzenia aplikacji często zachodzi potrzeba restartów serwera aplikacji i wtedy każda dodatkowa sekunda, która poświęca się na czekanie aż wszystkie aplikacje zostaną zainstalowane trwa wieczność :).

Aby włączyć tę funkcję, należy wywołać polecenie run.sh z dodatkowym parametrem:

./run.sh -Djboss.as.deployment.ondemand=true

W środowisku produkcyjnym nie jest zalecane włączanie tej opcji, tam należy preferować uruchamianie wszystkich aplikacji od razu podczas startu serwera aplikacji.

Informacje tu przedstawione dotyczą wersji JBossa 6.0.0M2, więc dalekiej od stabilności. W związku z tym mogą się zmienić.

Źródła

Tags:

Modyfikatory final i abstract w klasach w Javie

Modyfikator abstract

Modyfikator abstract występujący przy deklaracji klasie oznacza, że mamy do czynienia z definicją, która jest nie kompletna lub też powinna być za taką uważana. Tylko klasa tak oznaczona może zawierać metody, które nie posiadają implementacji. Dana klasa ma metody abstrakcyjne, jeżeli:

  • w klasie jest umieszczona jakakolwiek metoda oznaczona jako abstract
  • jakakolwiek klasa nadrzędna posiada metody abstrakcyjne, które nie zostają implementowane
  • klasa dziedziczy pośrednio lub bezpośrednio interfejs i nie ma implementuje wszystkich jego metod

Klasa abstrakcyjną jest używana w celu uogólnienia zbioru innych klas (zawiera pewne wspólne właściwości tych klas). Może także część tych właściwości definiować, pozwala natomiast zdefiniować interfejs dostępu do innych właściwości, których implementacja musi już nastąpić w którejś klasie potomnej.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
abstract class Figura {

    private int kolor;
   
    public void setKolor(int kolor) {
        this.kolor = kolor;
    }
   
    public abstract void rysuj();
   
}

class Kolo extends Figura {

    private int promien;
   
   
    @Override
    public void rysuj() {
        // implementacja rysowania, przy wykorzystaniu
        // zdefiniowanego wcześniej koloru
    }
}

class Program {
    public static void main(String[] args) {
        Kolo kolo = new Kolo();
       
        Figura kwadrat = new Figura() {
           
            @Override
            public void rysuj() {
                // implementacja rysowania kwadratu
            }
        };
    }
}

Nie można utworzyć obiektu przy wykorzystaniu klasy abstrakcyjnej, jeżeli nie zdefiniuje się wszystkich metod abstrakcyjnych.

Klasa powinna być oznaczona jako abstrakcyjna tylko wtedy, gdy zależy nam na tworzeniu klas potomnych w celu utworzenia pełnej implementacji.

Modyfikator final

Klasa może zostać zdefiniowana jako finalna przy użyciu modyfikatora final. Użycie go przy deklaracji klasy oznacza, że nie można dziedziczyć po danej klasie, jej implementacja jest ostateczna i nie ma możliwości jej modyfikowania.

Przykładami takich klas są np. klasy systemowe: String, Integer czy Long.

1
2
3
4
5
6
7
8
9
10
final class Kwadrat {
   
    int szerokosc;
    int wysokosc;
    int kolor;
   
    public void rysuj() {
       
    }
}

Próba dziedziczenie po podanej klasie spowoduje wygenerowanie komunikatu błędu przez kompilator.

Modyfikatory abstract oraz final wzajemnie się wykluczają (nie można jednocześnie nakazać dziedziczenia oraz zabronić go).

Podsumowanie

Podsumowanie użycia modyfikatorów final i abstract
Modyfikator Użycie w klasie Użycie w interfejsie Użycie w typie enum
abstract Klasa nie finalna może zostać oznaczona jako abstrakcyjna

Klasa która zawiera metody oznaczone jako abstract musi zostać oznaczona także jako abstrakcyjna

Nie można utworzyć obiektu bezpośrednio z klasy abstrakcyjnej (chyba że od razu utworzymy implementację metod abstrakcyjnych)

Dozwolone, ale niepotrzebne,
z założenia interfejs jest abstrakcyjny.
Zabronione.
final Tylko klasa nie abstrakcyjna może zostać oznaczona jako ostateczna.

Klasa zawierająca metody oznaczone jako final nie musi być klasą finalną.

Klasa oznaczona jako final nie może posiadać klas potomnych (nie da się jej rozszerzyć).

Zabronione. Zabronione.

Źródła

Tags: , , , ,

Jakiego zarządcę operacji dyskowych wybrać dla maszyn wirtualnych

Dostępni zarządcy kolejkowania operacji I/O

W Linuksie (przynajmniej w RHEL 5) mam do wybory czterech różnych zarządców procesów (będzie po angielsku):

  • Completely Fair Queuing (CFQ)

    CFQ maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. CFQ is well suited for mid-to-large multi-processor systems and for systems which require balanced I/O performance over multiple LUNs and I/O controllers.

  • Noop

    The NOOP scheduler is a simple FIFO queue and uses the minimal amount of CPU/instructions per I/O to accomplish the basic merging and sorting functionality to complete the I/O. It assumes performance of the I/O has been or will be optimized at the block device (memory-disk) or with an intelligent HBA or externally attached controller.

  • Deadline

    The Deadline elevator uses a deadline algorithm to minimize I/O latency for a given I/O request. The scheduler provides near real-time behavior and uses a round robin policy to attempt to be fair among multiple I/O requests and to avoid process starvation. Using five I/O queues, this scheduler will aggressively re-order requests to improve I/O performance.

  • Anticipatory

    The Anticipatory elevator introduces a controlled delay before dispatching the I/O to attempt to aggregate and/or re-order requests improving locality and reducing disk seek operations. This algorithm is intended to optimize systems with small or slow disk subsystems. One artifact of using the AS scheduler can be higher I/O latency.

    Agorytm zarządcy dyskowego anticipatory został usunięty w nowych wersjach jądra Linuksa. Ciągle jednak jest (i będzie dostępny) w wersji RHEL 5, która zawiera jądro w wersji 2.6.18.

Można to sprawdzić wydając poleceni:

# cat /sys/block/URZADZENIE/queue/scheduler
noop anticipatory deadline [cfq]

Aktualnie wybrany zarządca jest podany w nawiasach kwadratowych.

Zarządca kolejki I/O dla komputera hosta

W większości przypadków najlepsze efekty osiągnie się korzystając z aglgorytmu cfq. Pracuje on równie dobrze przy praktycznie wszelkich obciążeniach. Jeżeli natomiast jest ważniejsze zminimalizowanie opóźnień I/O kosztem ogólnej przepustowości, być może warto rozszerzyć algorytm deadline.

Zarządca kolejki I/O dla gościa

W przypadku systemów wirtualizowanych sytuacja nie jest już taka prosta. W dużej części przypadków opłacalne może być ustawienie zarządcy kolejki I/O jako noop. Jest to spowodowane tym, że nie ma potrzeby kolejkowania zapisów w dwóch warstwach, raz na systemie gościa a drugi raz na systemie gospodarza. Lepiej jest, gdy to gospodarz decyduje kiedy i jak zapisać czy odczytać dane z dysków. To system hosta ma informacje o wszystkich operacjach dyskowych ze wszystkich maszyn oraz posiada informacje o fizycznej charakterystyce dysków twardych.

Istnieją wyjątki od tej zasady wtedy, gdy system gości uzyskują dostęp do dysków poprzez protokół iSCSI lub też mają podłączone bezpośrednio urządzenie fizyczne. Wtedy powinny samodzielnie zarządzać kolejką I/O.

Konfiguracja domyślnego algorytmu kolejkowania

Zmiana algorytmu kolejkowania I/O w trakcie pracy systemu

Zmianę dokonujemy przy użyciu polecenia echo:

# cat /sys/block/URZADZENIE/queue/scheduler
noop anticipatory deadline [cfq]
# echo 'noop' > /sys/block/URZADZENIE/queue/scheduler
# cat /sys/block/URZADZENIE/queue/scheduler
[noop] anticipatory deadline cfq

Nowy algorytm będzie używany od razu, zmiana ta nie przetrwa restartu maszyny. Natomiast umożliwia wprowadzenie innego sposobu kolejkowania dla różnych urządzeń.

Aby zapewnić wprowadzenie tych zmian po restarcie maszyny, można dodać odpowiedni wpis do pliku /etc/rc.local

# echo "echo 'noop' > /sys/block/URZADZENIE/queue/scheduler" >> /etc/rc.local

Zmiana domyślnego algorytmu kolejkowania I/O

Zmiana domyślnego algorytmu kolejkowania I/O dla systemu Linuks polega na przekazania odpowiedniego parametru do jądra. Przypisujemy wartośc parametrowi elevator nazwę domyślnego algorytmu kolejkowania: noop, anticipatory, deadline oraz cfq.

Przykładowy wpis z pliku /boot/grub/grub.conf:

34
35
36
37
title Red Hat Enterprise Linux Server (2.6.18-8.el5)
root     (hd0,0)
kernel  /vmlinuz-2.6.18-8.el5 ro root=/dev/vg0/lv0 elevator=noop
initrd   /initrd-2.6.18-8.el5.img

Opis, w jaki sposób można modyfikować konfigurację GRUBa zarówno w dystrybucji RedHat jak i Debian można znaleźć we wpisie Konfiguracja dostępu do maszyny wirtualnej przy użyciu polecenia virsh lub xm.

Źródła

Tags: , , , , , , ,

Zdalny dostępu do sieci wewnętrznej przy użyciu protokołu SSH

Zdarza się, że trzeba zalogować się do serwera stojącego za firewallem, do którego nie mamy bezpośredniego dostępu (przynajmniej przy użyciu protokołu SSH).

Jeżeli zapora ogniowa jest oparta

  • firewall jest system opartym o Linuksa, na którym możemy zalogować się przy użyciu SSH
  • mamy możliwość skorzystania z uwierzytelnienia przy użyciu kluczy na oba serwery (nie jest to obligatoryjne, ale nie będzie potrzeby dwukrotnego wprowadzania hasła

Logowanie poprzez wykonanie polecenia

Jedną z podstawowych możliwości aplikacji ssh jest możliwość wykonania komendy na zdalnej maszynie oraz zwrócenie jej wyniku działania. Najprostsza demonstracja:

lukasz@karamba:~$ ssh login@firewall ls -l mysql*
-rw-r--r-- 1 lukasz lukasz 8640154 2008-10-21 04:06 mysql-connector-java-5.1.7.tar.gz

Można to wykorzystać i zamiast polecenia ls wywołać polecenie ssh i połączyć się ze zdalną maszyną:

lukasz@karamba:~$ ssh -t login@firewall 'ssh login@produkcja'

Należy zwrócić uwagę na przełącznik użycie przełącznika -t. Nakazuje on utworzyć terminal na maszynie firewall. Bez tej opcji połączenie będzie działać, ale nie zostanie pokazany np. standardowy znak zachęty.

O czym należy pamiętać:

  • jeżeli korzystamy z uwierzytelniania opartego o klucze, to nasz klucz publiczny musi być zainstalowany na maszynie firewall, oraz klucz publiczny z maszyny firewall musi być zainstalowany na maszynie produkcja, w przeciwnym wypadku będzie trzeba podać hasła
  • niestety sposób ten nie jest kompatybilny z poleceniami scp czy też rsync, aby przekopiować plik z maszyny lokalnej na produkcja należy to wykonać dwuetapowo za pośrednictwem maszyny firewall (w przypadku polecenia rsync da się to ograniczenia ominąć, ale nie jest to już takie oczywiste)

Konfiguracja dyrektywy ProxyCommand

Drugą metodą jest poinformowanie aplikacji ssh, że do połączenia z daną maszyną musi użyć maszyny pośredniczącej w komunikacji.

Należy utworzyć plik (lub zmodyfikować instniejący) ~/.ssh/config:

1
2
Host produkcja
        ProxyCommand ssh login@firewall nc -q0 %h %p 2> /dev/null

Parametr Host (linia 1) wskazuje jakiej maszyny będą dotyczyła konfiguracja. Należy wprowadzić taką nazwę, która będzie użyta podczas łączenia z maszyną wewnątrz sieci. Dyrektywa ProxyCommand (linia 2) informuje aplikację ssh o tym, że należy połączyć się z maszyną firewall i uruchomić polecenie nc.

Po wprowadzeniu tych zmian, można zainicjować połączenie z serwerem produkcja

ssh login@produkcja

Jeżeli używamy uwierzytelniania opartego o klucze połączenie nastąpi automatycznie, w przeciwnym wypadku będzie trzeba podać hasła dostępu do obu serwerów.

O czym należy pamiętać:

  • jeżeli używamy uwierzytelnienia opartego o klucze, to zarówno na maszynie firewall jak i produkcja należy zainstalować klucz z naszego lokalnego systemu (inaczej niż w przypadku pierwszego sposobu)
  • sposób ten jest przezroczysty zarówno dla polecenia scp, rsync czy też innych korzystających ze standardowego klienta ssh, można bezpośrednio kopiować pliki pomiędzy systemami, serwer pośredniczący będzie obsłużony dla nas całkowicie przezroczyście

Źródła

Tags: ,