Hallo people!
Ich mache diesen Thread auf, weil ich nichts der gleichen hier gefunden habe und habe am Anfang schon viele Fragen bzgl. dieses Thema.

Ich habe mir sehr viel Mühe gegeben und bereits sehr viel über die Cluster - Technologie gelesen, rausgegegoogelt e.t.c. Aber wie es so aussieht gibt es im Internet nicht sehr viele eindeutige Antworten oder guides darüber wie man's genau macht. Von original Docs vom Jboss.org wird man zwar bisschen klüger, stellt man aber am Ende noch mehr Fragen, weil es nicht so ganz gut und verständlich beschrieben ist. Daher muss ich leider euch (den Cluster Experten) bemühen, einige meine Fragen zu beantworten

Ich habe bereit geschafft 2 Jboss server in cluster zu starten (ein local, anderer im anderen Netz). Als Cluster finden sie einander. Darunter habe ich den Apache mit mod_jk halbwegs konfiguriert, dass er die nodes findet. Die Anwendung wird zwar gestartet und hier ist schon meine erste Frage:

Ich benutze JAAS technologie, für mein App, daher wird ein FORM - Login (nicht basic) verwendet. Es scheint so, dass die Anmeldedaten nicht richtig gespeichert werden, so dass die Login - Maske nach dem "OK" wieder angezeigt wird. Bemerkung: meine index.jsp redirectet am Anfang NICHT auf Login Seite, sondern schon auf den App- Inhalt. Wenn ich es über JBOSS (alleinstehende server) mache, funktioniert alles prima. Also wo könnte es liegen.

