[
https://jira.jboss.org/jira/browse/JBSEAM-4487?page=com.atlassian.jira.pl...
]
dave atkins updated JBSEAM-4487:
--------------------------------
Description:
I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts
our modest Seam app. After some investigation I discovered this in the log
2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up:
org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts]
starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO
[org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25
17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO
[org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session
This is repeated for thousands of lines. After digging around the seam code I realised
that if you have two concurrent requests and one invalidates the session before the other
is finished, seam goes into an recursive loop of session creation (normally ended by stack
overflow). Here's a stack trace showing two recursions.
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at
org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at
org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
This problem is partially documented here -
https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve
the root cause of the problem.
The problem is caused by the SessionMap used by ServerConversationContext. Internally the
session map uses HttpServletRequest.getSession(true) to retrieve the session, which
creates a new session if the one defined on the HttpServletRequest is invalid or null.
Unfortunately, when the new session is created session listeners are informed before the
session has been set on the HttpServletRequest. Seam is one of these session listeners and
creates a new Identity on session creation, which in turn accesses the SessionMap, still
before the new Session has been set on the request. This leads to an infinite recursive
loop.
The SessionMap used is returned by externalContext.getSessionMap(). One solution could be
to implement our own SessionMap that doesn't attempt to create a new session if the
current session is invalid or null, although I've no idea how this would impact on
other Seam code.
The problem is relatively easy to create. In our application we have a search page that
can take quite a while to complete a request. If we log out of the application in another
tab before the search has completed the problem arises.
We are using seam 2.1.1.GA. I've looked at the source code for the latest release and
it appears that the problem will still occur due to use of SessionMap.
Out current workaround is to add a ThreadLocal to Identity.create that counts recursive
calls. If more then two recursive calls are detected an IllegalStateException is thrown.
This isn't definitely isn't a permanent solution, but stops our server creating
100,000 sessions.
was:
I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts
our modest Seam app. After some investigation I discovered this in the log
2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up:
org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts]
starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO
[org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25
17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO
[org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session
This is repeated for thousands of lines. After digging around the seam code I realised
that if you have two concurrent requests and one invalidates the session before the other
is finished, seam goes into an recursive loop of session creation (normally ended by stack
overflow). Here's a stack trace showing two recursions.
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at
org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at
org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
This problem is partially documented here -
https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve
the root cause of the problem.
The problem is caused by the SessionMap used by ServerConversationContext. Internally the
session map uses HttpServletRequest.getSession(true) to retrieve the session, which
creates a new session if the one defined on the HttpServletRequest is invalid or null.
Unfortunately, when the new session is created session listeners are informed before the
session has been set on the HttpServletRequest. Seam is one of these session listeners and
creates a new Identity on session creation, which in turn accesses the SessionMap, still
before the new Session has been set on the request. This leads to an infinite recursive
loop.
The SessionMap used is returned by externalContext.getSessionMap(). One solution could be
to implement our own SessionMap that doesn't attempt to create a new session if the
current session is invalid or null, although I've no idea how this would impact on
other Seam code.
The problem is relatively easy to create. In our application we have a search page that
can take quite a while to complete a request. If we log out of the application in another
tab before the search has completed the problem arises.
We are using seam 2.1.1.GA. I've looked at the source code for the latest release and
it appears that the problem will still occur due to use of SessionMap.
Out current workaround is to add a ThreadLocal to Identity.create that counts recursive
calls. If more then two recursive calls are detected an IllegalProcessState exception is
thrown. This isn't definitely isn't a permanent solution, but stops our server
creating 100,000 sessions.
Concurrent requests; one invalidates the session, results in
recursive loop of session creation
-----------------------------------------------------------------------------------------------
Key: JBSEAM-4487
URL:
https://jira.jboss.org/jira/browse/JBSEAM-4487
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.1.1.GA, 2.1.2.CR1, 2.1.2.CR2, 2.1.2.GA, 2.2.0.CR1, 2.2.0.GA
Environment: Jboss 4.2.2 with shipped Tomcat on Linux.
Reporter: dave atkins
I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts
our modest Seam app. After some investigation I discovered this in the log
2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up:
org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts]
starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO
[org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25
17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up:
org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO
[org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session
This is repeated for thousands of lines. After digging around the seam code I realised
that if you have two concurrent requests and one invalidates the session before the other
is finished, seam goes into an recursive loop of session creation (normally ended by stack
overflow). Here's a stack trace showing two recursions.
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at
org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at
javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at
org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
This problem is partially documented here -
https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve
the root cause of the problem.
The problem is caused by the SessionMap used by ServerConversationContext. Internally the
session map uses HttpServletRequest.getSession(true) to retrieve the session, which
creates a new session if the one defined on the HttpServletRequest is invalid or null.
Unfortunately, when the new session is created session listeners are informed before the
session has been set on the HttpServletRequest. Seam is one of these session listeners and
creates a new Identity on session creation, which in turn accesses the SessionMap, still
before the new Session has been set on the request. This leads to an infinite recursive
loop.
The SessionMap used is returned by externalContext.getSessionMap(). One solution could be
to implement our own SessionMap that doesn't attempt to create a new session if the
current session is invalid or null, although I've no idea how this would impact on
other Seam code.
The problem is relatively easy to create. In our application we have a search page that
can take quite a while to complete a request. If we log out of the application in another
tab before the search has completed the problem arises.
We are using seam 2.1.1.GA. I've looked at the source code for the latest release and
it appears that the problem will still occur due to use of SessionMap.
Out current workaround is to add a ThreadLocal to Identity.create that counts recursive
calls. If more then two recursive calls are detected an IllegalStateException is thrown.
This isn't definitely isn't a permanent solution, but stops our server creating
100,000 sessions.
--
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