smithproject.org

Smith team leads:

Unless someone has an objection, I'm planning to build out CFSCHEDULE functionality using a separate executable than smith\web itself. If you think about it, scheduling the execution of web pages really has nothing to do with the processing of CFML templates. So, the plan is to build a stand-alone executable jar that is built on top of Quartz (an open source job scheduling engine). That jar's job will be to accept scheduling requests (updates, deletes, adds) through RMI, to use the Apache HTTP Client to run those requests as specified by stored scheduling requests, and to record results in a schedule.log file. The CFSCHEDULE tag will basically turn into an RMI client for this jar, simply updating the schedule. Someone can then build a front end web page to add into the smith administrator that allows admins to visually manipulate the schedule.

So that's what I'm planning to do. If one of the smith team leads has a different approach in mind, I'm listening. If not, I'm going to start on this and I plan to get it done in the next few days.

On a totally unrelated topic, those of you running Windows, you can probably turn Smith into a Windows Service by wrapping it with this: http://wrapper.tanukisoftware.org/doc/english/index.html

I've used the JSW on many other projects, it's usually pretty simple to get set up, and it's solid. You can then use all of Windows start/restart/notify behavior if the service experiences problems.

--Calphool

Ok everyone, I got the RMI/Quartz/HTTPClient service written and working. Basically you use RMI to request the invokation of httpclient to run your requested URL, passing most of the parms of <cfschedule>. Quartz then makes sure to invoke httpclient as specified in the RMI call.

Now it's just a matter of building the tag side of things in smith, which should be pretty easy (although the RMI coding might be a tiny bit tricky). After that, we've got a fully functional <cfschedule> tag just waiting for some industrious person to build a front-end for it in the admin screens. I may go ahead and do that myself after I get the tag running.

It's 2:19am for me right now, and I can barely keep my eyes open. I'll finish up the smith side of the <cfschedule> tag implementation tomorrow some time.

Cheers!

--Calphool

Hello Calphool,

thank you for your efforts! You are really making Smith better and better, everyday. Great work!

Best regards,
orcus

Ok everybody. I've got <cfschedule> working, more or less. I've got a few little bugs to work out, but it's mostly working as it should.

This is what's left to do:

1) Change action=update behavior so Quartz doesn't freak out when you try to schedule two tasks with the same name (the second one should stomp the first).

2) Figure out exactly what permissions are needed by smith for RMI client behavior. Right now I've got it wide open so I didn't have to deal with it during development.

3) Build a user interface to snap into the smith admin screens for schedule management.

4) Switch the SmithScheduler RMI server to use Log4J. I don't know why I started using java.util.logging.... I'm an idiot.

5) Come up with a bunch of test cases to make sure everything is completely stable.

6) Package up the SmithScheduler.jar nice and clean, and put together detailed instructions for the Smith patches. I'll start with a clean install of 1.3b6, and I'll patch it one piece at a time, writing the steps, until I get it completely up and running again.

7) Hook Quartz into Derby so that scheduled tasks persist beyond the life of the SmithScheduleServer executable.

There are some TODO:'s I'm going to leave in there for now. For example, I didn't implement "resolveURLs=Yes", because to be quite frank, I don't really know what it does. Another TODO: I'm going to leave is the Interval=monthly stuff. Right now it calculates an "average month duration" for it's interval window (about 30.5 days). That's not exactly what most people think when they say "this runs monthly". Although it would average out to be one month per iteration, it wouldn't run on the same day of the month, and that's what most people expect. So there will be a couple of little rough edges, but it should be more than solid for most purposes. Someone can come in behind me and clean up those little rough spots later.

Hi Calphool,

this sounds very good!

I hope I'll soon catch some time to integrate all of the stuff and release a new (beta) build, so that people can start playing with it, and provide some feedback.

Good work!
orcus

Ok... done. I've got this all working, and I've built the administration screens to manage schedules.

I had forgotten how much I really dislike JSP... It took me forever to get those admin screens working. The JSP is pretty nasty too (JSP has never been one of my strong suites... it ends up looking pretty much like a hand coded servlet.)

So, now I'm going to do an Araxis compare and document all the changes I made to Smith 1.3b6 to get this up and running. Then I'll upload all the new code to the patches area.

Man, I'm going to work on some of the easier tags to boost my ego back up...

Well, this is sort of annoying... I've got all this code to upload for CFSCHEDULE, and I can't seem to upload it anywhere that will work. SourceForge has some kind of size limitation that I'm hitting, and this site's forum gives me this:

java.lang.NullPointerException
net.jforum.JForumExecutionContext.enableRollback(JForumExecutionContext.java:272)
net.jforum.JForum.service(JForum.java:209)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
net.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59)

Ok, so I'll put it in a public folder on my SkyDrive account. Here's the link:

http://cid-c1778198fee7a8d0.skydrive.live.com/browse.aspx/Public

Hi Calphool,

sorry for the inconvenience! If all else fails, you can always mail it to contact@smithproject.org - it won't be available online, it's true, but it will fall into the right hands

Hi Calphool,

Would you not entertain discarding the RMI stuff? It seems like an unnecessary layer.

Good work by the way!!!!

Brian

It keeps the code base separate between scheduling and CF processing. Since I don't understand the overall architecture of the CF engine itself, I was worried about tying all that scheduling garbage into the CF engine. So, it was done mostly as a defensive move. If someone can give an overview of the CF engine, maybe it does make more sense to have a collection of threads or something that deals with all these "housekeeping" issues like scheduling.