It's also intermittent -- I had to refresh 30 times before it would happen. So far it won't happen on back to back refreshes. The shortest gap between having it exhibit the odd behavior was 6 refreshes. I spent about 10 minutes just hitting the refresh button, and I only had it happen a handful of times.
I'll see about getting a new version in place soon. If it still happens, I'll definitely log something in JIRA for it. Thanks! -- Chris On Thu, Aug 7, 2014 at 4:07 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 8/7/2014 1:46 PM, Christopher Gross wrote: > > Solr 4.1, in SolrCloud mode. 3 nodes configured, Running in Tomcat 7 w/ > > Java 7. > > > > I have a few cores set up, let's just call them A, B, C and D. They > have > > some uniquely named xslt files, but they all have a "rss.xsl" file. > > > > Sometimes, on just 1 of the nodes, if I do a query for something in A and > > translate it with the rss.xsl, it will do the query just fine and give > the > > right number of results (solr logged the query and had it going to the > > correct core), but it uses B or C's rss.xsl. Since the schemas are > > different, the xml is mostly empty. A refresh will have it go back to > > using the correct rss.xsl. > > > > Has anyone run into a problem like this? Is it a problem with the 4.1 > > Solr? Will upgrading fix it? > > > > Is it a better practice to uniquely name the xslt files for each core > > (having a-rss.xsl, b-rss.xsl, etc)? > > I wonder if Solr might have a bug with XSLT caching, where the cache is > global and simply looks at the base filename, not the full path. If it > works when you use xsl files with different names, then that is the most > likely problem. > > If you determine that the bug I mentioned is what's happening, before > filing a bug in Jira, we need to determine whether it's still a problem > in the latest version. Version 4.1 came out in January 2013. Upgrading > is definitely advised, if you can do it. > > Thanks, > Shawn > >