Meine zweite Frage: Der Loadbalancer an sich ist schon potentieller Fehler. Wenn es ausfählt, gibt es kein zurück mehr. Wie kann man den Apache (load balancer) so absichern (spiegeln, e.t.c.), so dass es beim Ausfahl sofort ein anderer (Apache) angesprochen wird . Denn sie werden mit nem festen IP angesprochen. Dann muss der Client irgenwie wiessen, dass ein anderer Apache Server angesprochen werden muss (sprich ander ip oder port). Gibt es dazu Infos oder guides (wie man's spiegelt und so Einstellt, dass es automatisch auf anderen umgelenkt wird).

Als ich das mit dem Load Balancer ausprobiert habe und das nicht so sauber lief, habe ich mir die Frage gestellt: Kann man auf Apache komplett verziechten und nur den Client-Side-Interceptor verwenden. Einfach die EJB als @Clustered annotieren und gut ist?
Gibt es auch für C-S-Interceptor irgendeiner guid oder ein Tutorial wie man's macht?
Und welche technologie ist besser oder zufferlässiger (oder auch einfache einzurichten)?

Das sind meine Fragen. Ich wäre sehr dankbar für die Antworten. Wenn ihr irgendwelche xml Dateien mit den Einstellungen braucht, kann ich sie hier posten.
Danke.

Hat sich jemand mit diesem Thema mehr oder weniger beschäftigt? Gibt es da irgendwelchen Einsätze?

hier

also, das login problem kannst Du durch sticky sessions beheben. das empfiehlt sich eh, da dann nur im ausnahmefall ein serverwechsel stattfindet.

Bei einer JSF-Anwendung funktioniert fehlertolerantes Zeug im übrigen erst mit

Code xml:

1 2 3 4

<context-param>   <param-name>javax.faces.STATE_SAVING_METHOD</param-name>   <param-value>server</param-value>  </context-param>

Ausserdem musst Du darauf achten, daß Du Deine Clusterparameter nicht zu leger gestaltest (Was immer funktioniert und auch Ausfallsicherheit bietet ist, dem Teil zu sagen, dass es SYNCHRONOUS replication mit PESSIMISTIC_LOCKING nutzen soll; Anmerkung hierzu : Gegenüber ASYNCHRONOUS + OPTIMISTIC LOCKING liegt ein Zeitfaktor von vier. Dafür ist die Anwendung erstmal unkaputtbar. Im Laufenden Tagesgeschäft kann man dann den Cluster langsam auf "entspannter" einstellen, wodurch man aber erstmal Kompromisse im Bezug auf Fehlertoleranz eingeht.

Beliebter Fehler : web.xml muss <distributable /> enthalten und evtl. involvierte Stateful Beans müssen @Clustered sein!

Du solltest auf jeden Fall die Multicast-Adresse als Variable in die Konfiguration eintragen, damit Du sie bei Bedarf ändern kannst. Ausserdem ist der von JBoss eingetragene Multicastadresse keine MC-Adresse im Sinne der IANA.

Last but not Least, du musst ein Clustered Post office konfigurieren, sonst hagelts bei jedem Start Fehler. Dies umfasst u.a. die Verwendung einer relationalen Datenbank im Backend. Beispielkonfigurationen findest Du unter docs/examples

Zusätzlich musst Du bei JBoss jedem Clustermember eine eindeutige Peer-ID mitgeben. (-Dserver.peer.id=xxx), damit sich die Clustermember gegenseitig identifizieren können.

Finally: Sicherstellen, daß alle von Deiner Anwendung verwendeten lokalen Container-Ressourcen auf allen Clusternodes gleich sind.

Für Details der JGroups Konfiguration lohnt sich auch der Blick ins Javadoc von JGroups, leider gibts dafür so gut wie keine Doku.

[EDIT]

Die Chance, daß ein Apache verreckt, beträgt nur einen Bruchteil einer JBoss-Crashlandung; ich habe - ausßer wenn ich den Apache selbst kompiliert habe - NIE bisher einen Apache-modJk-Crash erlebt. Allerdings gibt es bei jboss.org seit kurzen ein modJkClustered Projekt, daß sich genau damit befasst.


Grüße
gore*

*Fahre nen 5.1-Cluster mit 2 ETL-JBosse und 3 Graphic-Rendering JBosse

Danke für deine Antwort. Ich habe, wie du gesagt hast die meisten Sachen so eingestellt. Ich habe aber nur Stateless EJBs, die ich aber auch als @Clustered annotiert habe. Nun habe ich immernoch das Problem mit dem Einloggen: Mit dem Form Login -Maske ladet es die Login-Maske nach dem erfolgreichem Login immer wieder neu, mit dem Basic - Autothifizierung laden er zwar erste Seite meiner App, schmeisst aber sobald ich irgendwas anklicke folgende Exception:

Code :

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 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

2010-09-22 13:27:20,659 SEVERE [javax.enterprise.resource.webcontainer.jsf.lifecycle] (ajp-172.21.188.35-8009-2) JSF1054: (Phase ID: RESTORE_VIEW 1, View ID: ) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@8c752d] 2010-09-22 13:27:20,675 ERROR [org.ajax4jsf.webapp.BaseXMLFilter] (ajp-172.21.188.35-8009-2) Exception in the filter chain javax.servlet.ServletException: viewId:/pages/main.jsp - View /pages/main.jsp could not be restored.     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:270)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)     at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)     at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)     at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)     at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)     at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)     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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)     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.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:711)     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)     at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)     at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384)     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)     at java.lang.Thread.run(Thread.java:619) Caused by: javax.faces.application.ViewExpiredException: viewId:/pages/main.jsp - View /pages/main.jsp could not be restored.     at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:185)     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)     at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)     ... 31 more 2010-09-22 13:27:20,675 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[172.21.188.35].[/device].[Faces Servlet]] (ajp-172.21.188.35-8009-2) Servlet.service() for servlet Faces Servlet threw exception javax.faces.application.ViewExpiredException: viewId:/pages/main.jsp - View /pages/main.jsp could not be restored.     at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:185)     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)     at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)     at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:177)     at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:267)     at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:380)     at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:507)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)     at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)     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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)     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.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:711)     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)     at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)     at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384)     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)     at java.lang.Thread.run(Thread.java:619)

Es scheint, als ob die Session nicht gemerkt wird. Ich habe aber keine Idee warum es so ist. Hattest du dich schon mit solchem Problem angestossen?

Was ich noch kommisch finde, dass es auch noch eine (unfataler) Exception wirft im Bezug auf alle Managed-Beans, dass sie Serializable Interface implementieren MÜSSEN!! Das verstehe ich auch nicht ganz. Ich habe sie zwar jetzt auch implementiert, aber es fordert mich dann die Klasse als Serializable zu markieren, die gar nicht von mir, sondern schon von java-sourcen (bzw. von richfaces) kommen, sowie z.b. diese Exception:

Code :

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 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83

