Question on ScheduledTimerTask and ThreadPoolTaskExecutor issue

[back2grave]

Hi,

I'm facing an issue while try to use ScheduledTimerTask and ThreadPoolTaskExecutor in conjunction. My objective is to have a timer thread which will wake up in a specific interval of time and check number of threads running in a ThreadPoolTaskExecutor. If its less than its capacity, it'll create number of workers (max capacity - number of current tasks) and submit to the pool. Here's my spring config.

<bean id="scheduledTask" class="org.springframework.scheduling.timer.ScheduledTimerTask">
		<property name="delay" value="10000" />
		<!-- run every 20 seconds -->
		<property name="period" value="20000" />
		<property name="timerTask" ref="contentScheduler" />
	</bean>

	<bean id="timerFactory" class="org.springframework.scheduling.timer.TimerFactoryBean">
		<property name="scheduledTimerTasks">
			<list>
				<ref bean="scheduledTask" />
			</list>
		</property>
	</bean>

<bean id="contentScheduler"		class="com.test.contentextraction.scheduler.ContentScheduler"
		destroy-method="shutdown">
		<property name="taskExecutor">
			<ref local="threadPoolExecutor" />
		</property>
		<property name="properties">
			<ref local="extractionProperties" />
		</property>
	</bean>

	<bean id="contentWorker" class="com.test.contentextraction.processor.ContentWorker"
		scope="prototype">
		<property name="processorChain" ref="processorChain" />
		<property name="configuration" ref="configuration" />
	</bean>

	<bean id="taskExecutor" 	class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
		<property name="corePoolSize" value="5" />
		<property name="maxPoolSize" value="5" />
		<property 
			name="waitForTasksToCompleteOnShutdown" value="true" />
	</bean>


	<bean id="threadPoolExecutor"		class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
		<property name="targetObject">
			<ref local="taskExecutor" />
		</property>
		<property name="targetMethod" value="getThreadPoolExecutor" />
	</bean>

As you can see, I have defined ScheduledTimerTask called scheduledTask which has a property called timerTask that actually represents my bean ContentScheduler. ContentScheduler extends TimerTask.

I'm trying to inject the thread pool executor inside the ContentScheduler so that it can have the same pool instance. Inside the run method of ContentScheduler , I check for the pool size, based on which I'll create a contentworker instance and do executor.execute(worker).

Here's a code snippet,

public void setTaskExecutor(ExecutorService executor){
		this.executor = executor;
	}

public void run(){
		try{
			if(executor!=null){
				int activeCount = ((ThreadPoolExecutor)executor).getActiveCount();
				int poolThreshold = (Integer.parseInt(properties.getProperty(WORKER_COUNT)));
				if(activeCount < poolThreshold){
					for(int i=0; i< (poolThreshold - activeCount) ;i++){
AbstractApplicationContext ctx = new ClassPathXmlApplicationContext(EXTRACTION_CONFIG);
						IContentWorker task = (ContentWorker) ctx.getBean("contentWorker");
	executor.execute(task);
					}
				}
			}
		}catch (Exception ex) {
			ex.printStackTrace();
		}

Problem I'm facing is , every time the timer is waking up, it's creating a new intsance of the threadpool executor, which is defeating my objective.

Just wanted to know if there's a way to address this issue so that the timer object ContentScheduler will always refer to the same thread pool executor instance.

Any pointers will be highly appreciated.

-Thanks

[Marten Deinum]

Problem I'm facing is , every time the timer is waking up, it's creating a new intsance of the threadpool executor, which is defeating my objective.

Which isn't that strange is it. YOu are creating a new instance of an applicationcontext each time the method is run... If you need access to the BeanFactory/ApplicationContext implement BeanFactoryAware or ApplicationContextAware (or use @Autowired for either of the types), instead of creating a new instance...

[back2grave]

Which isn't that strange is it. YOu are creating a new instance of an applicationcontext each time the method is run... If you need access to the BeanFactory/ApplicationContext implement BeanFactoryAware or ApplicationContextAware (or use @Autowired for either of the types), instead of creating a new instance...

My bad, stupid mistake. Thanks for pointing it out Marten, appreciate your help.