lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <>
Subject Re: Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?
Date Wed, 05 Jun 2019 20:40:57 GMT
Experiences that force the user to think about the browser cache are
sub-par :). Anything that changes the URL will interrupt caching so just
adding a query parameter &_v=8.1.1 (or whatever) to every request would
probably do the trick, there's no need to mess with file names or file
locations IF the UI can easily do such a thing. One could write javascript
to find all the src/href etc on the page and append... as for whether
that's easy in our actual UI, I don't know. haven't tried to work with it

On Wed, Jun 5, 2019 at 4:22 PM Jan Høydahl <> wrote:

> Could perhaps the UI have a version hard coded, and when the dashboard
> fetches /admin/info/system it compares the version, and if newer than what
> is in the JS, it will pop up a dialogue to ask user to reload and clear
> caches for the site in browser?
> Jan Høydahl
> > 5. jun. 2019 kl. 20:47 skrev Shawn Heisey <>:
> >
> >> On 6/5/2019 11:10 AM, Colvin Cowie wrote:
> >> Upon opening the Admin UI I got some nasty behaviour, which appears to
> be a
> >> result of some the Solr 6 Admin UI pages being cached.
> >
> > In general I would consider this a bug, and a good reason to raise an
> issue in Jira.
> >
> > The admin UI should tell the browser not to EVER cache items that could
> change.
> >
> > We could probably go with "don't cache anything" ... but some of the
> files the admin UI uses are quite large, so I don't think it's a bad idea
> to let the browser go ahead and cache things that are not likely to change,
> especially if they have a version number in the filename.  Maybe for large
> things that don't have version numbers, which includes files like
> "angular.js", we could tell the browser to only cache it for a short time,
> say 5 to 15 minutes.
> >
> > An alternate idea for discussion ... we could modify the URLs so that
> everything that can be cached has a version number.  Maybe by putting it in
> a subdirectory that contains the release version, like "v8.1.1" or
> "v8.1.2-SNAPSHOT".  It would make the build process a little more
> complicated, but I think it would also make sure that problems like this
> never happen again.
> >
> > Thanks,
> > Shawn

-- (work) (play)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message