Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

Colvin Cowie
Hello,

I have just hit this and wondered if anyone has seen similar before since
the login page was added to the Admin UI?

I'm using Solr 6.6.6 currently, but I'm in the process of moving to 8.1.x.
That means I've been accessing the UI from 6 and had it cached. I switched
off 6 and run the 8.1.x (built off of
https://github.com/apache/lucene-solr/commit/c9bc8273c1e714ff06b2c443838f5aa690690298
)

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 Chrome, I got a Basic Auth prompt in the browser, rather than the login
page. Then when trying to run a query (from
http://localhost:8983/solr/#/gettingstarted/query), the results pane showed
a 401 for the entire results frame. Reloading the page without cache fixed
it. i.e the login page appeared and I then logged in through it, and things
worked correctly.


In Firefox, I got the login page, but it was malformed (see
https://i.ibb.co/SvVws3j/login.jpg). In the dev console the error was

Error: [$injector:unpr] Unknown provider:
AuthenticationServiceProvider <- AuthenticationService <-
LoginControllerhttp://errors.angularjs.org/1.3.8/$injector/unpr?p0=AuthenticationServiceProvider%20%3C-%20AuthenticationService%20%3C-%20LoginController
minErr/<@http://localhost:8983/solr/libs/angular.js:86:12
createInjector/providerCache.$injector<@http://localhost:8983/solr/libs/angular.js:4017:19
getService@http://localhost:8983/solr/libs/angular.js:4164:39
createInjector/instanceCache.$injector<@http://localhost:8983/solr/libs/angular.js:4022:28
getService@http://localhost:8983/solr/libs/angular.js:4164:39
invoke@http://localhost:8983/solr/libs/angular.js:4196:13
instantiate@http://localhost:8983/solr/libs/angular.js:4213:27
$ControllerProvider/this.$get</<@http://localhost:8983/solr/libs/angular.js:8472:18
link@http://localhost:8983/solr/libs/angular-route.min.js:30:268
invokeLinkFn@http://localhost:8983/solr/libs/angular.js:8236:9
nodeLinkFn@http://localhost:8983/solr/libs/angular.js:7745:11
compositeLinkFn@http://localhost:8983/solr/libs/angular.js:7098:13
publicLinkFn@http://localhost:8983/solr/libs/angular.js:6977:30
boundTranscludeFn@http://localhost:8983/solr/libs/angular.js:7116:16
controllersBoundTransclude@http://localhost:8983/solr/libs/angular.js:7772:18
x@http://localhost:8983/solr/libs/angular-route.min.js:29:364
$broadcast@http://localhost:8983/solr/libs/angular.js:14725:15
m/<@http://localhost:8983/solr/libs/angular-route.min.js:34:426
processQueue@http://localhost:8983/solr/libs/angular.js:13193:27
scheduleProcessQueue/<@http://localhost:8983/solr/libs/angular.js:13209:27
$eval@http://localhost:8983/solr/libs/angular.js:14406:16
$digest@http://localhost:8983/solr/libs/angular.js:14222:15
$apply@http://localhost:8983/solr/libs/angular.js:14511:13
done@http://localhost:8983/solr/libs/angular.js:9669:36
completeRequest@http://localhost:8983/solr/libs/angular.js:9859:7
requestLoaded@http://localhost:8983/solr/libs/angular.js:9800:9
 <div ng-view="" id="content" class="ng-scope">
angular.js:11617:18

Again, reloading the page without caching fixed the problem.

So, this isn't a major issue, but it's not a nice experience when you hit it.

Any thoughts? I can raise a JIRA issue just to track it, even if it's
not worth fixing.


Cheers

Colvin
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

Shawn Heisey-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

Jan Høydahl / Cominvent
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 <[hidden email]>:
>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

Gus Heck
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
yet.

On Wed, Jun 5, 2019 at 4:22 PM Jan Høydahl <[hidden email]> 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 <[hidden email]>:
> >
> >> 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
>


--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

Shawn Heisey-2
On 6/5/2019 2:40 PM, Gus Heck wrote:
> 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
> yet.

I agree, we definitely don't want it to become necessary for the user to
complete a complex action like clearing their cache.

A parameter like what you describe is already on some of the requests
... but not all.  Here are two requests that I see from the browser:

http://localhost:8983/solr/css/angular/segments.css?_=8.1.0
http://localhost:8983/solr/libs/angular.js

So if we can figure out how to get that parameter applied to more
requests, it would hopefully solve this.

Thanks,
Shawn
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviour when Solr 6 Admin UI pages are cached and server is Solr 8?

Colvin Cowie
I've raised https://issues.apache.org/jira/browse/SOLR-13522 - feel free to
update the description as you like

Cheers

On Wed, 5 Jun 2019 at 21:48, Shawn Heisey <[hidden email]> wrote:

> On 6/5/2019 2:40 PM, Gus Heck wrote:
> > 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
> > yet.
>
> I agree, we definitely don't want it to become necessary for the user to
> complete a complex action like clearing their cache.
>
> A parameter like what you describe is already on some of the requests
> ... but not all.  Here are two requests that I see from the browser:
>
> http://localhost:8983/solr/css/angular/segments.css?_=8.1.0
> http://localhost:8983/solr/libs/angular.js
>
> So if we can figure out how to get that parameter applied to more
> requests, it would hopefully solve this.
>
> Thanks,
> Shawn
>