[jira] [Updated] (SOLR-7123) /update/json/docs should have nested document support
[
https://issues.apache.org/jira/browse/SOLR-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-7123:
---
Attachment: SOLR-7123.patch
Added tests for nested documents
Changes interface
> /update/json/docs should have nested document support
> -
>
> Key: SOLR-7123
> URL: https://issues.apache.org/jira/browse/SOLR-7123
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: EaseOfUse
> Attachments: SOLR-7123.patch
>
>
> It is the next logical step after SOLR-6304
> For the example document given below where the /orgs belong to a nested
> document,
> {code}
> {
> "name": "Joe Smith",
> "phone": 876876687
> "orgs" :[ {" name" : "Microsoft",
> "city": "Seattle",
> "zip": 98052},
> {"name": “Apple”,
> "city:”Cupertino”,
> "zip":"95014" }
> ]
> }
> {code}
> The extra mapping parameters would be
> {noformat}
> child.split=o:/org&
> o.f=name&
> o.f=city&
> o.f=zip
> {noformat}
> * o is the short name for that child. It is possible to map multiple children
> with multiple shortnames
> * In this example all the o.* paths are relative. It is possible to five
> absolute path names such as o.f=/org/name
--
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-7123) /update/json/docs should have nested document support
[
https://issues.apache.org/jira/browse/SOLR-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375876#comment-14375876
]
Vitaliy Zhovtyuk commented on SOLR-7123:
If got right the idea of nested document the result of such parse will be list
of rows.
Row values represented as map where nested documents node "org" is item in map,
values of map will be list of maps containing name, city and zip.
So taking into account sample from SOLR-6304 it can look like:
[{ "recipeId":"001", "recipeType":"donut", "id":"1001", "type":"Regular" , "o"
: [{" name" : "Microsoft",
"city": "Seattle",
"zip": 98052},
{"name": “Apple”,
"city:”Cupertino”,
"zip":"95014" }]}]
So accordingly to parent split behaviour we transform nested documents with
child split same way.
> /update/json/docs should have nested document support
> -
>
> Key: SOLR-7123
> URL: https://issues.apache.org/jira/browse/SOLR-7123
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: EaseOfUse
>
> It is the next logical step after SOLR-6304
> For the example document given below where the /orgs belong to a nested
> document,
> {code}
> {
> "name": "Joe Smith",
> "phone": 876876687
> "orgs" :[ {" name" : "Microsoft",
> "city": "Seattle",
> "zip": 98052},
> {"name": “Apple”,
> "city:”Cupertino”,
> "zip":"95014" }
> ]
> }
> {code}
> The extra mapping parameters would be
> {noformat}
> child.split=o:/org&
> o.f=name&
> o.f=city&
> o.f=zip
> {noformat}
> * o is the short name for that child. It is possible to map multiple children
> with multiple shortnames
> * In this example all the o.* paths are relative. It is possible to five
> absolute path names such as o.f=/org/name
--
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] [Updated] (SOLR-7143) MoreLikeThis Query Parser does not handle multiple field names
[
https://issues.apache.org/jira/browse/SOLR-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-7143:
---
Attachment: SOLR-7143.patch
Multiple local parameters will not work in previous patch because Map as result of local params parsing. Replaced it with Map and MultiMapSolrParams in org.apache.solr.search.QParser and in
usages. Also removed parseLocalParams (comma split params support could be
complicated in case boost syntax in qf).
> MoreLikeThis Query Parser does not handle multiple field names
> --
>
> Key: SOLR-7143
> URL: https://issues.apache.org/jira/browse/SOLR-7143
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 5.0
>Reporter: Jens Wille
>Assignee: Anshum Gupta
> Attachments: SOLR-7143.patch, SOLR-7143.patch
>
>
> The newly introduced MoreLikeThis Query Parser (SOLR-6248) does not return
> any results when supplied with multiple fields in the {{qf}} parameter.
> To reproduce within the techproducts example, compare:
> {code}
> curl
> 'http://localhost:8983/solr/techproducts/select?q=%7B!mlt+qf=name%7DMA147LL/A'
> curl
> 'http://localhost:8983/solr/techproducts/select?q=%7B!mlt+qf=features%7DMA147LL/A'
> curl
> 'http://localhost:8983/solr/techproducts/select?q=%7B!mlt+qf=name,features%7DMA147LL/A'
> {code}
> The first two queries return 8 and 5 results, respectively. The third query
> doesn't return any results (not even the matched document).
> In contrast, the MoreLikeThis Handler works as expected (accounting for the
> default {{mintf}} and {{mindf}} values in SimpleMLTQParser):
> {code}
> curl
> 'http://localhost:8983/solr/techproducts/mlt?q=id:MA147LL/A&mlt.fl=name&mlt.mintf=1&mlt.mindf=1'
> curl
> 'http://localhost:8983/solr/techproducts/mlt?q=id:MA147LL/A&mlt.fl=features&mlt.mintf=1&mlt.mindf=1'
> curl
> 'http://localhost:8983/solr/techproducts/mlt?q=id:MA147LL/A&mlt.fl=name,features&mlt.mintf=1&mlt.mindf=1'
> {code}
> After adding the following line to
> {{example/techproducts/solr/techproducts/conf/solrconfig.xml}}:
> {code:language=XML}
>
> {code}
> The first two queries return 7 and 4 results, respectively (excluding the
> matched document). The third query returns 7 results, as one would expect.
--
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] [Updated] (SOLR-7062) CLUSTERSTATUS returns a collection with state=active, even though the collection could not be created due to a missing configSet
[
https://issues.apache.org/jira/browse/SOLR-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-7062:
---
Attachment: SOLR-7062.patch
Added test reproducing issue in this issue and SOLR-7053. The reason is
preRegister call in CoreContainer creating record in ZK. Core create is failed
with exception but state in ZK remains active and inconsistent. There 2 options
to solve this: rollback ZK data if core create was failed, check that configSet
exists before creating core and throw exception. Implemented last one check.
> CLUSTERSTATUS returns a collection with state=active, even though the
> collection could not be created due to a missing configSet
>
>
> Key: SOLR-7062
> URL: https://issues.apache.org/jira/browse/SOLR-7062
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.10.3
>Reporter: Ng Agi
> Labels: solrcloud
> Attachments: SOLR-7062.patch
>
>
> A collection can not be created, if its configSet does not exist.
> Nevertheless, a subsequent CLUSTERSTATUS CollectionAdminRequest returns this
> collection with a state=active.
> See log below.
> {noformat}
> [INFO] Overseer Collection Processor: Get the message
> id:/overseer/collection-queue-work/qn-000110 message:{
> "operation":"createcollection",
> "fromApi":"true",
> "name":"blueprint_media_comments",
> "collection.configName":"elastic",
> "numShards":"1",
> "property.dataDir":"data",
> "property.instanceDir":"cores/blueprint_media_comments"}
> [WARNING] OverseerCollectionProcessor.processMessage : createcollection , {
> "operation":"createcollection",
> "fromApi":"true",
> "name":"blueprint_media_comments",
> "collection.configName":"elastic",
> "numShards":"1",
> "property.dataDir":"data",
> "property.instanceDir":"cores/blueprint_media_comments"}
> [INFO] creating collections conf node /collections/blueprint_media_comments
> [INFO] makePath: /collections/blueprint_media_comments
> [INFO] Got user-level KeeperException when processing
> sessionid:0x14b315b0f4a000e type:create cxid:0x2f2e zxid:0x2f4 txntype:-1
> reqpath:n/a Error Path:/overseer Error:KeeperErrorCode = NodeExists for
> /overseer
> [INFO] LatchChildWatcher fired on path: /overseer/queue state: SyncConnected
> type NodeChildrenChanged
> [INFO] building a new collection: blueprint_media_comments
> [INFO] Create collection blueprint_media_comments with shards [shard1]
> [INFO] A cluster state change: WatchedEvent state:SyncConnected
> type:NodeDataChanged path:/clusterstate.json, has occurred - updating...
> (live nodes size: 1)
> [INFO] Creating SolrCores for new collection blueprint_media_comments,
> shardNames [shard1] , replicationFactor : 1
> [INFO] Creating shard blueprint_media_comments_shard1_replica1 as part of
> slice shard1 of collection blueprint_media_comments on localhost:44080_solr
> [INFO] core create command
> qt=/admin/cores&property.dataDir=data&collection.configName=elastic&name=blueprint_media_comments_shard1_replica1&action=CREATE&numShards=1&collection=blueprint_media_comments&shard=shard1&wt=javabin&version=2&property.instanceDir=cores/blueprint_media_comments
> [INFO] publishing core=blueprint_media_comments_shard1_replica1 state=down
> collection=blueprint_media_comments
> [INFO] LatchChildWatcher fired on path: /overseer/queue state: SyncConnected
> type NodeChildrenChanged
> [INFO] look for our core node name
> [INFO] Update state numShards=1 message={
> "core":"blueprint_media_comments_shard1_replica1",
> "roles":null,
> "base_url":"http://localhost:44080/solr";,
> "node_name":"localhost:44080_solr",
> "numShards":"1",
> "state":"down",
> "shard":"shard1",
> "collection":"blueprint_media_comments",
> "operation":"state"}
> [INFO] A cluster state change: WatchedEvent state:SyncConnected
> type:NodeDataChanged path:/clusterstate.json, has occurred - updating...
> (live nodes size: 1)
> [INFO] waiting to find shard id in clusterstate for
> blueprint_media_comments_shard1_replica1
> [INFO] Check for collection zkNode:blueprint_media_comments
> [INFO] Collection zkNode exists
> [INFO] Load collection config from:/collections/blueprint_media_comments
> [ERROR] Specified config does not exist in ZooKeeper:elastic
> [ERROR] Error creating core [blueprint_media_comments_shard1_replica1]:
> Specified config does not exist in ZooKeeper:elastic
> org.apache.solr.common.cloud.ZooKeeperException: Specified config does not
> exist in ZooKeeper:elastic
> at
> org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:160)
> at
> org.apache.solr.cloud.CloudConfigSetService.createCoreResourceLoader(CloudConfigSetService.java:3
[jira] [Updated] (SOLR-7052) Grouping on int field with docValues in SolrCloud raises exception.
[
https://issues.apache.org/jira/browse/SOLR-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-7052:
---
Attachment: SOLR-7052.patch
I was not able to compile tag lucene_solr_4_8_1 becuase of final modifier on
org.apache.lucene.codecs.memory.DirectDocValuesProducer#data,
org.apache.lucene.codecs.lucene42.Lucene42DocValuesProducer#data,
org.apache.lucene.codecs.lucene45.Lucene45DocValuesProducer#data,
org.apache.lucene.codecs.memory.MemoryDocValuesProducer#data (removed final
modifier and added to patch)
Added case with docValues on single and distributed grouping.
Issue reproduced in distributed mode on solr 4.8.1, but not reproduced solr
trunk. The reason: numeric fields with docValues executed in
org.apache.lucene.search.grouping.term.TermFirstPassGroupingCollector where
binary and number with docValues are checked in
org.apache.lucene.search.FieldCacheImpl#getTermsIndex(org.apache.lucene.index.AtomicReader,
java.lang.String, float).
Added check for numeric fields to skip this collector.
Backported changes from solr trunk LUCENE-5666: remove insanity during
distributed grouping
> Grouping on int field with docValues in SolrCloud raises exception.
> ---
>
> Key: SOLR-7052
> URL: https://issues.apache.org/jira/browse/SOLR-7052
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.8.1
>Reporter: Beliy
> Labels: SolrCloud, docValues, grouping
> Attachments: SOLR-7052.patch
>
>
> We have a grouping field which we defined as an integer; when we run a query
> grouping on that field it works fine in a non-cloud configuration, but when
> we try the same query in a SolrCloud configuration with multiple shards, we
> get the following error:
> Type mismatch: was indexed as NUMERIC
> Schema:
> {code:xml}
> docValues="true"/>
> {code}
> Query:
> {code}
> q=*:*&group=true&group.field=&group.limit=1
> {code}
--
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] [Updated] (SOLR-7143) MoreLikeThis Query Parser does not handle multiple field names
[
https://issues.apache.org/jira/browse/SOLR-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-7143:
---
Attachment: SOLR-7143.patch
Local parameters are not support multiple values syntax like: {!mlt qf=field1
qf=field2}, but qf list is required in MoreLikeThis.
Added support for comma separated fields: {!mlt qf=field1,field2}
Also comparing MLT handler query parser does not have any boost support on
fields. This can be extended in qf parameter syntax.
> MoreLikeThis Query Parser does not handle multiple field names
> --
>
> Key: SOLR-7143
> URL: https://issues.apache.org/jira/browse/SOLR-7143
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 5.0
>Reporter: Jens Wille
> Attachments: SOLR-7143.patch
>
>
> The newly introduced MoreLikeThis Query Parser (SOLR-6248) does not return
> any results when supplied with multiple fields in the {{qf}} parameter.
> To reproduce within the techproducts example, compare:
> {code}
> curl
> 'http://localhost:8983/solr/techproducts/select?q=%7B!mlt+qf=name%7DMA147LL/A'
> curl
> 'http://localhost:8983/solr/techproducts/select?q=%7B!mlt+qf=features%7DMA147LL/A'
> curl
> 'http://localhost:8983/solr/techproducts/select?q=%7B!mlt+qf=name,features%7DMA147LL/A'
> {code}
> The first two queries return 8 and 5 results, respectively. The third query
> doesn't return any results (not even the matched document).
> In contrast, the MoreLikeThis Handler works as expected (accounting for the
> default {{mintf}} and {{mindf}} values in SimpleMLTQParser):
> {code}
> curl
> 'http://localhost:8983/solr/techproducts/mlt?q=id:MA147LL/A&mlt.fl=name&mlt.mintf=1&mlt.mindf=1'
> curl
> 'http://localhost:8983/solr/techproducts/mlt?q=id:MA147LL/A&mlt.fl=features&mlt.mintf=1&mlt.mindf=1'
> curl
> 'http://localhost:8983/solr/techproducts/mlt?q=id:MA147LL/A&mlt.fl=name,features&mlt.mintf=1&mlt.mindf=1'
> {code}
> After adding the following line to
> {{example/techproducts/solr/techproducts/conf/solrconfig.xml}}:
> {code:language=XML}
>
> {code}
> The first two queries return 7 and 4 results, respectively (excluding the
> matched document). The third query returns 7 results, as one would expect.
--
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-6678) Collection/core reload is causing a memory leak
[ https://issues.apache.org/jira/browse/SOLR-6678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14337069#comment-14337069 ] Vitaliy Zhovtyuk commented on SOLR-6678: i did 100K reload on techproducts and other cores and i cannot reproduce issue in heap dump. Heap goes down after force GC. Can you pls provide exact JRE version, options and solr config? > Collection/core reload is causing a memory leak > --- > > Key: SOLR-6678 > URL: https://issues.apache.org/jira/browse/SOLR-6678 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10 >Reporter: Alexey Serba > Attachments: ReloadMemoryLeak.png > > > I have a use case where I need to periodically > [reload|https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api2] > a SolrCloud collection. Recently I did ~1k reload operations and noticed > that the cluster was running slower and slower, so I connected to it with > jconsole and noticed that heap was growing with every reload operation, > forcing GC wasn't helping. > So I took a heap dump and noticed that I have too many SolrCore-s hanging > around. > It's hard for me to grok the root cause of this, but maybe someone more > knowledgable in Solr internals can figure it out by looking into this GC root > path (see attached image)? If I interpret this correctly, it looks like one > SolrCore is referencing another SolrCore through SolrSuggester. Maybe close > hook for SolrSuggester component doesn't release everything that it should be > releasing (like SolrSuggester.dictionary)? -- 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] [Updated] (SOLR-6878) solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand)
[ https://issues.apache.org/jira/browse/SOLR-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6878: --- Attachment: SOLR-6878.patch Added support for expand parameter and tests for both cases. > solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand) > > > Key: SOLR-6878 > URL: https://issues.apache.org/jira/browse/SOLR-6878 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Affects Versions: 4.10.2 >Reporter: Tomasz Sulkowski > Labels: ManagedSynonymFilterFactory, REST, SOLR > Attachments: SOLR-6878.patch > > > Hi, > After switching from SynonymFilterFactory to ManagedSynonymFilterFactory I > have found out that there is no way to set an all-to-all synonyms relation. > Basically (judgind from google search) there is a need for "expand" > functionality switch (known from SynonymFilterFactory) which will treat all > synonyms with its keyword as equal. > For example: if we define a "car":["wagen","ride"] relation it would > translate a query that includes one of the synonyms or keyword to "car or > wagen or ride" independently of which word was used from those three. -- 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] [Updated] (SOLR-6977) Given a date/time, facet only by time
[ https://issues.apache.org/jira/browse/SOLR-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6977: --- Attachment: SOLR-6977.patch Clean for unnecessary changes > Given a date/time, facet only by time > - > > Key: SOLR-6977 > URL: https://issues.apache.org/jira/browse/SOLR-6977 > Project: Solr > Issue Type: Bug > Components: faceting, SearchComponents - other >Reporter: Grant Ingersoll > Attachments: SOLR-6977.patch, SOLR-6977.patch > > > Given a field that is indexed as date/time, it would be great if range > faceting could facet only on date or only on time as an option. For > instance, given a months worth of date, I'd like to be able to see what are > the hotspots during throughout the day. Now, I could index a separate time > field, but that seems redundant, as the data is already there. -- 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] [Updated] (SOLR-6977) Given a date/time, facet only by time
[ https://issues.apache.org/jira/browse/SOLR-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6977: --- Attachment: SOLR-6977.patch Added code to group facet range counts by date parts: date and time separately. > Given a date/time, facet only by time > - > > Key: SOLR-6977 > URL: https://issues.apache.org/jira/browse/SOLR-6977 > Project: Solr > Issue Type: Bug > Components: faceting, SearchComponents - other >Reporter: Grant Ingersoll > Attachments: SOLR-6977.patch > > > Given a field that is indexed as date/time, it would be great if range > faceting could facet only on date or only on time as an option. For > instance, given a months worth of date, I'd like to be able to see what are > the hotspots during throughout the day. Now, I could index a separate time > field, but that seems redundant, as the data is already there. -- 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] [Updated] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-3218: --- Attachment: SOLR-3218.patch 1. updated to latest trunk 2. Changed Currency.toString() to strValue so that toString is not used in range calculation 3. Added test for stats.facet in currency type 4. Added stats support for currency type, stats calculated on default currency of type. Min, max and sum return currency value with currency code, by default value.toString() is used to render those results, delegated toString to strValue Mean, sumOfSquares, stddev just return numeric value in cents without currency code. (not sure that we need those for currency, i would remove them) 5. Added tests for stats on currency field > Range faceting support for CurrencyField > > > Key: SOLR-3218 > URL: https://issues.apache.org/jira/browse/SOLR-3218 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Jan Høydahl > Fix For: 4.9, Trunk > > Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, > SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, > SOLR-3218.patch > > > Spinoff from SOLR-2202. Need to add range faceting capabilities for > CurrencyField -- 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] [Updated] (SOLR-6635) Cursormark should support skipping/goto functionality
[ https://issues.apache.org/jira/browse/SOLR-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6635: --- Attachment: SOLR-6635.patch As i understood skip case its about using skip to calculate next cursor mark, so this is pure cursor functionality. org.apache.solr.CursorPagingTest#testSkip illustrate the idea. This will require changes in TopDocs length calculation taking into account skip value for next cursor mark calculation. Also this code need to be refactored to remove duplicates. Another approach could be serialization for skip parameter and with sort values in Cursor and use skip value in offset for next call. > Cursormark should support skipping/goto functionality > - > > Key: SOLR-6635 > URL: https://issues.apache.org/jira/browse/SOLR-6635 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Reporter: Thomas Blitz > Labels: cursormark, pagination, search, solr > Attachments: SOLR-6635.patch > > > Deep pagination is possible with the cursormark. > We have discovered a need to be able to 'skip' a number of results. > Using the cursormark it should be possible to define a request with a skip > parameter, allowing the cursormark to simple skip a number of articles, kinda > like a goto, and then return results from that point in the resultset. -- 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] [Updated] (SOLR-2072) Search Grouping: expand group sort options
[ https://issues.apache.org/jira/browse/SOLR-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-2072: --- Attachment: SOLR-2072.patch Added test for sort groups and inside group by functions, added test to sort inside group by function in distributed mode > Search Grouping: expand group sort options > -- > > Key: SOLR-2072 > URL: https://issues.apache.org/jira/browse/SOLR-2072 > Project: Solr > Issue Type: Sub-task >Reporter: Yonik Seeley > Attachments: SOLR-2072-01.patch, SOLR-2072.patch > > > Ability to specify functions over group documents when sorting groups. > max(score) or avg(popularity), etc. -- 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] [Updated] (SOLR-5660) Send request level commitWithin as a param rather than setting it per doc
[
https://issues.apache.org/jira/browse/SOLR-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5660:
---
Attachment: SOLR-5660.patch
Added handling commitWithin as parameter - its passed on request level, in case
not present its passed per document.
Added test for request level, but failed to reproduce commitWithin per document
(org.apache.solr.cloud.FullSolrCloudDistribCmdsTest#testIndexingCommitWithinOnAttr).
If 2documents contain different commitWithin value its failed with exception:
{quote}org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
Illegal to have multiple roots (start tag in epilog?).
at [row,col {unknown-source}]: [1,236]
at
__randomizedtesting.SeedInfo.seed([FC019F99FE2DEADF:7DE7118189728AE3]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:569)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
at
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
at
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingCommitWithinOnAttr(FullSolrCloudDistribCmdsTest.java:183)
at
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.doTest(FullSolrCloudDistribCmdsTest.java:143)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618){quote}
Is it bug due to malformed XML?
If one document contains commitWithin passed its does not taken into account
(commitWithin=-1). Seems this value unmarshalled incorrectly in
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec#unmarshal
> Send request level commitWithin as a param rather than setting it per doc
> -
>
> Key: SOLR-5660
> URL: https://issues.apache.org/jira/browse/SOLR-5660
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers, SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-5660.patch
>
>
> In SolrCloud the commitWithin parameter is sent per-document even if it is
> set on the entire request.
> We should send request level commitWithin as a param rather than setting it
> per doc - that would mean less repeated data in the request. We still need to
> properly support per doc like this as well though, because that is the level
> cmd objects support and we are distributing cmd objects.
--
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-6376) Edismax field alias bug
[ https://issues.apache.org/jira/browse/SOLR-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244559#comment-14244559 ] Vitaliy Zhovtyuk commented on SOLR-6376: Unittest use the same in configuration as in standalone version. Two more parameters present in browse request handler configuration needed to reproduce parsing problem: text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4 title^10.0 description^5.0 keywords^5.0 author^2.0 resourcename^1.0 100% > Edismax field alias bug > --- > > Key: SOLR-6376 > URL: https://issues.apache.org/jira/browse/SOLR-6376 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 4.6.1, 4.7, 4.7.2, 4.8, 4.9, 4.10.1 >Reporter: Thomas Egense >Priority: Minor > Labels: difficulty-easy, edismax, impact-low > Attachments: SOLR-6376.patch, SOLR-6376.patch > > > If you create a field alias that maps to a nonexistent field, the query will > be parsed to utter garbage. > The bug can reproduced very easily. Add the following line to the /browse > request handler in the tutorial example solrconfig.xml > name features XXX > (XXX is a nonexistent field) > This simple query will actually work correctly: > name_features:video > and it will be parsed to (features:video | name:video) and return 3 results. > It has simply discarded the nonexistent field and the result set is correct. > However if you change the query to: > name_features:video AND name_features:video > you will now get 0 result and the query is parsed to > +(((features:video | name:video) (id:AND^10.0 | author:and^2.0 | > title:and^10.0 | cat:AND^1.4 | text:and^0.5 | keywords:and^5.0 | manu:and^1.1 > | description:and^5.0 | resourcename:and | name:and^1.2 | features:and) > (features:video | name:video))~3) > Notice the AND operator is now used a term! The parsed query can turn out > even worse and produce query parts such as: > title:2~2 > title:and^2.0^10.0 > Prefered solution: During start up, shut down Solr if there is a nonexistant > field alias. Just as is the case if the cycle-detection detects a cycle: > Acceptable solution: Ignore the nonexistant field totally. > Thomas Egense -- 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] [Updated] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6016:
---
Attachment: SOLR-6016.patch
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
>Assignee: Timothy Potter
> Attachments: SOLR-6016.patch, SOLR-6016.patch, SOLR-6016.patch,
> SOLR-6016.patch, solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberFormatException: For input string: "479.95"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:441)
> at java.lang.Long.parseLong(Long.java:483)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:609)
> at org.apache.solr.schema.TrieField.createFields(TrieField.java:660)
> {code}
> The full solr.log is attached.
> I understand why these errors occur but since we ship example data with Solr
> to demonstrate our core features, I expect that indexing exampl
[jira] [Updated] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6016:
---
Attachment: (was: SOLR-6019.patch)
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
>Assignee: Timothy Potter
> Attachments: SOLR-6016.patch, SOLR-6016.patch, SOLR-6016.patch,
> solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberFormatException: For input string: "479.95"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:441)
> at java.lang.Long.parseLong(Long.java:483)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:609)
> at org.apache.solr.schema.TrieField.createFields(TrieField.java:660)
> {code}
> The full solr.log is attached.
> I understand why these errors occur but since we ship example data with Solr
> to demonstrate our core features, I expect that indexing exampledocs
[jira] [Updated] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6016:
---
Attachment: SOLR-6019.patch
Yes, you're right. Missing file
{{server/solr/configsets/data_driven_schema_configs/conf/solrconfig.xml}} added.
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
>Assignee: Timothy Potter
> Attachments: SOLR-6016.patch, SOLR-6016.patch, SOLR-6016.patch,
> solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberFormatException: For input string: "479.95"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:441)
> at java.lang.Long.parseLong(Long.java:483)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:609)
> at org.apache.solr.schema.TrieField.createFields(TrieField.java:660)
> {code}
> The full solr.log is attached.
> I understand why these errors occur but since
[jira] [Updated] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6016:
---
Attachment: SOLR-6016.patch
Updated to latest trunk. Removed whitespace changes.
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6016.patch, SOLR-6016.patch, SOLR-6016.patch,
> solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberFormatException: For input string: "479.95"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:441)
> at java.lang.Long.parseLong(Long.java:483)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:609)
> at org.apache.solr.schema.TrieField.createFields(TrieField.java:660)
> {code}
> The full solr.log is attached.
> I understand why these errors occur but since we ship example data with Solr
> to demonstrate our core features, I expect that indexing example
[jira] [Updated] (SOLR-6019) Managed schema file does not show up in the "Files" UI
[ https://issues.apache.org/jira/browse/SOLR-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6019: --- Attachment: SOLR-6019.patch File should be available for viewing in admin UI, but should be restricted for edit. Currently, both handlers on view and edit managed schema are restricted. Changes: 1. Removed restriction on managed schema file ShowFileRequestHandler 2. Added restriction in file edit in EditFileRequestHandler 3. Fixed javascript issue to view file without extension: default content type passed. > Managed schema file does not show up in the "Files" UI > -- > > Key: SOLR-6019 > URL: https://issues.apache.org/jira/browse/SOLR-6019 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis, web gui >Affects Versions: 4.7.2, 4.8 >Reporter: Shalin Shekhar Mangar > Attachments: 6019-missing-managed-schema.png, SOLR-6019.patch > > > When running with the schema-less example, I noticed that the managed-schema > file does not show in the "Files" section of the Admin UI. This can be > confusing for a user. To make sure it was not a caching issue on the browser, > I closed and opened the UI again in a new tab. I also restarted Solr and > still the managed-schema is not visible in the Files section. Interestingly, > the schema.xml.bak does show up. A screenshot of the UI is attached. > It is possible that this bug affects other managed resources as well such as > synonyms but I haven't tested that yet. > The schema browser works fine though. -- 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] [Updated] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-3881:
---
Attachment: SOLR-3881.patch
1. LangDetectLanguageIdentifierUpdateProcessor.detectLanguage() still uses
concatFields(), but it shouldn't – that was the whole point about moving it to
TikaLanguageIdentifierUpdateProcessor; instead,
LangDetectLanguageIdentifierUpdateProcessor.detectLanguage() should loop over
inputFields and call detector.append() (similarly to what concatFields() does).
[VZ] LangDetectLanguageIdentifierUpdateProcessor.detectLanguage() changed to
use old flow with limit on field and max total on detector.
Each field value appended to detector.
2. concatFields() and getExpectedSize() should move to
TikaLanguageIdentifierUpdateProcessor.
[VZ] Moved to TikaLanguageIdentifierUpdateProcessor. Tests using concatFields()
moved to TikaLanguageIdentifierUpdateProcessorFactoryTest.
3. LanguageIdentifierUpdateProcessor.getExpectedSize() still takes a
maxAppendSize, which didn't get renamed, but that param could be removed
entirely, since maxFieldValueChars is available as a data member.
[VZ] Argument removed.
4. There are a bunch of whitespace changes in
LanguageIdentifierUpdateProcessorFactoryTestCase.java - it makes reviewing
patches significantly harder when they include changes like this. Your IDE
should have settings that make it stop doing this.
[VZ] Whitespaces removed.
5. There is still some import reordering in
TikaLanguageIdentifierUpdateProcessor.java.
[VZ] Fixed.
One last thing:
The total chars default should be its own setting; I was thinking we could make
it double the per-value default?
[VZ] added default value to maxTotalChars and changed both to 10K like in
com.cybozu.labs.langdetect.Detector.maxLength
Thanks for adding the total chars default, but you didn't make it double the
field value chars default, as I suggested. Not sure if that's better - if the
user specifies multiple fields and the first one is the only one that's used to
determine the language because it's larger than the total char default, is that
an issue? I was thinking that it would be better to visit at least one other
field (hence the idea of total = 2 * per-field), but that wouldn't fully
address the issue. What do you think?
[VZ] i think in most cases it will be only one field, but since both parameters
are optional we should not restrict result if only per field specified more
then 10K.
Updated total default value to 20K.
> frequent OOM in LanguageIdentifierUpdateProcessor
> -
>
> Key: SOLR-3881
> URL: https://issues.apache.org/jira/browse/SOLR-3881
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 4.0
> Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
>Reporter: Rob Tulloh
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-3881.patch, SOLR-3881.patch, SOLR-3881.patch,
> SOLR-3881.patch, SOLR-3881.patch
>
>
> We are seeing frequent failures from Solr causing it to OOM. Here is the
> stack trace we observe when this happens:
> {noformat}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2882)
> at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> at java.lang.StringBuffer.append(StringBuffer.java:224)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarsh
[jira] [Updated] (SOLR-6376) Edismax field alias bug
[ https://issues.apache.org/jira/browse/SOLR-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6376: --- Attachment: SOLR-6376.patch I was able to reproduce the issue with Unit test. Please see patch attached. Parsing behavior look like expected. When non existing field met, runtime exception indicating unknown field thrown, parser escape query and re-parced. In this case, parsed clauses converted to escaped "myalias:Zapp "AND" myalias:Zapp", where AND escaped as literal. > Edismax field alias bug > --- > > Key: SOLR-6376 > URL: https://issues.apache.org/jira/browse/SOLR-6376 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 4.6.1, 4.7, 4.7.2, 4.8, 4.9, 4.10.1 >Reporter: Thomas Egense >Priority: Minor > Labels: difficulty-easy, edismax, impact-low > Attachments: SOLR-6376.patch, SOLR-6376.patch > > > If you create a field alias that maps to a nonexistent field, the query will > be parsed to utter garbage. > The bug can reproduced very easily. Add the following line to the /browse > request handler in the tutorial example solrconfig.xml > name features XXX > (XXX is a nonexistent field) > This simple query will actually work correctly: > name_features:video > and it will be parsed to (features:video | name:video) and return 3 results. > It has simply discarded the nonexistent field and the result set is correct. > However if you change the query to: > name_features:video AND name_features:video > you will now get 0 result and the query is parsed to > +(((features:video | name:video) (id:AND^10.0 | author:and^2.0 | > title:and^10.0 | cat:AND^1.4 | text:and^0.5 | keywords:and^5.0 | manu:and^1.1 > | description:and^5.0 | resourcename:and | name:and^1.2 | features:and) > (features:video | name:video))~3) > Notice the AND operator is now used a term! The parsed query can turn out > even worse and produce query parts such as: > title:2~2 > title:and^2.0^10.0 > Prefered solution: During start up, shut down Solr if there is a nonexistant > field alias. Just as is the case if the cycle-detection detects a cycle: > Acceptable solution: Ignore the nonexistant field totally. > Thomas Egense -- 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] [Updated] (SOLR-5041) Add a test to make sure that a leader always recovers from log on startup
[ https://issues.apache.org/jira/browse/SOLR-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5041: --- Attachment: SOLR-5041.patch Added test to send updates and stop test server, then restart test server and commit. Added single and multiple shards tests. > Add a test to make sure that a leader always recovers from log on startup > - > > Key: SOLR-5041 > URL: https://issues.apache.org/jira/browse/SOLR-5041 > Project: Solr > Issue Type: Test > Components: SolrCloud >Reporter: Shalin Shekhar Mangar > Fix For: 4.9, Trunk > > Attachments: SOLR-5041.patch > > > From my comment on SOLR-4997: > bq. I fixed a bug that I had introduced which skipped log recovery on startup > for all leaders instead of only sub shard leaders. I caught this only because > I was doing another line-by-line review of all my changes. We should have a > test which catches such a condition. > Add a test which tests that leaders always recover from log on startup. -- 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-6054) Log progress of transaction log replays
[ https://issues.apache.org/jira/browse/SOLR-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14203587#comment-14203587 ] Vitaliy Zhovtyuk commented on SOLR-6054: i think this is enough to have state logging every one minute of replay, polling thread can lead to thread leaks issues. SOLR-6403 does it well. SOLR-6054 can be closed as duplicate. > Log progress of transaction log replays > --- > > Key: SOLR-6054 > URL: https://issues.apache.org/jira/browse/SOLR-6054 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Mark Miller >Priority: Minor > Fix For: 4.9, Trunk > > Attachments: SOLR-6054.patch > > > There is zero logging of how a transaction log replay is progressing. We > should add some simple checkpoint based progress information. Logging the > size of the log file at the beginning would also be useful. -- 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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
Added "whitebox" DistributedFacetPivotWhiteBoxTest test simulating pivot stats
shard requests in cases: get top level pivots and refinement requests. Both
contains stats on pivots.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
Restored FacetPivotSmallTest, was lost between patches.
Added distributed test
org.apache.solr.handler.component.DistributedFacetPivotSmallAdvancedTestcovering
3additional cases
1. Getting pivot stats in string stats field
2. Getting top level stats on pivot stats
3. Pivot stats on each shard are not the same
Added getter to check stats values presence on
org.apache.solr.handler.component.PivotFacetValue#getStatsValues
Whitebox test assertions are not yet completed. Still working on it.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-6376) Edismax field alias bug
[ https://issues.apache.org/jira/browse/SOLR-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6376: --- Attachment: SOLR-6376.patch Issue not reproduced. Not existing field completely ignored from parsed query. Added test to TestExtendedDismaxParser to check this. > Edismax field alias bug > --- > > Key: SOLR-6376 > URL: https://issues.apache.org/jira/browse/SOLR-6376 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 4.6.1, 4.7, 4.7.2, 4.8, 4.9 >Reporter: Thomas Egense >Priority: Minor > Labels: difficulty-easy, edismax, impact-low > Attachments: SOLR-6376.patch > > > If you create a field alias that maps to a nonexistent field, the query will > be parsed to utter garbage. > The bug can reproduced very easily. Add the following line to the /browse > request handler in the tutorial example solrconfig.xml > name features XXX > (XXX is a nonexistent field) > This simple query will actually work correctly: > name_features:video > and it will be parsed to (features:video | name:video) and return 3 results. > It has simply discarded the nonexistent field and the result set is correct. > However if you change the query to: > name_features:video AND name_features:video > you will now get 0 result and the query is parsed to > +(((features:video | name:video) (id:AND^10.0 | author:and^2.0 | > title:and^10.0 | cat:AND^1.4 | text:and^0.5 | keywords:and^5.0 | manu:and^1.1 > | description:and^5.0 | resourcename:and | name:and^1.2 | features:and) > (features:video | name:video))~3) > Notice the AND operator is now used a term! The parsed query can turn out > even worse and produce query parts such as: > title:2~2 > title:and^2.0^10.0 > Prefered solution: During start up, shut down Solr if there is a nonexistant > field alias. Just as is the case if the cycle-detection detects a cycle: > Acceptable solution: Ignore the nonexistant field totally. > Thomas Egense -- 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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
Fixed TestCloudPivotFacet. The reason for previous random test failures were
facet.limit, facet.offset, facet.overrequest.count, facet.overrequest.ratio
parameters generated randomly,
this was leading to inconsistent stats with pivot stats. Added cleanup for
those parameters before stats on pivots test. All tests are passing.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
During work on
{code}
org.apache.solr.handler.component.DistributedFacetPivotLargeTest found:
junit.framework.AssertionFailedError:
.facet_counts.facet_pivot.place_s,company_t[0].stats!=pivot (unordered or
missing)
at
__randomizedtesting.SeedInfo.seed([705F7E1C2B9679AA:F1B9F0045CC91996]:0)
at
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:842)
at
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:861)
at
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:562)
{code}
This mean difference in named list order between control shard and random shard.
Found the reason in
org.apache.solr.handler.component.PivotFacetValue#convertToNamedList
Due to this reason also updated DistributedFacetPivotSmallTest to use call
org.apache.solr.BaseDistributedSearchTestCase#query(org.apache.solr.common.params.SolrParams)
with response comparison.
Test org.apache.solr.handler.component.DistributedFacetPivotLongTailTest works
only on string fields, added int field to make stats on it.
org.apache.solr.cloud.TestCloudPivotFacet: added buildRandomPivotStatsFields to
build stats.filed list, this methods skip fields of string and boolean type
since they are not supported.
added tag string random generation on stat fields generated and if stats active
tags also added to pivot fields.
Added handling for not present controls stats (count=0) in TestCloudPivotFacet.
About skipping stats if count=0, it is not really good cause we losing missing
stats distribution.
Case with count=0, but missing=1 is real.
There are still some failures for TestCloudPivotFacet for date and double
(precision?). Will check it tomorrow.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Comment Edited] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159648#comment-14159648
]
Vitaliy Zhovtyuk edited comment on SOLR-6351 at 10/5/14 7:20 PM:
-
1. Added stats fields pivot distribution to DistributedFacetPivotSmallTest
(same data and values from
org.apache.solr.handler.component.FacetPivotSmallTest used)
2. Fixed "LinkedHashMap cannot be casted to NamedList" exception, occurring on
stats distribution (changed
org.apache.solr.handler.component.PivotFacetHelper#convertStatsValuesToNamedList)
3. About Testing for not supported types, i think we need to cover/document
limitations as well.I'm not happy with asserting error message.
Added http code 400 assertion and error message substring assertion.
was (Author: vzhovtiuk):
1. Added stats fields pivot distribution to DistributedFacetPivotSmallTest
2. Fixed "LinkedHashMap cannot be casted to NamedList" exception, occurring on
stats distribution (changed
org.apache.solr.handler.component.PivotFacetHelper#convertStatsValuesToNamedList)
3. About Testing for not supported types, i think we need to cover/document
limitations as well.I'm not happy with asserting error message.
Added http code 400 assertion and error message substring assertion.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
1. Added stats fields pivot distribution to DistributedFacetPivotSmallTest
2. Fixed "LinkedHashMap cannot be casted to NamedList" exception, occurring on
stats distribution (changed
org.apache.solr.handler.component.PivotFacetHelper#convertStatsValuesToNamedList)
3. About Testing for not supported types, i think we need to cover/document
limitations as well.I'm not happy with asserting error message.
Added http code 400 assertion and error message substring assertion.
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
Combined with previous patch.
1. Added more solrj tests for stats on pivots
2. Fixed stats result
3. Minor tweaks
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1632: --- Attachment: SOLR-1632.patch Wrong patch was attached on 1.04.2014. Updated previous changes to current trunk. TestDefaultStatsCache, TestExactSharedStatsCache, TestExactStatsCache, TestLRUStatsCache are passing. > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 4.9, Trunk > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > distrib-2.patch, distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- 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] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1632: --- Attachment: (was: SOLR-5488.patch) > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 4.9, Trunk > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, distrib-2.patch, > distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- 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] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6351:
---
Attachment: SOLR-6351.patch
Intermediate results:
1. Added pivot facet test to SolrExampleTests, extended
org.apache.solr.client.solrj.SolrQuery to provide multipls stats.field parameter
2. Added FacetPivotSmallTest and moved all asserts from
DistributedFacetPivotSmallTest to XPath assertions, separated it to few test
methods
3. "tag" local parameter parsing added
4. added org.apache.solr.handler.component.StatsInfo#tagToStatsFields and
org.apache.solr.handler.component.StatsInfo#getStatsFieldsByTag
to lookup list of stats fields by tag
5. Modified PivotFacetProcessor to collect and put StatValues for ever pivot
field, added test to assert stats value of pivots
6. Updated PivotField and org.apache.solr.client.solrj.response.QueryResponse
to read stats values on pivots
> Let Stats Hang off of Pivots (via 'tag')
>
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
>Reporter: Hoss Man
> Attachments: SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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] [Updated] (SOLR-6028) SOLR returns 500 error code for query /<,/
[ https://issues.apache.org/jira/browse/SOLR-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6028: --- Attachment: SOLR-6028.patch Added catch and transformation to SolrException (BadRequest) that lead to HTTP 400. The thing looks not really nice - IllegalArgumentException on parse problems in org.apache.lucene.search.RegexpQuery, shouldn't it be custom runtime exception. > SOLR returns 500 error code for query /<,/ > -- > > Key: SOLR-6028 > URL: https://issues.apache.org/jira/browse/SOLR-6028 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 4.7.1 >Reporter: Kingston Duffie >Priority: Minor > Attachments: SOLR-6028.patch > > > If you enter the following query string into the SOLR admin console to > execute a query, you will get a 500 error: > /<,/ > This is an invalid query -- in the sense that the field between the slashes > is not a valid regex. Nevertheless, I would have expected to get a 400 error > rather than 500. -- 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] [Updated] (SOLR-5992) add "removeregex" as an atomic update operation
[ https://issues.apache.org/jira/browse/SOLR-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5992: --- Attachment: SOLR-5992.patch Added removeregex atomic operation. Works on single patterns or lists of patterns. Regex patterns created before matching loop execution. > add "removeregex" as an atomic update operation > --- > > Key: SOLR-5992 > URL: https://issues.apache.org/jira/browse/SOLR-5992 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.9, Trunk >Reporter: Erick Erickson > Attachments: SOLR-5992.patch > > > Spinoff from SOLR-3862. If someone wants to pick it up, please do, create a > patch and assign to me. See the discussion at SOLR-3862 for some things to > bear in mind, especially the interface discussion. -- 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] [Updated] (SOLR-6009) edismax mis-parsing RegexpQuery
[
https://issues.apache.org/jira/browse/SOLR-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6009:
---
Attachment: SOLR-6009.patch
Actually there are 2linked issues:
1. edismax was not supported Regex queries
2. since regex queries was not supported RegexpQuery was created by
org.apache.solr.parser.SolrQueryParserBase#getRegexpQuery without taking into
account aliasing and
org.apache.solr.search.ExtendedDismaxQParser#IMPOSSIBLE_FIELD_NAME
Attached patch provide support for RegexQueries and fix issue with leaking
impossible field name. Also added tests covering case with defined field and
undefined field (but matching by '*' dynamic field) and DebugQuery output.
> edismax mis-parsing RegexpQuery
> ---
>
> Key: SOLR-6009
> URL: https://issues.apache.org/jira/browse/SOLR-6009
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.7.2
>Reporter: Evan Sayer
> Attachments: SOLR-6009.patch
>
>
> edismax appears to be leaking its IMPOSSIBLE_FIELD_NAME into queries
> involving a RegexpQuery. Steps to reproduce on 4.7.2:
> 1) remove the explicit definition for 'text'
> 2) add a catch-all '*' dynamic field of type text_general
> {code}
> stored="true" />
> {code}
> 3) index the exampledocs/ data
> 4) run a query like the following:
> {code}
> http://localhost:8983/solr/collection1/select?q={!edismax%20qf=%27text%27}%20/.*elec.*/&debugQuery=true
> {code}
> The debugQuery output will look like this:
> {code}
>
> {!edismax qf='text'} /.*elec.*/
> {!edismax qf='text'} /.*elec.*/
> (+RegexpQuery(:/.*elec.*/))/no_coord
> +:/.*elec.*/
> {code}
> If you copy/paste the parsed-query into a text editor or something, you can
> see that the field-name isn't actually blank. The IMPOSSIBLE_FIELD_NAME ends
> up in there.
> I haven't been able to reproduce this behavior on 4.7.2 without getting rid
> of the explicit field definition for 'text' and using a dynamicField, which
> is how things are setup on the machine where this issue was discovered. The
> query isn't quite right with the explicit field definition in place either,
> though:
> {code}
>
> {!edismax qf='text'} /.*elec.*/
> {!edismax qf='text'} /.*elec.*/
> (+DisjunctionMaxQuery((text:elec)))/no_coord
> +(text:elec)
> {code}
> numFound=0 for both of these. This site is useful for looking at the
> characters in the first variant:
> http://rishida.net/tools/conversion/
--
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] [Updated] (SOLR-6541) Enhancement for SOLR-6452 StatsComponent "missing" stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6541: --- Attachment: SOLR-6541.patch Patch based on trunk to address mentioned issues. > Enhancement for SOLR-6452 StatsComponent "missing" stat won't work with > docValues=true and indexed=false > > > Key: SOLR-6541 > URL: https://issues.apache.org/jira/browse/SOLR-6541 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.10, 6.0 >Reporter: Vitaliy Zhovtyuk >Priority: Minor > Fix For: 5.0, 6.0 > > Attachments: SOLR-6541.patch > > > This issue is refactoring of solution provided in SOLR-6452 StatsComponent > "missing" stat won't work with docValues=true and indexed=false. > I think the following points need to be addressed: > 1. Accumulate methods should not return stats specific numbers (it is > generic). Attached solution with container class. Also made them private > scoped. > Returning just missing fields from accumulate methods does not allow you to > extend it with additional counts field, therefore i propose to leave void. > 2. Reduced visibility of fields in FieldFacetStats. > 3. Methods FieldFacetStats#accumulateMissing and > FieldFacetStats#accumulateTermNum does not throw any IO exception > 4. We don't need intermediate maps to accumulate missing counts. Method > org.apache.solr.handler.component.FieldFacetStats#facetMissingNum > can be changed to work directly on StatsValues structure and removed > org.apache.solr.handler.component.FieldFacetStats#accumulateMissing. > We don't need to have it in 2 phases. -- 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] [Created] (SOLR-6541) Enhancement for SOLR-6452 StatsComponent "missing" stat won't work with docValues=true and indexed=false
Vitaliy Zhovtyuk created SOLR-6541: -- Summary: Enhancement for SOLR-6452 StatsComponent "missing" stat won't work with docValues=true and indexed=false Key: SOLR-6541 URL: https://issues.apache.org/jira/browse/SOLR-6541 Project: Solr Issue Type: Improvement Affects Versions: 4.10, 6.0 Reporter: Vitaliy Zhovtyuk Priority: Minor Fix For: 5.0, 6.0 This issue is refactoring of solution provided in SOLR-6452 StatsComponent "missing" stat won't work with docValues=true and indexed=false. I think the following points need to be addressed: 1. Accumulate methods should not return stats specific numbers (it is generic). Attached solution with container class. Also made them private scoped. Returning just missing fields from accumulate methods does not allow you to extend it with additional counts field, therefore i propose to leave void. 2. Reduced visibility of fields in FieldFacetStats. 3. Methods FieldFacetStats#accumulateMissing and FieldFacetStats#accumulateTermNum does not throw any IO exception 4. We don't need intermediate maps to accumulate missing counts. Method org.apache.solr.handler.component.FieldFacetStats#facetMissingNum can be changed to work directly on StatsValues structure and removed org.apache.solr.handler.component.FieldFacetStats#accumulateMissing. We don't need to have it in 2 phases. -- 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] [Updated] (SOLR-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6452: --- Attachment: SOLR-6452-trunk.patch Added patch based on trunk. Added facet fields tests for integer and double types, and facet value stats is not available. Does it require new issue or reopen SOLR-6452? Implementation of this issue can be improved in few cases: 1. Accumulate methods should not return stats specific numbers (it is generic). Attached solution with container class. Also made them private scoped. Returning just missing fields from accumulate methods does not allow you to extend it with additional counts field, therefore i propose to leave void. 2. Reduced visibility of fields in FieldFacetStats. Created getter to expose FieldFacetStats.facetStatsValues. 3. Methods FieldFacetStats#accumulateMissing and FieldFacetStats#accumulateTermNum does not throw any IO exception 4. We don't need intermediate maps to accumulate missing counts. Changed org.apache.solr.handler.component.FieldFacetStats#facetMissingNum to work directly on StatsValues structure and removed org.apache.solr.handler.component.FieldFacetStats#accumulateMissing. We don't need to have it in 2 phases. > StatsComponent "missing" stat won't work with docValues=true and indexed=false > -- > > Key: SOLR-6452 > URL: https://issues.apache.org/jira/browse/SOLR-6452 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10, 5.0 >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Fix For: 4.11, 5.0 > > Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, > SOLR-6452-trunk.patch, SOLR-6452.patch, SOLR-6452.patch, SOLR-6452.patch > > > StatsComponent can work with DocValues, but it still required to use > indexed=true for the "missing" stat to work. Missing values should be > obtained from the docValues too. -- 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] [Updated] (SOLR-6452) StatsComponent "missing" stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6452: --- Attachment: SOLR-6452.patch There are few issues in committed code addressed in attached patch: 1. Accumulate methods should not return stats specific numbers (it is generic calculation). Attached solution with nested container class. Also made them private scoped. 2. Reduced visibility of fields in FieldFacetStats. Created getter to expose FieldFacetStats.facetStatsValues. 3. Methods FieldFacetStats#accumulateMissing and FieldFacetStats#accumulateTermNum does not throw any IO exception 4. Why missing facet counters cant work on StatsValues directly without intermediate maps. They have all required required methods that look like duplicated in org.apache.solr.handler.component.FieldFacetStats#facetMissingNum and org.apache.solr.handler.component.AbstractStatsValues#missing? Will try to unite it. > StatsComponent "missing" stat won't work with docValues=true and indexed=false > -- > > Key: SOLR-6452 > URL: https://issues.apache.org/jira/browse/SOLR-6452 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10, 5.0 >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, > SOLR-6452.patch, SOLR-6452.patch, SOLR-6452.patch > > > StatsComponent can work with DocValues, but it still required to use > indexed=true for the "missing" stat to work. Missing values should be > obtained from the docValues too. -- 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] [Updated] (SOLR-6024) StatsComponent does not work for docValues enabled multiValued fields
[
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6024:
---
Attachment: SOLR-6024-trunk.patch
Patch based on latest added trunk patch.
Added stats calculation tests for docValues and multiValued fields of float and
integer numeric types, added calculate distinct count, added stats.facet query
on docValues field (leads to field type exception)
> StatsComponent does not work for docValues enabled multiValued fields
> -
>
> Key: SOLR-6024
> URL: https://issues.apache.org/jira/browse/SOLR-6024
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 4.8
> Environment: java version "1.7.0_45"
> Mac OS X Version 10.7.5
>Reporter: Ahmet Arslan
> Labels: StatsComponent, docValues, multiValued
> Fix For: 4.9
>
> Attachments: SOLR-6024-trunk.patch, SOLR-6024-trunk.patch,
> SOLR-6024-trunk.patch, SOLR-6024-trunk.patch, SOLR-6024-trunk.patch,
> SOLR-6024.patch, SOLR-6024.patch
>
>
> Harish Agarwal reported this in solr user mailing list :
> http://search-lucene.com/m/QTPaoTJXV1
> It is east to re-produce with default example solr setup. Following types are
> added example schema.xml. And exampledocs are indexed.
> {code:xml}
> docValues="true" multiValued="true"/>
>docValues="true" multiValued="true"/>
> {code}
> When {{docValues="true"}} *and* {{multiValued="true"}} are used at the same
> time, StatsComponent throws :
> {noformat}
> ERROR org.apache.solr.core.SolrCore – org.apache.solr.common.SolrException:
> Type mismatch: popularity was indexed as SORTED_SET
> at
> org.apache.solr.request.UnInvertedField.(UnInvertedField.java:193)
> at
> org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
> at
> org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
> at
> org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
> at
> org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
> {noformat}
--
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-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[
https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112984#comment-14112984
]
Vitaliy Zhovtyuk commented on SOLR-6191:
About type safety: maybe wrong term, but in my opinion having
{code}SolrParams.get(MoreLikeThisParameters.MLT){code} is more safe then
{code}SolrParams.get("mlt"){code} used a lot in code, MoreLikeThisParameters
enum relates to documenting parameters and is not so error prone like string
hardcodes, it should be same way for components and handlers to refer
parameters.
> Self Describing SearchComponents, RequestHandlers, params. etc.
> ---
>
> Key: SOLR-6191
> URL: https://issues.apache.org/jira/browse/SOLR-6191
> Project: Solr
> Issue Type: Bug
>Reporter: Vitaliy Zhovtyuk
>Assignee: Noble Paul
> Labels: features
> Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch,
> SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch
>
>
> We should have self describing parameters for search components, etc.
> I think we should support UNIX style short and long names and that you should
> also be able to get a short description of what a parameter does if you ask
> for INFO on it.
> For instance, &fl could also be &fieldList, etc.
> Also, we should put this into the base classes so that new components can add
> to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6054) Log progress of transaction log replays
[ https://issues.apache.org/jira/browse/SOLR-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6054: --- Attachment: SOLR-6054.patch Added log watches for every 10sec, added log statements to expose log internal state. > Log progress of transaction log replays > --- > > Key: SOLR-6054 > URL: https://issues.apache.org/jira/browse/SOLR-6054 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Minor > Fix For: 4.9, 5.0 > > Attachments: SOLR-6054.patch > > > There is zero logging of how a transaction log replay is progressing. We > should add some simple checkpoint based progress information. Logging the > size of the log file at the beginning would also be useful. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6024) StatsComponent does not work for docValues enabled multiValued fields
[
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6024:
---
Attachment: SOLR-6024.patch
Added patch based for lucene_solr_4_9 branch fixing issue,
for fields having docValues called
org.apache.solr.request.DocValuesStats#getCounts from rev. 1595259 and
UnInvertedField in other cases.
> StatsComponent does not work for docValues enabled multiValued fields
> -
>
> Key: SOLR-6024
> URL: https://issues.apache.org/jira/browse/SOLR-6024
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 4.8
> Environment: java version "1.7.0_45"
> Mac OS X Version 10.7.5
>Reporter: Ahmet Arslan
> Labels: StatsComponent, docValues, multiValued
> Fix For: 4.9
>
> Attachments: SOLR-6024.patch, SOLR-6024.patch
>
>
> Harish Agarwal reported this in solr user mailing list :
> http://search-lucene.com/m/QTPaoTJXV1
> It is east to re-produce with default example solr setup. Following types are
> added example schema.xml. And exampledocs are indexed.
> {code:xml}
> docValues="true" multiValued="true"/>
>docValues="true" multiValued="true"/>
> {code}
> When {{docValues="true"}} *and* {{multiValued="true"}} are used at the same
> time, StatsComponent throws :
> {noformat}
> ERROR org.apache.solr.core.SolrCore – org.apache.solr.common.SolrException:
> Type mismatch: popularity was indexed as SORTED_SET
> at
> org.apache.solr.request.UnInvertedField.(UnInvertedField.java:193)
> at
> org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
> at
> org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
> at
> org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
> at
> org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100056#comment-14100056
]
Vitaliy Zhovtyuk commented on SOLR-6016:
File solrconfig.xml does not contain whitespace changes, the order of
typeMapping elements changed intentionally to favor Double over Integer,
therefore any tests with random values will pass by this configuration (since
all will be as double).
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6016.patch, SOLR-6016.patch, solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberFormatException: For input string: "479.95"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:441)
> at java.lang.Long.parseLong(Long.java:483)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:609)
> at org.apache.solr.schema.TrieField.createFields(TrieFiel
[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100051#comment-14100051 ] Vitaliy Zhovtyuk commented on SOLR-6191: Annotation approach is beautiful, but it does not describe used in code parameter names since it just string constants. Original goal was to replace all parameter string names with strong typed enum containing parameter string description, see org.apache.solr.common.params.SolrParams. Probably make sense to use both ways and use Parameter enum implementing org.apache.solr.common.params.ParameterDescription as @Param value and don't require component to extend interface. This will bring strong typing code usages and provide generic API for describing parameters. > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk >Assignee: Noble Paul > Labels: features > Attachments: SOLR-6191.patch, SOLR-6191.patch, SOLR-6191.patch, > SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6024) StatsComponent does not work for docValues enabled multiValued fields
[
https://issues.apache.org/jira/browse/SOLR-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6024:
---
Attachment: SOLR-6024.patch
Issue reproduced in solr-4.9.0.
Issue not reproduced on trunk, attached test in patch don't get exception on
query.
UnInvertedField invokation was removed in rev:
1595259 5/16/14 6:39 PM rmuir 1594441, 1593789LUCENE-5666:
Add UninvertingReader
> StatsComponent does not work for docValues enabled multiValued fields
> -
>
> Key: SOLR-6024
> URL: https://issues.apache.org/jira/browse/SOLR-6024
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other
>Affects Versions: 4.8
> Environment: java version "1.7.0_45"
> Mac OS X Version 10.7.5
>Reporter: Ahmet Arslan
> Labels: StatsComponent, docValues, multiValued
> Fix For: 4.9
>
> Attachments: SOLR-6024.patch
>
>
> Harish Agarwal reported this in solr user mailing list :
> http://search-lucene.com/m/QTPaoTJXV1
> It is east to re-produce with default example solr setup. Following types are
> added example schema.xml. And exampledocs are indexed.
> {code:xml}
> docValues="true" multiValued="true"/>
>docValues="true" multiValued="true"/>
> {code}
> When {{docValues="true"}} *and* {{multiValued="true"}} are used at the same
> time, StatsComponent throws :
> {noformat}
> ERROR org.apache.solr.core.SolrCore – org.apache.solr.common.SolrException:
> Type mismatch: popularity was indexed as SORTED_SET
> at
> org.apache.solr.request.UnInvertedField.(UnInvertedField.java:193)
> at
> org.apache.solr.request.UnInvertedField.getUnInvertedField(UnInvertedField.java:699)
> at
> org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:319)
> at
> org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:290)
> at
> org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:78)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:221)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1964)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-3881:
---
Attachment: SOLR-3881.patch
About moving concatFields() to the tika language identifier: I think the way to
go is just move the whole method there, then change the detectLanguage() method
to take the SolrInputDocument instead of a String. You don't need to carry over
the field[] parameter from concatFields(), since data member inputFields will
be accessible everywhere it's needed.
[VZ] This call looks more cleaner now, i changed inputFields to private now to
reduce visibility scope
I should have mentioned previously: I don't like the maxAppendSize and
maxTotalAppendSize names - "size" is ambiguous (could refer to bytes, chars,
whatever), and "append" refers to an internal operation... I'd like to see
"append"=>"field value" and "size"=>"chars": maxFieldValueChars, and
maxTotalChars (since appending doesn't need to be mentioned for the global
limit). The same thing goes for the default constants and the test method names.
[VZ] Renamed parameters and test methods
Some minor issues I found with your patch:
As I said previously: "We should also set default maxima for both per-value and
total chars, rather than MAX_INT, as in the current patch."
The total chars default should be its own setting; I was thinking we could make
it double the per-value default?
[VZ] added default value to maxTotalChars and changed both to 10K like in
com.cybozu.labs.langdetect.Detector.maxLength
It's better not to reorder import statements unless you're already making
significant changes to them; it distracts from the meat of the change. (You
reordered them in LangDetectLanguageIdentifierUpdateProcessor and
LanguageIdentifierUpdateProcessorFactoryTestCase)
[VZ] This is IDE optimization to put imports in alphabetical order - restored
it to original order
In LanguageIdentifierUpdateProcessor.concatFields(), when you trim the
concatenated text to maxTotalAppendSize, I think
StringBuilder.setLength(maxTotalAppendSize); would be more efficient than
StringBuilder.delete(maxTotalAppendSize, sb.length() - 1);
[VZ] Yep, cleaned that
In addition to the test you added for the global limit, we should also test
using both the per-value and global limits at the same time.
[VZ] Tests for both limits added
> frequent OOM in LanguageIdentifierUpdateProcessor
> -
>
> Key: SOLR-3881
> URL: https://issues.apache.org/jira/browse/SOLR-3881
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 4.0
> Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
>Reporter: Rob Tulloh
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3881.patch, SOLR-3881.patch, SOLR-3881.patch,
> SOLR-3881.patch
>
>
> We are seeing frequent failures from Solr causing it to OOM. Here is the
> stack trace we observe when this happens:
> {noformat}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2882)
> at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> at java.lang.StringBuffer.append(StringBuffer.java:224)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
> at
[jira] [Updated] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6016:
---
Attachment: SOLR-6016.patch
Added test with random order of values on schemaless example config, asserted
thrown exception
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6016.patch, SOLR-6016.patch, solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberFormatException: For input string: "479.95"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:441)
> at java.lang.Long.parseLong(Long.java:483)
> at org.apache.solr.schema.TrieField.createField(TrieField.java:609)
> at org.apache.solr.schema.TrieField.createFields(TrieField.java:660)
> {code}
> The full solr.log is attached.
> I understand why these errors occur but since we ship example data with Solr
> to demonstrate our core features, I expe
[jira] [Updated] (SOLR-6163) special chars and ManagedSynonymFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6163: --- Attachment: SOLR-6163.patch Added change with decode=true Checked org.restlet.data.Reference methods usage, used only in org.apache.solr.rest.RestManager > special chars and ManagedSynonymFilterFactory > - > > Key: SOLR-6163 > URL: https://issues.apache.org/jira/browse/SOLR-6163 > Project: Solr > Issue Type: Bug >Affects Versions: 4.8 >Reporter: Wim Kumpen > Attachments: SOLR-6163.patch > > > Hey, > I was playing with the ManagedSynonymFilterFactory to create a synonym list > with the API. But I have difficulties when my keys contains special > characters (or spaces) to delete them... > I added a key ééé that matches with some other words. It's saved in the > synonym file as ééé. > When I try to delete it, I do: > curl -X DELETE > "http://localhost/solr/mycore/schema/analysis/synonyms/english/ééé"; > error message: %C3%A9%C3%A9%C3%A9%C2%B5 not found in > /schema/analysis/synonyms/english > A wild guess from me is that %C3%A9 isn't decoded back to ééé. And that's why > he can't find the keyword? -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6248) MoreLikeThis Query Parser
[
https://issues.apache.org/jira/browse/SOLR-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073671#comment-14073671
]
Vitaliy Zhovtyuk commented on SOLR-6248:
With current implementation in patch mlt qparser can match document by unique
field configured in schema and find similar document out of it. Parser syntax
now look like {code}{!mlt id=17 qf=lowerfilt}lowerfilt:*{code} where id is
value of unique field configure (not "id" column in schema), qf is matched
fields to search.
About passing text this parser can be extended with text parameter, search
document by this term and look for similar document using existing
implementation.
> MoreLikeThis Query Parser
> -
>
> Key: SOLR-6248
> URL: https://issues.apache.org/jira/browse/SOLR-6248
> Project: Solr
> Issue Type: New Feature
>Reporter: Anshum Gupta
> Attachments: SOLR-6248.patch
>
>
> MLT Component doesn't let people highlight/paginate and the handler comes
> with an cost of maintaining another piece in the config. Also, any changes to
> the default (number of results to be fetched etc.) /select handler need to be
> copied/synced with this handler too.
> Having an MLT QParser would let users get back docs based on a query for them
> to paginate, highlight etc. It would also give them the flexibility to use
> this anywhere i.e. q,fq,bq etc.
> A bit of history about MLT (thanks to Hoss)
> MLT Handler pre-dates the existence of QParsers and was meant to take an
> arbitrary query as input, find docs that match that
> query, club them together to find interesting terms, and then use those
> terms as if they were my main query to generate a main result set.
> This result would then be used as the set to facet, highlight etc.
> The flow: Query -> DocList(m) -> Bag (terms) -> Query -> DocList\(y)
> The MLT component on the other hand solved a very different purpose of
> augmenting the main result set. It is used to get similar docs for each of
> the doc in the main result set.
> DocSet\(n) -> n * Bag (terms) -> n * (Query) -> n * DocList(m)
> The new approach:
> All of this can be done better and cleaner (and makes more sense too) using
> an MLT QParser.
> An important thing to handle here is the case where the user doesn't have
> TermVectors, in which case, it does what happens right now i.e. parsing
> stored fields.
> Also, in case the user doesn't have a field (to be used for MLT) indexed, the
> field would need to be a TextField with an index analyzer defined. This
> analyzer will then be used to extract terms for MLT.
> In case of SolrCloud mode, '/get-termvectors' can be used after looking at
> the schema (if TermVectors are enabled for the field). If not, a /get call
> can be used to fetch the field and parse it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6248) MoreLikeThis Query Parser
[ https://issues.apache.org/jira/browse/SOLR-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6248: --- Attachment: SOLR-6248.patch Added mlt qparser, works in single and cloud mode. Added support for numeric id. Result of mlt written as query result - not in MoreLikeThis. Added tests to call in single and cloud modes. > MoreLikeThis Query Parser > - > > Key: SOLR-6248 > URL: https://issues.apache.org/jira/browse/SOLR-6248 > Project: Solr > Issue Type: New Feature >Reporter: Anshum Gupta > Attachments: SOLR-6248.patch > > > MLT Component doesn't let people highlight/paginate and the handler comes > with an cost of maintaining another piece in the config. Also, any changes to > the default (number of results to be fetched etc.) /select handler need to be > copied/synced with this handler too. > Having an MLT QParser would let users get back docs based on a query for them > to paginate, highlight etc. It would also give them the flexibility to use > this anywhere i.e. q,fq,bq etc. > A bit of history about MLT (thanks to Hoss) > MLT Handler pre-dates the existence of QParsers and was meant to take an > arbitrary query as input, find docs that match that > query, club them together to find interesting terms, and then use those > terms as if they were my main query to generate a main result set. > This result would then be used as the set to facet, highlight etc. > The flow: Query -> DocList(m) -> Bag (terms) -> Query -> DocList\(y) > The MLT component on the other hand solved a very different purpose of > augmenting the main result set. It is used to get similar docs for each of > the doc in the main result set. > DocSet\(n) -> n * Bag (terms) -> n * (Query) -> n * DocList(m) > The new approach: > All of this can be done better and cleaner (and makes more sense too) using > an MLT QParser. > An important thing to handle here is the case where the user doesn't have > TermVectors, in which case, it does what happens right now i.e. parsing > stored fields. > Also, in case the user doesn't have a field (to be used for MLT) indexed, the > field would need to be a TextField with an index analyzer defined. This > analyzer will then be used to extract terms for MLT. > In case of SolrCloud mode, '/get-termvectors' can be used after looking at > the schema (if TermVectors are enabled for the field). If not, a /get call > can be used to fetch the field and parse it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-3881:
---
Attachment: SOLR-3881.patch
Added global limit to concatenated string
Added limit to detector to detector.setMaxTextLength(maxTotalAppendSize);
About moving
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor#concatFields
to org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessor it's
a bit unclear because concatFields is used in both
org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessor and
org.apache.solr.update.processor.LangDetectLanguageIdentifierUpdateProcessor
> frequent OOM in LanguageIdentifierUpdateProcessor
> -
>
> Key: SOLR-3881
> URL: https://issues.apache.org/jira/browse/SOLR-3881
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 4.0
> Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
>Reporter: Rob Tulloh
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-3881.patch, SOLR-3881.patch, SOLR-3881.patch
>
>
> We are seeing frequent failures from Solr causing it to OOM. Here is the
> stack trace we observe when this happens:
> {noformat}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2882)
> at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> at java.lang.StringBuffer.append(StringBuffer.java:224)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:47)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:58)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev
[jira] [Updated] (SOLR-6016) Failure indexing exampledocs with example-schemaless mode
[
https://issues.apache.org/jira/browse/SOLR-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-6016:
---
Attachment: SOLR-6016.patch
The reason is should be know issue with TypeMapping in schemaless mode:
When Integer type has priority over Double and Float and integer price "10"
come first it's mapped like org.apache.solr.schema.TrieLongField, next price
values like "10.6" that supposed to be org.apache.solr.schema.TrieDoubleField
fail to be indexed.
Therefore if Double has priority over Integer this will solve the issue, but
then values that supposed to be like int and long can be mapped as double. I
think make sense to distinguish numeric types with type ending "10i" as integer
and "10d" as double and default type as integer. This allow to solve the issue
with ambiguous types.
> Failure indexing exampledocs with example-schemaless mode
> -
>
> Key: SOLR-6016
> URL: https://issues.apache.org/jira/browse/SOLR-6016
> Project: Solr
> Issue Type: Bug
> Components: documentation, Schema and Analysis
>Affects Versions: 4.7.2, 4.8
>Reporter: Shalin Shekhar Mangar
> Attachments: SOLR-6016.patch, solr.log
>
>
> Steps to reproduce:
> # cd example; java -Dsolr.solr.home=example-schemaless/solr -jar start.jar
> # cd exampledocs; java -jar post.jar *.xml
> Output from post.jar
> {code}
> Posting files to base url http://localhost:8983/solr/update using
> content-type application/xml..
> POSTing file gb18030-example.xml
> POSTing file hd.xml
> POSTing file ipod_other.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file ipod_video.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file manufacturers.xml
> POSTing file mem.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file money.xml
> POSTing file monitor2.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file monitor.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file mp500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file sd500.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> POSTing file solr.xml
> POSTing file utf8-example.xml
> POSTing file vidcard.xml
> SimplePostTool: WARNING: Solr returned an error #400 Bad Request
> SimplePostTool: WARNING: IOException while reading response:
> java.io.IOException: Server returned HTTP response code: 400 for URL:
> http://localhost:8983/solr/update
> 14 files indexed.
> COMMITting Solr index changes to http://localhost:8983/solr/update..
> Time spent: 0:00:00.401
> {code}
> Exceptions in Solr (I am pasting just one of them):
> {code}
> 5105 [qtp697879466-14] ERROR org.apache.solr.core.SolrCore –
> org.apache.solr.common.SolrException: ERROR: [doc=EN7800GTX/2DHTV/256M] Error
> adding field 'price'='479.95' msg=For input string: "479.95"
> at
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:167)
> at
> org.apache.solr.update.AddUpdateCommand.getLuceneDocument(AddUpdateCommand.java:77)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:234)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:160)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
> at
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
> ..
> Caused by: java.lang.NumberF
[jira] [Updated] (SOLR-6020) Auto-generate a unique key in schema-less mode if data does not have an "id" field
[ https://issues.apache.org/jira/browse/SOLR-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6020: --- Attachment: SOLR-6020.patch Added patch with changes to UUIDUpdateProcessorFactory and test. UUIDUpdateProcessorFactory will use uniqueKeyField if its UUID and field is not defined in processor configuration. Maybe make sense to throw exception if configured or uniqueKeyField is not UUID type. Currently it's ignored. > Auto-generate a unique key in schema-less mode if data does not have an "id" > field > -- > > Key: SOLR-6020 > URL: https://issues.apache.org/jira/browse/SOLR-6020 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-6020.patch > > > Currently it is not possible to use the schema-less example if my data does > not have an "id" field. > I was indexing data where the unique field name was "url" in schema-less > mode. This requires one to first change unique key name in the schema and > then start solr and then index docs. If one had already started solr, one'd > first need to remove managed-schema, rename schema.xml.bak to schema.xml and > then make the necessary changes in schema.xml. I don't think we should fail > on such simple things. > Here's what I propose: > # We remove "id" and uniqueKey from the managed schema example > # If there's a field named "id" in the document, we use that as the uniqueKey > # Else we fallback on generating a UUID or a signature field via an update > processor and store it as the unique key field. We can name it as "id" or > "_id" > # But if a uniqueKey is already present in original schema.xml then we should > expect the incoming data to have that field and we should preserve the > current behavior of failing loudly. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4044) CloudSolrServer early connect problems
[
https://issues.apache.org/jira/browse/SOLR-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-4044:
---
Attachment: SOLR-4044.patch
Added test to reproduce the issue
> CloudSolrServer early connect problems
> --
>
> Key: SOLR-4044
> URL: https://issues.apache.org/jira/browse/SOLR-4044
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.0
>Reporter: Grant Ingersoll
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-4044.patch
>
>
> If you call CloudSolrServer.connect() after Zookeeper is up, but before
> clusterstate, etc. is populated, you will get "No live SolrServer" exceptions
> (line 322 in LBHttpSolrServer):
> {code}
> throw new SolrServerException("No live SolrServers available to handle this
> request");{code}
> for all requests made even though all the Solr nodes are coming up just fine.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of "namespacing"
[
https://issues.apache.org/jira/browse/SOLR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5095:
---
Attachment: SOLR-5095.patch
1. Made map key as JMX canonical name that correspond to registered mbean and
unique
2. Overriden Map.get in order to translate existing key to JMX canonical name
3. Changed unregister method: removed unused InfoMBean parameter, changed
unregister to work on canonical name
4. JMX names reminded unchanged and backward compatible
> SolrCore.infoRegistry needs overhauled with some form of "namespacing"
> --
>
> Key: SOLR-5095
> URL: https://issues.apache.org/jira/browse/SOLR-5095
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-5095.patch, SOLR-5095_bug_demo.patch
>
>
> While investigating SOLR-3616 / SOLR-2715, I realized the failure i was
> seeing didn't seem to be related to the initial report of that bug, and
> instead seemed to be due to an obvious and fundemental limitation in the way
> SolrCore keeps track of "plugins" using the infoRegistry: It's just a
> {{Map}} keyed off of the name of the plugin, but there
> is not "namespacing" used in the infoRegistry, so two completley different
> types of plugins with the same name will overwrite each other.
> When looking at data using something like /admin/mbeans, this manifests
> itself solely as missing objects: last one .put() into the infoRegistry
> "wins" -- using JMX, both objects are actually visible because of how JMX
> ObjectNames are built arround a set of key=val pairs, and a bug in how
> JmxMonitorMap unregisters existing MBeans when .put() is called on a key it
> already knows about (the unregister call is made using an ObjectName built
> using the infoBean passed to the put() call -- if infoBean.getName() is not
> exactly the same as the previous infoBean put() with the same key, then the
> MbeanServer will continue to know about both of them)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-6191: --- Attachment: SOLR-6191.patch All methods in SolrParams are migrated to enum approach, old methods with string field name marked as deprecated. Migrated MLT params to enum containing params description. Component/Handler that has self described parameters should implement SelfDescribableParameters where T is enum type describing each parameter. This enum type should implement ParameterDescription interface in order to provide same contact for all parameter description enums. > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk > Labels: features > Attachments: SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-6190) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk closed SOLR-6190. -- Resolution: Invalid > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6190 > URL: https://issues.apache.org/jira/browse/SOLR-6190 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
Vitaliy Zhovtyuk created SOLR-6191: -- Summary: Self Describing SearchComponents, RequestHandlers, params. etc. Key: SOLR-6191 URL: https://issues.apache.org/jira/browse/SOLR-6191 Project: Solr Issue Type: Bug Reporter: Vitaliy Zhovtyuk We should have self describing parameters for search components, etc. I think we should support UNIX style short and long names and that you should also be able to get a short description of what a parameter does if you ask for INFO on it. For instance, &fl could also be &fieldList, etc. Also, we should put this into the base classes so that new components can add to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6190) Self Describing SearchComponents, RequestHandlers, params. etc.
Vitaliy Zhovtyuk created SOLR-6190: -- Summary: Self Describing SearchComponents, RequestHandlers, params. etc. Key: SOLR-6190 URL: https://issues.apache.org/jira/browse/SOLR-6190 Project: Solr Issue Type: Bug Reporter: Vitaliy Zhovtyuk We should have self describing parameters for search components, etc. I think we should support UNIX style short and long names and that you should also be able to get a short description of what a parameter does if you ask for INFO on it. For instance, &fl could also be &fieldList, etc. Also, we should put this into the base classes so that new components can add to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5480) Make MoreLikeThisHandler distributable
[ https://issues.apache.org/jira/browse/SOLR-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5480: --- Attachment: SOLR-5480.patch Updated patch sources to latest trunk. There are two approaches to get distributed MLT: 1. Added mlt qparser, works in single and cloud mode. Added support for numeric id. Result of mlt written as query result - not in MoreLikeThis. Added tests to call in single and cloud modes. 2. SingleMLT component, mlt per shards distribution, added org.apache.solr.handler.DistributedMoreLikeThisHandlerTest > Make MoreLikeThisHandler distributable > -- > > Key: SOLR-5480 > URL: https://issues.apache.org/jira/browse/SOLR-5480 > Project: Solr > Issue Type: Improvement >Reporter: Steve Molloy >Assignee: Noble Paul > Attachments: SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch, > SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch > > > The MoreLikeThis component, when used in the standard search handler supports > distributed searches. But the MoreLikeThisHandler itself doesn't, which > prevents from say, passing in text to perform the query. I'll start looking > into adapting the SearchHandler logic to the MoreLikeThisHandler. If anyone > has some work done already and want to share, or want to contribute, any help > will be welcomed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-3881:
---
Attachment: SOLR-3881.patch
Updated to latest trunk.
Fixed multivalue support.
Added string size calculation as string builder capacity. Used to prevent
multiple array allocation on append. (Maybe also need to be configurable - for
large documents only)
> frequent OOM in LanguageIdentifierUpdateProcessor
> -
>
> Key: SOLR-3881
> URL: https://issues.apache.org/jira/browse/SOLR-3881
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 4.0
> Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
>Reporter: Rob Tulloh
> Fix For: 4.8
>
> Attachments: SOLR-3881.patch, SOLR-3881.patch
>
>
> We are seeing frequent failures from Solr causing it to OOM. Here is the
> stack trace we observe when this happens:
> {noformat}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2882)
> at
> java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
> at java.lang.StringBuffer.append(StringBuffer.java:224)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
> at
> org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
> at
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:47)
> at
> org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:58)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1632: --- Attachment: SOLR-5488.patch - Fixed global stats distribution - Added assert on query explain (docNum, weight and idf should be the same in distributed tests), this assert is valid on 2nd query only since global stats merged in the end of 1st query. > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 4.8, 5.0 > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-5488.patch, > distrib-2.patch, distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5488: --- Attachment: SOLR-5488.patch Fixed FieldFacetExtrasTest. Tests passing for me now. > Fix up test failures for Analytics Component > > > Key: SOLR-5488 > URL: https://issues.apache.org/jira/browse/SOLR-5488 > Project: Solr > Issue Type: Bug >Affects Versions: 4.7, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, > SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, > SOLR-5488.patch, SOLR-5488.patch, eoe.errors > > > The analytics component has a few test failures, perhaps > environment-dependent. This is just to collect the test fixes in one place > for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5488) Fix up test failures for Analytics Component
[
https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5488:
---
Attachment: SOLR-5488.patch
The following changes were done:
1. Removed throw new IllegalArgumentException("No stat named '"+stat+"' in this
collector " + this); in
org.apache.solr.analytics.statistics.MinMaxStatsCollector#getStat because when
no stats collected and this method requested it's not excpetional case.
2. Fixed
org.apache.solr.analytics.facet.FieldFacetTest#perc20Test
org.apache.solr.analytics.facet.FieldFacetTest#perc60Test
The reason is stats name incompatibility in
org.apache.solr.analytics.expression.BaseExpression#getValue like "percentile"
and "precentile_60". Fixed by composible stat name for percentile calls from
"percentile_" + second function argument in
org.apache.solr.analytics.statistics.StatsCollectorSupplierFactory#create.
3. Fixed
org.apache.solr.analytics.util.valuesource.FunctionTest#constantStringTest
and org.apache.solr.analytics.util.valuesource.FunctionTest#multiplyTest.
The reason order incompetibility in Maps containing stats in
org.apache.solr.analytics.statistics.StatsCollectorSupplierFactory#create
Changed to TreeMap since order by stat string should be same.
4. Fixed org.apache.solr.analytics.facet.FieldFacetTest#missingFacetTest
by adding to
org.apache.solr.analytics.accumulator.FacetingAccumulator#FacetingAccumulator
always same order for facet fields.
5. Tests in org.apache.solr.analytics.facet.FieldFacetTest was working unstable
because they depended on facet fields order returned from query. Added sorting
of result and then assert Also added sorting of stdev results between assert.
6. Removed //nocommit in row in
org.apache.solr.analytics.AbstractAnalyticsStatsTest since it did not pass
precommit.
> Fix up test failures for Analytics Component
>
>
> Key: SOLR-5488
> URL: https://issues.apache.org/jira/browse/SOLR-5488
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.7, 5.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch,
> SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch,
> SOLR-5488.patch, eoe.errors
>
>
> The analytics component has a few test failures, perhaps
> environment-dependent. This is just to collect the test fixes in one place
> for convenience when we merge back into 4.x
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5394) facet.method=fcs seems to be using threads when it shouldn't
[
https://issues.apache.org/jira/browse/SOLR-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5394:
---
Attachment: SOLR-5394.patch
Attached patch contains 3tests reproducing issues with thread number.
There 2 unrelated usages of SimpleFacets.threads with different initialization:
- facet.threads - pool size for getting term count per each faces field.
Synchrous exectuion if 0.
- pool size of org.apache.solr.request.PerSegmentSingleValuedFaceting from
local parameters used in query like {!prefix f=bla threads=3
ex=text:bla}signatureField
If negative or zero thread number pased, then used MAX_INT as thread number -
int threads = nThreads <= 0 ? Integer.MAX_VALUE : nThreads;
Default value as -1 could be the issue.
About proposed fix i dont see any good reason to keep negative threads number
by default. Absolute limit for threads if negative should be -1.
I propose to set threads=1 by default meaning single thread execution, if
unspecified.
If it's requried to get MAX_INT thread pool (with is unlimited threads number)
is can be specified in query as -1.
> facet.method=fcs seems to be using threads when it shouldn't
>
>
> Key: SOLR-5394
> URL: https://issues.apache.org/jira/browse/SOLR-5394
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.6
>Reporter: Michael McCandless
> Attachments: SOLR-5394.patch,
> SOLR-5394_keep_threads_original_value.patch
>
>
> I built a wikipedia index, with multiple fields for faceting.
> When I do facet.method=fcs with facet.field=dateFacet and
> facet.field=userNameFacet, and then kill -QUIT the java process, I see a
> bunch (46, I think) of facetExecutor-7-thread-N threads had spun up.
> But I thought threads for each field is turned off by default?
> Even if I add facet.threads=0, it still spins up all the threads.
> I think something is wrong in SimpleFacets.parseParams; somehow, that method
> returns early (because localParams) is null, leaving threads=-1, and then the
> later code that would have set threads to 0 never runs.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5763) Upgrade to Tika 1.5
[ https://issues.apache.org/jira/browse/SOLR-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5763: --- Attachment: SOLR-5763.patch Updated versions and checksums: pdfbox 1.8.1 -> 1.8.4 jempbox 1.8.1 -> 1.8.4 fontbox 1.8.1 -> 1.8.4 > Upgrade to Tika 1.5 > --- > > Key: SOLR-5763 > URL: https://issues.apache.org/jira/browse/SOLR-5763 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Reporter: Steve Rowe >Priority: Minor > Attachments: SOLR-5763.patch, SOLR-5763.patch, SOLR-5763.patch > > > Just released: http://www.apache.org/dist/tika/CHANGES-1.5.txt -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5763) Upgrade to Tika 1.5
[ https://issues.apache.org/jira/browse/SOLR-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5763: --- Attachment: SOLR-5763.patch Updated sha1 checksumms > Upgrade to Tika 1.5 > --- > > Key: SOLR-5763 > URL: https://issues.apache.org/jira/browse/SOLR-5763 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Reporter: Steve Rowe >Priority: Minor > Attachments: SOLR-5763.patch, SOLR-5763.patch > > > Just released: http://www.apache.org/dist/tika/CHANGES-1.5.txt -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5763) Upgrade to Tika 1.5
[ https://issues.apache.org/jira/browse/SOLR-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5763: --- Attachment: SOLR-5763.patch Removed duplicates in solr-cell ivy.xml Updated tika to 1.5 and updated tika's dependencies: pdfbox 1.8.1 -> 1.8.2 jempbox 1.8.1 -> 1.8.2 fontbox 1.8.1 -> 1.8.2 POI 3.9 -> 3.10-beta2 xz 1.0 -> 1.2 > Upgrade to Tika 1.5 > --- > > Key: SOLR-5763 > URL: https://issues.apache.org/jira/browse/SOLR-5763 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Reporter: Steve Rowe >Priority: Minor > Attachments: SOLR-5763.patch > > > Just released: http://www.apache.org/dist/tika/CHANGES-1.5.txt -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3177) Excluding tagged filter in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-3177:
---
Attachment: SOLR-3177.patch
Removed grouping code from
org.apache.solr.handler.component.SimpleStats#parseParams.
Grouping functionality in stats need ticket to address it separately.
> Excluding tagged filter in StatsComponent
> -
>
> Key: SOLR-3177
> URL: https://issues.apache.org/jira/browse/SOLR-3177
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Affects Versions: 3.5, 3.6, 4.0-ALPHA, 4.1
>Reporter: Mathias H.
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Labels: localparams, stats, statscomponent
> Attachments: SOLR-3177.patch, SOLR-3177.patch, SOLR-3177.patch
>
>
> It would be useful to exclude the effects of some "fq" params from the set of
> documents used to compute stats -- similar to
> how you can exclude tagged filters when generating facet counts...
> https://wiki.apache.org/solr/SimpleFacetParameters#Tagging_and_excluding_Filters
> So that it's possible to do something like this...
> http://localhost:8983/solr/select?fq={!tag=priceFilter}price:[1 TO
> 20]q=*:*&stats=true&stats.field={!ex=priceFilter}price
> If you want to create a price slider this is very useful because then you can
> filter the price ([1 TO 20) and nevertheless get the lower and upper bound of
> the unfiltered price (min=0, max=100):
> {noformat}
> |<-[---]-->|
> $0 $1 $20$100
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1604: --- Attachment: SOLR-1604.patch I mean 2 things: 1. Put plug-in sources in Solr codebase (not like separate lib jar) 2. Make org.apache.solr.search.ComplexPhraseQParserPlugin as built-in standard plug-ins Added patch fixing name:jo* issue with highlighter. Tests in org.apache.solr.search.ComplexPhraseQParserPluginTest uncommented and passing. > Wildcards, ORs etc inside Phrase Queries > > > Key: SOLR-1604 > URL: https://issues.apache.org/jira/browse/SOLR-1604 > Project: Solr > Issue Type: Improvement > Components: query parsers, search >Affects Versions: 1.4 >Reporter: Ahmet Arslan >Assignee: Erick Erickson >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, > ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, > ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, > ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, > SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, > SOLR-1604.patch, SOLR-1604.patch > > > Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports > wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1604) Wildcards, ORs etc inside Phrase Queries
[ https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1604: --- Attachment: SOLR-1604.patch Probably it make sense to base plug-in on solr sources. Attached patch contains: org.apache.lucene.queryparser.classic.ComplexPhraseQueryParser and org.apache.solr.search.ComplexPhraseQParserPlugin in solr and lucene sources respectively. Made some code cleanup. Added tests on lucene side for org.apache.lucene.queryparser.classic.ComplexPhraseQueryParser. Renamed test resources for solr plugin test. I continue working on name:jo* prefix query issue when Highlighter return empty string instead of highlight matched term (TODO added). > Wildcards, ORs etc inside Phrase Queries > > > Key: SOLR-1604 > URL: https://issues.apache.org/jira/browse/SOLR-1604 > Project: Solr > Issue Type: Improvement > Components: query parsers, search >Affects Versions: 1.4 >Reporter: Ahmet Arslan >Assignee: Erick Erickson >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, > ComplexPhrase-4.2.1.zip, ComplexPhrase-4.7.zip, ComplexPhrase.zip, > ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, > ComplexPhrase.zip, ComplexPhraseQueryParser.java, ComplexPhrase_solr_3.4.zip, > SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch, SOLR-1604.patch > > > Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports > wildcards, ORs, ranges, fuzzies inside phrase queries. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1632: --- Attachment: SOLR-1632.patch Updated to latest trunk. Cleaned code duplicates. Fixed org.apache.solr.search.stats.TestLRUStatsCache, added test for org.apache.solr.search.stats.ExactSharedStatsCache. Fixed javadocs. > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 4.7, 5.0 > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, distrib-2.patch, > distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-3218: --- Attachment: SOLR-3218.patch Fixed some javadocs > Range faceting support for CurrencyField > > > Key: SOLR-3218 > URL: https://issues.apache.org/jira/browse/SOLR-3218 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Jan Høydahl > Fix For: 4.7 > > Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, > SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch > > > Spinoff from SOLR-2202. Need to add range faceting capabilities for > CurrencyField -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5466) Add List Collections functionality to Collections API
[ https://issues.apache.org/jira/browse/SOLR-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5466: --- Attachment: SOLR-5466.patch Added STATUS operation for collection, for specific collection by collection parameter, for specific collection and shard (comma separated shard parameter), all properties retrieved from cluster state without request to ZK host. Collection status action is similar to core admin STATUS call. I left LISTCOLLECTIONS action as is cause user should have an option wheather to get collection status from cluster state or from ZK host directly. > Add List Collections functionality to Collections API > - > > Key: SOLR-5466 > URL: https://issues.apache.org/jira/browse/SOLR-5466 > Project: Solr > Issue Type: Sub-task > Components: scripts and tools, SolrCloud > Environment: All >Reporter: Dave Seltzer >Assignee: Shalin Shekhar Mangar >Priority: Minor > Labels: api, collections, rest > Attachments: SOLR-5466.patch, SOLR-5466.patch > > > The collections API lets you add, delete and modify existing collections. At > the moment the API does not let you get a list of current collections or view > information about a specific collection. > The workaround is the use the Zookeeper API to get the list. This makes the > Collections API harder to work with. > Adding an action=LIST would significantly improve the function of this API. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3177) Excluding tagged filter in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-3177:
---
Attachment: SOLR-3177.patch
Updated to latest trunk. Fixed StatsComponent to pass tests.
> Excluding tagged filter in StatsComponent
> -
>
> Key: SOLR-3177
> URL: https://issues.apache.org/jira/browse/SOLR-3177
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Affects Versions: 3.5, 3.6, 4.0-ALPHA, 4.1
>Reporter: Mathias H.
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Labels: localparams, stats, statscomponent
> Attachments: SOLR-3177.patch, SOLR-3177.patch
>
>
> It would be useful to exclude the effects of some "fq" params from the set of
> documents used to compute stats -- similar to
> how you can exclude tagged filters when generating facet counts...
> https://wiki.apache.org/solr/SimpleFacetParameters#Tagging_and_excluding_Filters
> So that it's possible to do something like this...
> http://localhost:8983/solr/select?fq={!tag=priceFilter}price:[1 TO
> 20]q=*:*&stats=true&stats.field={!ex=priceFilter}price
> If you want to create a price slider this is very useful because then you can
> filter the price ([1 TO 20) and nevertheless get the lower and upper bound of
> the unfiltered price (min=0, max=100):
> {noformat}
> |<-[---]-->|
> $0 $1 $20$100
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2908) To push the terms.limit parameter from the master core to all the shard cores.
[
https://issues.apache.org/jira/browse/SOLR-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-2908:
---
Attachment: SOLR-2908.patch
if you want to override only limit passed to shards, other params also should
not be passed,{code}sreq.params.set(TermsParams.TERMS_SORT,
TermsParams.TERMS_SORT_INDEX);
sreq.params.set(TermsParams.TERMS_LIMIT, -1);
sreq.params.remove(TermsParams.TERMS_MAXCOUNT);
sreq.params.remove(TermsParams.TERMS_MINCOUNT);{code} otherwise
completely wrong (unsorted) terms will be limited and passed from shard.
Please see attached patch illustrating this idea, by adding
'shards.terms.limit' parameter.
Note that problem with inconsistent results still exists, but this can be
minimized with combining terms.limit and shards.terms.limit like in
org.apache.solr.handler.component.DistributedTermsComponentParametersTest.
> To push the terms.limit parameter from the master core to all the shard cores.
> --
>
> Key: SOLR-2908
> URL: https://issues.apache.org/jira/browse/SOLR-2908
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Affects Versions: 1.4.1
> Environment: Linux server. 64 bit processor and 16GB Ram.
>Reporter: sivaganesh
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Labels: patch
> Fix For: 4.7
>
> Attachments: SOLR-2908.patch, SOLR-2908.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> When we pass the terms.limit parameter to the master (which has many shard
> cores), it's not getting pushed down to the individual cores. Instead the
> default value of -1 is assigned to Terms.limit parameter is assigned in the
> underlying shard cores. The issue being the time taken by the Master core to
> return the required limit of terms is higher when we are having more number
> of underlying shard cores. This affects the performances of the auto suggest
> feature.
> Can thought we can have a parameter to explicitly override the -1 being set
> to Terms.limit in shards core.
> We saw the source code(TermsComponent.java) and concluded that the same.
> Please help us in pushing the terms.limit parameter to shard cores.
> PFB code snippet.
> private ShardRequest createShardQuery(SolrParams params) {
> ShardRequest sreq = new ShardRequest();
> sreq.purpose = ShardRequest.PURPOSE_GET_TERMS;
> // base shard request on original parameters
> sreq.params = new ModifiableSolrParams(params);
> // remove any limits for shards, we want them to return all possible
> // responses
> // we want this so we can calculate the correct counts
> // dont sort by count to avoid that unnecessary overhead on the shards
> sreq.params.remove(TermsParams.TERMS_MAXCOUNT);
> sreq.params.remove(TermsParams.TERMS_MINCOUNT);
> sreq.params.set(TermsParams.TERMS_LIMIT, -1);
> sreq.params.set(TermsParams.TERMS_SORT, TermsParams.TERMS_SORT_INDEX);
> return sreq;
> }
> Solr Version:
> Solr Specification Version: 1.4.0.2010.01.13.08.09.44
> Solr Implementation Version: 1.5-dev exported - yonik - 2010-01-13 08:09:44
> Lucene Specification Version: 2.9.1-dev
> Lucene Implementation Version: 2.9.1-dev 888785 - 2009-12-09 18:03:31
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1880) Performance: Distributed Search should skip GET_FIELDS stage if EXECUTE_QUERY stage gets all fields
[ https://issues.apache.org/jira/browse/SOLR-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905530#comment-13905530 ] Vitaliy Zhovtyuk commented on SOLR-1880: Yes, this optimization will work in case fl=id,score only > Performance: Distributed Search should skip GET_FIELDS stage if EXECUTE_QUERY > stage gets all fields > --- > > Key: SOLR-1880 > URL: https://issues.apache.org/jira/browse/SOLR-1880 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Shawn Smith >Assignee: Shalin Shekhar Mangar > Attachments: ASF.LICENSE.NOT.GRANTED--one-pass-query-v1.4.0.patch, > ASF.LICENSE.NOT.GRANTED--one-pass-query.patch, SOLR-1880.patch > > > Right now, a typical distributed search using QueryComponent makes two HTTP > requests to each shard: > # STAGE_EXECUTE_QUERY executes one HTTP request to each shard to get top N > ids and sort keys, merges the results to produce a final list of document IDs > (PURPOSE_GET_TOP_IDS). > # STAGE_GET_FIELDS executes a second HTTP request to each shard to get the > document field values for the final list of document IDs (PURPOSE_GET_FIELDS). > If the "fl" param is just "id" or just "id,score", all document data to > return is already fetched by STAGE_EXECUTE_QUERY. The second > STAGE_GET_FIELDS query is completely unnecessary. Eliminating that 2nd HTTP > request can make a big difference in overall performance. > Also, the "fl" param only gets id, score and sort columns, it would probably > be cheaper to fetch the final sort column data in STAGE_EXECUTE_QUERY which > has to read the sort column data anyway, and skip STAGE_GET_FIELDS. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1880) Performance: Distributed Search should skip GET_FIELDS stage if EXECUTE_QUERY stage gets all fields
[ https://issues.apache.org/jira/browse/SOLR-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-1880: --- Attachment: SOLR-1880.patch Updated to latest trunk. Added functional distributed test org.apache.solr.handler.component.DistributedQueryComponentOptimizationTest for one step pass. Added trace to return error reason in org.apache.solr.client.solrj.impl.HttpSolrServer, otherwise runtime errors hard to detect. > Performance: Distributed Search should skip GET_FIELDS stage if EXECUTE_QUERY > stage gets all fields > --- > > Key: SOLR-1880 > URL: https://issues.apache.org/jira/browse/SOLR-1880 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Shawn Smith > Attachments: ASF.LICENSE.NOT.GRANTED--one-pass-query-v1.4.0.patch, > ASF.LICENSE.NOT.GRANTED--one-pass-query.patch, SOLR-1880.patch > > > Right now, a typical distributed search using QueryComponent makes two HTTP > requests to each shard: > # STAGE_EXECUTE_QUERY executes one HTTP request to each shard to get top N > ids and sort keys, merges the results to produce a final list of document IDs > (PURPOSE_GET_TOP_IDS). > # STAGE_GET_FIELDS executes a second HTTP request to each shard to get the > document field values for the final list of document IDs (PURPOSE_GET_FIELDS). > If the "fl" param is just "id" or just "id,score", all document data to > return is already fetched by STAGE_EXECUTE_QUERY. The second > STAGE_GET_FIELDS query is completely unnecessary. Eliminating that 2nd HTTP > request can make a big difference in overall performance. > Also, the "fl" param only gets id, score and sort columns, it would probably > be cheaper to fetch the final sort column data in STAGE_EXECUTE_QUERY which > has to read the sort column data anyway, and skip STAGE_GET_FIELDS. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1913) QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations on Integer Fields
[
https://issues.apache.org/jira/browse/SOLR-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-1913:
---
Attachment: SOLR-1913.patch
Changed packages for BitwiseFIlter: org.apache.lucene.search.BitwiseFilter,
for BitwiseQueryParserPlugin: org.apache.solr.search.BitwiseQueryParserPlugin.
Added Lucene tests for BitwiseFilter, added Solr tests checking bitwise parser
queries for BitwiseQueryParserPlugin.
> QParserPlugin plugin for Search Results Filtering Based on Bitwise Operations
> on Integer Fields
> ---
>
> Key: SOLR-1913
> URL: https://issues.apache.org/jira/browse/SOLR-1913
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Israel Ekpo
> Fix For: 4.7
>
> Attachments: SOLR-1913-src.tar.gz, SOLR-1913.bitwise.tar.gz,
> SOLR-1913.patch, WEB-INF lib.jpg, bitwise_filter_plugin.jar,
> solr-bitwise-plugin.jar
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> BitwiseQueryParserPlugin is a org.apache.solr.search.QParserPlugin that
> allows
> users to filter the documents returned from a query
> by performing bitwise operations between a particular integer field in the
> index
> and the specified value.
> This Solr plugin is based on the BitwiseFilter in LUCENE-2460
> See https://issues.apache.org/jira/browse/LUCENE-2460 for more details
> This is the syntax for searching in Solr:
> http://localhost:8983/path/to/solr/select/?q={!bitwise field=fieldname
> op=OPERATION_NAME source=sourcevalue negate=boolean}remainder of query
> Example :
> http://localhost:8983/solr/bitwise/select/?q={!bitwise field=user_permissions
> op=AND source=3 negate=true}state:FL
> The negate parameter is optional
> The field parameter is the name of the integer field
> The op parameter is the name of the operation; one of {AND, OR, XOR}
> The source parameter is the specified integer value
> The negate parameter is a boolean indicating whether or not to negate the
> results of the bitwise operation
> To test out this plugin, simply copy the jar file containing the plugin
> classes into your $SOLR_HOME/lib directory and then
> add the following to your solrconfig.xml file after the dismax request
> handler:
> class="org.apache.solr.bitwise.BitwiseQueryParserPlugin" basedOn="dismax" />
> Restart your servlet container.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-3218: --- Attachment: SOLR-3218.patch Updated to latest trunk. Added range facet tests to org.apache.solr.schema.AbstractCurrencyFieldTest, Moved org.apache.solr.schema.CurrencyValue back to separate class from nested class org.apache.solr.schema.CurrencyField since CurrencyValue used outside in org.apache.solr.request.SimpleFacets and other classes. Probably worth for wrap and encapsulate in org.apache.solr.schema.CurrencyField > Range faceting support for CurrencyField > > > Key: SOLR-3218 > URL: https://issues.apache.org/jira/browse/SOLR-3218 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Jan Høydahl > Fix For: 4.7 > > Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, > SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch > > > Spinoff from SOLR-2202. Need to add range faceting capabilities for > CurrencyField -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2908) To push the terms.limit parameter from the master core to all the shard cores.
[
https://issues.apache.org/jira/browse/SOLR-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-2908:
---
Attachment: SOLR-2908.patch
If you limit terms number you'd need to pass at least sorting to shard in order
to get most relevant terms (if needed).
Added shards.terms.params.override=true parameter, if terms parameters
(terms.limit, terms.sort, terms.maxcount, terms.mincount) should be passed to
shards.
Using this parameter with terms.sort=index (no sorting) is ok, but using
shards.terms.params.override with terms.sort=count can lead to inconsistent
results with single core.
See org.apache.solr.handler.component.DistributedTermsComponentParametersTest.
For example, we use
{code}shards.terms.params.override=true&terms.limit=5&terms.sort=count{code}
and data
{code}index(id, 18, "b_t", "snake spider shark snail slug seal");
index(id, 19, "b_t", "snake spider shark snail slug");
index(id, 20, "b_t", "snake spider shark snail");
index(id, 21, "b_t", "snake spider shark");
index(id, 22, "b_t", "snake spider");
index(id, 23, "b_t", "snake");
index(id, 24, "b_t", "ant zebra");
index(id, 25, "b_t", "zebra");
{code}
WIth single core results will be like
{code}snake=6 spider=5 shark=4 snail=3 slug=2{code}
For 2shards results will be like
shard 1: {code} snake=3 spider=3 shark=2 snail=2 ant=1 {code}
shard 2: {code} snake=3 spider=2 shark=2 seal=1 slug=1 {code}
Combined result: {code} snake=6 spider=5 shark=4 snail=2 ant=1 {code}
I suggest this parameter override will be useful with sorting and custom
routing, in case that same terms located on the same shard,
sorted and limited there correctly.
> To push the terms.limit parameter from the master core to all the shard cores.
> --
>
> Key: SOLR-2908
> URL: https://issues.apache.org/jira/browse/SOLR-2908
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
>Affects Versions: 1.4.1
> Environment: Linux server. 64 bit processor and 16GB Ram.
>Reporter: sivaganesh
>Priority: Critical
> Labels: patch
> Fix For: 4.7
>
> Attachments: SOLR-2908.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> When we pass the terms.limit parameter to the master (which has many shard
> cores), it's not getting pushed down to the individual cores. Instead the
> default value of -1 is assigned to Terms.limit parameter is assigned in the
> underlying shard cores. The issue being the time taken by the Master core to
> return the required limit of terms is higher when we are having more number
> of underlying shard cores. This affects the performances of the auto suggest
> feature.
> Can thought we can have a parameter to explicitly override the -1 being set
> to Terms.limit in shards core.
> We saw the source code(TermsComponent.java) and concluded that the same.
> Please help us in pushing the terms.limit parameter to shard cores.
> PFB code snippet.
> private ShardRequest createShardQuery(SolrParams params) {
> ShardRequest sreq = new ShardRequest();
> sreq.purpose = ShardRequest.PURPOSE_GET_TERMS;
> // base shard request on original parameters
> sreq.params = new ModifiableSolrParams(params);
> // remove any limits for shards, we want them to return all possible
> // responses
> // we want this so we can calculate the correct counts
> // dont sort by count to avoid that unnecessary overhead on the shards
> sreq.params.remove(TermsParams.TERMS_MAXCOUNT);
> sreq.params.remove(TermsParams.TERMS_MINCOUNT);
> sreq.params.set(TermsParams.TERMS_LIMIT, -1);
> sreq.params.set(TermsParams.TERMS_SORT, TermsParams.TERMS_SORT_INDEX);
> return sreq;
> }
> Solr Version:
> Solr Specification Version: 1.4.0.2010.01.13.08.09.44
> Solr Implementation Version: 1.5-dev exported - yonik - 2010-01-13 08:09:44
> Lucene Specification Version: 2.9.1-dev
> Lucene Implementation Version: 2.9.1-dev 888785 - 2009-12-09 18:03:31
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5257) confusing warning logged when unexpected xml attributes are found
[
https://issues.apache.org/jira/browse/SOLR-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5257:
---
Attachment: SOLR-5257.patch
Fixed warning messages
I have not added TODOs, but few if's in this class can be replaced with switch
for clarity: starting at lines 221, 233, 299
Maybe improve this in future.
> confusing warning logged when unexpected xml attributes are found
> -
>
> Key: SOLR-5257
> URL: https://issues.apache.org/jira/browse/SOLR-5257
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Minor
> Attachments: SOLR-5257.patch
>
>
> Brian Robinson on the solr-user list got really confused by this warning
> message...
> {{Unknown attribute id in add:allowDups}}
> ...the mention of "id" in that warning was a big red herring that led him to
> assume something was wrong with the "id" in his documents, because it's not
> at all clear that's refering to the "xml node id" of an unexpected "xml
> attribute" (which in this case is "allowDups")
> filing this issue so i remembe to fix this warning to be more helpful, and
> review the rest of the file while i'm at it for other confusing warnings.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5561) DefaultSimilarity 'init' method is not called, if the similarity plugin is not explicitly declared in the schema
[ https://issues.apache.org/jira/browse/SOLR-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5561: --- Attachment: SOLR-5561.patch Added changes to IndexSchema Added IndexSchema tests checking discountOverlaps depending on luceneMatchVersion > DefaultSimilarity 'init' method is not called, if the similarity plugin is > not explicitly declared in the schema > > > Key: SOLR-5561 > URL: https://issues.apache.org/jira/browse/SOLR-5561 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 4.6 >Reporter: Isaac Hebsh > Labels: similarity > Fix For: 4.7, 4.6.1 > > Attachments: SOLR-5561.patch, SOLR-5561.patch, SOLR-5561.patch > > > As a result, discountOverlap is not initialized to true, and the default > behavior is that multiple terms on the same position DO affect the fieldNorm. > this is not the intended default. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5589) Disabled replication in config is ignored
[ https://issues.apache.org/jira/browse/SOLR-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885556#comment-13885556 ] Vitaliy Zhovtyuk commented on SOLR-5589: Lets consider the following config: commit schema.xml false http://127.0.0.1:TEST_PORT/solr 00:00:01 COMPRESSION Slave is disabled, but master can be used to replicate to separate Solr instance. Therefore i think it's only make sense to disable replication when both master and slave explicitly disabled. And i think it will not have side effects with replication when slave is disabled for some reason, but master is replication to separate instance. > Disabled replication in config is ignored > - > > Key: SOLR-5589 > URL: https://issues.apache.org/jira/browse/SOLR-5589 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.5 >Reporter: alexey >Assignee: Shalin Shekhar Mangar > Fix For: 4.7 > > Attachments: SOLR-5589.patch, SOLR-5589.patch, SOLR-5589.patch, > SOLR-5589.patch > > > When replication on master node is explicitly disabled in config, it is still > enabled after start. This is because when both master and slave > configurations are written with enabled=false, replication handler considers > this node is a master and enables it. With proposed patch handler will > consider this as master node but will disable replication on startup if it is > disabled in config (equivalent to disablereplication command). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5589) Disabled replication in config is ignored
[ https://issues.apache.org/jira/browse/SOLR-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5589: --- Attachment: SOLR-5589.patch Master and slave considered as disabled in 3cases: not configured master/slave, configured but missing "enable" parameter on master/slave, explicitly defined enable=false on master/slave. In all 3cases when master and slave disabled only default value for non-configured ReplicationHandler is master and replicateOnCommit. Since we disable replication in this case (not configured master and slave or omitted enable config) replication stops working. This is the reason of those tests failure (master and replication expected when handler configuration omitted). I propose to disable replication only in case of explicitly defined enable=false for master and slave. Attached patch illustrate the idea. > Disabled replication in config is ignored > - > > Key: SOLR-5589 > URL: https://issues.apache.org/jira/browse/SOLR-5589 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.5 >Reporter: alexey >Assignee: Shalin Shekhar Mangar > Fix For: 4.7 > > Attachments: SOLR-5589.patch, SOLR-5589.patch, SOLR-5589.patch, > SOLR-5589.patch > > > When replication on master node is explicitly disabled in config, it is still > enabled after start. This is because when both master and slave > configurations are written with enabled=false, replication handler considers > this node is a master and enables it. With proposed patch handler will > consider this as master node but will disable replication on startup if it is > disabled in config (equivalent to disablereplication command). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5530) SolrJ NoOpResponseParser
[
https://issues.apache.org/jira/browse/SOLR-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5530:
---
Attachment: SOLR-5530.patch
Added comments to org.apache.solr.client.solrj.impl.NoOpResponseParser
Added Tests checking NoOpResponseParser
Added test demonstrating how to use NoOpResponseParser in order to construct
query
> SolrJ NoOpResponseParser
>
>
> Key: SOLR-5530
> URL: https://issues.apache.org/jira/browse/SOLR-5530
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Reporter: Upayavira
>Priority: Minor
> Attachments: PATCH-5530.txt, SOLR-5530.patch
>
>
> If you want the raw response string out of SolrJ, the advice seems to be to
> just use an HttpClient directly.
> However, sometimes you may have a lot of SolrJ infrastructure already in
> place to build out queries, etc, so it would be much simpler to just use
> SolrJ to do the work.
> This patch offers a NoOpResponseParser, which simply puts the entire response
> into an entry in a NamedList.
> Because the response isn't parsed into a QueryResponse, usage is slightly
> different:
> HttpSolrServer server = new HttpSolrServer("http://localhost:8983/solr";);
> SolrQuery query = new SolrQuery("*:*");
> QueryRequest req = new QueryRequest(query);
> server.setParser(new NoOpResponseParser());
> NamedList resp = server.request(req);
> String responseString = resp.get("response");
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5589) Disabled replication in config is ignored
[ https://issues.apache.org/jira/browse/SOLR-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5589: --- Attachment: SOLR-5589.patch Added ReplicationHandler tests and configuration. ReplicationHandler state tested by details request (http://slave_host:port/solr/replication?command=details) and by getting handler statistic. > Disabled replication in config is ignored > - > > Key: SOLR-5589 > URL: https://issues.apache.org/jira/browse/SOLR-5589 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.5 >Reporter: alexey > Fix For: 4.7 > > Attachments: SOLR-5589.patch, SOLR-5589.patch > > > When replication on master node is explicitly disabled in config, it is still > enabled after start. This is because when both master and slave > configurations are written with enabled=false, replication handler considers > this node is a master and enables it. With proposed patch handler will > consider this as master node but will disable replication on startup if it is > disabled in config (equivalent to disablereplication command). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: SOLR-5526.patch
minor fixes:
{quote} QParserPlugin.standardPlugins's javadoc needs to point out the
importance of these names being static & final so people aren't surprised by
these tests when new parsers are added in the future.{quote}
Added relevant javadocs.
{quote}
TestStandardQParsers is doing something sufficiently odd that it really needs
some javadocs explaining why it exists (ie: mention the class loading problems
associated if there is a standardPlugin that has a non-static, non-final name,
with an {{@see}} this issue, {{@see QParserPlugin.standardPlugins}},
etc...){quote}
Added javadocs
{quote} we should probably make TestStandardQParsers assert that the static &
final name it finds in each class matches the name associated in
QParserPlugin.standardPlugins.{quote}
Thats actually what TestStandardQParsers does. Unit test takes classes
registered in QParserPlugin.standardPlugins and ensure that each class has
final and static NAME field.
Added relevant javadocs to TestStandardQParsers.
{quote} solrconfig-query-parser-init.xml has a cut & paste comment referring to
an unrelated test.{quote}
Fixed, added relevant comments.
{quote} TestInitQParser should have a javadoc comment explaining what the point
of the test is{quote}
Fixed, added relevant comments.
{quote}TestInitQParser should actaully do a query using the "fail" parser
registered in the config, to help future-proof us against someone unwittingly
changing the test config in a way that defeats the point of the test.{quote}
This test alerady does query using defType=fail, so i expect this registered
QParser used and return result.
> Query parser extends standard cause NPE on Solr startup
> ---
>
> Key: SOLR-5526
> URL: https://issues.apache.org/jira/browse/SOLR-5526
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.5.1, 4.6, 5.0
> Environment: Linux, Java 1.7.0_45
>Reporter: Nikolay Khitrin
>Priority: Blocker
> Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
> SOLR-5526-final-names.patch, SOLR-5526-tests.patch, SOLR-5526.patch,
> SOLR-5526.patch, SOLR-5526.patch
>
>
> Adding any custom query parser extending standard one with non-final field
> {{NAME}} lead to messy {{NullPointerException}} during Solr startup.
> Definition of standard parsers is located in
> {{QParserPlugin.standardPlugins}} static array. The array contains names from
> static {{NAME}} fields and classes for each plugin.
> But all of listed parsers are derived from {{QParserPlugin}}, so we have
> circular dependency of static fields.
> Normally, class loader start initializing {{QParserPlugin}} before all listed
> plugins in {{SolrCore.initQParsers}}, and array elements referenced to
> {{NAME}} plugins' fields are filled properly.
> Custom parsers are instantiated before standard parsers. And when we subclass
> plugin with non-final {{NAME}} field and add it to Solr via
> {{solrconfig.xml}}, class loader start loading our class before
> {{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
> must be initialized before subclasses, and static dereferencing cause null
> elements in {{standardPlugins}} array because it filled before {{NAME}} field
> of loading plugin's superclass.
> How to reproduce:
> # Checkout Solr (trunk or stable)
> # Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
> {{}}
> # Call ant run-example in solr folder
> Possible workarounds:
> * dev-workaround: add {{int workaround =
> QParserPlugin.standardPlugins.length;}} as a first line to
> {{SolrCore.initQParsers}}
> * user-workaround: add plugin with final {{NAME}} field (edismax) to
> solrconfig.xml before subclasses of standard plugins.
> {{ class="solr.search.ExtendedDismaxQParserPlugin"/>}}
>
> Possible fix:
> Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields
[
https://issues.apache.org/jira/browse/SOLR-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5598:
---
Attachment: SOLR-5598.patch
Added content logging in case of non-string value
Added test for multivalue field with 1st value as empty string
Added test for multivalue field with values in 2languages (most en). resolved
as en.
> LanguageIdentifierUpdateProcessor ignores all but the first value of
> multiValued string fields
> --
>
> Key: SOLR-5598
> URL: https://issues.apache.org/jira/browse/SOLR-5598
> Project: Solr
> Issue Type: Bug
> Components: contrib - LangId
>Affects Versions: 4.5.1
>Reporter: Andreas Hubold
> Fix For: 4.7
>
> Attachments: SOLR-5598.patch, SOLR-5598.patch
>
>
> The LanguageIdentifierUpdateProcessor just uses the first value of the
> multiValued field to detect the language.
> Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should
> instead iterate over {{doc.getFieldValues(fieldName)}}.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: SOLR-5526.patch
Combined:
Missed final NAME field fixes.
Test reproducing NPE on Solr start-up
Test checking final and static NAME field for all standard parsers
> Query parser extends standard cause NPE on Solr startup
> ---
>
> Key: SOLR-5526
> URL: https://issues.apache.org/jira/browse/SOLR-5526
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.5.1, 4.6, 5.0
> Environment: Linux, Java 1.7.0_45
>Reporter: Nikolay Khitrin
>Priority: Blocker
> Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
> SOLR-5526-final-names.patch, SOLR-5526-tests.patch, SOLR-5526.patch,
> SOLR-5526.patch
>
>
> Adding any custom query parser extending standard one with non-final field
> {{NAME}} lead to messy {{NullPointerException}} during Solr startup.
> Definition of standard parsers is located in
> {{QParserPlugin.standardPlugins}} static array. The array contains names from
> static {{NAME}} fields and classes for each plugin.
> But all of listed parsers are derived from {{QParserPlugin}}, so we have
> circular dependency of static fields.
> Normally, class loader start initializing {{QParserPlugin}} before all listed
> plugins in {{SolrCore.initQParsers}}, and array elements referenced to
> {{NAME}} plugins' fields are filled properly.
> Custom parsers are instantiated before standard parsers. And when we subclass
> plugin with non-final {{NAME}} field and add it to Solr via
> {{solrconfig.xml}}, class loader start loading our class before
> {{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
> must be initialized before subclasses, and static dereferencing cause null
> elements in {{standardPlugins}} array because it filled before {{NAME}} field
> of loading plugin's superclass.
> How to reproduce:
> # Checkout Solr (trunk or stable)
> # Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
> {{}}
> # Call ant run-example in solr folder
> Possible workarounds:
> * dev-workaround: add {{int workaround =
> QParserPlugin.standardPlugins.length;}} as a first line to
> {{SolrCore.initQParsers}}
> * user-workaround: add plugin with final {{NAME}} field (edismax) to
> solrconfig.xml before subclasses of standard plugins.
> {{ class="solr.search.ExtendedDismaxQParserPlugin"/>}}
>
> Possible fix:
> Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: SOLR-5526-tests.patch
Test reproducing NPE on Solr start-up
Test checking final and static NAME field for all standard parsers
> Query parser extends standard cause NPE on Solr startup
> ---
>
> Key: SOLR-5526
> URL: https://issues.apache.org/jira/browse/SOLR-5526
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.5.1, 4.6, 5.0
> Environment: Linux, Java 1.7.0_45
>Reporter: Nikolay Khitrin
>Priority: Blocker
> Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
> SOLR-5526-final-names.patch, SOLR-5526-tests.patch, SOLR-5526.patch
>
>
> Adding any custom query parser extending standard one with non-final field
> {{NAME}} lead to messy {{NullPointerException}} during Solr startup.
> Definition of standard parsers is located in
> {{QParserPlugin.standardPlugins}} static array. The array contains names from
> static {{NAME}} fields and classes for each plugin.
> But all of listed parsers are derived from {{QParserPlugin}}, so we have
> circular dependency of static fields.
> Normally, class loader start initializing {{QParserPlugin}} before all listed
> plugins in {{SolrCore.initQParsers}}, and array elements referenced to
> {{NAME}} plugins' fields are filled properly.
> Custom parsers are instantiated before standard parsers. And when we subclass
> plugin with non-final {{NAME}} field and add it to Solr via
> {{solrconfig.xml}}, class loader start loading our class before
> {{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
> must be initialized before subclasses, and static dereferencing cause null
> elements in {{standardPlugins}} array because it filled before {{NAME}} field
> of loading plugin's superclass.
> How to reproduce:
> # Checkout Solr (trunk or stable)
> # Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
> {{}}
> # Call ant run-example in solr folder
> Possible workarounds:
> * dev-workaround: add {{int workaround =
> QParserPlugin.standardPlugins.length;}} as a first line to
> {{SolrCore.initQParsers}}
> * user-workaround: add plugin with final {{NAME}} field (edismax) to
> solrconfig.xml before subclasses of standard plugins.
> {{ class="solr.search.ExtendedDismaxQParserPlugin"/>}}
>
> Possible fix:
> Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: SOLR-5526-final-names.patch
Missed final NAME field in org.apache.solr.search.SimpleQParserPlugin. Fixed.
> Query parser extends standard cause NPE on Solr startup
> ---
>
> Key: SOLR-5526
> URL: https://issues.apache.org/jira/browse/SOLR-5526
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.5.1, 4.6, 5.0
> Environment: Linux, Java 1.7.0_45
>Reporter: Nikolay Khitrin
>Priority: Blocker
> Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
> SOLR-5526-final-names.patch, SOLR-5526.patch
>
>
> Adding any custom query parser extending standard one with non-final field
> {{NAME}} lead to messy {{NullPointerException}} during Solr startup.
> Definition of standard parsers is located in
> {{QParserPlugin.standardPlugins}} static array. The array contains names from
> static {{NAME}} fields and classes for each plugin.
> But all of listed parsers are derived from {{QParserPlugin}}, so we have
> circular dependency of static fields.
> Normally, class loader start initializing {{QParserPlugin}} before all listed
> plugins in {{SolrCore.initQParsers}}, and array elements referenced to
> {{NAME}} plugins' fields are filled properly.
> Custom parsers are instantiated before standard parsers. And when we subclass
> plugin with non-final {{NAME}} field and add it to Solr via
> {{solrconfig.xml}}, class loader start loading our class before
> {{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
> must be initialized before subclasses, and static dereferencing cause null
> elements in {{standardPlugins}} array because it filled before {{NAME}} field
> of loading plugin's superclass.
> How to reproduce:
> # Checkout Solr (trunk or stable)
> # Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
> {{}}
> # Call ant run-example in solr folder
> Possible workarounds:
> * dev-workaround: add {{int workaround =
> QParserPlugin.standardPlugins.length;}} as a first line to
> {{SolrCore.initQParsers}}
> * user-workaround: add plugin with final {{NAME}} field (edismax) to
> solrconfig.xml before subclasses of standard plugins.
> {{ class="solr.search.ExtendedDismaxQParserPlugin"/>}}
>
> Possible fix:
> Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: NPE_load_trace
NPE stacktrace during solr load
> Query parser extends standard cause NPE on Solr startup
> ---
>
> Key: SOLR-5526
> URL: https://issues.apache.org/jira/browse/SOLR-5526
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 4.5.1, 4.6, 5.0
> Environment: Linux, Java 1.7.0_45
>Reporter: Nikolay Khitrin
>Priority: Blocker
> Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
> SOLR-5526.patch
>
>
> Adding any custom query parser extending standard one with non-final field
> {{NAME}} lead to messy {{NullPointerException}} during Solr startup.
> Definition of standard parsers is located in
> {{QParserPlugin.standardPlugins}} static array. The array contains names from
> static {{NAME}} fields and classes for each plugin.
> But all of listed parsers are derived from {{QParserPlugin}}, so we have
> circular dependency of static fields.
> Normally, class loader start initializing {{QParserPlugin}} before all listed
> plugins in {{SolrCore.initQParsers}}, and array elements referenced to
> {{NAME}} plugins' fields are filled properly.
> Custom parsers are instantiated before standard parsers. And when we subclass
> plugin with non-final {{NAME}} field and add it to Solr via
> {{solrconfig.xml}}, class loader start loading our class before
> {{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
> must be initialized before subclasses, and static dereferencing cause null
> elements in {{standardPlugins}} array because it filled before {{NAME}} field
> of loading plugin's superclass.
> How to reproduce:
> # Checkout Solr (trunk or stable)
> # Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
> {{}}
> # Call ant run-example in solr folder
> Possible workarounds:
> * dev-workaround: add {{int workaround =
> QParserPlugin.standardPlugins.length;}} as a first line to
> {{SolrCore.initQParsers}}
> * user-workaround: add plugin with final {{NAME}} field (edismax) to
> solrconfig.xml before subclasses of standard plugins.
> {{ class="solr.search.ExtendedDismaxQParserPlugin"/>}}
>
> Possible fix:
> Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
