[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3070) Tomcat not cleaning up HttpSessions after a single FeedServlet request
by Christian Bauer (JIRA)
Tomcat not cleaning up HttpSessions after a single FeedServlet request
----------------------------------------------------------------------
Key: JBSEAM-3070
URL: http://jira.jboss.com/jira/browse/JBSEAM-3070
Project: Seam
Issue Type: Bug
Components: Wiki
Reporter: Christian Bauer
Assigned To: Christian Bauer
Priority: Critical
Only reproducible in production: The number of HttpSessions is growing over several days. I wrote a listener and it shows the following pattern:
<User> <Action> <Creation timestamp> <Last access timestamp> <Idle> <Expired since>
Guest Feed: 1 04. Jun 2008, 16:01:46 04. Jun 2008, 16:01:46 00:13:49 00:03:49 (EXPIRED!) 5 KiB
Guest Feed: 1 04. Jun 2008, 15:59:56 04. Jun 2008, 15:59:56 00:15:39 00:05:39 (EXPIRED!) 5 KiB
Guest Feed: 1450 04. Jun 2008, 16:03:31 04. Jun 2008, 16:03:31 00:12:04 00:02:04 (EXPIRED!) 5 KiB
The EXPIRED! sessions are alive past their maxInactiveInterval (see the time next to it). Tomcat does not clean them up and I don't know why. The only recognizable pattern is that they are all from the FeedServlet, and a single request to that servlet. At this point I suspect that something in Seams ContextualRequest filter is wrong and influencing Tomcat negatively. Will keep this assigned to the wiki until the cause is clearer.
--
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
14 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2452) Event logging and notification system
by Christian Bauer (JIRA)
Event logging and notification system
-------------------------------------
Key: JBSEAM-2452
URL: http://jira.jboss.com/jira/browse/JBSEAM-2452
Project: JBoss Seam
Issue Type: Feature Request
Components: Wiki
Reporter: Christian Bauer
Assigned To: Christian Bauer
Notification system that supports user personalization:
- All actions should throw events with a payload (otherwise context lookup in the generic event listener gets complicated)
- A generic event listener is the router for these events, pushes events to more specialized registered listeners (how do we observe all wiki.* events?)
- There has to be some asynchronous processing at that point, the generic event listener should not block
- Specialized listeners can register on the generic listener based on groups of events, e.g. "Document actions" or "User actions"
- The API for the specialized listeners (and how they are registered) has to be usable for the core and plugins
In a second step, implement the following core specialized listeners:
- access logging (document reads, etc.)
- channels bound to user, e.g. a user can build his own channel(s) by picking event groups he is interested in
Not sure at this point how notification looks like, that is, how listeners can push notifications (or whole channels?) to some endpoint (e-mail).
--
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
14 years, 10 months