I think a quick fix is to change from calling scheduleAtFixedRate to just calling schedule, this different being the way the interval between executions is controlled.
For scheduleAtFixedRate which we use now execution rate is scheduled based on the time that the task was first scheduled. > In fixed-rate execution, each execution is scheduled relative to the > scheduled execution time of the initial execution. If an execution is > delayed for any reason (such as garbage collection or other background > activity), two or more executions will occur in rapid succession to "catch > up." In the long run, the frequency of execution will be exactly the > reciprocal of the specified period (assuming the system clock underlying > Object.wait(long) is accurate). > For schedule the rate is controlled based on the time of the last execution: > In fixed-delay execution, each execution is scheduled relative to the > actual execution time of the previous execution. If an execution is > delayed for any reason (such as garbage collection or other background > activity), subsequent executions will be delayed as well. In the long run, > the frequency of execution will generally be slightly lower than the > reciprocal of the specified period (assuming the system clock underlying > Object.wait(long) is accurate). > In the case of the write check task I'd think that it'd be better to have the occasional delays that can occur because of garbage collection etc vs having write checks occur in quick rapid fire succession because things got slowed down since once you do one write check, then you don't need to do another until the next configured interval. Regards Tim. http://fusesource.com Gary Tully wrote: > > hmm, that sounds like a reasonable theory... seems like a scheduled > executor is the answer or a scheduler that uses cpu relative time... > so that sleep time is ignored. > > Can you raise a jira issue to track this, there are a few schedulers > in the code base, so they may all need the same treatment. > > On 13 July 2011 22:45, Michael Brewer-Davis > <mich...@tech4learning.com> wrote: >> Using activemq 5.4.0 for a P2P desktop applicaiton, I get an OOME when my >> computer awakes from sleep: >> >> Exception in thread "InactivityMonitor WriteCheck" >> java.lang.OutOfMemoryError: unable to create new native thread >> >> The cause appears to be: >> - WRITE_CHECK_TIMER schedules checks at a fixed rate >> - ASYNC_THREADS uses an unbounded thread pool to service the checks >> >> When the computer wakes, WRITE_CHECK_TIMER satuates the system with pent >> up >> requests and uses up all available threads. >> >> Am I right in thinking: >> - this is an issue >> - some options for resolution are: >> bounding the ASYNC_THREADS >> converting WRITE_CHECK_TIMER to a scheduled executor, which would run >> the submitted task serially >> >> >> michael >> >> > > > > -- > http://fusesource.com > http://blog.garytully.com > -- View this message in context: http://activemq.2283324.n4.nabble.com/Possible-memory-leak-tp3665094p3667681.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
