Some more thoughts on caching ...
Santiago Gala wrote:
> [EMAIL PROTECTED] wrote:
> >
> > ...
> >
> > This is a good approach. Maybe we can classify the elements by
> > their lifetime, location (remote resource vs. local file system)
> > and their associated entities (user, user-session, portal, portlet,
> > etc.) Are there more parameters ? I'd expect that depending on
> > the usage scenario of the portal, different caching policies will
> > be appropriate for the different element classes. We should create
> > up with a list of different usage scenarios against which we can
> > validate our ideas.
>
> Location is not meaningful for me. It should be transparent. I would
> change it by cacheable vs non-cacheable. I would specify most (but
> maybe not all) local objects as non-cacheable. Conversely, a user
> PSML can be stored in a remote server, but still be non-cacheable.
Sorry, I was unprecise here. With remote I actally meant on a server
somewhere in the Internet as opposed to a server in a LAN. I agree
that location should be transparent from an API point of view.
It is not transparent if we look at access latencies, though. It may
be necessary to configure different cache policies for cachable
elements depening on whether they are resources somewhere on the web
or resources in a local machine, for example.
>
> There is also the writable attribute. For instance, JetspeedContent
> files are writable, and also user PSML files once the Customizer works.
>
> Another distinction, done by Avalon, is CharacterStream versus Object.
> For instance, the remote channels are currently recovered as streams,
> while the user PSML would be better hadled as an object, i.e. parsed
> before caching. They really speak about ByteStreams, but we would need
> the distinction to avoid i18n problems later on, as the character
> encoding of a URLConnection gets lost once the cache encapsulates it
> as a InputStream.
>
> I would not use the entities, but have a distinction between Objects
> and CharacterStreams or ByteStreams, and have Objects used implement
> some interface, that would have unmarshall( Stream/Reader ) and
> marshall (if they are writable) as methods. So, the service could
> cache an object given the class and a url. Also, if the object is
> writable, the copy could be modified and saved back to the given url.
I tried writing up some characteristics of user/group PSMLs and
XML content/content feeds.
User/Group PSMLs
- Type: Object (XML unmarshalled into object tree)
- Lifetime: Minimum lifetime: processing of one request
(performance problem)
Optimal lifetime: starts together with user session that
requires it
ends when no more user session exists
that requires it.
Maximum lifetime: from first use until system restart
(memory problem)
- Location: Local (located at the server on which JetSpeed runs or
on a server connected via a fast network).
- Cachable, but needs to be discarded from cache upon customization
- Unmarshalling/Marshalling is expensive
-> Caching Policy Options: As object tree in User Session
(maximum concurrency)
As object tree in MRU Memory Cache
(needs some sync)
? others ?
XML Content and Content Feeds
- Type: Byte Stream (e.g. XML files processed through XSL)
- Lifetime: Minimum lifetime: processing of one request
(latency problem)
Optimal lifetime: while often used
Maximum lifetime: publishing until expiry
(potential memory problem)
- Location: Remote (located at a remote server only accessible via
the Internet, i.e. a slow network)
- Cachable
-> Caching Policy Options: As file in MRU Cache
(decentral, per JetSpeed instance)
As file in Proxy
(decentral, per JetSpeed instance)
As file in Proxy
(central, shared by JetSpeed instances)
? others ?
Possible JetSpeed Scenarios:
JetSpeed running on a cluster of servers (Enterprise/ISP Portals)
- PSML object trees stored on individual JetSpeed servers with session
affinity
- Content and Content feeds stored in proxy cache as files
+----------------+ +----------------+
| Content Server | | Content Server |
+-------+--------+ +-------+--------+
| |
+--------------+--------------+
|
Internet
|
+-------+-------+
| Central |-Content
|Proxy Cache(s) |
+-------+-------+
|
+---------------------+----------------------+
| | |
+--------+--------+ +---------+-------+ +--------+--------+
|JetSpeed Instance| |JetSpeed Instance| ... |JetSpeed Instance|
+-----------------+ +-----------------+ +-----------------+
| | |
+---------------------+----------------------+
|
+-----------------+
| Central |-User Info
| User Database |-User PSMLs
|(e.g. DB or LDAP)|
+-----------------+
JetSpeed running on a single machine (e.g. portal prototypes)
- PSML object trees stored on individual JetSpeed servers
- Content and Content feeds stored in file cache as files
+----------------+ +----------------+
| Content Server | | Content Server |
+-------+--------+ +-------+--------+
| |
+--------------+--------------+
|
Internet
|
+--------+--------+
| File Cache |
+-----------------+
|JetSpeed Instance|
+-----------------+
| User Database |
|(e.g. DB or LDAP)|
+-----------------+
Which other scenarios might exist ?
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--------------------------------------------------------------
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]
