User activity scheduler thread not stopped

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Deploy application with GWTEventService in Tomcat and start it
2. Stop Tomcat

What is the expected output? What do you see instead?
GWTEventService should properly clean-up resources it allocates. Instead Tomcat 
reports
"...appears to have started a thread named 
[GWTEventService-UserActivityScheduler] but has failed to stop it. This is very 
likely to create a memory leak."

What version of the product are you using? On what operating system?
1.2.0

Please provide any additional information below.
If necessary there could be a ServletContextListener which stops this thread in 
the contextDestroyed() method.

Original issue reported on code.google.com by marcel@frightanic.com on 8 Jun 2012 at 8:46

[GoogleCodeExporter]

This is actually not possible, because the GWTEventService uses only 
daemon-threads which are terminated automatically. I will re-check it with 
Tomcat. Could you please re-check it too? Is Tomcat running in an own JVM 
instance?

Original comment by sven.strohschein@googlemail.com on 16 Jul 2012 at 6:56

• Added labels: Waitingforresponse

[GoogleCodeExporter]

I don't see the correlation between one (deamon-thread) and the other (graceful 
termination). The simple principle, in terms of software, I try to live by is: 
if you allocate resources you're responsible the de-allocate them. With Java 
it's fortunately not so much about memory anymore but it still applies. If you 
start a thread you're responsible to stop it.
True, if the VM goes down that happens automatically with deamon-threads. 
However, if you reload a context in a Servlet container the VM is not 
terminated. If deamon-threads are not terminated on context destroyed they 
cause memory leaks because the classloader cannot be GCed.
I'm super thankful to the Tomcat-team they implemented this piece of code that 
detects and reports such cases.

Original comment by marcel@frightanic.com on 17 Jul 2012 at 9:38

[GoogleCodeExporter]

Ok, it will be improved with 1.3 (or maybe 1.2.1)

Original comment by sven.strohschein@googlemail.com on 17 Jul 2012 at 5:54

• Changed state: Accepted
• Added labels: 1.3
• Removed labels: Waitingforresponse

[GoogleCodeExporter]

The thread gets now stopped when the EventService servlet gets 
deregistered/destroyed by the ServletContainer / environment. That fixes the 
problem.

It could be an idea to start and stop the user management for example with a 
servlet context listener because it is and should be completely separated from 
the pure event listening, but a servlet context listener would increase the 
configuration requirements for the user/developer. I will think about it...

Original comment by sven.strohschein@googlemail.com on 22 Jul 2012 at 10:14

• Changed state: Fixed