http://localhost:8983/solr/#/~cores
hi all,
SolrCore Initialization Failures
{{core}}: {{error}}
Please check your logs for more information
{{exception.msg}}
here my log file
2019-10-29 06:03:30.995 INFO (main) [ ] o.e.j.u.log Logging initialized
@1449ms to org.eclipse.jetty.util.log.Slf4jLog
2019-10-29 06:03:31.302 INFO (main) [ ] o.e.j.s.Server
jetty-9.4.10.v20180503; built: 2018-05-03T15:56:21.710Z; git:
daa59876e6f384329b122929e70a80934569428c; jvm 1.8.0_144-b01
2019-10-29 06:03:31.346 INFO (main) [ ] o.e.j.d.p.ScanningAppProvider
Deployment monitor
[file:///C:/Users/uma.maheswar/Downloads/solr740/server/contexts/] at
interval 0
2019-10-29 06:03:32.206 INFO (main) [ ]
o.e.j.w.StandardDescriptorProcessor NO JSP Support for /solr, did not find
org.apache.jasper.servlet.JspServlet
2019-10-29 06:03:32.215 INFO (main) [ ] o.e.j.s.session
DefaultSessionIdManager workerName=node0
2019-10-29 06:03:32.232 INFO (main) [ ] o.e.j.s.session No
SessionScavenger set, using defaults
2019-10-29 06:03:32.233 INFO (main) [ ] o.e.j.s.session node0 Scavenging
every 66ms
2019-10-29 06:03:32.245 INFO (main) [ ] c.e.s.SolrSecurityFilter
SolrSecurityFilter --> Filter successfully initialized.
2019-10-29 06:03:32.247 INFO (main) [ ] c.e.s.ValidateAuthorization
Validate Authorization --> validation Filter file solrsecurity.properties
successfully initialized
2019-10-29 06:03:32.296 INFO (main) [ ]
o.a.s.u.c.SSLCredentialProviderFactory Processing SSL Credential Provider
chain: env;sysprop
2019-10-29 06:03:32.326 INFO (main) [ ] o.a.s.s.SolrDispatchFilter Using
logger factory org.apache.logging.slf4j.Log4jLoggerFactory
2019-10-29 06:03:32.331 INFO (main) [ ] o.a.s.s.SolrDispatchFilter ___
_ Welcome to Apache Solr™ version 7.4.0
2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter / __|
___| |_ _ Starting in standalone mode on port 8983
2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter \__ \/
_ \ | '_| Install dir: C:\Users\uma.maheswar\Downloads\solr740
2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
|___/\___/_|_|Start time: 2019-10-29T06:03:32.332Z
2019-10-29 06:03:32.358 INFO (main) [ ] o.a.s.c.SolrResourceLoader Using
system property solr.solr.home:
C:\Users\uma.maheswar\Downloads\solr740\server\solr
2019-10-29 06:03:32.362 INFO (main) [ ] o.a.s.c.SolrXmlConfig Loading
container configuration from
C:\Users\uma.maheswar\Downloads\solr740\server\solr\solr.xml
2019-10-29 06:03:32.419 INFO (main) [ ] o.a.s.c.SolrXmlConfig MBean
server found: com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27, but no JMX
reporters were configured - adding default JMX reporter.
2019-10-29 06:03:32.861 INFO (main) [ ] o.a.s.c.SolrResourceLoader [null]
Added 1 libs to classloader, from paths:
[/C:/Users/uma.maheswar/Downloads/solr740/server/solr/lib]
2019-10-29 06:03:33.786 INFO (main) [ ]
o.a.s.c.TransientSolrCoreCacheDefault Allocating transient cache for
2147483647 transient cores
2019-10-29 06:03:33.789 INFO (main) [ ] o.a.s.h.a.MetricsHistoryHandler
No .system collection, keeping metrics history in memory.
2019-10-29 06:03:33.867 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
monitoring for 'solr.node' (registry 'solr.node') enabled at server:
com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
2019-10-29 06:03:33.867 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
monitoring for 'solr.jvm' (registry 'solr.jvm') enabled at server:
com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
2019-10-29 06:03:33.874 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
monitoring for 'solr.jetty' (registry 'solr.jetty') enabled at server:
com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
2019-10-29 06:03:33.900 INFO (main) [ ] o.a.s.c.CorePropertiesLocator
Found 1 core definitions underneath
C:\Users\uma.maheswar\Downloads\solr740\server\solr
2019-10-29 06:03:33.901 INFO (main) [ ] o.a.s.c.CorePropertiesLocator
Cores are: [ebmpapst_AEM]
2019-10-29 06:03:33.908 INFO (coreLoadExecutor-9-thread-1) [
x:ebmpapst_AEM] o.a.s.c.SolrResourceLoader [null] Added 1 libs to
classloader, from paths:
[/C:/Users/uma.maheswar/Downloads/solr740/server/solr/ebmpapst_AEM/lib]
2019-10-29 06:03:34.075 INFO (coreLoadExecutor-9-thread-1) [
x:ebmpapst_AEM] o.a.s.c.SolrResourceLoader [ebmpapst_AEM] Added 73 libs to
classloader, from paths:
[/C:/Users/uma.maheswar/Downloads/solr740/contrib/clustering/lib,
/C:/Users/uma.maheswar/Downloads/solr740/contrib/extraction/lib,
/C:/Users/uma.maheswar/Downloads/solr740/contrib/langid/lib,
/C:/Users/uma.maheswar/Downloads/solr740/contrib/velocity/lib,
/C:/Users/uma.maheswar/Downloads/solr740/dist,
/C:/Users/uma.maheswar/Downloads/solr740/server/solr/ebmpapst_AEM/lib]
2019-10-29 06:03:34.162 INFO (coreLoadExecutor-9-thread-1) [
x:ebmpapst_AEM] o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.4.0
2019-10-29 06:03:34.375 INFO (coreLoadExecutor-9-thread-1) [
x:ebmpapst_AEM] o.a.s.s.IndexSchema [ebmpapst_AEM] Schema name=minimal
2019-10-29 06:
Re: Solr Ref Guide Changes - now HTML only
Although I don't use the pdf version I highly recommend watching Cassandra's talk from Activate last year ( https://m.youtube.com/watch?v=DixlnxAk08s). In this talk she addresses the challenges of the Solr ref guide including the 'title search' mentioned below and presents a number of options for the guide's future. It certainly gave me an appreciation for some of the complexities in this part of the Solr project that I'd never fully appreciated before. The guide has come a long way since the confluence days and continues to evolve with every release. Although the title search is not ideal I'm yet to not find anything I'm looking for with a little creative googling. That's my tire cents on the matter. From: Alexandre Rafalovitch Sent: Tuesday, 29 October 2019 9:11 AM To: solr-user Subject: Re: Solr Ref Guide Changes - now HTML only I've done some experiments about indexing RefGuide (from source) into Solr at: https://github.com/arafalov/solr-refguide-indexing . But the problem was creating UI, hosting, etc. There was also a thought (mine) of either shipping RefGuide in Solr with pre-built index as an example or even just shipping an index with links to the live version. Both of these were complicated because PDF was throwing the publication schedule of. And also because we are trying to make Solr distribution smaller, not bigger. A bit of a catch-22 there. But maybe now it could be revisited. Regards, Alex. P.s. A personal offline copy of Solr RefGuide could certainly be built from source. And it will become even easier to do that soon. But yes, perhaps a compressed download of HTML version would be a nice replacement of PDF. On Tue, 29 Oct 2019 at 09:04, Shawn Heisey wrote: > > On 10/28/2019 3:51 PM, Nicolas Paris wrote: > > I am not very happy with the search engine embedded within the html > > documentation I admit. Hope this is not solr under the hood :S > > It's not Solr under the hood. It is done by a javascript library that > runs in the browser. It only searches page titles, not the whole document. > > The fact that a search engine has terrible search in its documentation > is not lost on us. We talked about what it would take to use Solr ... > the infrastructure that would have to be set up and maintaned is > prohibitive. > > We are looking into improving things in this area. It's going a lot > slower than we'd like. > > Thanks, > Shawn
Re: http://localhost:8983/solr/#/~cores
There’s no exception message there. Please do a little work when asking for this kind of help to narrow down what we should be looking at and present it in a manner that helps us help you with the least effort, this is after all a volunteer list. You might want to review: https://cwiki.apache.org/confluence/display/solr/UsingMailingLists Best, Erick > On Oct 29, 2019, at 2:12 AM, UMA MAHESWAR > wrote: > > exception
ShardRequest, ShardRequest.PURPOSE_REFINE_PIVOT_FACETS
Hello, We have code that utilizes SOLR, org.apache.solr.common, etc. I’m wondering, wanting too understand what about facet data equates to various ShardRequest bitwise conditions. What about data might result in ShardRequest.PURPOSE_REFINE_PIVOT_FACETS? ShardRequest.PURPOSE_REFINE_FACETS? I’m trying to simulate data, Index that would trigger, result in this type of ShardRequest Michael
Re: http://localhost:8983/solr/#/~cores
unsubscribe
On Tue, Oct 29, 2019 at 4:34 AM UMA MAHESWAR
wrote:
> hi all,
> SolrCore Initialization Failures
> {{core}}: {{error}}
> Please check your logs for more information
>
>
> {{exception.msg}}
>
> here my log file
> 2019-10-29 06:03:30.995 INFO (main) [ ] o.e.j.u.log Logging initialized
> @1449ms to org.eclipse.jetty.util.log.Slf4jLog
> 2019-10-29 06:03:31.302 INFO (main) [ ] o.e.j.s.Server
> jetty-9.4.10.v20180503; built: 2018-05-03T15:56:21.710Z; git:
> daa59876e6f384329b122929e70a80934569428c; jvm 1.8.0_144-b01
> 2019-10-29 06:03:31.346 INFO (main) [ ] o.e.j.d.p.ScanningAppProvider
> Deployment monitor
> [file:///C:/Users/uma.maheswar/Downloads/solr740/server/contexts/] at
> interval 0
> 2019-10-29 06:03:32.206 INFO (main) [ ]
> o.e.j.w.StandardDescriptorProcessor NO JSP Support for /solr, did not find
> org.apache.jasper.servlet.JspServlet
> 2019-10-29 06:03:32.215 INFO (main) [ ] o.e.j.s.session
> DefaultSessionIdManager workerName=node0
> 2019-10-29 06:03:32.232 INFO (main) [ ] o.e.j.s.session No
> SessionScavenger set, using defaults
> 2019-10-29 06:03:32.233 INFO (main) [ ] o.e.j.s.session node0 Scavenging
> every 66ms
> 2019-10-29 06:03:32.245 INFO (main) [ ] c.e.s.SolrSecurityFilter
> SolrSecurityFilter --> Filter successfully initialized.
> 2019-10-29 06:03:32.247 INFO (main) [ ] c.e.s.ValidateAuthorization
> Validate Authorization --> validation Filter file solrsecurity.properties
> successfully initialized
> 2019-10-29 06:03:32.296 INFO (main) [ ]
> o.a.s.u.c.SSLCredentialProviderFactory Processing SSL Credential Provider
> chain: env;sysprop
> 2019-10-29 06:03:32.326 INFO (main) [ ] o.a.s.s.SolrDispatchFilter Using
> logger factory org.apache.logging.slf4j.Log4jLoggerFactory
> 2019-10-29 06:03:32.331 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> ___
> _ Welcome to Apache Solr™ version 7.4.0
> 2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter / __|
> ___| |_ _ Starting in standalone mode on port 8983
> 2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter \__
> \/
> _ \ | '_| Install dir: C:\Users\uma.maheswar\Downloads\solr740
> 2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
> |___/\___/_|_|Start time: 2019-10-29T06:03:32.332Z
> 2019-10-29 06:03:32.358 INFO (main) [ ] o.a.s.c.SolrResourceLoader Using
> system property solr.solr.home:
> C:\Users\uma.maheswar\Downloads\solr740\server\solr
> 2019-10-29 06:03:32.362 INFO (main) [ ] o.a.s.c.SolrXmlConfig Loading
> container configuration from
> C:\Users\uma.maheswar\Downloads\solr740\server\solr\solr.xml
> 2019-10-29 06:03:32.419 INFO (main) [ ] o.a.s.c.SolrXmlConfig MBean
> server found: com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27, but no JMX
> reporters were configured - adding default JMX reporter.
> 2019-10-29 06:03:32.861 INFO (main) [ ] o.a.s.c.SolrResourceLoader
> [null]
> Added 1 libs to classloader, from paths:
> [/C:/Users/uma.maheswar/Downloads/solr740/server/solr/lib]
> 2019-10-29 06:03:33.786 INFO (main) [ ]
> o.a.s.c.TransientSolrCoreCacheDefault Allocating transient cache for
> 2147483647 transient cores
> 2019-10-29 06:03:33.789 INFO (main) [ ] o.a.s.h.a.MetricsHistoryHandler
> No .system collection, keeping metrics history in memory.
> 2019-10-29 06:03:33.867 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
> monitoring for 'solr.node' (registry 'solr.node') enabled at server:
> com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
> 2019-10-29 06:03:33.867 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
> monitoring for 'solr.jvm' (registry 'solr.jvm') enabled at server:
> com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
> 2019-10-29 06:03:33.874 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
> monitoring for 'solr.jetty' (registry 'solr.jetty') enabled at server:
> com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
> 2019-10-29 06:03:33.900 INFO (main) [ ] o.a.s.c.CorePropertiesLocator
> Found 1 core definitions underneath
> C:\Users\uma.maheswar\Downloads\solr740\server\solr
> 2019-10-29 06:03:33.901 INFO (main) [ ] o.a.s.c.CorePropertiesLocator
> Cores are: [ebmpapst_AEM]
> 2019-10-29 06:03:33.908 INFO (coreLoadExecutor-9-thread-1) [
> x:ebmpapst_AEM] o.a.s.c.SolrResourceLoader [null] Added 1 libs to
> classloader, from paths:
> [/C:/Users/uma.maheswar/Downloads/solr740/server/solr/ebmpapst_AEM/lib]
> 2019-10-29 06:03:34.075 INFO (coreLoadExecutor-9-thread-1) [
> x:ebmpapst_AEM] o.a.s.c.SolrResourceLoader [ebmpapst_AEM] Added 73 libs to
> classloader, from paths:
> [/C:/Users/uma.maheswar/Downloads/solr740/contrib/clustering/lib,
> /C:/Users/uma.maheswar/Downloads/solr740/contrib/extraction/lib,
> /C:/Users/uma.maheswar/Downloads/solr740/contrib/langid/lib,
> /C:/Users/uma.maheswar/Downloads/solr740/contrib/velocity/lib,
> /C:/Users/uma.maheswar/Downloads/solr740/dist,
> /C:/Users/uma.maheswar/Downloads/solr740/server/solr/ebmpapst_AEM/lib]
> 2019-10-29 06:03:34.162 INFO (coreLoadExe
Re: ant precommit fails on .adoc files
I have the same problem: validate-source-patterns: [source-patterns] Unescaped symbol "->" on line #46: solr/solr-ref-guide/src/analytics.adoc [source-patterns] Unescaped symbol "->" on line #55: solr/solr-ref-guide/src/analytics.adoc -- Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: http://localhost:8983/solr/#/~cores
Follow the instructions here:
http://lucene.apache.org/solr/community.html#mailing-lists-irc. You must use
the _exact_ same e-mail as you used to subscribe.
If the initial try doesn't work and following the suggestions at the "problems"
link doesn't work for you, let us know. But note you need to show us the
_entire_ return header to allow anyone to diagnose the problem.
Best,
Erick
> On Oct 29, 2019, at 9:51 AM, Eric Katherman wrote:
>
> unsubscribe
>
> On Tue, Oct 29, 2019 at 4:34 AM UMA MAHESWAR
> wrote:
>
>> hi all,
>> SolrCore Initialization Failures
>> {{core}}: {{error}}
>> Please check your logs for more information
>>
>>
>> {{exception.msg}}
>>
>> here my log file
>> 2019-10-29 06:03:30.995 INFO (main) [ ] o.e.j.u.log Logging initialized
>> @1449ms to org.eclipse.jetty.util.log.Slf4jLog
>> 2019-10-29 06:03:31.302 INFO (main) [ ] o.e.j.s.Server
>> jetty-9.4.10.v20180503; built: 2018-05-03T15:56:21.710Z; git:
>> daa59876e6f384329b122929e70a80934569428c; jvm 1.8.0_144-b01
>> 2019-10-29 06:03:31.346 INFO (main) [ ] o.e.j.d.p.ScanningAppProvider
>> Deployment monitor
>> [file:///C:/Users/uma.maheswar/Downloads/solr740/server/contexts/] at
>> interval 0
>> 2019-10-29 06:03:32.206 INFO (main) [ ]
>> o.e.j.w.StandardDescriptorProcessor NO JSP Support for /solr, did not find
>> org.apache.jasper.servlet.JspServlet
>> 2019-10-29 06:03:32.215 INFO (main) [ ] o.e.j.s.session
>> DefaultSessionIdManager workerName=node0
>> 2019-10-29 06:03:32.232 INFO (main) [ ] o.e.j.s.session No
>> SessionScavenger set, using defaults
>> 2019-10-29 06:03:32.233 INFO (main) [ ] o.e.j.s.session node0 Scavenging
>> every 66ms
>> 2019-10-29 06:03:32.245 INFO (main) [ ] c.e.s.SolrSecurityFilter
>> SolrSecurityFilter --> Filter successfully initialized.
>> 2019-10-29 06:03:32.247 INFO (main) [ ] c.e.s.ValidateAuthorization
>> Validate Authorization --> validation Filter file solrsecurity.properties
>> successfully initialized
>> 2019-10-29 06:03:32.296 INFO (main) [ ]
>> o.a.s.u.c.SSLCredentialProviderFactory Processing SSL Credential Provider
>> chain: env;sysprop
>> 2019-10-29 06:03:32.326 INFO (main) [ ] o.a.s.s.SolrDispatchFilter Using
>> logger factory org.apache.logging.slf4j.Log4jLoggerFactory
>> 2019-10-29 06:03:32.331 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
>> ___
>> _ Welcome to Apache Solr™ version 7.4.0
>> 2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter / __|
>> ___| |_ _ Starting in standalone mode on port 8983
>> 2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter \__
>> \/
>> _ \ | '_| Install dir: C:\Users\uma.maheswar\Downloads\solr740
>> 2019-10-29 06:03:32.332 INFO (main) [ ] o.a.s.s.SolrDispatchFilter
>> |___/\___/_|_|Start time: 2019-10-29T06:03:32.332Z
>> 2019-10-29 06:03:32.358 INFO (main) [ ] o.a.s.c.SolrResourceLoader Using
>> system property solr.solr.home:
>> C:\Users\uma.maheswar\Downloads\solr740\server\solr
>> 2019-10-29 06:03:32.362 INFO (main) [ ] o.a.s.c.SolrXmlConfig Loading
>> container configuration from
>> C:\Users\uma.maheswar\Downloads\solr740\server\solr\solr.xml
>> 2019-10-29 06:03:32.419 INFO (main) [ ] o.a.s.c.SolrXmlConfig MBean
>> server found: com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27, but no JMX
>> reporters were configured - adding default JMX reporter.
>> 2019-10-29 06:03:32.861 INFO (main) [ ] o.a.s.c.SolrResourceLoader
>> [null]
>> Added 1 libs to classloader, from paths:
>> [/C:/Users/uma.maheswar/Downloads/solr740/server/solr/lib]
>> 2019-10-29 06:03:33.786 INFO (main) [ ]
>> o.a.s.c.TransientSolrCoreCacheDefault Allocating transient cache for
>> 2147483647 transient cores
>> 2019-10-29 06:03:33.789 INFO (main) [ ] o.a.s.h.a.MetricsHistoryHandler
>> No .system collection, keeping metrics history in memory.
>> 2019-10-29 06:03:33.867 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
>> monitoring for 'solr.node' (registry 'solr.node') enabled at server:
>> com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
>> 2019-10-29 06:03:33.867 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
>> monitoring for 'solr.jvm' (registry 'solr.jvm') enabled at server:
>> com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
>> 2019-10-29 06:03:33.874 INFO (main) [ ] o.a.s.m.r.SolrJmxReporter JMX
>> monitoring for 'solr.jetty' (registry 'solr.jetty') enabled at server:
>> com.sun.jmx.mbeanserver.JmxMBeanServer@551bdc27
>> 2019-10-29 06:03:33.900 INFO (main) [ ] o.a.s.c.CorePropertiesLocator
>> Found 1 core definitions underneath
>> C:\Users\uma.maheswar\Downloads\solr740\server\solr
>> 2019-10-29 06:03:33.901 INFO (main) [ ] o.a.s.c.CorePropertiesLocator
>> Cores are: [ebmpapst_AEM]
>> 2019-10-29 06:03:33.908 INFO (coreLoadExecutor-9-thread-1) [
>> x:ebmpapst_AEM] o.a.s.c.SolrResourceLoader [null] Added 1 libs to
>> classloader, from paths:
>> [/C:/Users/uma.maheswar/Downloads/solr740/server/solr/ebmpapst_AEM/lib]
>> 2019-10-29 06:03:34.075 INFO (coreLoadExecutor-
Re: ant precommit fails on .adoc files
On 10/8/2019 5:37 PM, Chris Hostetter wrote: This is strange -- I can't reproduce, and I can't see any evidence of a change to explain why this might have been failing 8 days ago but not any more. On the master branch that I just updated, "ant clean precommit" fails. Looks like it had a problem with the options being used on the javadoc command: [javadoc] javadoc: error - invalid flag: --no-module-directories This is Ubuntu 18 with OpenJDK 11.0.4. Switching to branch_8x and OpenJDK 8u222 on the same system, since branch_8x is where the OP was working, precommit passes. Looking again at the original post, I see that it's running on Windows. So I tried it on Windows 10 Pro with Oracle JDK 8u212. It failed just like the OP stated, validating source for the ref guide. I tried once to build a Solr package on Windows. It didn't work, requiring tools that are not normally found on Windows. What I found for this thread seems to indicate that the source validation for the ref guide does not work correctly either. I would be interested in finding out whether or not we expect the build system to work right on Windows. I suspect that it is not supported. Thanks, Shawn
colStatus response not as expected with Solr 8.1.1 in a distributed deployment
Hi,
We're seeing an issue with colStatus in a distributed Solr deployment.
Scenario:
Collection with:
- 1 zk
- 2 solr nodes on different boxes (simulated using Docker containers)
- replication factor 5
When we take down one node, our clusterStatus response is as expected (only
listing the live node as live, and anything on the "down" node shows the state
as down).
Our colStatus response however continues to shows every shard as being "active"
with the replica breakdown on every shard as "total" == "active", and "down"
always being zero.
i.e.
"shards":{
"shard1":{
"state":"active",
"range":"8000-",
"replicas":{
"total":5,
"active":5,
"down":0,
"recovering":0,
"recovery_failed":0},
Even though we expect the "down" count to be either 3 or 2 depending on the
shard (and thus "active" being of count 2 or 3 less than it is).
When testing this situation with both Solr nodes being on the same box, the
colStatus response is as expected in regards to the replica counts.
Thanks!Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: colStatus response not as expected with Solr 8.1.1 in a distributed deployment
Uhm, what is colStatus? You need to show us _exactly_ what Solr commands you’re
running for us to make any intelligent comments.
> On Oct 29, 2019, at 1:12 PM, Elizaveta Golova wrote:
>
> Hi,
>
> We're seeing an issue with colStatus in a distributed Solr deployment.
>
> Scenario:
> Collection with:
> - 1 zk
> - 2 solr nodes on different boxes (simulated using Docker containers)
> - replication factor 5
>
> When we take down one node, our clusterStatus response is as expected (only
> listing the live node as live, and anything on the "down" node shows the
> state as down).
>
> Our colStatus response however continues to shows every shard as being
> "active" with the replica breakdown on every shard as "total" == "active",
> and "down" always being zero.
> i.e.
> "shards":{
> "shard1":{
> "state":"active",
> "range":"8000-",
> "replicas":{
> "total":5,
> "active":5,
> "down":0,
> "recovering":0,
> "recovery_failed":0},
>
> Even though we expect the "down" count to be either 3 or 2 depending on the
> shard (and thus "active" being of count 2 or 3 less than it is).
>
> When testing this situation with both Solr nodes being on the same box, the
> colStatus response is as expected in regards to the replica counts.
>
> Thanks!Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
Re: [EXTERNAL] Re: colStatus response not as expected with Solr 8.1.1 in a distributed deployment
colStatus (and clusterStatus) from the Collections api.
https://lucene.apache.org/solr/guide/8_1/collections-api.html#colstatus
Running something like this in the browser where the live solr node is
accessible on port 8983 (but points at a Docker container which is running the
Solr node):
http://localhost:8983/solr/admin/collections?action=COLSTATUS&collection=coll
-Erick Erickson wrote: -
To: solr-user@lucene.apache.org
From: Erick Erickson
Date: 10/29/2019 05:39PM
Subject: [EXTERNAL] Re: colStatus response not as expected with Solr 8.1.1 in a
distributed deployment
Uhm, what is colStatus? You need to show us _exactly_ what Solr commands you’re
running for us to make any intelligent comments.
> On Oct 29, 2019, at 1:12 PM, Elizaveta Golova wrote:
>
> Hi,
>
> We're seeing an issue with colStatus in a distributed Solr deployment.
>
> Scenario:
> Collection with:
> - 1 zk
> - 2 solr nodes on different boxes (simulated using Docker containers)
> - replication factor 5
>
> When we take down one node, our clusterStatus response is as expected (only
> listing the live node as live, and anything on the "down" node shows the
> state as down).
>
> Our colStatus response however continues to shows every shard as being
> "active" with the replica breakdown on every shard as "total" == "active",
> and "down" always being zero.
> i.e.
> "shards":{
> "shard1":{
> "state":"active",
> "range":"8000-",
> "replicas":{
> "total":5,
> "active":5,
> "down":0,
> "recovering":0,
> "recovery_failed":0},
>
> Even though we expect the "down" count to be either 3 or 2 depending on the
> shard (and thus "active" being of count 2 or 3 less than it is).
>
> When testing this situation with both Solr nodes being on the same box, the
> colStatus response is as expected in regards to the replica counts.
>
> Thanks!Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Solr v4.2.1: fields without associated documents
Hi all - I'm working with an application that uses Solr v4.2.1 and I'm seeing a strange issue with our index: I have many fields (10s of thousands) of fields that don't seem to have any associated document. I was wondering if there was any way of getting them out of our index (or out of our admin/luke endpoint, maybe more specifically). A very helpful person on IRC suggested that the only way to get rid of these might be a clean rebuild of the index, and that's not out of the question for us; I hoped to get a bit more information here. The fields appear in /solr/admin/luke: string I-S-M---OF-l *_ms but querying for them, using something like `fq=fedora_datastream_latest_hesler_200_0006_MIMETYPE_ms:[* TO *]` doesn't return any documents, and when using the admin UI's Schema Browser there isn't any corresponding 'Index' section (only 'Schema'). We don't have these fields statically assigned in our schema. Other than a clean reindexing of our data, is there anything we can do to clean these up? Thanks in advance for your help! Best, Bridger
Re: Solr v4.2.1: fields without associated documents
On 10/29/2019 2:25 PM, Bridger Dyson-Smith wrote: A very helpful person on IRC suggested that the only way to get rid of these might be a clean rebuild of the index, and that's not out of the question for us; I hoped to get a bit more information here. I'm the one who you talked to on IRC. Other than a clean reindexing of our data, is there anything we can do to clean these up? Thanks in advance for your help! You should wait for confirmation, but I am not aware of any other way to fix this. The optimize operation (that I was hopeful would take care of it) is a purely Lucene operation that knows nothing at all about Solr. I learned that the optimize operation preserves all field metadata built into the index, even if the field was only referenced by deleted documents. Discussing the issue with other committers in our slack channel has revealed that it might be extremely difficult or impossible to improve the optimize operation so it purges unused metadata. I can ask on our dev list to see what I can learn. I personally feel that Solr users should always be prepared to completely rebuild indexes from scratch. As painful as that prospect might be, it is the only solution to a number of problems, and is also frequently required by many configuration changes. Thanks, Shawn
Re: Solr v4.2.1: fields without associated documents
On 10/29/2019 4:05 PM, Shawn Heisey wrote: I can ask on our dev list to see what I can learn. I should add something important to this. Even if we can implement an enhancement, it would only be added to an 8.x version at the earliest. It is not possible to take an index from 4.2.1 and use it in Solr 8.x, so you'd have to rebuild your index anyway even if you upgraded to get the new feature. Thanks, Shawn
Re: Solr v4.2.1: fields without associated documents
Hi Shawn - Thanks again for your help on IRC -- I took your suggestions and info, talked it over with my colleagues, and we decided that we'll rebuild our index -- all before I had finished composing my original email to the list. On Tue, Oct 29, 2019 at 6:17 PM Shawn Heisey wrote: > On 10/29/2019 4:05 PM, Shawn Heisey wrote: > > I can > > ask on our dev list to see what I can learn. > > I should add something important to this. Even if we can implement an > enhancement, it would only be added to an 8.x version at the earliest. > It is not possible to take an index from 4.2.1 and use it in Solr 8.x, > so you'd have to rebuild your index anyway even if you upgraded to get > the new feature. > > That makes complete sense. We're hopeful that we'll be able to move to a new version of Solr in the next year, but we don't have any expectations for moving the index over. > Thanks, > Shawn > Thank you! Best, Bridger
