Basically:
init()
preload(Rundata,timeoutInMs) --> threaded
supportsPreload
getContent(Rundata)
Where X (where X being whatever is loading the portlets I'm still trying to figure that out) would launch each's "preload" in a sepeate method.
From there some "Object" could be cached and loaded by one's JSP/Velocity/Whatever.
The preload is given a "gentle suggestion" timeout (for passing to queries, loading pages, etc), and jetspeed will generally time it out within some configurable time period. If the number of timed out requests exceeds some configurable instance variable the portlet looses its preload privileges for some configurable time period (or maybe just for good)..
After all of the portlets have preloaded or times out the getContent is called.
The advantage of this approach is that JSP/Velocity/Etc portlets that go to the database can concurrently and theoretically portal load time can be substantially reduced.
For instance if there are 10 portlets that take 2 seconds from the database -- 20 seconds. vs 2-5 seconds...
Thoughts?
Luta, Raphael (VUN) wrote:
De : Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
>Hi,
>
>I'm working on making portlets load parallelly... But I'm having
>trouble tracing the lifecycle of a portlet. Perhaps someone knows it
>offhand. what is the general flow?
>
Yep, if you can wait until wednesday, I think I should completed the doc
at this time :)
>My approach.. . add a method to Portlet called "preload"
>which is called
>in seperate threads before getContent (which is called single
>threaded).. . But I need to know the hierachy of control...
>What gets
>called which calls what which calls Portlet.init and eventually
>portlet.getcontent. I'm debugging through but its jumping
>all around so
>its kinda hard to follow... especially at the drunkathon..I mean
>Apachecon hackathon...
>
You'll one major issue to solve: stream caching.
If you need to generate content in parallel streams you need to make
sure that content is not sent to the client out of order -> hence
caching of all the generated content before producing the global page.
The default settings of the portal are to allow portlet to stream
content directly to the client. This can be done easily by changing the
Turbine Layout to VelocityOnlyLayout *but* there's a catch:
if you use JSP templates for your portlet, the spec of the RequestDispatcher
requires that you pass to the JSP the exact same request and response
objects
you recieved from the servlet container.
This requirement makes it quite difficult to cache the JSP generated content
without assumptions on the container.
In short, if you use only Velocity then it should be pretty trivial, if you
need to support JSP as well... I'd sure like to know how manage to cache
their
content :)
--
To unsubscribe, e-mail:
For additional commands, e-mail:
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