2010-09-22 15:08:31,909 ERROR [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-172.21.188.35-8009-3) java.io.NotSerializableException: org.richfaces.component.html.HtmlTree 2010-09-22 15:08:31,909 WARN  [org.jboss.cache.interceptors.TxInterceptor] (ajp-172.21.188.35-8009-3) Commit failed.  Clearing stale locks. 2010-09-22 15:08:31,925 ERROR [org.jboss.cache.marshall.CacheMarshaller300] (ajp-172.21.188.35-8009-1) Error while marshalling object: ReplicateCommand{cmds=PrepareCommand{globalTransaction=GlobalTransaction:<172.21.188.35:3319>:29, modifications=[PutDataMapCommand{fqn=/JSESSION/device_172.21.188.35/FDJ2rhWygFACMYFmlVatOg__, dataVersion=null, data={TreeController=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=de.vce.dmks.web.fassade.SoftwarePackageTreeController@ff2a4dserialized=false}, licenceController=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=de.vce.dmks.web.fassade.DMLicenceController@1fb1ab7serialized=false}, userController=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=de.vce.dmks.web.fassade.UserController@1a4fbeserialized=false}, dvc=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=de.vce.dmks.web.fassade.DMDeviceViewController@6621f2serialized=false}, clientController=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=de.vce.dmks.web.fassade.DMClientSoftwareController@6adda6serialized=false}}, globalTransaction=GlobalTransaction:<172.21.188.35:3319>:29, erase=false}, PutDataMapCommand{fqn=/JSESSION/device_172.21.188.35/FDJ2rhWygFACMYFmlVatOg__, dataVersion=null, data={0=23, 1=1285160911862}, globalTransaction=null, erase=false}], localAddress=172.21.188.35:3319, onePhaseCommit=true}} java.io.NotSerializableException: org.richfaces.component.html.HtmlTree     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)     at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)     at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)     at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)     at org.jboss.ha.framework.server.SimpleCachableMarshalledValue.serialize(SimpleCachableMarshalledValue.java:271)     at org.jboss.ha.framework.server.SimpleCachableMarshalledValue.writeExternal(SimpleCachableMarshalledValue.java:252)     at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421)     at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390)     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)     at org.jboss.cache.marshall.CacheMarshaller200.marshallObject(CacheMarshaller200.java:460)     at org.jboss.cache.marshall.CacheMarshaller300.marshallObject(CacheMarshaller300.java:47)     at org.jboss.cache.marshall.CacheMarshaller200.marshallMap(CacheMarshaller200.java:569)     at org.jboss.cache.marshall.CacheMarshaller200.marshallObject(CacheMarshaller200.java:370)     at org.jboss.cache.marshall.CacheMarshaller300.marshallObject(CacheMarshaller300.java:47)     at org.jboss.cache.marshall.CacheMarshaller200.marshallCommand(CacheMarshaller200.java:519)     at org.jboss.cache.marshall.CacheMarshaller200.marshallObject(CacheMarshaller200.java:314)     at org.jboss.cache.marshall.CacheMarshaller300.marshallObject(CacheMarshaller300.java:47)     at org.jboss.cache.marshall.CacheMarshaller200.marshallCollection(CacheMarshaller200.java:555)     at org.jboss.cache.marshall.CacheMarshaller200.marshallObject(CacheMarshaller200.java:365)     at org.jboss.cache.marshall.CacheMarshaller300.marshallObject(CacheMarshaller300.java:47)     at org.jboss.cache.marshall.CacheMarshaller200.marshallCommand(CacheMarshaller200.java:519)     at org.jboss.cache.marshall.CacheMarshaller200.marshallObject(CacheMarshaller200.java:314)     at org.jboss.cache.marshall.CacheMarshaller300.marshallObject(CacheMarshaller300.java:47)     at org.jboss.cache.marshall.CacheMarshaller200.marshallCommand(CacheMarshaller200.java:519)     at org.jboss.cache.marshall.CacheMarshaller200.marshallObject(CacheMarshaller200.java:314)     at org.jboss.cache.marshall.CacheMarshaller300.marshallObject(CacheMarshaller300.java:47)     at org.jboss.cache.marshall.CacheMarshaller200.objectToObjectStream(CacheMarshaller200.java:191)     at org.jboss.cache.marshall.CacheMarshaller200.objectToObjectStream(CacheMarshaller200.java:136)     at org.jboss.cache.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:182)     at org.jboss.cache.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:52)     at org.jboss.cache.marshall.CommandAwareRpcDispatcher$ReplicationTask.call(CommandAwareRpcDispatcher.java:369)     at org.jboss.cache.marshall.CommandAwareRpcDispatcher$ReplicationTask.call(CommandAwareRpcDispatcher.java:341)     at org.jboss.cache.util.concurrent.WithinThreadExecutor.submit(WithinThreadExecutor.java:82)     at org.jboss.cache.marshall.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:206)     at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:748)     at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:716)     at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:721)     at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:161)     at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:135)     at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:107)     at org.jboss.cache.interceptors.ReplicationInterceptor.runPreparePhase(ReplicationInterceptor.java:192)     at org.jboss.cache.interceptors.ReplicationInterceptor.visitPrepareCommand(ReplicationInterceptor.java:72)     at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)     at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)     at org.jboss.cache.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:50)     at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)     at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)     at org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterceptor.java:539)     at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:572)     at org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:969)     at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.afterCompletion(TxInterceptor.java:1156)     at org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:92)     at org.jboss.cache.transaction.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:307)     at org.jboss.cache.transaction.DummyTransaction.commit(DummyTransaction.java:96)     at org.jboss.cache.transaction.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:109)     at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.BatchingManagerImpl.endBatch(BatchingManagerImpl.java:70)     at org.jboss.web.tomcat.service.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1967)     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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)     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.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:711)     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)     at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)     at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384)     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)     at java.lang.Thread.run(Thread.java:619)

