Menu
▾
▴
Re: [Quickfixj-users] Any way to clean up threads?
|
From: Christoph J. <chr...@ma...> - 2018-11-19 18:57:26
|
I am not sure if it works but you could try to replace the MINA JAR that is bundled with QFJ 1.6.3 and replace it with the current MINA 2.0.19. That *might* fix part of the problem. Cheers, Chris. Am 19. November 2018 19:40:47 MEZ schrieb Sean LeBlanc <sea...@ic...>: >Ah, thanks, Chris, that's good to know. Unfortunately, we probably >won't >be upgrading any time in the near-near future. :( > > >But when we do, I will make a note to re-try this for our >automation/testing scenarios. > > >Cheers! > > >On 11/19/18 10:56 AM, Christoph John wrote: >> Hi >> I am pretty sure that this has been corrected in later versions. >Could >> you retest with 2.1.0? IIRC there was also a bug in MINA. >> Cheers, >> Chris. >> >> Am 19. November 2018 17:38:56 MEZ schrieb Sean LeBlanc >> <sea...@ic...>: >> >> Hello, >> >> >> we are using QuickFIX/J 1.6.3 and for testing, we sometimes stop >> initiators/acceptors and start them after changing their settings >> for test scenarios. However, it seems that after doing a stop on >> these objects still leaves some threads (e.g., >> NIOSocketAcceptor-14, QFJ Message Processor) around, and if this >> start/stop cycle is called enough times, the JVM eventually will >> hit an OS restriction on number of threads. If I were to bump >that >> up, I would think the next problem would be memory, as that also >> gets quite large. >> >> I've tried various scenarios to try to make these get cleaned up, >> but nothing I've done seems to work. What I've tried is: adding >> the "true" in the call to stop, trying to set initiator to null >> >> To see what I'm talking about, attach something like Java >VisualVM >> to your JVM, then do something like: >> >> >> initiator = new SocketInitiator(this, storeFactory, >> sessionSettings, logFactory, messageFactory) >> >> initiator.start() >> >> initiator.stop(true) >> >> initiator.start() >> >> ... >> >> etc. >> >> >> ...and watch the thread count. Invoking GC directly doesn't seem >> to reap any of the threads, either. Acceptors seem to have >similar >> behavior. >> >> >> Is there anything I could try to clear these? >> >> >> -- >> *Sean LeBlanc* >> *Software Architect/Senior Software Engineer* >> *Institutional Cash Distributors Technology, LLC* >> Direct 720.453.1288 >> Fax 720.453.1335 >> sea...@ic... <mailto:sea...@ic...> | >> www.icdportal.com <http://www.icdportal.com/> >> >-- >*Sean LeBlanc* >*Software Architect/Senior Software Engineer* >*Institutional Cash Distributors Technology, LLC* >Direct 720.453.1288 >Fax 720.453.1335 >sea...@ic... <mailto:sea...@ic...> | >www.icdportal.com <http://www.icdportal.com/> |
