El s�b, 30-03-2002 a las 00:44, David Sean Taylor escribi�: > > From the SOAP exception, I guess you are using the Stock > > Quote Portlet - this is connecting to a SOAP service over the > > net - perhaps there are delays on that end. > > >From what I hear that particular web service provider is pretty iffy ;) > > This give me an idea for a new story: > > Timeouts on content generation. > If a portlet doesn't generate its content within n seconds (or ms), then > skip its content generation and move on to the next portlet. The timeout > setting will be configurable in the JR.p. > > > This leads to another story: multi-threaded generation of content. > (Lets save that for next time) > >
Having the engine proactively acting to avoid latency during content generation is good. On the other hand, a reasonable workaround can be designed by the portlet writer. This is what the JetspeedDiskCache tries to do. The reason why the JetspeedDiskCache was written was exactly this one: RSS content was originally fetched for every request and this was rather slow, and also we were sending a lot of requests to the content servers. The contract that currently is implicit in JetspeedDiskCache is as follows: - any URL will be fetched at most once in parallel (other requests will wait for the first one to complete, and then get the cached results). - the minimal timeout in config: cache.default.expiration=(default 900) implies that any external URL which does not specify expiration will be fetched at most once in this period of time - While an entry has not expired, the cached content will be delivered to the rest of Jetspeed, and this is expected to be fast. This means that we can trade off and have less current content delivered but better response time, or the other way round, very current content but higher latency. While I know the caching stuff needs definitely a rewrite, I think such a kind of mechanism is very required for any serious portal engine. We could extend such mechanisms to SOAP based RPC stuff, and avoid hitting the server (and delaying the answer) while the current content is considered valid. I am not familiar with what the different Web Services specification say about temporal validity of the result, but it would be worth to research for it. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
