[JBoss JIRA] Created: (JBMESSAGING-1340) In memory session replication
by Tim Fox (JIRA)
In memory session replication
-----------------------------
Key: JBMESSAGING-1340
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1340
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Priority: Critical
Fix For: 2.0.0 Beta
Implement in memory replication of sessions.
It will be possible to replicate sessions to a backup node.
The replication needs to happen in memory sychronously.
Write to journal on both nodes can be lazy (asynchronous) since on failover we can be sure it is in memory on backup so no single point of failover.
But can persist to disk asynchronously?? I think we can persist to disk asynchrnously on the master node, but needs to be synchronous on the backup node, in case we get a failure of the backup too shortly after failure of the master.
If we can tolerate duplicate messages (or messages thought sent but not store) in a double failure then can do asynchronous storage on both master and slave.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JBAS-6175) Form-based WAR authentication - redirect fails second time round.
by Keith Johnston (JIRA)
Form-based WAR authentication - redirect fails second time round.
-----------------------------------------------------------------
Key: JBAS-6175
URL: https://jira.jboss.org/jira/browse/JBAS-6175
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-4.2.2.GA
Environment: Win XP; JDK 1.6.0_07; Firefox 3.0.3
Reporter: Keith Johnston
Assignee: Anil Saldhana
When using standard J2EE authentication of a WAR file redirects fail to return the correct page.
Authentication proceeds as follows:
1. Request / -> server responds with login page.
2. Login ok -> server authenticates and sends 302 redirect
3. Follow redirect -> server responds with 'real' page.
4. Do some work...
5. Invalidate session to logout; send browser to / with javascript using window.location()
6. Request / -> server responds with login page.
7. Login ok -> server authenticates and sends 302 redirect
8. Follow redirect -> server responds with 304 -> browser renders last seen version of URL: login page.
The result of step 8 should be to display the 'real' page.
Refreshing the page (Ctrl-R) loads the 'real' page fine confirming authentication worked ok and that the browser is incorrectly using a cached copy.
The same behaviour is also seen in Google Chrome, although Internet explorer works as expected.
Possible cause?
-----------------------
I'm wondering if tomcat is getting confused with the If-Modified-Since or If-None-Match values on the requests? The requests made in steps 3 & 8 are identical (all headers the same).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JBAS-6174) shutdown.jar is missing classes
by Andrew Lee Rubinger (JIRA)
shutdown.jar is missing classes
-------------------------------
Key: JBAS-6174
URL: https://jira.jboss.org/jira/browse/JBAS-6174
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Andrew Lee Rubinger
Assignee: Andrew Lee Rubinger
Fix For: JBossAS-5.0.0.GA
After moving sources from "main" to "bootstrap" in JBAS-6169, shutdown.jar now fails with:
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/bootstrap/spi/Server
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.jboss.Shutdown.main(Shutdown.java:117)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months