Re: SolR 5.3.1 deletes index files
> I still think you should look at ensuring your merge policy is turned off >in solrconfig.xml (if I understand your scenario, you have 1 instance which >is read-only for searching, and another writing to the same index >location), and did your turn infostream on as Erick suggested? Thank you for the hint. I have tried but it did not solve my problem. And yes I have enabled infostream and loglevel debug. Best regards Andreas Moll Vertraulichkeitshinweis Diese Information und jeder uebermittelte Anhang beinhaltet vertrauliche Informationen und ist nur fuer die Personen oder das Unternehmen bestimmt, an welche sie tatsaechlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfaenger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten sein kann und gegebenenfalls Schadensersatzpflichten ausloesen kann. Sollten Sie diese Nachricht aufgrund eines Uebermittlungsfehlers erhalten haben, bitten wir Sie den Sender unverzueglich hiervon in Kenntnis zu setzen. Sicherheitswarnung: Bitte beachten Sie, dass das Internet kein sicheres Kommunikationsmedium ist. Obwohl wir im Rahmen unseres Qualitaetsmanagements und der gebotenen Sorgfalt Schritte eingeleitet haben, um einen Computervirenbefall weitestgehend zu verhindern, koennen wir wegen der Natur des Internets das Risiko eines Computervirenbefalls dieser E-Mail nicht ausschliessen.
Re: Position increment in WordDelimiterFilter.
Can you please send us tokens you get (and positions) when you analyze *WiFi device* Tokens generated and their respective positions. WiFi1 Wi 1 WiFi1 Fi2 device 3 Best, Modassar On Fri, Jan 15, 2016 at 6:25 PM, Emir Arnautovic < emir.arnauto...@sematext.com> wrote: > Can you please send us tokens you get (and positions) when you analyze > *WiFi device* > > On 15.01.2016 13:15, Modassar Ather wrote: > >> Are you saying that WiFi Wi-Fi and Wi Fi should not match each other? >> I am using WhiteSpaceTokenizer in my analysis chain so wi fi becomes two >> different token. Please refer to my examples given in previous mail about >> the issues faced. >> Wi Fi are two term which will match but what happens if for a content >> having *WiFi device* is searched with *"WiFi device"*. It will not match >> as >> there is a position increment by WordDelimiterFilter for WiFi. >> "WiFi device"~1 will match which is confusing that there is no gap in the >> content why a slop is required. >> >> Why do you use WordDelimiterFilter? Can you give us few examples where it >> is useful? >> It is useful when a word like* lucene-search documentation *is indexed >> with >> >> WordDelimiterFilter and it is broken in two terms like lucene and search >> then it will be helpful to get the documents containing it for queries >> like >> lucene documentation or search documentation. >> >> Best, >> Modassar >> >> On Fri, Jan 15, 2016 at 2:14 PM, Emir Arnautovic < >> emir.arnauto...@sematext.com> wrote: >> >> Modassar, >>> Are you saying that WiFi Wi-Fi and Wi Fi should not match each other? Why >>> do you use WordDelimiterFilter? Can you give us few examples where it is >>> useful? >>> >>> Thanks, >>> Emir >>> >>> >>> On 15.01.2016 05:13, Modassar Ather wrote: >>> >>> Thanks for your responses. It seems to me that you don't want to split on numbers. It is not with number only. Even if you try to analyze WiFi it will create 4 token one of which will be at position 2. So basically the issue is with position increment which causes few of the queries behave unexpectedly. Which release of Solr are you using? I am using Lucene/Solr-5.4.0. Best, Modassar On Thu, Jan 14, 2016 at 9:44 PM, Jack Krupansky < jack.krupan...@gmail.com wrote: Which release of Solr are you using? Last year (or so) there was a Lucene > change that had the effect of keeping all terms for WDF at the same > position. There was also some discussion about whether this was either > a > bug or a bug fix, but I don't recall any resolution. > > -- Jack Krupansky > > On Thu, Jan 14, 2016 at 4:15 AM, Modassar Ather < > modather1...@gmail.com> > wrote: > > Hi, > >> I have following definition for WordDelimiterFilter. >> >> > generateNumberParts="1" catenateWords="1" catenateNumbers="1" >> catenateAll="1" splitOnCaseChange="1" preserveOriginal="1"/> >> >> The analysis of 3d shows following four tokens and their positions. >> >> token position >> 3d 1 >> 3 1 >> 3d 1 >> d 2 >> >> Please help me understand why d is at 2? Should not it also be at >> >> position > > 1. >> Is it a bug and if not is there any attribute which I can use to >> restrict >> the position increment? >> >> Thanks, >> Modassar >> >> >> -- >>> Monitoring * Alerting * Anomaly Detection * Centralized Log Management >>> Solr & Elasticsearch Support * http://sematext.com/ >>> >>> >>> > -- > Monitoring * Alerting * Anomaly Detection * Centralized Log Management > Solr & Elasticsearch Support * http://sematext.com/ > >
Re: Position increment in WordDelimiterFilter.
On 1/18/2016 6:21 AM, Modassar Ather wrote: > Can you please send us tokens you get (and positions) when you analyze > *WiFi device* > > Tokens generated and their respective positions. > > WiFi1 > Wi 1 > WiFi1 > Fi 2 > device 3 It seems very odd to me that the original value would show up twice with the preserveOriginal parameter set, but I am seeing the same behavior on 4.7 and 5.3. Because both copies are at the same position, this will not affect search, but will slightly affect relevance if you are not specifying a sort parameter. Everything else about the analysis looks correct to me, and the positions you see are needed for a phrase query to work correctly. I have seen working configurations where preserveOriginal is set on the index analysis but NOT set on query analysis. This is how my own schema is configured. One of the reasons for this configuration is to reduce the number of terms in the query so it is faster than it would be if preserveOriginal were present and generated additional terms. The preserveOriginal on the index side ensures a match whether mixed case is used or not. Thanks, Shawn
Solr Failing to Initialize Embedded Server on XWiki Startup
Hello, I'm in need of immediate assistance regarding an issue with Solr and an XWiki implementation. My project has been upgraded from using XWiki Enterprise 5.2.1 to 5.2.3 through a manual transition of differing source. The oddity begins when I double-click my start_wiki.bat script to start up my Jetty services to then produce an XWiki instance in a browser. I have successfully gotten the Wiki to take the 5.2.3 manual upgrades and posted to a web browser. The only way this can be accomplished is if I run the script and all source from a remote network store OR oddly enough pull that remote source down to a flash drive and run externally from that drive. The external drive method however, does not work on every laptop. I have only gotten the script to not fail on two other machines running externally from the drive. All other machines(Windows OS version independent and Java JDK version independent) have failed using the external drive method. I will post the console output from the command line below. Note: the failures below have occurred pre and post upgrade of XWiki. Are there any fixes for removing these errors that anybody has verified to work? I have already deleted every instance of a Solr folder and still received the same error. Command Line Output: *** DENOTES PROPRIETARY INFORMATION 2016-01-18 12:19:01.346:INFO:oejd.DeploymentManager:Deployable added: C:\Users\***\Documents\***\***\Installer\XWiki\XWiki Enterprise\jetty\contexts\xwiki.xml 2016-01-18 12:19:05.102:INFO:oejw.StandardDescriptorProcessor:NO JSP Support for /xwiki, did not find org.apache.jasper.servlet.JspServlet 2016-01-18 12:19:06,481 [main] INFO o.x.s.s.i.EmbeddedSolrInstance - Starting embedded Solr server... 2016-01-18 12:19:06,487 [main] INFO o.x.s.s.i.EmbeddedSolrInstance - Using Solr home directory: data\solr 2016-01-18 12:19:06,712 [main] ERROR o.x.s.s.i.SolrInstanceProvider - org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [org.xwiki.search.solr.internal.EmbeddedSolrInstance] identified by [role = [interface org.xwiki.search.solr.internal.api.SolrInstance] hint = [embedded]] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:349) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.search.solr.internal.SolrInstanceProvider.initialize(SolrInstanceProvider.java:71) ~[xwiki-platform-search-solr-api-5.2.3.jar:na] at org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:324) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:379) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:347) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:305) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:379) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceMap(EmbeddableComponentManager.java:185) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.component.embed.EmbeddableComponentManager.getInstanceList(EmbeddableComponentManager.java:169) [xwiki-commons-legacy-component-default-5.2.3.jar:na] at org.xwiki.observation.internal.DefaultObservationManager.initializeListeners(DefaultObservationManager.java:164) [xwiki-commons-observation-local-5.2.3.jar:na] at org.xwiki.observation.internal.DefaultObservationManager.getListenersByEvent(DefaultObservationManager.java:131) [xwiki-commons-observation-local-5.2.3.jar:na] at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:262) [xwiki-commons-observation-local-5.2.3.jar:na] at org.xwiki.observation.internal.DefaultObservationManager.notify(DefaultObservationManager.java:316) [xwiki-commons-observation-local-5.2.3.jar:na] at org.xwiki.container.servlet.XWikiServletContex
Solrcloud getting warning "missed update"
Hello, could anyone explain why i am getting below warning in my solrcloud system. WARN null PeerSync "no frame of reference to tell if we've missed updates" Is there any issue or may create probelm and how to resolve it. Thanks Mugeesh -- View this message in context: http://lucene.472066.n3.nabble.com/Solrcloud-getting-warning-missed-update-tp4251556.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Failing to Initialize Embedded Server on XWiki Startup
Probably better asked on an xwiki support forum. It looks like this is custom code on their part. Best, Erick On Mon, Jan 18, 2016 at 9:26 AM, Spencer Rich wrote: > Hello, > > > > I'm in need of immediate assistance regarding an issue with Solr and an XWiki > implementation. My project has been upgraded from using XWiki Enterprise > 5.2.1 to 5.2.3 through a manual transition of differing source. > > > > The oddity begins when I double-click my start_wiki.bat script to start up my > Jetty services to then produce an XWiki instance in a browser. I have > successfully gotten the Wiki to take the 5.2.3 manual upgrades and posted to > a web browser. The only way this can be accomplished is if I run the script > and all source from a remote network store OR oddly enough pull that remote > source down to a flash drive and run externally from that drive. The external > drive method however, does not work on every laptop. I have only gotten the > script to not fail on two other machines running externally from the drive. > All other machines(Windows OS version independent and Java JDK version > independent) have failed using the external drive method. > > > > I will post the console output from the command line below. Note: the > failures below have occurred pre and post upgrade of XWiki. > > > > Are there any fixes for removing these errors that anybody has verified to > work? > > > > I have already deleted every instance of a Solr folder and still received the > same error. > > > > Command Line Output: > > > > *** DENOTES PROPRIETARY INFORMATION > > > > 2016-01-18 12:19:01.346:INFO:oejd.DeploymentManager:Deployable added: > C:\Users\***\Documents\***\***\Installer\XWiki\XWiki > Enterprise\jetty\contexts\xwiki.xml > > 2016-01-18 12:19:05.102:INFO:oejw.StandardDescriptorProcessor:NO JSP Support > for /xwiki, did not find org.apache.jasper.servlet.JspServlet > > 2016-01-18 12:19:06,481 [main] INFO o.x.s.s.i.EmbeddedSolrInstance - > Starting embedded Solr server... > > 2016-01-18 12:19:06,487 [main] INFO o.x.s.s.i.EmbeddedSolrInstance - Using > Solr home directory: data\solr > > 2016-01-18 12:19:06,712 [main] ERROR o.x.s.s.i.SolrInstanceProvider - > > org.xwiki.component.manager.ComponentLookupException: Failed to lookup > component [org.xwiki.search.solr.internal.EmbeddedSolrInstance] identified by > [role = [interface org.xwiki.search.solr.internal.api.SolrInstance] hint = > [embedded]] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:349) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.search.solr.internal.SolrInstanceProvider.initialize(SolrInstanceProvider.java:71) > ~[xwiki-platform-search-solr-api-5.2.3.jar:na] > > at > org.xwiki.component.embed.InitializableLifecycleHandler.handle(InitializableLifecycleHandler.java:39) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:324) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:379) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:347) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:305) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:379) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getInstanceMap(EmbeddableComponentManager.java:185) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getInstanceList(EmbeddableComponentManager.java:169) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.observation.internal.DefaultObservationManager.initializeListeners(DefaultObservationManager.java:164) > [xwiki-commons-observation-local-5.2.3.jar:na] > > at > org.xwiki.observation.internal.DefaultObservationManager.getListenersByEvent(DefaultObservationManager.java:131) > [xwiki-commons-observation-local-5.2.3.jar:na] > > at > org.xwiki.obs
Re: Solrcloud hosting
Please follow the instructions here: http://lucene.apache.org/solr/resources.html Note the "problems?" link. NOTE: You must use the _exact_ e-mail you originally subscribed with. Best, Erick On Sun, Jan 17, 2016 at 8:13 PM, Saulabiu Baba Akinlolu wrote: > Unsubscribe > > >Shawn Heisey --- Re: Solrcloud hosting --- > From:"Shawn Heisey" To:"" > Date:Sun, Jan 17, 2016 9:39 PMSubject:Re: > Solrcloud hosting > > On 1/17/2016 2:43 PM, Pranaya Behera wrote: > > I have 1 zookeeper server and 3 solr servers. I want to access the > > search end point which solr server's url i should try ? > > And is there anyway to assign one domain for this solrcloud and how ? > > Adding on to Erick's reply: > > If you want zookeeper to be redundant, you must have at least three of > them, and an odd number is recommended. With three servers, one can > fail with no change in operation. Five servers offers an additional > level of redundancy -- you can take a server down for maintenance, and > the cluster can still survive a secondserver going down. > > I was writing this message while Erick was composing his reply. He got > his finished first. It says much the same thing: > > To always access SolrCloud with a single hostname even when there's a > failure, you need a load balancer, and the load balancer should also be > redundant. If your client code is Java, there is an alternate option: > the CloudSolrClient object in SolrJ. This client discovers the cloud > via Zookeeper, and is constantly aware of the clusterstate. > > Thanks, > Shawn
RE: Solr Failing to Initialize Embedded Server on XWiki Startup
That's what my next step was. Had a feeling this was something special we did. Thanks for the insight though! Spencer Rich SOFTWARE ENGINEER INTERN MODUS OPERANDI, INC. O • 321.473.1419 M • 772.607.4569 F • 321.473.1499 sr...@modusoperandi.com www.modusoperandi.com CONFIDENTIALITY NOTICE: The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521. This transmission is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or proprietary material. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient or have received this transmission in error, please contact the sender by reply e-mail and destroy all copies of the original message. -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Monday, January 18, 2016 3:43 PM To: solr-user Subject: Re: Solr Failing to Initialize Embedded Server on XWiki Startup Probably better asked on an xwiki support forum. It looks like this is custom code on their part. Best, Erick On Mon, Jan 18, 2016 at 9:26 AM, Spencer Rich wrote: > Hello, > > > > I'm in need of immediate assistance regarding an issue with Solr and an XWiki > implementation. My project has been upgraded from using XWiki Enterprise > 5.2.1 to 5.2.3 through a manual transition of differing source. > > > > The oddity begins when I double-click my start_wiki.bat script to start up my > Jetty services to then produce an XWiki instance in a browser. I have > successfully gotten the Wiki to take the 5.2.3 manual upgrades and posted to > a web browser. The only way this can be accomplished is if I run the script > and all source from a remote network store OR oddly enough pull that remote > source down to a flash drive and run externally from that drive. The external > drive method however, does not work on every laptop. I have only gotten the > script to not fail on two other machines running externally from the drive. > All other machines(Windows OS version independent and Java JDK version > independent) have failed using the external drive method. > > > > I will post the console output from the command line below. Note: the > failures below have occurred pre and post upgrade of XWiki. > > > > Are there any fixes for removing these errors that anybody has verified to > work? > > > > I have already deleted every instance of a Solr folder and still received the > same error. > > > > Command Line Output: > > > > *** DENOTES PROPRIETARY INFORMATION > > > > 2016-01-18 12:19:01.346:INFO:oejd.DeploymentManager:Deployable added: > C:\Users\***\Documents\***\***\Installer\XWiki\XWiki > Enterprise\jetty\contexts\xwiki.xml > > 2016-01-18 12:19:05.102:INFO:oejw.StandardDescriptorProcessor:NO JSP > Support for /xwiki, did not find org.apache.jasper.servlet.JspServlet > > 2016-01-18 12:19:06,481 [main] INFO o.x.s.s.i.EmbeddedSolrInstance - > Starting embedded Solr server... > > 2016-01-18 12:19:06,487 [main] INFO o.x.s.s.i.EmbeddedSolrInstance - > Using Solr home directory: data\solr > > 2016-01-18 12:19:06,712 [main] ERROR o.x.s.s.i.SolrInstanceProvider - > > org.xwiki.component.manager.ComponentLookupException: Failed to lookup > component [org.xwiki.search.solr.internal.EmbeddedSolrInstance] > identified by [role = [interface > org.xwiki.search.solr.internal.api.SolrInstance] hint = [embedded]] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInsta > nce(EmbeddableComponentManager.java:349) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getInstance(Embed > dableComponentManager.java:161) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.search.solr.internal.SolrInstanceProvider.initialize(SolrIns > tanceProvider.java:71) ~[xwiki-platform-search-solr-api-5.2.3.jar:na] > > at > org.xwiki.component.embed.InitializableLifecycleHandler.handle(Initial > izableLifecycleHandler.java:39) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.createInstance(Em > beddableComponentManager.java:324) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInsta > nce(EmbeddableComponentManager.java:379) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getComponentInsta > nce(EmbeddableComponentManager.java:347) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.EmbeddableComponentManager.getInstance(Embed > dableComponentManager.java:161) > [xwiki-commons-legacy-component-default-5.2.3.jar:na] > > at > org.xwiki.component.embed.Embe
Re: Position increment in WordDelimiterFilter.
Thanks Shawn for your explanation. Everything else about the analysis looks correct to me, and the positions you see are needed for a phrase query to work correctly. Here the "WiFi device" will not be searched as there is a gap in between because Fi is at position 2. The document containing WiFi device will be seen as a phrase with no word in between hence it should match phrase "WiFi device" but it will not whereas "WiFi device"~1 will matched. Best, Modassar On Mon, Jan 18, 2016 at 7:57 PM, Shawn Heisey wrote: > On 1/18/2016 6:21 AM, Modassar Ather wrote: > > Can you please send us tokens you get (and positions) when you analyze > > *WiFi device* > > > > Tokens generated and their respective positions. > > > > WiFi1 > > Wi 1 > > WiFi1 > > Fi 2 > > device 3 > > It seems very odd to me that the original value would show up twice with > the preserveOriginal parameter set, but I am seeing the same behavior on > 4.7 and 5.3. Because both copies are at the same position, this will > not affect search, but will slightly affect relevance if you are not > specifying a sort parameter. Everything else about the analysis looks > correct to me, and the positions you see are needed for a phrase query > to work correctly. > > I have seen working configurations where preserveOriginal is set on the > index analysis but NOT set on query analysis. This is how my own schema > is configured. One of the reasons for this configuration is to reduce > the number of terms in the query so it is faster than it would be if > preserveOriginal were present and generated additional terms. The > preserveOriginal on the index side ensures a match whether mixed case is > used or not. > > Thanks, > Shawn > >
Solr node 'Gone' status
Hi, Solr-admin cloud view page has got another new radio button indicating status of node : 'Gone' status. What does that mean? One of my collection is in that state and it is not serving any request. How to bring that up?
