"Kevin A. Burton" wrote:
>
> Basically this involves some significant core changes:
>
> - RunData will be removed from as many places as possible. This is
> necessary so that Jetspeed can instantiate Portlets in the background so
> that client performance can be maximized. The RunData is attached to a
> specific HTTP request so this won't really work. Things like expiring
> of Portlets should not happen while the user waits. Jetspeed should
> return the expired portlet and do the expiration in the background.
>
+1024
> - Portlets need to be thread safe. I am going be creating these left
> and right within the Engine. In the future we might have a tag
> interface which Jetspeed can use to buffer up multiple Portlets in a
> pool and then have only one thread process these at once... but not
> right now.
>
1.3 but I think this would provide *major* performance improvement.
> - BadURLRequestor: Right now if a URL is requested and the server isn't
> available for some reason (routing, server down), Jetspeed will time out
> every time this is requested. The fixed JetspeedDiskCache will put all
> invalid URLs into a hashtable. If this URL is requested again Jetspeed
> will immediately throw an IOException and serve the content. There will
> be a low priority thread that will download the invalid URLs and try to
> update the cache as the URLs become available.
>
> - Smarter Disk Cache: This is an area which is clearly a problem but I
> am not sure how to fix. Right when Jetspeed is started it fetches XML
> from the FeedDaemon and tries to put as much in the cache as possible.
> This isn't such a *huge* problem because this happens within one or two
> minutes. The problem is that when a client requests something like an
> RSS channel (or anything that wants to pull content form the Disk Cache)
> it might need to fetches a remote URL. The problem is that this may
> time out (DOS). So there are two alternatives:
>
> - Allow Jetspeed to time out because delivering correct content is more
> important.
>
> - Don't allow Jetspeed to time out because delivering *fast* content is
> more important.
> At this point Jetspeed would throw an IOException and then create a
> thread to fetch a URL
> so that the next request doesn't have to throw an IOException because
> the URL will be in
> cache at this point.
>
> If anyone has any comments here it would be appreciated. It could
> perhaps be a property that the user could choose.
>
I think we should chose fast rendering with a default "content unavailable" message
when an IOException occurs. This effect will be mitigated by either the
pre-instanciating of the Portlets or the use of disk-based portlet content cache.
> - Pre-instantiating all Portlets: If you turn on a property, and
> Jetspeed has enough memory, I am going to instantiate all Portlets from
> the PortletRegistry and from the FeedDaemon. This should basically make
> Jetspeed run right from memory and much faster. Smaller installations
> can turn this off. There are only 1700 or so possible Portlets even
> with OCS turned on. Maybe this will change in the future but hopefully
> this will grow while memory becomes cheaper.
>
I think we should separate the PortletRegistry pre-instanciation which we can
turn on by default (I don't think we will have more than a hundred portlets
definition in this registry) and the FeddDaemon which may not be useful for
some jetspeed uses.
--
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://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
