[QFJ-867] Thread handling after exiting QuickFIX Created: 06/Nov/15  Updated: 16/Nov/15

Status: Open
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.6.1
Fix Version/s: None

Type: Bug Priority: Default
Reporter: Martin Vrábel Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: QuickfixJ
Environment:

Apache Tomcat 8 on Windows 10, Spring 4 web application


 Description   

Hi,

I stumbling over this thing over and over. When I stop my application I always get error messages in output about spawning a new thread during execution of application but failing to remove it when application stops:

```
06-Nov-2015 12:29:26.653 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@7f03e077]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.654 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@6b6c6237]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.654 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@2aca975d]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.654 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@2bebb3b3]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.655 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@4b8bfee1]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
```

It has something to do with `UtcTimestampConverter` but I have no idea why is it happening. I correctly shutdown all threads I manually start.

 Comments   
Comment by Christoph John [ 16/Nov/15 ]

Hmm, looks more like a false positive to me. But to be honest I never tried running QFJ in a managed environment or appserver.
http://stackoverflow.com/questions/28105803/tomcat8-memory-leak says that the ThreadLocals need to be removed but I think this is not done because it is expected that QFJ is ran in a stand-alone environment.

Comment by Martin Vrábel [ 16/Nov/15 ]

Would it be possible to call a method or something from outside of quickfix to manually shutdown all spawned threads when exiting my webapp?

Comment by Christoph John [ 16/Nov/15 ]

From what I understand from the output it does not have to do anything with threads but ThreadLocal variables that are still held. But AFAIK there is no built-in mechanism to clean them up.

Generated at Sat Nov 23 15:03:22 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.