Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Code:

 QuartzSchedulerMBean bean;
 Map<String, Object> jobDetailInfo = new HashMap<String, Object>();
 Map<String, Object> triggerInfo = new HashMap<String, Object>()
 
 jobDetailInfo.put("name", "MyJobName");
 jobDetailInfo.put("group", "MyJobGroup");
 jobDetailInfo.put("description", "This is my JobDetail");
 jobDetailInfo.put("jobClass", "org.me.MyJobImpl");
 jobDetailInfo.put("jobDataMap", new HashMap<String, String>());
 jobDetailInfo.put("durability", Boolean.FALSE);
 jobDetailInfo.put("shouldRecover" ,Boolean.FALSE);
 
 triggerInfo.put("name", "MyTrigger");
 triggerInfo.put("group", "MyTriggerGroup");
 triggerInfo.put("description", "This is my trigger");
 
 if(cronExpression) {
   triggerInfo.put("cronExpression", "0 0/5 * * * ?");
 } else {
   triggerInfo.put("startTime", new Date());
   triggerInfo.put("endTime", new Date());
   triggerInfo.put("repeatCount", Integer.valueOf(5));
   triggerInfo.put("repeatInterval",Long.valueOf(10));
 }
 triggerInfo.put("jobName", "MyJobName");
 triggerInfo.put("jobGroup", "MyJobGroup");
 
 bean.scheduleBasicJob(jobDetailInfo, triggerInfo);

You can only use simple types in the jobDataMap.

There are other ways of scheduling jobs over JMX if you have custom jobDetail or trigger types, but this is the simplest way.

Well, the documentation on how to have the SchedulerMBean registered is fairly clear, so let's start there. Can you please include you quartz.properties here. In jconsole there should be a top-level "quartz" node. It may be the case that you've successfully exposed the MBean but that you can't access it because you haven't enabled remote JMX in your app:

-Dcom.sun.management.jmxremote

Once you can see the MBean, we can talk about how to add new JobDetails to the scheduler over JMX. Note that you can only add new JobDetails whose JobClass is already known to the scheduler.

Are there any errors/warnings in the Ehcache log?
Note that Bitronix 2.0.0 or later is required.

Open up jconsole and point it at your tomcat and see if there are any Terracotta MBeans in the default, platform MBeanServer. What version of tomcat?

Are you certain you spelled it correctly: bootstrapCacheLoaderFactory?

Try enabling statistics -- you shouldn't need to do this. I created your scenario and it maxed correctly for me.

Did you run your application with the following settings?

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Also, I would recommend you not override the jmx.objectName.

I'm not sure how rmi.registryPort interacts with the jmxremote.port... you may need to change one of them.

Well, that should have been fixed in 3.5.1 so let's start over. Please create a JIRA ticket, explain the problem and what steps you take to make it happen.

Yes, QM works with 1.8 and greater. You can also look in ~/quartzmgr/logs/quartzmgr.log for any additional clues.

The title of this message states Quartz version 1.8.5 but the MBean shows version 1.6.5.... I believe the MBean. ;^)

Yes, that is the correct method to call. It returns a boolean indicating if it was successful. It firsts unschedules the job before removing it.

Is jobId a variable or a string? In one place you have "jobId" and in another just jobId.

Objects must first be freed by the local JVM's garbage collector before they can be removed by the distributed collector. Seems like the bogus sessions are expiring, being collected locally, and then via DGC. You can enable logging to see what's happening with the sessions. Add a section like this to your tc-config.xml:

Code:

  <tc-properties>
     <property name="session.debug.sessions" value="true"/>
     <property name="session.debug.invalidate" value="true"/>
  </tc-properties>

Look at Platform|Clustered Heap|Instance Counts to see what types are hot.

You could implement an RMI service that receives the jobs, packaged as a JAR, as a byte array. Save the bytes to a temp file which you then pass to URLClassLoader. Details about the jobs could be described by the existing XMLSchedulingDataProcessPlugin format. You would need to extend (copy?)
XMLSchedulingDataProcessPlugin so that it used a subclass of CascadingClassLoaderHelper that knows where you JAR is located. It wouldn't really be a registered plugin but rather something your RMI service uses to get the described jobs scheduled.

Now the problem is how to let your users package up their jobs/trigger descriptions so they can invoke your RMI service.

It would cool if you could have your users package up their jobs JAR and stick it in DropBox and then have your service poll for new JARs, remove them from DropBox and then schedule the jobs. No RMI needed!

This is all just thinking out loud really.