Announcement Announcement Module
Collapse
No announcement yet.
best practice for destroy method for FactoryBeans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • best practice for destroy method for FactoryBeans

    What is the best practice to deal with the destroy method for a FactoryBean if the innerbean has multiple shutdown methods? If you take a look at the ScheduledThreadPoolExecutor there are 2 methods: shutdown and shutdownNow. It depends on the situation how you want to shut down so the FactoryBean should be configurable so you can choose which one you want to use.

    So how should the FactoryBean get the information to choose between these alternative shutdown methods? Should a 'shutdownmethod' property be added? What is common practice in Spring?

  • #2
    I would definitely create a property to select the shutdown method to use, choosing a sensible default. I was looking at adding support for ScheduledThreadPoolExecutor to the core and this was the approach I was planning to take.

    Rob

    Comment


    • #3
      Originally posted by robh
      I would definitely create a property to select the shutdown method to use, choosing a sensible default.
      And what about the result of the shutdownNow? You get a list with tasks and maybe they have to be handled. Should a shutdownNowHandler be added?

      I was looking at adding support for ScheduledThreadPoolExecutor to the core and this was the approach I was planning to take.

      Rob
      I`m currently writing it and I would be happy to share it with the Spring community. I`m also thinking about a better way to create schedule-dates.

      Comment


      • #4
        A shutdown handler would make sense, perhaps with some default implementations that discard the outstanding jobs or execute them serially. Feel free to post your code as a JIRA issue and then we will use this if we do add this to the main framework. It may be something that we choose to add to Spring Modules rather than the main project itself.

        Rob

        Comment


        • #5
          Originally posted by robh
          A shutdown handler would make sense, perhaps with some default implementations that discard the outstanding jobs or execute them serially.
          Yes.. but in essence the same goes for a Future handler if a task is scheduled. I could think of a situation where this would be a nice thing to have. The question is if the api is not going to be too complex.

          Feel free to post your code as a JIRA issue and then we will use this if we do add this to the main framework. It may be something that we choose to add to Spring Modules rather than the main project itself.
          Rob
          I allready had a JIRA issue where I just have added the code.
          http://opensource.atlassian.com/proj...rowse/SPR-1181

          There are some things to do, for example: submits with only a Runnable (direct execution).

          I also have created 2 other JIRA issues:
          http://opensource.atlassian.com/proj...browse/SPR-914
          http://opensource.atlassian.com/proj...browse/SPR-784

          This is very handy if you want to do something like this:

          Code:
          <bean id="indexWriterJobCronTrigger"
          		class="org.springframework.scheduling.quartz.CronTriggerBean">
          
          		<property name="jobDetail">
          			<bean class="com.jph.spring.MethodInvokingSequenceJobDetailFactoryBean">
          				<property name="methodInvokerList">
          					<list>
          						<bean class="org.springframework.util.MethodInvoker">
          							<property name="targetObject" ref="indexUpdater"/>
          							<property name="targetMethod" value="process"/>
          						</bean>
          
          						<bean class="org.springframework.util.MethodInvoker">
          							<property name="targetObject" ref="indexOptimizer"/>
          							<property name="targetMethod" value="optimize"/>
          						</bean>
          
          						<bean class="org.springframework.util.MethodInvoker">
          							<property name="targetObject" ref="indexReaderProviderService"/>
          							<property name="targetMethod" value="refresh"/>
          						</bean>
          					</list>
          				</property>
          
          				<property name="concurrent" value="false"/>
          			</bean>
          		</property>
          
          		<property name="cronExpression">
          			<!-- iedere minuut -->
          			<value>0 0/1 * * * ?</value>
          		</property>
          	</bean>
          And this:
          Code:
          <bean id="indexUpdaterScheduler"
          		  class="org.jph.spring.scheduling.concurrent.ScheduledThreadPoolExecutorFactoryBean">
          
          		<property name="scheduledWithFixedDelayRunnable">
          			<bean class="org.jph.spring.scheduling.concurrent.ScheduledWithFixedDelayRunnable">
          				<property name="runnable">
          					<bean class="org.jph.spring.scheduling.MethodInvokeSequenceRunnable">
          						<property name="methodInvokerList">
          							<list>
          								<bean class="org.springframework.util.MethodInvoker">
          									<property name="targetObject" ref="indexUpdater"/>
          									<property name="targetMethod" value="process"/>
          								</bean>
          
          								<bean class="org.springframework.util.MethodInvoker">
          									<property name="targetObject" ref="indexOptimizer"/>
          									<property name="targetMethod" value="optimize"/>
          								</bean>
          
          								<bean class="org.springframework.util.MethodInvoker">
          									<property name="targetObject" ref="indexReaderProviderService"/>
          									<property name="targetMethod" value="refresh"/>
          								</bean>
          							</list>
          						</property>
          					</bean>
          				</property>
          				<property name="initialDelay" value="60"/>
          				<property name="delay" value="60"/>
          				<property name="timeUnit" ref="java.util.concurrent.TimeUnit.SECONDS"/>
          			</bean>
          		</property>
          	</bean>

          Comment


          • #6
            I see my feature request is going to be part of Spring 1.3RC1. It is now totally in your hands or can I still be part of it? Writing the documentation, testing, more code for the missing parts etc etc.

            Comment


            • #7
              Any help is welcome. I would wait to see what happens with the code before beginning any documentation but I'm sure you help will come in handy.

              Rob

              Comment


              • #8
                Originally posted by robh
                Any help is welcome. I would wait to see what happens with the code before beginning any documentation but I'm sure you help will come in handy.
                Ok.. do you have a Spring code styleguide somewhere so I can change the style of the code? And do you have other styleguides as well? For example the unit testing part. What do you find acceptable to test.. how do you want it.


                Btw:
                The ThreadPoolExecutorService is not perfect. From an oo standpoint it should never have extended the ThreadPoolExecutor but it also is a little inflexible. What happens if the processing takes longer than the rate it fires -> the queue with tasks keeps growing and as far I have seen isn`t blocked in any way. So it would be nice if tasks could be canceled (or die if they are too old). In Quartz you have such control, but with the ScheduledThreadPoolExecutor you don`t. So I`m thinking about creating my own implementation of that aswell and it is going to be part of a small concurrency util library I`m writing for other projects. It also contains a BlockingExecutorService that gives more control on the blocking part than the ExecutorService does.

                Comment

                Working...
                X