FeedDaemon not a service?

[Glenn Golden <gg...@umich.edu>]

As I was deciphering how the .ocs files are processed, and found the
org.apache.jetspeed.daemon.impl.FeedDaemon, and found it was a
jetspeed.Daemon, I was surprised to find that a Daemon is just a Runnable.

Why are these not turbine services? It would seem that anything that is
running as a singleton or running a thread, and possibly providing an api to
the rest of the system (services and portlets) would want to be a service.

Is this just historical (i.e. sure, it would be nice to have these services)
or am I missing something here?

Thanks!

- Glenn

--------------------------------------------
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu           734-615-1419
http://www-personal.si.umich.edu/~ggolden/
--------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: FeedDaemon not a service?

[Santiago Gala <sg...@hisitech.com>]

Frans Thamura wrote:

>Santiago,
>
>can you help me? where is the start point to learn that FeedDaemon??
>
>Because it is activated when a jetspeed is called in web.xml
>
As part of the initialization of turbine, the services/daemonfactory 
service gets initialized. This service starts some daemon threads that 
run in the background:

- FeedDaemon, that loads .ocs files, parses them and transforms them 
using a xslt stylesheet into portlet registries, which are then added to 
the portlet registry. This daemon is used to retrieve remote (or local) 
channels dynamically.  You should look for OCS format for details on how 
to write a "feed" of channels.

- DiskCacheDaemon, that scans the URL cache every so and so to ensure 
that expired remote urls are refreshed.
- BadURLManagerDaemon, that tries to get URLs that the previous deamon 
stopped trying

The purpose of the DiskCache is to try to avoid Jetspeed asking for URLs 
in parallel when you have concurrent requests. Imagine a site with 20 
concurrent users refreshing a page once a minute where the Slashdot 
channel is included. Without the DiskCache, Jetspeed would ask for the 
page every few seconds. In addition, the page refresh would be very 
slow, because Jetspeed would have to wait for the request to go to 
Slashdot (and to plenty of other sites). DiskCacheDaemon is the one that 
looks for pages offline. When a page fails due to the server being off 
or network problems, it is put into a "bad" list. BadURLManager scans 
this list and tries to reload the pages from time to time.

For details on the Turbine service framework, go to the turbine 
documentation.

The daemon code is old. Part of the daemon was re-written to use turbine 
(daemonfactory), but there are still parts using the older code.

>
>
>
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>To: "Jetspeed Developers List" <je...@jakarta.apache.org>
>Sent: Wednesday, January 30, 2002 9:22 PM
>Subject: Re: FeedDaemon not a service?
>
>
>>Glenn Golden wrote:
>>
>>>As I was deciphering how the .ocs files are processed, and found the
>>>org.apache.jetspeed.daemon.impl.FeedDaemon, and found it was a
>>>jetspeed.Daemon, I was surprised to find that a Daemon is just a
>>>
>Runnable.
>
>>>Why are these not turbine services? It would seem that anything that is
>>>running as a singleton or running a thread, and possibly providing an api
>>>
>to
>
>>>the rest of the system (services and portlets) would want to be a
>>>
>service.
>
>>>Is this just historical (i.e. sure, it would be nice to have these
>>>
>services)
>
>>>or am I missing something here?
>>>
>>Historical. Nobody found the time to port it to the new architecture. It
>>really needs a cleanup.
>>
>>The same is true about the diskcache and the badurlmanager. The
>>urlmanager calls them, but they should be integrated in a URLManager
>>service together.
>>
>>Even if I did not wrote them originally, I have come to be the one that
>>best knows this code. Plainly I could not find time to clean it (yet).
>>It is also fragile code, which makes more painful to try to modify it.
>>
>>Are you volunteering? ;)
>>
>>>Thanks!
>>>
>>>- Glenn
>>>
>>>--------------------------------------------
>>>Glenn R. Golden, Systems Research Programmer
>>>University of Michigan School of Information
>>>ggolden@umich.edu           734-615-1419
>>>http://www-personal.si.umich.edu/~ggolden/
>>>--------------------------------------------
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>
><ma...@jakarta.apache.org>
>
>>>For additional commands, e-mail:
>>>
><ma...@jakarta.apache.org>
>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: FeedDaemon not a service?

[Frans Thamura <ft...@yahoo.com>]

Santiago,

can you help me? where is the start point to learn that FeedDaemon??

Because it is activated when a jetspeed is called in web.xml


----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Wednesday, January 30, 2002 9:22 PM
Subject: Re: FeedDaemon not a service?


> Glenn Golden wrote:
>
> >As I was deciphering how the .ocs files are processed, and found the
> >org.apache.jetspeed.daemon.impl.FeedDaemon, and found it was a
> >jetspeed.Daemon, I was surprised to find that a Daemon is just a
Runnable.
> >
> >Why are these not turbine services? It would seem that anything that is
> >running as a singleton or running a thread, and possibly providing an api
to
> >the rest of the system (services and portlets) would want to be a
service.
> >
> >Is this just historical (i.e. sure, it would be nice to have these
services)
> >or am I missing something here?
> >
> Historical. Nobody found the time to port it to the new architecture. It
> really needs a cleanup.
>
> The same is true about the diskcache and the badurlmanager. The
> urlmanager calls them, but they should be integrated in a URLManager
> service together.
>
> Even if I did not wrote them originally, I have come to be the one that
> best knows this code. Plainly I could not find time to clean it (yet).
> It is also fragile code, which makes more painful to try to modify it.
>
> Are you volunteering? ;)
>
> >
> >Thanks!
> >
> >- Glenn
> >
> >--------------------------------------------
> >Glenn R. Golden, Systems Research Programmer
> >University of Michigan School of Information
> >ggolden@umich.edu           734-615-1419
> >http://www-personal.si.umich.edu/~ggolden/
> >--------------------------------------------
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: FeedDaemon not a service?

[Santiago Gala <sg...@hisitech.com>]

Glenn Golden wrote:

>As I was deciphering how the .ocs files are processed, and found the
>org.apache.jetspeed.daemon.impl.FeedDaemon, and found it was a
>jetspeed.Daemon, I was surprised to find that a Daemon is just a Runnable.
>
>Why are these not turbine services? It would seem that anything that is
>running as a singleton or running a thread, and possibly providing an api to
>the rest of the system (services and portlets) would want to be a service.
>
>Is this just historical (i.e. sure, it would be nice to have these services)
>or am I missing something here?
>
Historical. Nobody found the time to port it to the new architecture. It 
really needs a cleanup.

The same is true about the diskcache and the badurlmanager. The 
urlmanager calls them, but they should be integrated in a URLManager 
service together.

Even if I did not wrote them originally, I have come to be the one that 
best knows this code. Plainly I could not find time to clean it (yet). 
It is also fragile code, which makes more painful to try to modify it.

Are you volunteering? ;)

>
>Thanks!
>
>- Glenn
>
>--------------------------------------------
>Glenn R. Golden, Systems Research Programmer
>University of Michigan School of Information
>ggolden@umich.edu           734-615-1419
>http://www-personal.si.umich.edu/~ggolden/
>--------------------------------------------
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>