JBoss Application Server 5.1, Seam Framework und Clustering

[steppi]

Hallo Leute, ich brauche dringend Hilfe bezüglich einer Facharbeit.

Meine Aufgabe ist es zwei JBoss 5.1 Instanzen aufzusetzen, eine Beispielapplication zu implementieren (Booking-Example ausm Seam Framework) und diese dann redudant auf beiden Knoten zu verteilen.

Grundlage ist ein

Ubuntu 8.10

JBoss 5.1

Seam Framework 1.2.2

open-jdk-6

Was ist der Stand der Dinge?

Beide Ubuntus laufen in einer VM, haben Internetzugang über ein LAN-Interface und befinden sich im selbem Netz (192.168.1.0/24).

Auf beiden Ubuntus läuft der JBoss.

Verwendet habe ich die Standardkonfiguration "all"

gestartet mit "sudo ./run.sh -c -b 192.168.1.x"

Beiden Server starten nun voll durch, finden sich und bilden ein Cluster

(soweit so gut)

Das deployen der Seam Beispielapplication Booking funktioniert jeweils einwandfrei (egal ob im /deploy/cluster, /deploy, /farm - Ordner)

<-- weiß leider nicht welchen ich nun verwenden muss

Im Farm-Ordner jedenfalls funktioniert es auch, dass ich sie auf Server1 deploye und Server2 sich die Applikation holt.

Nun zum Problem...

Der nächste Schritt wäre es, dass sich beide Applikationen redundant ergänzen. (bevor wir auf LOAD-Balancing kommen, sollte erstmal die Replikation funktionieren... soll eh ein HA-Cluster werden)

Hier finde ich leider keinen aktuellen Guide, was wie einzurichten ist, damit dies funktioniert. Aus dem JBoss AS 5 Clustering Guide werde ich net schlau (zumal der auf alten Tatsachen basiert).

Wenn ich jetzt auf Server1 ein Account erstelle od. ein Hotel buche interessiert das Server2 null... würde Server1 also wegbrechen wären alle Session-Daten verloren.

Ich brauche quasi eine Anleitung, wie ich die Failover-Funktion einrichte und so die Session übergeben kann ?

Falls jemand ein einfacheres Beispiel hat, an den man Clustering beleuchten kann mit dem JBoss immerher damit... die Zeit drängt und das ist der Hauptbestandteil der Arbeit

Vielen Dank!

[kein-tee]

Siehe Seam 2.1.2 Documentation (Clustering and EJB Passivation) .

Gruß

[steppi]

Danke werd ich morgen mal testen, wie weit ich damit komme.

Weißt du auf welcher JBoss-Version das basiert?

Leider hat sich das Clustering von Version 4.x zu Version 5.0 zu Version 5.1 ganz schön verändert... wenn ich das an den Configs in diesem Tut richtig sehe dürfte das ne 4.x sein.

Der 5.1 hat ja nen extra Verzeichnis /deploy/cluster, was im Prinzip die cluster-service.xml ersetzt... Leider sind dabei die Configs auch anders aufgebaut (deswegen auch die argen Probleme für mich mit dem JBoss Clustering Guide)

Gruß

[steppi]

Hi...

Bei diesem Schritt...

#

Add <distributable/> as the first child element in WEB-INF/web.xml

#

Set the distributable property on org.jboss.seam.core.init to true to enable the ManagedEntityInterceptor (i.e., <core:init distributable="true"/>)

Frag ich mich schon wieder in welchem Verzeichnis, bei welcher web.xml und falls das Ressourcen-Verzeichnis vom booking-example wo gehört der 2te Punkt hin, denn org.jboss.seam.core.init finde ich da net

[steppi]

So die Fragen zum Tut haben sich geklärt, der Erfolg bleibt mir trotzdem vergönnt...

Wie gehabt funktioniert die Applikation auf beiden Instanzen, sobald ich mich jedoch in eine Session einlogge erscheint auf der Console folgendes Fehler-Bild :

10:11:16,109 WARN [/seam-booking] Failed to replicate session lqTst3-uL20YH8x9YIisqg__

org.jboss.seam.security.NotLoggedInException

at org.jboss.seam.security.Identity.checkRestriction(Identity.java:217)

at org.jboss.seam.security.SecurityInterceptor$Restriction.check(SecurityInterceptor.java:113)

at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:159)

at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)

at org.jboss.seam.ejb.RemoveInterceptor.aroundInvoke(RemoveInterceptor.java:43)

at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)

at org.jboss.seam.core.SynchronizationInterceptor.aroundInvoke(SynchronizationInterceptor.java:32)

at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)

at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:118)

at org.jboss.seam.intercept.ClientSideInterceptor.invoke(ClientSideInterceptor.java:54)

at org.javassist.tmp.java.lang.Object_$$_javassist_5.hashCode(Object_$$_javassist_5.java)

at java.util.HashMap$Entry.hashCode(HashMap.java:737)

at java.util.AbstractMap.hashCode(AbstractMap.java:494)

at org.jboss.ha.framework.server.SimpleCachableMarshalledValue.<init>(SimpleCachableMarshalledValue.java:74)

at org.jboss.ha.framework.server.SimpleCachableMarshalledValue.<init>(SimpleCachableMarshalledValue.java:80)

at org.jboss.web.tomcat.service.session.distributedcache.spi.SessionSerializationFactory.createMarshalledValue(SessionSerializationFactory.java:74)

