Problem z J2EE przy instalacji Solution Managera 4.0
Instalacja Solution Managera to czasami niezła zabawa. Ponieważ jeden z kolegów przygotowuje się do certyfikacji, a przy okazji trzeba było przenieść system szkoleniowy na inny (słabszy sprzętowo) komputer, w ostatnim tygodniu instalowaliśmy Solution Managera 4.0. Oczywiście tak jak w poprzednim przypadku, instalacja była przeprowadzana na maszynie z zainstalowanym systemem Windows XP Pro SP2, chociaż oficjalnie taki system operacyjny jest nieodpowiedni (w czasie instalacji pojawia się komunikat, który trzeba zignorować).
Tak jak się spodziewaliśmy, pojawiły się błędy. Zaczęło się od problemu w czasie kroku „database load”. Do tej pory nie wiem, co spowodowało że przy kolejnej próbie instalacji tego błędu nie było (generalnie chodziło o dostępność bazy, czyli ORA-1034). Pojawił się za to inny, bardzo upierdliwy błąd, o którym chciałbym nieco więcej napisać, na wypadek jeżeli ktoś będzie się z tym zmagał. Jest to błąd typowy dla słabych sprzętowo komputerów.
Chodzi o start Java (krok “Start Java Engine“).
Jak pewnie wiecie, kilka lat temu SAP podjął decyzję, w wyniku której nowe systemy oparte o technologię Netweaver posiadają tak zwany dual stack. Z jednej strony mamy ABAP, a z drugiej JAVA Virtual Machine. Ma to być stopniowe odejście od ABAPa. Założenie jest takie, że Java jest bardziej uniwersalna i szerzej znana. Nie wszyscy są przekonani o tym, że Java jest tym czego potrzebował SAP i nie chodzi mi tu bynajmniej tylko o klientów, ale też o samych pracowników SAP. Java i eSOA były szczególnie mocno promowane przez byłego członka zarządu Shai’a Agassi, który w zeszłym roku opuścił SAP (nie został prezesem, więc zdecydował się odejść). Czy decyzja o wsparciu dla Java była słuszna czy nie, pokaże czas. Faktem jest, że wszystko oparte o ABAP ma długoletnia tradycję, działa stabilnie i nie jest tak wymagające sprzętowo jak JAVA.
Wracając do błędu przy instalacji. SAP w swoich materiałach podaje, że do zainstalowania Solution Managera w podstawowej wersji wystarczy 1 CPU i 1GB RAM. Niestety nie znalazłem w materiałach szkoleniowych wyraźniej informacji, że chodzi tu o oddzielny serwer dla Solution Managera i bazy danych. Instalowaliśmy na zwykłym roboczym komputerze z CPU 2,8GHz i 1,5GB RAM. Plik wymiany został ustawiony na maksymalna wartość. Najpierw zainstalowaliśmy bazę danych Oracle 10.2. Ta aplikacja zabrała znaczą część dostępnej pamięci komputera, a cały nasz problem z instalacją sprowadzał się do wielkości pamięci.
Kiedy przy poprzedniej instalacji pojawiał się tego typu błąd (na komputerze z 2GB RAM), to opis wyglądał tak:
ERROR 2006-08-04 11:26:46
CJS-30151 Java process server0 of instance (…) did not start after (…) minutes. Giving up.
ERROR 2006-08-04 11:26:46
FCO-00011 The step startJava with step key |NW_Onehost|ind|ind|ind|ind|0|0|
SAP_Software_Features_Configuration|
ind|ind|ind|ind|7|0|NW_Call_Offline_CTC|
ind|ind|ind|ind|5|0|startJava was executed with status ERROR .
Udało się go obejść w następujący sposób:
(1) wyłączyć instalator
(2) wystartować maszynę SAP (poprzez SAP Management Console) - trwało to dłużej niż kilkanaście minut
(3) Poczekać aż “lampki” w sekcji J2EE process będą zielone
(4) Kontynuować instalację
Problemem był długi czas potrzebny na wystartowanie J2EE (sama cześć ABAPowa startuje bardzo szybko).
Tym razem tak łatwo nie poszło. Sprawdziliśmy DEV Trace (plik server0 w katalogu C:\usr\sap\<SID>\DVEBMGS00\work).
Oto fragment wpisu:
Wed Feb 06 13:39:20 2008
Error occurred during initialization of VM
Could not reserve enough space for object heap
[Thr 4340] JLaunchIAbortJava: abort hook is called
[Thr 4340] ******************************************
*** ERROR => The Java VM aborted unexpectedly.
*** Please see SAP Note 943602 , section ‘Java VM crashes’
*** for additional information and trouble shooting.
*******************************************************
[Thr 4340] JLaunchCloseProgram: good bye (exitcode = -2)
J2EE nie miał wystarczającego miejsca w pamięci, dlatego trzeba było zmienić parametr Xms<size>. Można to zrobić poprzez configtool , który znajdziecie w katalogu:
C:\usr\sap\<SID>\DVEBMGS00\j2ee\configtool\
Jeżeli pojawi się komunikat o braku ustawionej zmiennej JAVA_HOME, to w XP można ją zdefiniować przez dopisanie w C:\AUTOEXEC.BAT czegoś takiego (przykład):
SET PATH=C:\j2sdk1.4.2_16;c:\windows;c:\windows\command
SET JAVA_HOME=C:\j2sdk1.4.2_16
Po uruchomieniu configtool zmieniamy ustawienia serwera. Załączony poniżej zrzut pochodzi z innej maszyny, ale chodziło mi o pokazanie miejsca, w którym można xms ustawić.
Zmniejszenie tej wartości pomaga wystartować serwer i dokończyć instalację, aczkolwiek nie jestem pewien czy wszystko będzie działało stabilnie (w zakresie J2EE). Ponieważ wiele firm decyduje się używać Solution Managera jako narzędzie do pobierania nowych patchy, to nie powinno to za bardzo przeszkadzać.
W samym Solution Managerze, jeżeli chcemy korzystać z SMD (Solution Manager Diagnostics – bardzo ciekawe narzędzie do analizy wydajności) to J2EE musi działać!
Tags: solution manager



Thursday, 24 April, 2008 at 09:08
Witam,
Dokładnie taki sam błąd objawił się w przypadku mojej instalacji. Rozwiązaniem natomiast było działanie dokładnie odwrotne do zaproponowanego. Jakimś trafem przy ustawieniu parametrów Dispacher’a J2EE parametr Xms ustawioną miał wartość 170M, co jak się okazało było niewystarczające do jego wystarowania. Wystarczyła zmiana na wartość 512M dla obu parametrów Xmx i Xms.
Być może komuś przyda się taka informacja.
(A od 1 maja będziemy mieli SSM 7.0 zamiast 4.0 :))
Pozdrawiam