Raphael Luta wrote:
> Santiago Gala wrote:
> >
> > I have got this response from one of the installations I have:
> >
> > <snip>
> >
> > All the network54 channels give the same answer. I have yet to contact
> > them to apologise and query for further information WRT limits in
> > access. It looks that we are in a IP-based black list.
> >
> > The problem is that Jetspeed has a default setup in which 50 parallel
> > threads will ask for updated channels. The way it works now, it can very
> > easily overflow servers (I have seen it happen with 10.am and
> > network54.com). I strongly suggest that we look for means to avoid that.
> > In the meantime, I make the following PROPOSAL:
> >
> > - Default thread count be lowered to 5, with a maximum of 10, and 2 free
> > threads.
> > - We should play with the refresh rate of the DiskCacheDaemon. Possibly
> > 1 hour is too fast.
> >
> > This is still enough to overflow servers, and should not be slow when
> > used with native threads (No problems with locks in DNS lookups).
> >
> > A longer term proposal would be to implement a maximum number of
> > concurrent requests PER SERVER. A way to achieve that would be to use
> > the W3C libwww protocol implementation, a drop in HTTP package. I wil
> > test it.
> >
> > BTW: Has anybody experienced such a problem? I got it in a machine that
> > is deployed in a fast corporate network. With my modem, I only got reset
> > connections from 10.am, but never overflowed network54.com
> >
> > What do you think about that?
> >
>
> This should be handled by the feed declaration: currently OCS only
> define attributes for specifying content refresh rate (and we can
> use this information to induce a polling rate) but it should also
> add an allowed hit rate, a la ICE specification.
>
The problem is that there is no direct relation between provider and channels.
I.E., the OCS can be refreshed every XXX time, but the channels are not
tagged, at least for some of the formats. Also, the problem with providers
delivering several channels is that they will be updated, currenty, in
directory order, that will very possibly be alphabetical, so the same server
will be hit in parallel. I'll look for a simple way to avoid this problem.
>
> Currently Jetspeed is very bad behaved because it doesn't even
> recognize the OCS information. This should be supported IMHO and is
> a much cleaner solution because it's piloted by the content
> provider. I think all the server thread settings and limitation, which
> may definitely be useful, should be thought of as a server side
> resource optimization rather than inforcement of a policy.
>
OK. So, take this just as a suggestion, especially if you are in a fast
network, or if you are developing and have several copies of Jetspeed running
with default setup.
We are considering to have only one server using the cache, while the rest
read it as a read-only resource. Also, we could consider having the cache
refresh as an external process, sharing only the directory with the jetspeed
machine.
>
> The provider must be able to set the preferred automatically
> from its feed description.
>
> Comments ?
>
I'll look at both approaches. Nothing final by now.
>
> --
> 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]
--
--------------------------------------------------------------
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]
