Nach einer Neu-Installation (Essbase-Migration von AIX auf LINUX) schaut man sich ja so einige Bereiche genauer an, bevor das System fĂĽr Benutzer freigegeben wird.
So ist es auch in diesem Fall, bei Sichtung der Essbase-Server-Logdatei ist eine (Fehler)-Meldung aufgefallen, die kurz nach jedem Neustart des Essbase-Servers protokolliert wurde, dort sprang mir direkt der Text
OutOfMemoryError: Java heap space
in’s Auge (ein längerer Auszug aus dem Essbase.log folgt am Ende des Beitrages).
Eine schnelle Internet-Recherche fĂĽhrte zurĂĽck zur Oracle-Dokumentation und von dort zur vermeintlichen Ursache.
In Kapitel How-to increase Essbase CSS Java heap size wird auf Datei opmn.xml und 2 Parameter verwiesen, ein Auszug daraus:
..…
go to MIDDLEWARE_HOME\user_projects/epmsystem1\user_projects\epmsystem1\config\OPMN\opmn, and set or update below two minimum and maximum heaps parameters in file under tag
<process-type id=“EssbaseAgent“ module-id=“ESS“> <environment>
<variable id=“ESS_CSS_JVM_OPTION4″ value=“-Xms256M“>
<variable id=“ESS_CSS_JVM_OPTION5″ value=“-Xmx1024M“>
…
Das wäre schnell erledigt, dennoch entschied ich mich, doch nochmal die gleichen Parameter auf dem bisherigen System anzusehen. Beim Vergleich beider Dateien dann die Überraschung, sie sind auf AIX und LINUX identisch!
Das kann doch nicht sein!?
Entweder
- benötigt LINUX andere Settings als AIX oder
- die o.g. Einstellungen sind nicht ursächlich für diesen Fehler
Wenn letzteres zutrifft, was ist dann die Ursache? Ein erneuter Blick auf die Fehlermeldung lenkte die Aufmerksamkeit auf den ersten Teil der Meldung:
Exception in thread „Name des MSAD“ java.lang.OutOfMemoryError: Java heap space
Nochmal:
Exception in thread „Name des MSAD“?
Das ist doch der Prozess fĂĽr das angebundene Active Directory!
Das Gespräch mit dem Kollegen, der die Installation durchgeführt hat, brachte es dann auf den Punkt:
Bei der Anbindung des MSAD werden häufig nur die Benutzer übernommen, es können jedoch genauso auch die Gruppendefinitionen übernommen werden. Und genau davon wurde bei der neuen Konfiguration des Benutzerverzeichnis Gebrauch gemacht, leider irrtümlich.
Die Aktivierung von Benutzern und Gruppen vergrößert offensichtlich den Speicherbedarf für die Garbage-Collection der JVM. Dieser lässt sich, wie oben beschrieben, mit den minimum / maximum heaps Parameter in Datei opmn.xml anpassen.
Da mein Kunde die Gruppen nicht aus dem MSAD übernehmen, sondern in EPM verwalten möchte, war die Anpassung der opmn.xml nicht erforderlich.
Stattdessen wurde die Konfiguration des Benutzerverzeichnisses korrigiert, indem das Häkchen bei Support Groups (Gruppen übernehmen) rausgenommen wurde.
Der Erfolg ist sofort nach dem Neustart des Essbase-Servers sichtbar, denn Essbase verbindet sich umgehend mit dem Active-Directory, um von dort die Benutzer zu ĂĽbernehmen.
Es zeigt sich wieder, wie wichtig es ist, eine Fehlermeldung vollständig zu lesen und zu verstehen, anstatt schon alleine beim Wort ERROR die weitere Analyse aufzugeben.
Auszug aus der Essbase-Server-Logdatei nach dem Essbase-Start(Essbase.log):
[Fri Feb 27 18:44:26 2015]Local/ESSBASE0///139690458957600/Info(1051283)
Retrieving License Information Please Wait…
[Fri Feb 27 18:44:26 2015]Local/ESSBASE0///139690458957600/Info(1051286)
License information retrieved.
[Fri Feb 27 18:44:31 2015]Local/ESSBASE0///139690458957600/Info(1051199)
Single Sign-On Initialization Succeeded !
:
Startup sequence completed
Security is enabled
Logins are enabled
Essbase Default Storage type is Multidimensional
[Fri Feb 27 18:44:33 2015]Local/ESSBASE0///139690458957600/Info(1051134)
External Authentication Module: [Single Sign-On] enabled
[Fri Feb 27 18:44:33 2015]Local/ESSBASE0///139690458957600/Info(1051051)
Essbase Server – started
[Fri Feb 27 18:44:33 2015]Local/ESSBASE0///139690458957600/Info(1056823)
Reading Essbase config info [/opt/app/essbase/Oracle/Middleware/user_projects/epmsystem1/EssbaseServer/essbaseserver1/EssbaseConfigInfo.properties]
[Fri Feb 27 18:44:33 2015]Local/ESSBASE0///139690458957600/Info(1056820)
Essbase config info was retrieved successfully with user name [TestUser].
Waiting for Client Requests…
[Fri Feb 27 18:45:13 2015]Local/ESSBASE0///139689413048064/Info(1042059)
Connected from [xxx.xx.xx.xx]
Exception in thread „Bezeichnung des MSAD“ „java.lang.OutOfMemoryError: Java heap space“
at java.nio.ByteBuffer.wrap(ByteBuffer.java:350)
at java.lang.StringCoding$StringDecoder.decode(StringCoding.java:137)
at java.lang.StringCoding.decode(StringCoding.java:173)
at java.lang.String.
at java.lang.String.
at com.sun.jndi.ldap.BerDecoder.parseStringWithTag(BerDecoder.java:245)
at com.sun.jndi.ldap.BerDecoder.parseString(BerDecoder.java:204)
at com.sun.jndi.ldap.LdapClient.parseAttribute(LdapClient.java:688)
at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:632)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1965)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1827)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1752)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
at com.hyperion.css.spi.util.jndi.CSSLdapMsadContext.search(CSSLdapMsadContext.java:115)
at com.hyperion.css.spi.impl.msad.MSADProvider.findGroupsForGroupCache(MSADProvider.java:1725)
at com.hyperion.css.spi.impl.msad.MSADCacheBuilder.buildCache(MSADCacheBuilder.java:64)
at com.hyperion.css.spi.impl.msad.MSADProvider.createCache(MSADProvider.java:4355)
at com.hyperion.css.cache.ProviderCacheThread.run(ProviderCacheThread.java:37)
[Fri Feb 27 18:45:34 2015]Local/ESSBASE0///139689413048064/Info(1042059)
Connected from [xxx.xx.xx.xx4]
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.