"Brekke, Jeff" wrote:
> >
> > +1 for using scheduled jobs.
> >
> > I think it would be best to leverage the URLManager service
> > in the process.
> > If we define an extended URLInfo record, by adding the fields:
> >
> > updateFrequency: the number of seconds between updates for this URL
> > lastUpdate: timestamp of the last update
> > urlType: (FEED|CONTENT|...)
> > source: Vector of URL of the feed(s) in which this URL is described
> >
> > We can write a URLManagerScheduledJob (executed at frequency
> > set in JR.p) to
> > schedule a DiskCacheUpdateJob on any entry whithout a pending
> > DiskCacheUpdateJob in the schedule list to refresh the
> > content of this URL
> > at lastUpdate+updateFrequency and update the status and
> > lastUpdate records
> > in the corresponding URLInfo.
> >
> > If the URL updated is modified and the urlType is FEED, execute a
> > FeedUpdateJob which would unregister/register all the entries in the
> > URLManager whose source contains the feed URL.
> >
> > This has many advantages over the current system but will require the
> > URLManager URL records to be stored in a DB for rapidity of access.
>
> I'm confused, and it may me my lack of understanding the URLManager. Would
> there be a scheduled job ( record in db ) for every url in the URLManager? (
> potential for thousands? ) or would there be one job to go through the list
> or urls in the manager, check to see if it needs to be updated, etc. ?
>
That's implementation optimization.
The one job/URL is an "AT queue" model whereas the "one job for updating the
whole URLManager" is a cron model.
I don't know what kind of model the Scheduler is supposed to handle best.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