at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService.getMarshalledValue(AbstractJBossCacheService.java:635)

at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.SessionBasedJBossCacheService.storeSessionAttributes(SessionBasedJBossCacheService.java:124)

at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.SessionBasedJBossCacheService.storeSessionAttributes(SessionBasedJBossCacheService.java:37)

at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService.storeSessionData(AbstractJBossCacheService.java:403)

at org.jboss.web.tomcat.service.session.ClusteredSession.processSessionReplication(ClusteredSession.java:1166)

at org.jboss.web.tomcat.service.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1937)

at org.jboss.web.tomcat.service.session.JBossCacheManager.storeSession(JBossCacheManager.java:309)

at org.jboss.web.tomcat.service.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:51)

at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:147)

at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)

at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)

at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)

at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)

at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)

at java.lang.Thread.run(Thread.java:636)

Edit:

Selbst wenn das dann läuft ist das doch nur auf Seam-Beispiel anwendbar?

Gibts noch ne Möglichkeit direkt über/ von Jboss ohne Zusatzsoftware, sondern einfach durch die Konfiguration der JBoss-Konfigurationen selbst ?

Bearbeitet 18. Juni 2009 von steppi

[kein-tee]

10:11:16,109 WARN [/seam-booking] Failed to replicate session lqTst3-uL20YH8x9YIisqg__

org.jboss.seam.security.NotLoggedInException [...]

JBSEAM-4003

Gefixt mit aktueller SEAM Version. Welche nutzt du?

Gibts noch ne Möglichkeit direkt über/ von Jboss ohne Zusatzsoftware, sondern einfach durch die Konfiguration der JBoss-Konfigurationen selbst ?

Befrag hierzu bitte den Clustering Guide der JBoss AS Doku. Kurz: Es sollten nur ein paar Einträge in der web.xml und jboss-web.xml nötig sein.

Gruß

[steppi]

Hey dank dir, dem Eintrag im Jira hatte ich mittlerweile gefunden und hab das auch so gemacht... konnte noch nicht testen ob es funktioniert, aber die Fehler sind definitiv weg.

Seam hab ich in der aktuellen Version (stable)

Ja das ja mein Problem... ich finde die JBoss Doku irgendwie ziemlich schlecht und die stiftet bei mir mehr Verwirrung als Klarheit.

Gerade der Fakt, dass die 5er Doku nicht angepasst wurde. Sprich die Doku ist mehr als veraltet und einige Strukturen und Configs passen nicht mehr aufeinander.

Bestes Beispiel ist die cluster-service.xml, die einfach nicht mehr existiert!

[kein-tee]

Siehe auch: Web Application Clustering Guide(AS 5)

Bestes Beispiel ist die cluster-service.xml, die einfach nicht mehr existiert!

/server/all/farm/cluster-examples-service.xml

Gruß

[steppi]

Siehe auch: Web Application Clustering Guide(AS 5)

/server/all/farm/cluster-examples-service.xml

Gruß

Das ist aber nicht die selbe Datei

Die cluster-service.xml wurde auf 4 Dateien gesplittet und in deploy/cluster/ versenkt, leider ist aber die interne Dateistruktur bei dieser Aufteilung nicht die selbe.

Glaub mir, der Guide ist einfach schlichtweg Mist.

Beschäftige mich ja jetzt schon 1-2 Monate damit.

[steppi]

Soo...

Also die Server schmeißen beide keine Fehler mehr, d.H. es sollte jetzt alles funktionieren.

Gestern habe ich bereits einen Session-Failover hinbekommen, allerdings war das ne Ausnahme.

So 100% funktioniert das im Test irgendwie nicht.

Wie könnte son Test aussehen?

Momentan geh ich so vor....

Start Server1 (-c all -b 192.168.1.20)

Start Server2 (siehe oben .22)

Deployen der DataSource und der Applikation im Farm-Ordner

Austausch zw. Server1 und 2 findet statt

Aufrufen 192.168.1.20:8080/seam-booking

Einloggen mit einem Account

Killen von Server1...

Anwählen eines Menüpunktes

Einmal hatte dabei bisher der Handover funktioniert, jetzt bleibt der Dienst dann einfach unerreichbar

Gibts irgend ne "virtuelle" IP mit der ich beide Server anspreche, dass die Anfrage solange an den Master geht, bis der wegbricht und dann auf den Slave wechselt?

[steppi]

Soo...

Also die Server schmeißen beide keine Fehler mehr, d.H. es sollte jetzt alles funktionieren.

Gestern habe ich bereits einen Session-Failover hinbekommen, allerdings war das ne Ausnahme.

So 100% funktioniert das im Test irgendwie nicht.

Wie könnte son Test aussehen?

Momentan geh ich so vor....

Start Server1 (-c all -b 192.168.1.20)

Start Server2 (siehe oben .22)

Deployen der DataSource und der Applikation im Farm-Ordner

Austausch zw. Server1 und 2 findet statt

Aufrufen 192.168.1.20:8080/seam-booking

Einloggen mit einem Account

Killen von Server1...

Anwählen eines Menüpunktes

Einmal hatte dabei bisher der Handover funktioniert, jetzt bleibt der Dienst dann einfach unerreichbar

Gibts irgend ne "virtuelle" IP mit der ich beide Server anspreche, dass die Anfrage solange an den Master geht, bis der wegbricht und dann auf den Slave wechselt?

*Push*