Hast du dafür eine Erklärung?

Danke

Tritt das Problem auch bei einem JBoss auf?

Ansonsten : apache modJk Einstellungen auf Sticky Session stellen.

[edit] bei Sun gefunden :

com.sun.faces.enableRestoreView11Compatibility
org.ajax4jsf.handleViewExpiredOnClient

beide auf true setzen

Wegen der Sache mit dem implements Serializable.

Was meinst Du passiert, wenn Objekte zwischen zwei Server ausgetauscht werden? Haben die beiden Server remote Zugriff auf den RAM des anderen? Genau, nein.

Also werden die Objekte die Du über das Netzwerk verteilen willst serialisiert, sprich sie werden in Text umgewandelt. Dieser Text wandert dann über das Netzwerk zum anderen Server und wird wieder in ein Objekt umgewandelt.

Wenn Du jetzt willst, dass eines der Attribute deiner Klassen nicht serialisiert werden soll, markier es als transient. Aber dann wäre es null, sobald es einmal über die Leitung gegangen ist => NullPointerException ist dein Freund in diesem Fall

Weil Du dich mit dem Thema wohl oder übel auseinander setzen musst, lege ich Dir ans Herz
- Schau mal bei google
- Der erste Treffer
- Der zweite Treffer

Danke für eure Hilfe. Das erste Problem mit Session view ID habe ich gelöst , indem ich in jboss-web.xml den Parameter <use_jk> (oder so ähnlich heisst es) auf true umgestellt habe. Das ist mir sehr peinlich, war mein Fehler. Seitdem funktioniert es mit dem Einloggen. Und weiterhin in der App wird keine Exception mit view ID geworfen.

Mit Serializable habe ich verstanden. Verstehe aber immernoch nicht, dass er auch noch die Klassen von richfaces Serialisert haben will. Auf die habe ich doch kein Zugriff. Und überschreiben, bzw. eigene implementieren und von denen ableiten nur wegen Serializable Marker will ich nicht. Es muss doch irgendwie anderesrum gehen. Und bei der JBoss Clustering GUIDE habe ich kein Wort über die Serialisieren des Managed-Beans bzw. Backing-Beans gesehen.
Und wie soll ich damit vorgehen?

Ahso und noch was: Ich habe nur noch Stateless EJB in meine App. Welche EJB muss ich denn genau @Clustered annotieren? Alle?(sowohl in EJB Projekt (die DAO's BEANS), als auch in WEB Projekt (die Beans, die auf die EJB Interfaces referenzieren?))?

Hi,

gehe ich richtig in der Annahme, dass Du Deine Session-bezogenen Daten in der HTTP-Session ablegst?

Ich benutze JSF mit Richfaces Framework. Außer die Daten, die JSF Selbst verwaltet, lege ich keinen anderen Daten in HTTP - Session ab.

Ich benutze JSF mit Richfaces Framework. Außer die Daten, die JSF selbst verwaltet, lege ich keinen anderen Daten in HTTP - Session ab.

Also,

1. hast du <distributable/> in der web.xml stehen?
2. @Clustered bei allen SLBs ist ok, aber eigentlich egal, weil SLBs net repliziert werden (weil stateless)
3. keine statics in den @Clustered bean (evtl geht transient)

damit sollte es eigentlich gehen

edit : du solltest sticky sessions machen, damit du nur im versagensfall umgerouted wirst. ansonsten musst du deinen http session cache mal etwas konservativer gestalten (PESSIMITIC, SYNCHRONOUS)