Re: NSTimer replacement?
Re: NSTimer replacement?
- Subject: Re: NSTimer replacement?
- From: Kieran Kelleher <email@hidden>
- Date: Wed, 9 May 2007 11:49:44 -0400
On May 9, 2007, at 10:34 AM, Johann Werner wrote:
Am 09.05.2007 um 15:35 schrieb Kieran Kelleher:
I'll try and be brief ......... For stuff like this I create
scheduled tasks in the database. ScheduledTasks have a start date
(1/1/2007 0:00 for example) and end date(12/31/2008 10:00 for
example) and a frequency (1, 2 ... n) and an interval (minutes,
hours, days, weeks, months) and a class name that implements
ScheduledTask interface. Related to that are many
ScheduledTaskEvents, one for each time the task has executed.
Since I run multiple instances, I have a standalone app
(ScheduleManager.woa for example) that regularly (every 60 seconds
for example) checks the schedule table for tasks to be executed,
creates new ScheduledTaskEvents in the db for tasks that are to be
executed, and then issues a direct action to the multiple instance
app with the ScheduledTaskEvent ID. The task is executed and
that's it. The ScheduledTaskEvent entity has STATE such as INIT,
PROCESSING and DONE. The ScheduledTaskManager only sends DA's for
ones with INIT state.
That's an interesting and good approach I will definitely consider.
Are you using wget to trigger the DA
public void fireEvent( CTScheduledTaskEvent event ) {
int portNumber = ERXProperties.intForKeyWithDefault
( "singletonOperations.fireEvent.portNumber", 80 );
String targetHostName = System.getProperty
( "singletonOperations.fireEvent.targetHostName" );
WOHTTPConnection httpConn = new WOHTTPConnection
( targetHostName,
portNumber );
String url = System.getProperty
( "singletonOperations.fireEvent.baseUrl" );
url = "http://"; + targetHostName + url + "?keycode=" +
event.keycode();
if ( log.isInfoEnabled() ) log.info("fireEvent
targetHostName = "
+ ( targetHostName ==
null ? "null" : targetHostName )
+ "; port = " + portNumber
+ "; url = " + url );
WORequest request = new WORequest( "GET", url, "HTTP/1.1",
null,
null,
null );
if ( log.isDebugEnabled() ) log.debug( "httpConn = " +
httpConn + "; targetHostName = " + targetHostName + "; port = " +
portNumber + "; request uri = " + request.uri() );
httpConn.sendRequest( request );
WOResponse response = httpConn.readResponse();
if ( log.isDebugEnabled() ) log.debug("response = " +
response );
}
and then depending of the response getting back mark the task as DONE?
Coupling is loose. The "singleton" DA firing app only "dumbly" fires
for tasks that are in INIT state.
Or does the instance that handles the DA write directly to the db?
The DA in the receiving app, if it gets executed, immediately updates
the task state to PROCESSING, creates the task and dispatches it to
java.util.concurrent.ExecutorService, and returns. All tasks are
subclasses of a specific abstract class which catches errors,
executes the task method (abstract hook method) and updates the task
state to DONE when finished. Any log.error statements (in all and any
apps) are emailed using log4j smtp appender, so we know straight away
of we did have an error that could not be handled by the task code
itself.
Just thoughts: You could add another field to ScheduledTasks to
name the WO app the DA should be sent to allowing to manage a whole
bunch of differten apps.
You could, but such refactoring is not needed for my current
situation right now.
Also, I forgot to mention that each ScheduledTask has a dictionary
blob whose contents are relevent to the class name that will be
executing the task.
When I need a new type of task, I subclass my abstract class, write
the "performTask" method and sometimes create a custom WOComponent to
put a friendly relevant GUI on the task depending on whether the task
is related to a specific account EO, a subcription EO or whatever.
To add new tasks the same DA/wget approach could be used so the
"client" apps don't need to have the ScheduledTasks EOModel or
access to the db respectively.
That's the strategy anyway... it has worked solid for a very long
time.
If you try and go the simple route with a simple java Timer, then
AFAIK you will lose that task if you restart your app before it
gets executed. So, if you want persistence and reliability, I
think you have to consider a way to persist your scheduled tasks
in the database and have "Singleton" style app in your cluster
that triggers the scheduled task events. The to-many tasks events
allows me to ensure that every task is absolutely executed which
is critical since many of the tasks are related to automatic
subscription payments and credit card charges.
Remains the problem that the instance could crash during execution
of the DA leaving the task partly finished, but that's life ;-)
jw
HTH, Kieran
On May 9, 2007, at 5:47 AM, Johann Werner wrote:
I recently looked at the NSTimer documentation where a note came
up stating that it is obsolete and should not be used for new
development. Unfortunately there is no mention of alternatives.
I have a WO app running that should execute a function at certain
dates automagically ;) More precisely: people can register for an
event and put in different information. At a certain date (to
make sense a couple of days ahead of the event) the app should
check if all mandatory information has been entered and sends a
reminder email to that person if not.
By searching the web the only way if found to implement such
behaviour is using a cronjob with wget and a direct action. But
by this the app loses control of when the action gets called as
it is hardcoded. Additionally I would have to add this call
manually in a system config file. I think that's no good as it is
not directly related to the app and therefore adds to the install/
maintenance complexitiy.
What is the common practice to implement such timing needs?
jw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden