Friday, April 3, 2009

The Return of the Persistent Quartz Job

Finally I managed to understand the persistent job and make it work reliably: for your stateful job and the trigger volatility should NOT be true. Even setting durability to true can cause problems as it would persist orphan jobs that we may not need. If the intention is to just prevent loss of jobs during system re-starts, it is enough to set requests recovery to true. That's it. Simple is beautiful :).

Thursday, April 2, 2009

Caching Method Invocation Results

Worked on setting up a cache for a method invocation fetching results from a webservice using Spring Cache AOP and EHCache in a Spring-Maven environment.Long live sourceforge! The spring cache java doc is pretty helpful and this article by Pieter Coucke expands on what you read in the java doc. You can also have a look at my complete configuration (which works) and is based on the article and the java doc.

And if you are using Maven, you would need to add dependencies for ehcache and spring cache.


<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>1.5.0</version>
</dependency>
<dependency>
<groupId>spring-cache</groupId>
<artifactId>spring-cache</artifactId>
<version>2.4.1</version>
</dependency>

Wednesday, April 1, 2009

Another Way of Starting ActiveMQ Broker in Spring

I had posted a blog about running an ActiveMQ broker in Spring. Recently, I found an alternative way to start an ActiveMQ message broker in spring environment by injecting a bean based on org.apache.activemq.xbean.XBeanBrokerService:


<bean id="broker" class="org.apache.activemq.xbean.XBeanBrokerService">
<property name="useJmx" value="true"/>
<!-- this tells it to create a filesystem store -->
<property name="persistent" value="true"/>
<property name="brokerName" value="mySpringBroker"/>
<!--the queues/topics that this broker starts with-->
<property name="destinations">
<list>
<ref bean="destination1"/>
<ref bean="destination2"/>
</list>
</property>
<property name="transportConnectors">
<list>
<!-- an in vm connector which is nice and fast -->
<bean class="org.apache.activemq.broker.TransportConnector">
<property name="uri" value="vm://localhost"/>
</bean>
<!-- a connection for external clients specifying the IP of machine deploying the broker, something like tcp://10.10.10.10:61636. Here read from a properties file but can be hard-coded as well-->
<bean class="org.apache.activemq.broker.TransportConnector">
<property name="uri" value="${broker.transportExternalConnectorUri}"/>
</bean>
</list>
</property>
</bean>

<bean id="destination1" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg value="com.saveenkumar.myQueue1"/>
</bean>

<bean id="destination2" class="org.apache.activemq.command.ActiveMQQueue">
<constructor-arg value="com.saveenkumar.myQueue2"/>
</bean>

In fact,the package org.apache.activemq.xbean provides various options (beans) to start the broker in a spring environment.

The Wierd Persistent Quartz Job

I recently faced a problem with getting quartz to persist the jobs in case of a scheduler shut down. Penning down how it got solved (with Ben's help). 


Also, when I configured my stateful job, I set volatility and request recovery to true besides putting in job class, name and group. Sadly, the job never-ever persisted when the system re-started. 

Miraculously, this started working fine when config was replaced by this configuration (only scheduler config is different).

Plus when I configured the stateful job, I set durability to true and always put in job class, name and group. Of course you can add what you want to the data map (as long as it is Serializable). 

What I don't understand is that even when I have not set either volatility or request recovery to true, how setting only durability to true takes care of persisting the Job between shutdowns and startups. Whatever it takes to make it work... Quirky but may be helpful to you if you face a similar problem. Cheers.