Hi Rick, Hi Solr Experts, Thank you for this reply!
My solr database is supposed to be(come) open source. Hence, I am willing to share any information. Since I am new to solr, I just did not know what to share. But in the mean time, I put some of the information online. My current configuration can be found at https://github.com/multimedia-berkeley/mmc_search_solr/blob/master/mmc_search3/conf/solrconfig.xml <https://github.com/multimedia-berkeley/mmc_search_solr/blob/master/mmc_search3/conf/solrconfig.xml> and I also put it at the end of this mail. At this repository link, also the other configuration of my search engine can be found. Apart from updating the luceneMatchVersion from time to time, I didn’t do any major changes. I once tried to switch to the current solrconfig template but could not get it running but can’t remember anymore why. I also tested a similar configuration with lucene and solr version 6.5 where I knew that originally umlauts as in T%C3%BCbingen or Chinese symbols worked but even there I got the previously described weird behavior. At https://multimediacommons.wordpress.com/getting-started/#solr <https://multimediacommons.wordpress.com/getting-started/#solr>, I describe how I set up my search engine and theoretically it should be possible to download it. However, it is quite big. The search engine is used as backend for a webpage, that I am working on (http://search.mmcommons.org/ <http://search.mmcommons.org/>). If required, I could open the firewall port of the public solr server for a short time, but this would have to happen under personal communication. Best, Mario <?xml version="1.0" encoding="utf-8" ?> <!-- Copyright 2011, 2013, 2014 Hendrik Schnepel Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <config> <luceneMatchVersion>7.0.1</luceneMatchVersion> <requestHandler name="/select" class="solr.SearchHandler" default="true" /> <requestHandler name="/update" class="solr.UpdateRequestHandler" /> <requestHandler name="/admin/ping" class="solr.PingRequestHandler"> <lst name="invariants"> <str name="qt">search</str> <str name="q">*:*</str> </lst> </requestHandler> <!-- *** WARNING *** The settings below authorize Solr to fetch remote files, You should make sure your system has some authentication before using enableRemoteStreaming="true" --> <requestDispatcher handleSelect="false" > <requestParsers enableRemoteStreaming="true" /> </requestDispatcher> <updateHandler class="solr.DirectUpdateHandler2"> <!-- Enables a transaction log, used for real-time get, durability, and and solr cloud replica recovery. The log can grow as big as uncommitted changes to the index, so use of a hard autoCommit is recommended (see below). "dir" - the target directory for transaction logs, defaults to the solr data directory. --> <updateLog> <str name="dir">${solr.ulog.dir:}</str> </updateLog> <!-- AutoCommit Perform a hard commit automatically under certain conditions. Instead of enabling autoCommit, consider using "commitWithin" when adding documents. http://wiki.apache.org/solr/UpdateXmlMessages maxDocs - Maximum number of documents to add since the last commit before automatically triggering a new commit. maxTime - Maximum amount of time in ms that is allowed to pass since a document was added before automatically triggering a new commit. openSearcher - if false, the commit causes recent index changes to be flushed to stable storage, but does not cause a new searcher to be opened to make those changes visible. If the updateLog is enabled, then it's highly recommended to have some sort of hard autoCommit to limit the log size. --> <autoCommit> <maxTime>6000000</maxTime> <openSearcher>false</openSearcher> </autoCommit> <!-- softAutoCommit is like autoCommit except it causes a 'soft' commit which only ensures that changes are visible but does not ensure that data is synced to disk. This is faster and more near-realtime friendly than a hard commit. --> <!-- <autoSoftCommit>--> <!-- <maxTime>900000</maxTime>--> <!-- </autoSoftCommit>--> <!-- Update Related Event Listeners Various IndexWriter related events can trigger Listeners to take actions. postCommit - fired after every commit or optimize command postOptimize - fired after every optimize command --> <!-- The RunExecutableListener executes an external command from a hook such as postCommit or postOptimize. exe - the name of the executable to run dir - dir to use as the current working directory. (default=".") wait - the calling thread waits until the executable returns. (default="true") args - the arguments to pass to the program. (default is none) env - environment variables to set. (default is none) --> <!-- This example shows how RunExecutableListener could be used with the script based replication... http://wiki.apache.org/solr/CollectionDistribution --> <!-- <listener event="postCommit" class="solr.RunExecutableListener"> <str name="exe">solr/bin/snapshooter</str> <str name="dir">.</str> <bool name="wait">true</bool> <arr name="args"> <str>arg1</str> <str>arg2</str> </arr> <arr name="env"> <str>MYVAR=val1</str> </arr> </listener> --> </updateHandler> </config> > On Nov 6, 2017, at 04:35, Rick Leir <rl...@leirtech.com> wrote: > > Dr. Krell > You could look at your /select query handler, and compare it with the /query > query handler in the Admin config. > > Did you upgrade from a previous version of Solr? Or change your config ( no, > you must have thought of that). If it is a bug related to the Java upgrade > then you need to show your config before folks can help. > Cheers -- Rick > > > On November 4, 2017 5:11:36 PM EDT, "Dr. Mario Michael Krell" > <kr...@uni-bremen.de> wrote: >> Hi, >> >> We recently discovered issues with solr with converting utf8 code in >> the search. One or two month ago everything was still working. >> >> - What might have caused it is a Java update (Java 8 Update 151). >> - We are using firefox as well as chrome for displaying results. >> - We tested it with Solr 6.5, Solr 7.0.0, 7.0.1, and 7.1. >> >> We created a search engine base on the yfcc100m and in the normal >> browser (http://localhost:8983/solr/#/mmc_search3/query >> <http://localhost:8983/solr/#/mmc_search3/query>), we can search for >> "title:T%C3%BCbingen” in the query field and get more than 3 million >> results: >> >> { >> "responseHeader":{ >> "status":0, >> "QTime":103}, >> "response":{"numFound":3092484,"start":0,"docs":[ >> { >> "photoid":"6182384834", >> >> However, when we use the respective web-address, >> http://localhost:8983/solr/mmc_search3/select?q=title:T%C3%BCbingen&wt=json >> <http://localhost:8983/solr/mmc_search3/select?q=title:T%C3%BCbingen&wt=json> >> The results are deduced to zero: >> { >> "responseHeader":{ >> "status":0, >> "QTime":0}, >> "response":{"numFound":0,"start":0,"docs":[] >> }} >> >> responseHeader >> status 0 >> QTime 0 >> response >> numFound 0 >> start 0 >> docs [] >> >> I would be happy for any suggestions on how to fix this problem. For me >> it seems like a bug in solr caused by Java. >> >> Best, >> >> Mario > > -- > Sorry for being brief. Alternate email is rickleir at yahoo dot com
