3 Replies Latest reply on Jul 10, 2009 10:07 AM by timfox

    Usage of Timers in JBM 2

    timfox

      Timers should rarely if ever be used.

      Each Timer maintains its own thread so this doesn't scale.

      On the client side a scheduled executor pool is available to the session factory and this should be used for any scheduled tasks, e.g. for http transport.

      Take a look at the thread pooling chapter in the user manual. We have to be very careful where and how threads are created, always use the pools unless you have a *very* good reason not to (e.g. you need to set thread priority)

        • 1. Re: Usage of Timers in JBM 2
          jmesnil

          I'll rewrite the 2 http timer tasks (one used in NettyConnector, the other in Netty Acceptor) to use our scheduled thread pools instead of timers.

          I'll update our remoting SPI to pass a ScheduledExecutorService for the scheduled thread pool when creating a connector/acceptor in addition to the regular thread pool

          • 2. Re: Usage of Timers in JBM 2
            jmesnil

            I've removed the 2 TimerTasks used by Netty HTTP code (in r7558).
            I'll soon commit the removal of 2 other TimerTasks in MessageCounterManager and ResourceManager. Both will also be replaced by Runnabled executed by JBM scheduled thread pool.

            There remains 2 TimerTasks:
            * 1 in JBMBootstrapServer to check if there is a STOP_ME file and shutdown the server in that case
            * 1 in TimedBuffer

            The one in JBMBootstraspServer will stay.

            I'm not sure for the one in TimedBuffer. I guess we could also use the global scheduled thread pool for this one but the asyncio code already defines its own thread pools (in AIOSequentialFileFactory). Should it also define its own scheduled executor service or can it use the global one?
            Clebert, could you comment on this one?

            • 3. Re: Usage of Timers in JBM 2
              timfox

              The one in TimedBuffer is just for rate logging and wouldn't normally get instantiated so don't worry about it.