[jira] [Commented] (SOLR-5543) solr.xml duplicat eentries after SWAP 4.6
[ https://issues.apache.org/jira/browse/SOLR-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848457#comment-13848457 ] ASF subversion and git services commented on SOLR-5543: --- Commit 1550970 from [~romseygeek] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1550970 ] SOLR-5543: Core Swaps result in duplicate entries in solr.xml > solr.xml duplicat eentries after SWAP 4.6 > - > > Key: SOLR-5543 > URL: https://issues.apache.org/jira/browse/SOLR-5543 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: Bill Bell >Assignee: Alan Woodward > Fix For: 4.7 > > Attachments: SOLR-5543.patch > > > We are having issues with SWAP CoreAdmin in 4.6. > Using legacy solr.xml we issue a COreodmin SWAP, and we want it persistent. > It has been running flawless since 4.5. Now it creates duplicate lines in > solr.xml. > Even the example multi core schema in doesn't work with persistent="true" - > it creates duplicate lines in solr.xml. > > transient="false"/> > instanceDir="citystateprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="inactiveproviders" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="portalprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="providersearch" transient="false"/> > instanceDir="tridioncomponents" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5543) solr.xml duplicat eentries after SWAP 4.6
[ https://issues.apache.org/jira/browse/SOLR-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-5543. - Resolution: Fixed Fix Version/s: 4.7 Thanks Bill! > solr.xml duplicat eentries after SWAP 4.6 > - > > Key: SOLR-5543 > URL: https://issues.apache.org/jira/browse/SOLR-5543 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: Bill Bell >Assignee: Alan Woodward > Fix For: 4.7 > > Attachments: SOLR-5543.patch > > > We are having issues with SWAP CoreAdmin in 4.6. > Using legacy solr.xml we issue a COreodmin SWAP, and we want it persistent. > It has been running flawless since 4.5. Now it creates duplicate lines in > solr.xml. > Even the example multi core schema in doesn't work with persistent="true" - > it creates duplicate lines in solr.xml. > > transient="false"/> > instanceDir="citystateprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="inactiveproviders" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="portalprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="providersearch" transient="false"/> > instanceDir="tridioncomponents" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5543) solr.xml duplicat eentries after SWAP 4.6
[ https://issues.apache.org/jira/browse/SOLR-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848456#comment-13848456 ] ASF subversion and git services commented on SOLR-5543: --- Commit 1550969 from [~romseygeek] in branch 'dev/trunk' [ https://svn.apache.org/r1550969 ] SOLR-5543: Core Swaps result in duplicate entries in solr.xml > solr.xml duplicat eentries after SWAP 4.6 > - > > Key: SOLR-5543 > URL: https://issues.apache.org/jira/browse/SOLR-5543 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: Bill Bell >Assignee: Alan Woodward > Fix For: 4.7 > > Attachments: SOLR-5543.patch > > > We are having issues with SWAP CoreAdmin in 4.6. > Using legacy solr.xml we issue a COreodmin SWAP, and we want it persistent. > It has been running flawless since 4.5. Now it creates duplicate lines in > solr.xml. > Even the example multi core schema in doesn't work with persistent="true" - > it creates duplicate lines in solr.xml. > > transient="false"/> > instanceDir="citystateprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="inactiveproviders" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="portalprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="providersearch" transient="false"/> > instanceDir="tridioncomponents" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5543) solr.xml duplicat eentries after SWAP 4.6
[ https://issues.apache.org/jira/browse/SOLR-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-5543: Attachment: SOLR-5543.patch This patch adds an explicit #swap(CoreContainer, CoreDescriptor, CoreDescriptor) method to CoreLocator. CoreContainer.swap() was just using persist, which ended up adding two new entries to the end of the cores list but never clearing them out. This wasn't being picked up in tests because the SolrXMLCoreLocator deduplicated them in discovery (by a happy accident). > solr.xml duplicat eentries after SWAP 4.6 > - > > Key: SOLR-5543 > URL: https://issues.apache.org/jira/browse/SOLR-5543 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: Bill Bell >Assignee: Alan Woodward > Attachments: SOLR-5543.patch > > > We are having issues with SWAP CoreAdmin in 4.6. > Using legacy solr.xml we issue a COreodmin SWAP, and we want it persistent. > It has been running flawless since 4.5. Now it creates duplicate lines in > solr.xml. > Even the example multi core schema in doesn't work with persistent="true" - > it creates duplicate lines in solr.xml. > > transient="false"/> > instanceDir="citystateprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="inactiveproviders" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="portalprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="providersearch" transient="false"/> > instanceDir="tridioncomponents" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5473) Make one state.json per collection
[ https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848439#comment-13848439 ] Mark Miller commented on SOLR-5473: --- Perhaps time for a branch yet? Especially if Potter is doing stuff that interacts with this too, seems like it would make it easier for everyone to review / collaborate on these changes. > Make one state.json per collection > -- > > Key: SOLR-5473 > URL: https://issues.apache.org/jira/browse/SOLR-5473 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul > Attachments: SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, > SOLR-5473.patch, SOLR-5473.patch > > > As defined in the parent issue, store the states of each collection under > /collections/collectionname/state.json node -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5543) solr.xml duplicat eentries after SWAP 4.6
[ https://issues.apache.org/jira/browse/SOLR-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward reassigned SOLR-5543: --- Assignee: Alan Woodward > solr.xml duplicat eentries after SWAP 4.6 > - > > Key: SOLR-5543 > URL: https://issues.apache.org/jira/browse/SOLR-5543 > Project: Solr > Issue Type: Bug >Affects Versions: 4.6 >Reporter: Bill Bell >Assignee: Alan Woodward > > We are having issues with SWAP CoreAdmin in 4.6. > Using legacy solr.xml we issue a COreodmin SWAP, and we want it persistent. > It has been running flawless since 4.5. Now it creates duplicate lines in > solr.xml. > Even the example multi core schema in doesn't work with persistent="true" - > it creates duplicate lines in solr.xml. > > transient="false"/> > instanceDir="citystateprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="inactiveproviders" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="portalprovider" transient="false"/> > transient="false"/> > transient="false"/> > instanceDir="providersearch" transient="false"/> > instanceDir="tridioncomponents" transient="false"/> > transient="false"/> > loadOnStartup="true" transient="false"/> > -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5555) CloudSolrServer need not declare to throw MalformedURLException
[
https://issues.apache.org/jira/browse/SOLR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-:
--
Fix Version/s: 4.7
5.0
> CloudSolrServer need not declare to throw MalformedURLException
> ---
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 4.6
>Reporter: Sushil Bajracharya
>Assignee: Alan Woodward
> Fix For: 5.0, 4.7
>
> Attachments: SOLR-.patch, SOLR-.patch
>
>
> Currently CloudSolrServer declares to throw MalformedURLException for some of
> its constructors. This does not seem necessary.
>
> Details based on looking through Solr 4.6 release code:
>
> CloudSolrServer has the following constructor that declares a checked
> exception MalformedURLException..
> {code}
>
> public CloudSolrServer(String zkHost) throws MalformedURLException {
>
> this.zkHost = zkHost;
>
> this.myClient = HttpClientUtil.createClient(null);
>
> this.lbServer = new LBHttpSolrServer(myClient);
>
> this.lbServer.setRequestWriter(new BinaryRequestWriter());
>
> this.lbServer.setParser(new BinaryResponseParser());
>
> this.updatesToLeaders = true;
>
> shutdownLBHttpSolrServer = true;
>
> }
>
> {code}
>
> The only thing that seemed capable of throwing MalformedURLException seems to
> be LBHttpSolrServer’s constructor:
>
> {code}
> public LBHttpSolrServer(HttpClient httpClient, String... solrServerUrl)
> throws MalformedURLException {
> this(httpClient, new BinaryResponseParser(), solrServerUrl);
> }
> {code}
>
> which calls ..
>
> {code}
> public LBHttpSolrServer(HttpClient httpClient, ResponseParser parser,
> String... solrServerUrl)
> throws MalformedURLException {
> clientIsInternal = (httpClient == null);
> this.parser = parser;
> if (httpClient == null) {
> ModifiableSolrParams params = new ModifiableSolrParams();
> params.set(HttpClientUtil.PROP_USE_RETRY, false);
> this.httpClient = HttpClientUtil.createClient(params);
> } else {
> this.httpClient = httpClient;
> }
> for (String s : solrServerUrl) {
> ServerWrapper wrapper = new ServerWrapper(makeServer(s));
> aliveServers.put(wrapper.getKey(), wrapper);
> }
> updateAliveList();
> }
> {code}
>
> which calls ..
>
> {code}
> protected HttpSolrServer makeServer(String server) throws
> MalformedURLException {
> HttpSolrServer s = new HttpSolrServer(server, httpClient, parser);
> if (requestWriter != null) {
> s.setRequestWriter(requestWriter);
> }
> if (queryParams != null) {
> s.setQueryParams(queryParams);
> }
> return s;
> }
> {code}
>
> Note that makeServer(String server) above does not need to throw
> MalformedURLException.. sine the only thing that seems capable of throwing
> MalformedURLException is HttpSolrServer’s constructor (which does not):
>
> {code}
> public HttpSolrServer(String baseURL, HttpClient client, ResponseParser
> parser) {
> this.baseUrl = baseURL;
> if (baseUrl.endsWith("/")) {
> baseUrl = baseUrl.substring(0, baseUrl.length() - 1);
> }
> if (baseUrl.indexOf('?') >= 0) {
> throw new RuntimeException(
> "Invalid base url for solrj. The base URL must not contain
> parameters: "
> + baseUrl);
> }
>
> if (client != null) {
> httpClient = client;
> internalClient = false;
> } else {
> internalClient = true;
> ModifiableSolrParams params = new ModifiableSolrParams();
> params.set(HttpClientUtil.PROP_MAX_CONNECTIONS, 128);
> params.set(HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST, 32);
> params.set(HttpClientUtil.PROP_FOLLOW_REDIRECTS, followRedirects);
> httpClient = HttpClientUtil.createClient(params);
> }
>
> this.parser = parser;
> }
> {code}
>
> I see nothing above that’d throw MalformedURLException. It is throwing a
> RuntimeException when the baseUrl does not match certain pattern, may be that
> was intended to be a MalformedURLException.
>
> It seems like an error or oversight that CloudSolrServer declares to throw
> MalformedURLException for some of its constructors.
> This could be fixed by making LBHttpSolrServer not declare the
> MalformedURLException, and thus other callers to it do not need to do so.
>
>
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5554) Ordering Issue when Collapsing using min max
[
https://issues.apache.org/jira/browse/SOLR-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848344#comment-13848344
]
Deepak Mishra edited comment on SOLR-5554 at 12/14/13 1:14 PM:
---
Attaching required schema details, minimum query (even without score) I took to
get the error and the error log I got in fine mode.
was (Author: deepakmishra117):
Attaching required schema details, minimum query I took to get the error and
the error log I got in fine mode.
> Ordering Issue when Collapsing using min max
>
>
> Key: SOLR-5554
> URL: https://issues.apache.org/jira/browse/SOLR-5554
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.6
> Environment: Solr 4.6
>Reporter: Deepak Mishra
> Fix For: 4.6, 5.0
>
> Attachments: DetailedErrorOnQuery6.txt, Error On Query4, Query1.txt,
> Query2.txt, Query3.txt, Query4.txt, Query5.txt, Query6.txt, SchemaDetails.txt
>
>
> We faced the ordering issue without passing any sorting parameter and same
> filters in both queries.
> Query1
> fq=
> {!collapse field=company_id}
> Query2
> fq=
> {!collapse field=comany_id min=price}
> Query3
> For debugging Query2, we added score field in
> fl=score,offering_id,company_id...
> That actually solved the document order issue
> Query4
> But when we passed selective exclude in facet field of Query3, it give
> document in correct order but with NullPointerException in error and no facet
> (not the one in SOLR-5416).
> facet.field=
> {!ex="samsung"}
> brand
> fq=
> {!tag="samsung"}
> (brand:"samsung")
> The error is
> NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$FloatValueCollapse.collapse(CollapsingQParserPlugin.java:852)
> Query5
> Removing score from fl in Query 4 removes the error
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1118 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1118/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 9867 lines...] [junit4] JVM J0: stderr was not empty, see: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20131214_123159_503.syserr [junit4] >>> JVM J0: stderr (verbatim) [junit4] java(215,0x149b97000) malloc: *** error for object 0x149b85e14: pointer being freed was not allocated [junit4] *** set a breakpoint in malloc_error_break to debug [junit4] <<< JVM J0: EOF [...truncated 1 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=2F70BA8F285A21FB -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.disableHdfs=true -classpath /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/classes/test:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/test-framework/lib/junit4-ant-2.0.13.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test-files:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/classes/java:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/common/lucene-analyzers-common-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/codecs/lucene-codecs-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/highlighter/lucene-highlighter-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/memory/lucene-memory-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/misc/lucene-misc-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/spatial/lucene-spatial-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/expressions/lucene-expressions-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/suggest/lucene-suggest-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/grouping/lucene-grouping-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/queries/lucene-queries-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/queryparser/lucene-queryparser-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/join/lucene-join-5.0-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/antlr-runtime-3.5.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/asm-4.1.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/asm-commons-4.1.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-cli-1.2.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-codec-1.7.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-configuration-1.6.jar:/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/lib/commons-
[jira] [Updated] (SOLR-5554) Ordering Issue when Collapsing using min max
[
https://issues.apache.org/jira/browse/SOLR-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deepak Mishra updated SOLR-5554:
Attachment: DetailedErrorOnQuery6.txt
> Ordering Issue when Collapsing using min max
>
>
> Key: SOLR-5554
> URL: https://issues.apache.org/jira/browse/SOLR-5554
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.6
> Environment: Solr 4.6
>Reporter: Deepak Mishra
> Fix For: 4.6, 5.0
>
> Attachments: DetailedErrorOnQuery6.txt, Error On Query4, Query1.txt,
> Query2.txt, Query3.txt, Query4.txt, Query5.txt, Query6.txt, SchemaDetails.txt
>
>
> We faced the ordering issue without passing any sorting parameter and same
> filters in both queries.
> Query1
> fq=
> {!collapse field=company_id}
> Query2
> fq=
> {!collapse field=comany_id min=price}
> Query3
> For debugging Query2, we added score field in
> fl=score,offering_id,company_id...
> That actually solved the document order issue
> Query4
> But when we passed selective exclude in facet field of Query3, it give
> document in correct order but with NullPointerException in error and no facet
> (not the one in SOLR-5416).
> facet.field=
> {!ex="samsung"}
> brand
> fq=
> {!tag="samsung"}
> (brand:"samsung")
> The error is
> NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$FloatValueCollapse.collapse(CollapsingQParserPlugin.java:852)
> Query5
> Removing score from fl in Query 4 removes the error
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5554) Ordering Issue when Collapsing using min max
[
https://issues.apache.org/jira/browse/SOLR-5554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deepak Mishra updated SOLR-5554:
Attachment: SchemaDetails.txt
Query6.txt
Attaching required schema details, minimum query I took to get the error and
the error log I got in fine mode.
> Ordering Issue when Collapsing using min max
>
>
> Key: SOLR-5554
> URL: https://issues.apache.org/jira/browse/SOLR-5554
> Project: Solr
> Issue Type: Sub-task
> Components: search
>Affects Versions: 4.6
> Environment: Solr 4.6
>Reporter: Deepak Mishra
> Fix For: 4.6, 5.0
>
> Attachments: DetailedErrorOnQuery6.txt, Error On Query4, Query1.txt,
> Query2.txt, Query3.txt, Query4.txt, Query5.txt, Query6.txt, SchemaDetails.txt
>
>
> We faced the ordering issue without passing any sorting parameter and same
> filters in both queries.
> Query1
> fq=
> {!collapse field=company_id}
> Query2
> fq=
> {!collapse field=comany_id min=price}
> Query3
> For debugging Query2, we added score field in
> fl=score,offering_id,company_id...
> That actually solved the document order issue
> Query4
> But when we passed selective exclude in facet field of Query3, it give
> document in correct order but with NullPointerException in error and no facet
> (not the one in SOLR-5416).
> facet.field=
> {!ex="samsung"}
> brand
> fq=
> {!tag="samsung"}
> (brand:"samsung")
> The error is
> NullPointerException at
> org.apache.solr.search.CollapsingQParserPlugin$FloatValueCollapse.collapse(CollapsingQParserPlugin.java:852)
> Query5
> Removing score from fl in Query 4 removes the error
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Errors
Hello Dears,
When I try to index text files using the below code, I come accross errors
like (Error one4, Error one5, Error one6, Error one3, ). I tried to
save the file in different formats like(UTF-8, Big Indian, UTF) but the
change is only the number of errors varied.
The text is in Ethiopic(Geez), and I have my own analyzer.
The environment is: Windows 7, Netbeans IDE 7.3.1, and I have included the
necessary jar files. Please help me to avoid these errors.
public void addTextDocument(String htmlPath, IndexWriter Writerindex)
throws Exception{
File file=new File(htmlPath);
FileInputStream input=new FileInputStream(file);
InputStreamReader read=new InputStreamReader(input,"utf-8");
BufferedReader reader=new BufferedReader(read);
StringBuffer buffer=new StringBuffer();
String line=null;
while((line=reader.readLine())!=null)
{ buffer.append(line);}
String content=buffer.toString();
String filename= file.getName();
String url=filename;
Document document = new Document();
if((url!=null)&&(!url.equals("")))
{ document.add(Field.Keyword("url",url));}
if((content!=null) &&(!content.equals("")))
{ document.add(Field.Text("content",content));}
try {
System.out.println("=");
Writerindex.addDocument(document);
System.out.println("=");
} catch (IOException e) {
e.printStackTrace();
}
}
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b119) - Build # 8687 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8687/ Java: 64bit/jdk1.8.0-ea-b119 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.schema.ModifyConfFileTest Error Message: ERROR: SolrIndexSearcher opens=1 closes=0 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=1 closes=0 at __randomizedtesting.SeedInfo.seed([147CA29710A8B4F5]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:139) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:700) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:744) FAILED: junit.framework.TestSuite.org.apache.solr.schema.ModifyConfFileTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.schema.ModifyConfFileTest: 1) Thread[id=2578, name=searcherExecutor-1225-thread-1, state=WAITING, group=TGRP-ModifyConfFileTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.schema.ModifyConfFileTest: 1) Thread[id=2578, name=searcherExecutor-1225-thread-1, state=WAITING, group=TGRP-ModifyConfFileTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) at __randomizedtesting.SeedInfo.seed([147CA29710A8B4F5]:0) FAILED: junit.framework.TestSuite.org.apache.solr.schema.ModifyConfFileTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=2578, name=searcherExecutor-1225-thread-1, state=WA
[jira] [Commented] (SOLR-4832) Unable to open new searcher
[ https://issues.apache.org/jira/browse/SOLR-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848310#comment-13848310 ] Anders Thulin commented on SOLR-4832: - I experienced the same issue suddenly on Solr 4.4 stand alone after it had been working fine for a month. Upgraded to solr 4.6 solved the problem but I suspect it might still be there, poping up later. > Unable to open new searcher > --- > > Key: SOLR-4832 > URL: https://issues.apache.org/jira/browse/SOLR-4832 > Project: Solr > Issue Type: Bug >Affects Versions: 4.3 > Environment: Debian Squeeze, Zookeeper 3.4.5 >Reporter: Christian Schramm >Priority: Blocker > > I'm using a freshly installed Solr 4.3.0 on Debian Squeeze. Whenever I access > the webinterface I get: > Unable to load environment info from /agent/admin/system?wt=json. > This interface requires that you activate the admin request handlers in all > SolrCores by adding the following configuration to your solrconfig.xml: > > > where agent is the name of my core. The above line exists in solrconfig.xml. > When I call /agent/admin/system?wt=xml I get: > > > Error opening new searcher > > org.apache.solr.common.SolrException: Error opening new searcher at > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1434) at > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1546) at > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1319) at > org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1254) at > org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:94) > at > org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcLastModified(HttpCacheHeaderUtil.java:145) > at > org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:218) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453) at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:560) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072) > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:365) at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485) > at > org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635) at > org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) > at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) > at java.lang.Thread.run(Thread.java:662) Caused by: > org.apache.lucene.store.AlreadyClosedException: Already closed at > org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:336) > at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:246) at > org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1341) ... 33 more > > 500 > > -- This message was sent by Atlassian JIRA (v6.1.4#6159) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
