[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
1:41 a.m.
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
3:06 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Pete Muir updated JBSEAM-2888:
------------------------------
Fix Version/s: 2.0.2.CR2
2.1.0.BETA1
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Fix For: 2.0.2.CR2, 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
1:57 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Norman Richards reassigned JBSEAM-2888:
---------------------------------------
Assignee: Norman Richards
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Fix For: 2.0.2.CR2, 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
8:08 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=comments#action_12408781 ]
Norman Richards commented on JBSEAM-2888:
-----------------------------------------
I can't figure out how to reproduce this. I did not observe any problems calling
invalidate and then accessing conversation scoped components. Can you post some more
details?
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.2.CR1, 2.1.0.A1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Fix For: 2.1.0.BETA1, 2.0.2.CR2
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
1:54 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Norman Richards closed JBSEAM-2888.
-----------------------------------
Resolution: Cannot Reproduce Bug
I'm going to close this out since I still can't reproduce it. If you can, please
re-open with more information.
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Fix For: 2.0.2.CR2, 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
1:42 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=comments#action_12409858 ]
Dan Allen commented on JBSEAM-2888:
-----------------------------------
After some research, I have reached the root of the problem. First, this only happens when
you deploy to Tomcat (I tested the Tomcat 6.0.X series). The problem occurs when you
invoke the method binding expression #{session.invalidate} from a UI command button.
Although Seam has a component named "session", the session that is actually
resolved is the org.apache.catalina.session.StandardSessionFacade, the implementation of
HttpSession. Seam yells at you not to interact with invalidate() method on this API
directly. The proper way to invalidate the session would be to call
#{org.jboss.seam.web.session.invalidate}.
I verified that the explosion of sessions occurs using the Tomcat JPA example under the
examples directory. <s:link action="#{session.invalidate}"
value="Invalidate Session (with HttpSession)"/>. The problem does not occur
when using <s:link action="#{org.jboss.seam.web.session.invalidate}"
value="Invalidate Session (with Seam)"/>
I don't understand why this happens on Tomcat and not JBoss AS. Theoretically, there
is nothing we can do about it since we cannot stop the HttpSession#invalidate() method
from being invoked. Perhaps a better solution is to use a different name (or alias) for
the Seam session wrapper so that people don't mistakenly think they are using it when
in fact they are interacting with the implicit session EL variable.
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Fix For: 2.0.2.CR2, 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
1:52 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Reopened: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Norman Richards reopened JBSEAM-2888:
-------------------------------------
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Fix For: 2.0.2.CR2, 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
8:19 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Norman Richards updated JBSEAM-2888:
------------------------------------
Fix Version/s: (was: 2.0.2.CR2)
No change for 2.0. We could potentially change the component name for 2.1.
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Fix For: 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
9:20 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Norman Richards updated JBSEAM-2888:
------------------------------------
Priority: Minor (was: Major)
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Priority: Minor
Fix For: 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
11:59 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Resolved: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Norman Richards resolved JBSEAM-2888.
-------------------------------------
Resolution: Done
Ok. I see. This does occur on JBoss when you bind to #{session.invalidate} from a view,
as "session" is reserved in EL. I've linked to a related issue where we
first hit this.
I've added an factory named org.jboss.seam.web.webSession. I don't know if this
is the best solution, but anyone who is concerned can use the alias. It's possible
we might want to rename the component and only retain "session" as a factory for
backwards compatibility. If anyone has strong feelings on the topic, speak up.
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.2.CR1, 2.1.0.A1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Priority: Minor
Fix For: 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
5:21 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=comments#action_12411818 ]
Dan Allen commented on JBSEAM-2888:
-----------------------------------
Sounds good to me. I'm just glad that we could track this down to a concrete problem.
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.2.CR1, 2.1.0.A1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Priority: Minor
Fix For: 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
6:56 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-2888) Calling Session.invalidate() leads to an explosion of new sessions
[ http://jira.jboss.com/jira/browse/JBSEAM-2888?page=all ]
Pete Muir closed JBSEAM-2888.
-----------------------------
Calling Session.invalidate() leads to an explosion of new sessions
------------------------------------------------------------------
Key: JBSEAM-2888
URL: http://jira.jboss.com/jira/browse/JBSEAM-2888
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0.A1, 2.0.2.CR1, 2.0.1.GA
Reporter: Dan Allen
Assigned To: Norman Richards
Priority: Minor
Fix For: 2.1.0.BETA1
Original Estimate: 2 days
Remaining Estimate: 2 days
There appears to be a pretty nasty bug in Seam during the post-session invalidation
routine. If you call #{session.invalidate} (which is also called by #{identity.logout}) a
new session is created each time the conversation is referenced for the duration of the
request.
To observe this behavior, install an HttpSessionListener that watches for session
creation. Then run one of these two action listener methods. You will observe the many
hits to the sessionCreated() method during the request that terminates the session with
Session.invalidate().
public class SessionNotifier implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent e) {
System.out.println("created session with id: " +
e.getSession().getId());
}
public void sessionDestroyed(HttpSessionEvent e) {}
}
You can run Thread.dumpStack() in the listener to see that it is happening as a result of
attribute reads on the ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it works with the
conversation within that request.
I consider this a pretty serious bug because it leads to significant growth of the HTTP
session.
--
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
6521
days inactive
6570
days old
11 comments
3 participants
participants (3)
-
Dan Allen (JIRA) -
Norman Richards (JIRA)
-
Pete Muir (JIRA)