[jira] [Commented] (SOLR-4509) Disable HttpClient stale check for performance and fewer spurious connection errors.
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225183#comment-14225183 ] Ryan Zezeski commented on SOLR-4509: Ryan Zezeski, what drove your decision to make the sweeper thread interval 5 seconds (considering what the default should be)? It had to be shorter than the server connection timeout; 5 seconds was less than the 60 second server timeout I had. It seems you are running with this patch nicely. Feel free to modify it however you see fit. As for the latency differences that Shawn mentioned, keep in mind I was running microbenchmarks. It was a tight loop of small queries running at max throughput and everything was a cache hit. IIRC, faster CPUs showed less of a gain. Part of this is explained because it removes at least one syscall for every request. Faster, more modern, CPUs should context switch more efficiently. If I was doing this benchmark over again today I would try other variations (low-rate to avoid any CPU run-queue buildup and focus on latency only) and examine more performance metrics. That aside, this patch should avoid the case where a stale conn is chosen and a new one has to be created as part of the request which will result in latency outliers. A win in my book. Disable HttpClient stale check for performance and fewer spurious connection errors. Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Assignee: Mark Miller Priority: Minor Fix For: 5.0, Trunk Attachments: IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, baremetal-stale-nostale-med-latency.dat, baremetal-stale-nostale-med-latency.svg, baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. ReviewBoard: https://reviews.apache.org/r/28393/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13786290#comment-13786290 ] Ryan Zezeski commented on SOLR-4509: I recently updated Yokozuna (1) to use Solr 4.4.0. After running a query benchmark I noticed that throughput had dropped to 44% of the baseline. After some head scratching I realized that my distributed search patch had not applied successfully. Sure enough, after I updated the patch for 4.4.0 throughput returned to 100%+ of baseline. Below is a table showing results of query benchmark for 4.3.0, 4.4.0 and 4.4.0 without this patch. The throughput drops to less than half of Solr 4.4.0 with the patch and the latency more than doubles. |Measurement |Solr 4.3.0 |Solr 4.4.0 |Solr 4.4.0 w/o Patch | ||-|-|--| |Mean Throughput |1512 ops/s |1525 ops/s |670 ops/s (44%) | |Median Latency |22.0ms |21.6ms |46.2ms (2.1x) | |95th Latency|29.8ms |29.4ms |76.8ms (2.6x) | |99th Latency|35.3ms |34.6ms |86.2ms (2.5x) | These results are against a 4-node cluster all hosted on 1 physical machine. Manual distributed search is used for querying, there is no use of SolrCloud. There are only 1 million small text documents stored. The query matches only 1 of these documents. The query results and filter caches are enabled and should have a high hit ratio. The point is to make the queries inexpensive as possible to see what other overhead might occur. There may very well be scenarios where this patch makes little to no difference. But in this case it seems to make a big one. This update is not to prove that my patch makes a significant difference in all cases. Rather, I accidentally ran this benchmark and was surprised at the difference I saw. I wanted to ping this issue in hopes that others might try the patch to see if it helps. Here is the corresponding ticket on the Yokozuna repo: https://github.com/basho/yokozuna/pull/197 1: Yokozuna is a project with integrates Solr with the Riak database. https://github.com/basho/yokozuna Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: baremetal-stale-nostale-med-latency.dat, baremetal-stale-nostale-med-latency.svg, baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg, IsStaleTime.java, SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Zezeski updated SOLR-4509: --- Attachment: SOLR-4509-4_4_0.patch Version of the patch that applies to 4.4.0. Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: baremetal-stale-nostale-med-latency.dat, baremetal-stale-nostale-med-latency.svg, baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg, IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Zezeski updated SOLR-4509: --- Attachment: baremetal-stale-nostale-throughput.svg baremetal-stale-nostale-throughput.dat baremetal-stale-nostale-med-latency.svg baremetal-stale-nostale-med-latency.dat I have some new results from a different cluster. The short story is that I still see improvement from removing the stale check, just not as dramatic as on my SmartOS cluster. Throughput improved by 108-120% and there was a 0-5ms delta in latency. What I take from this is that the benefits of removing the stale check will vary depending on # of nodes, hardware, query and load. In theory removing the stale check should never hurt as removing blocking syscalls should only help. But I totally understand if about being cautious with a change like this. Personally I'd like to see at least one other person confirm a non-negligible difference before I bother to make this patch more acceptable. Best to let this ticket stir a while I suppose. ## Cluster Specs Add nodes are running on baremetalcloud so this time they are truly different physical machines with no virtualization involved. * 8 nodes/shards * 1 x 2.66GHz Woodcrest E5150 (2 cores) * 2GB DDR2-667 * 73GB SAS 10k RPM * Ubuntu 12.04 * Oracle JDK: Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) * 512MB max heap * Example schema ## Bench Runner * 1 node * 2 x 2.66GHz Woodcrest E5150 * 8GB DDR2-667 * Using Basho Bench as load gen ## Queries All queries hit all shards. All queries were single term queries except for alpha which is conjunction. The numbers listed are the number of documents matching each term query. * alpha: 100K, 100K, 0 * lima: 1 * mike: 10 * november: 100 * oscar: 1K * papa: 10K * quebec: 100K Attached is the aggregate data (.dat) and corresponding plots (.svg) of that data. The data was aggregated from raw data collected by Basho Bench (and this raw data is actually the aggregate of all events at 10s intervals). E.g. the median latency is actually the mean of the median latencies calculated against all events in a given 10s period. What I'm saying is, it's rollup or a rollup so while there are 2 decimals of precision those numbers are not actually that precise. But this should be good for ballpark figures (if you're a stats geek please let me know if I'm committing a sin here). There is a big delta in latency for the mike benchmark but I'm chalking that up to an anomaly for the time being. Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: baremetal-stale-nostale-med-latency.dat, baremetal-stale-nostale-med-latency.svg, baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg, IsStaleTime.java, SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589601#comment-13589601 ] Ryan Zezeski commented on SOLR-4509: Markus, Until now i've not seen real significant latency improvements when performing concurrent stress tests. The response time still hovers between 70ms and 100ms with and without the patch using today's trunk. Fair enough, it could be that my particular setup had something to do with it. I should verify on a 2nd set of hardware. What is this concurrent stress test you are running? Is it something public I could run as well? How many shards is each query hitting and is each shard on its own physical machine? Also, I'm going to attach a BTrace script. If you could run this script it would be really helpful as it would tell us how long the stale check is taking in your environment. I included instructions on running the script in the comments of the source. I'm not sure yet why these occur, maybe it's my Tomcat settings that do not match Jetty's defaults. My patch currently assumes a 50s idle timeout (or larger) on the server. Any smaller and you might see socket reset errors. I'm not sure why you are seeing the errors you mentioned. Your first trace doesn't match up with the 4.1.3 HTTP Client code. Has the client version been updated for the latest? Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: IsStaleTime.java, SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Zezeski updated SOLR-4509: --- Attachment: IsStaleTime.java BTrace script to dynamically time the stale check Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: IsStaleTime.java, SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
Ryan Zezeski created SOLR-4509: -- Summary: Disable Stale Check - Distributed Search (Performance) Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Zezeski updated SOLR-4509: --- Attachment: SOLR-4509.patch Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588561#comment-13588561 ] Ryan Zezeski commented on SOLR-4509: I generated the patch from my clone of the git mirror. If this patch is unacceptable in anyway I'm willing to redo. Just thought I'd take the easy route first. Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588657#comment-13588657 ] Ryan Zezeski commented on SOLR-4509: Would the 100ms latency you have described here show up in QTime values or be purely client-side? So my latency measurements include end-to-end from client-yokozuna-solr coordinator-shards-solr coordinator-yokozuna-client. I didn't track the QTimes, but in benchmarks I ran months ago I saw the same results whether I went through Yokozuna or hit Solr directly with the distributed search. I could probably re-run to report QTime changes. I ask because the median (not average)... I'm also reporting median latency, not mean. In my first link you can also find graphs with 95th, 99th, 99.9 percentiles. ...an assumption of a server timeout of 50 milliseconds The assumption is 50s, but yes, it is an assumption. A better patch would make the idle timeout configurable as well as the period. If these are not actual worries, then I can be quiet. No, these are great points. This patch, as it sits now, is for a specific context. I did what I needed to do to improve my specific situation. Honestly, I would like to see another person run this patch and verify at least some amount of speed-up. Otherwise, it might best stay downstream. Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4509) Disable Stale Check - Distributed Search (Performance)
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588787#comment-13588787 ] Ryan Zezeski commented on SOLR-4509: ...i'll be testing this in the next few days. Great, I would love to see these results reproduced by someone else. I'm not very sure enabling TCP_NODELAY (e.g. disable Nagle's algorithm) will help a lot I agree, it probably doesn't matter but I disabled it anyways given that nagle is really meant for things like telnet and such. I figured it couldn't hurt to disable. Disable Stale Check - Distributed Search (Performance) -- Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Priority: Minor Attachments: SOLR-4509.patch By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3629) core `config` attribute not persisted properly
Ryan Zezeski created SOLR-3629: -- Summary: core `config` attribute not persisted properly Key: SOLR-3629 URL: https://issues.apache.org/jira/browse/SOLR-3629 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 5.0 Reporter: Ryan Zezeski Priority: Minor If a custom config filename is set CoreContainer persists it as `conf` but attempts to read it as `config`. This results in an exception saying that solrconfig.xml cannot be found--as it has reverted to searching for the default. The work-around is to not set a custom config filename. I noticed this both in trunk and branch_4x on the GitHub mirror. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3629) core `config` attribute not persisted properly
[ https://issues.apache.org/jira/browse/SOLR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Zezeski updated SOLR-3629: --- Attachment: SOLR-3629.patch I generated this patch by modifying the git-format-patch output. I realize this is not the precise way to contribute a patch but it was the path of least resistance. core `config` attribute not persisted properly -- Key: SOLR-3629 URL: https://issues.apache.org/jira/browse/SOLR-3629 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 5.0 Reporter: Ryan Zezeski Priority: Minor Attachments: SOLR-3629.patch If a custom config filename is set CoreContainer persists it as `conf` but attempts to read it as `config`. This results in an exception saying that solrconfig.xml cannot be found--as it has reverted to searching for the default. The work-around is to not set a custom config filename. I noticed this both in trunk and branch_4x on the GitHub mirror. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
