[jira] [Commented] (SOLR-10890) Parallel SQL - column not found error
[
https://issues.apache.org/jira/browse/SOLR-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049576#comment-16049576
]
Yury Kats commented on SOLR-10890:
--
Mail list discussion: http://markmail.org/message/vsxb726cdrhflst7
> Parallel SQL - column not found error
> -
>
> Key: SOLR-10890
> URL: https://issues.apache.org/jira/browse/SOLR-10890
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Parallel SQL
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Minor
>
> Parallel SQL throws "column not found" error when the query hits multiple
> shards and one of shard doesn't have any documents yet.
> Sample error
> ==
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT
> sr_sv_userFirstName as firstName, sr_sv_userLastName as lastName FROM
> collection1 ORDEr BY dv_sv_userLastName LIMIT 15' against JDBC connection
> 'jdbc:calcitesolr:'.\nError while executing SQL \"SELECT sr_sv_userFirstName
> as firstName, sr_sv_userLastName as lastName FROM collection1 ORDEr BY
> dv_sv_userLastName LIMIT 15\": From line 1, column 9 to line 1, column 27:
> Column 'sr_sv_userFirstName' not found in any
> table","EOF":true,"RESPONSE_TIME":87}]}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8847) SolrJ JDBC - Implement "Select *"
[
https://issues.apache.org/jira/browse/SOLR-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014628#comment-16014628
]
Yury Kats edited comment on SOLR-8847 at 5/17/17 6:59 PM:
--
"SELECT *" still does not work for queries without a LIMIT, even when all
fields in the schema are docValues.
The query fails with
{code}
java.io.IOException: score is not a valid field for unlimited queries
{code}
Since the user has no control over the "score" field, there is no way to make
this work for the end user.
was (Author: ykats):
"SELECT *" still does not work for queries without a LIMIT, even when all
fields in the schema as docValues.
The query fails with
{code}
java.io.IOException: score is not a valid field for unlimited queries
{code}
Since the user has no control over the "score" field, there is no way to make
this work for the end user.
> SolrJ JDBC - Implement "Select *"
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Trey Cahill
>Assignee: Kevin Risden
> Attachments: SOLR-8847.patch, SOLR-8847.patch
>
>
> The sql query "Select *" is commonly used, but currently all fields need to
> be specified. This can cause some troubles as "Select *" has been used to
> pull back column metadata in some JDBC clients.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8847) SolrJ JDBC - Implement "Select *"
[
https://issues.apache.org/jira/browse/SOLR-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014628#comment-16014628
]
Yury Kats commented on SOLR-8847:
-
"SELECT *" still does not work for queries without a LIMIT, even when all
fields in the schema as docValues.
The query fails with
{code}
java.io.IOException: score is not a valid field for unlimited queries
{code}
Since the user has no control over the "score" field, there is no way to make
this work for the end user.
> SolrJ JDBC - Implement "Select *"
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Affects Versions: 6.0
>Reporter: Trey Cahill
>Assignee: Kevin Risden
> Attachments: SOLR-8847.patch, SOLR-8847.patch
>
>
> The sql query "Select *" is commonly used, but currently all fields need to
> be specified. This can cause some troubles as "Select *" has been used to
> pull back column metadata in some JDBC clients.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10267) Solr SQL throws an error for collections with uppercase chars in name
[
https://issues.apache.org/jira/browse/SOLR-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905591#comment-15905591
]
Yury Kats commented on SOLR-10267:
--
This is a dup of SOLR-10260.
> Solr SQL throws an error for collections with uppercase chars in name
> -
>
> Key: SOLR-10267
> URL: https://issues.apache.org/jira/browse/SOLR-10267
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.3
>Reporter: Andy Tran
> Attachments: BestBuy.png
>
>
> Team, I did some tests on a local Solr v6.3 instance where the curl works for
> `default` but fails for `BestBuy` collection:
> ~> curl --data-urlencode 'stmt=SELECT count(*) FROM BestBuy'
> http://localhost:8983/solr/BestBuy/sql?aggregationMode=facet
> {"result-set":{"docs":[
> {"EXCEPTION":"org.apache.solr.common.SolrException: Collection not found:
> bestbuy","EOF":true,"RESPONSE_TIME":0}]}}
> ~> curl --data-urlencode 'stmt=SELECT count(*) FROM default'
> http://localhost:8983/solr/default/sql?aggregationMode=facet
> {"result-set":{"docs":[
> {"count(*)":224736},
> {"EOF":true,"RESPONSE_TIME":5}]}}
> Can someone confirm this bug and remedy? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2791) Replication: abortfetch is broken if replication was started by fetchindex
Replication: abortfetch is broken if replication was started by fetchindex -- Key: SOLR-2791 URL: https://issues.apache.org/jira/browse/SOLR-2791 Project: Solr Issue Type: Bug Components: Build Affects Versions: 4.0 Reporter: Yury Kats If I start replication by issuing a fetchindex command with a masterUrl parameter, it seems to me (by looking at the trunk code) that abortfetch command would not do anything. It appears to be aborting only when replication is configured with hardcoded master/slave cores. The fix appears to be to use tempSnapPuller.abortPull always because tempSnapPuller is always the snap puller doing the actual work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2791) Replication: abortfetch is broken if replication was started by fetchindex
[ https://issues.apache.org/jira/browse/SOLR-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2791: Attachment: SOLR-2791.patch patch Replication: abortfetch is broken if replication was started by fetchindex -- Key: SOLR-2791 URL: https://issues.apache.org/jira/browse/SOLR-2791 Project: Solr Issue Type: Bug Components: Build Affects Versions: 4.0 Reporter: Yury Kats Assignee: Shalin Shekhar Mangar Attachments: SOLR-2791.patch If I start replication by issuing a fetchindex command with a masterUrl parameter, it seems to me (by looking at the trunk code) that abortfetch command would not do anything. It appears to be aborting only when replication is configured with hardcoded master/slave cores. The fix appears to be to use tempSnapPuller.abortPull always because tempSnapPuller is always the snap puller doing the actual work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
[ https://issues.apache.org/jira/browse/SOLR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095318#comment-13095318 ] Yury Kats commented on SOLR-2675: - Wiki updated. Support core properties when creating cores via REST API (CoreAdminHandler) --- Key: SOLR-2675 URL: https://issues.apache.org/jira/browse/SOLR-2675 Project: Solr Issue Type: Improvement Components: multicore Reporter: Yury Kats Assignee: Hoss Man Fix For: 3.4, 4.0 Attachments: SOLR-2675.patch, coreadmin.patch When crating cores through solr.xml, I am able to specify custom properties, to be referenced in solrconfig.xml. For example: cores adminPath=/admin/cores defaultCoreName=master core name=master instanceDir=core1 shard=shard1 collection=myconf property name=enable.master value=true / /core core name=slave instanceDir=core2 shard=shard2 collection=myconf property name=enable.slave value=true / property name=masterHost value=node2:8983 / /core /cores There does not seem a way to specify such properties when creating cores through the CoreAdminHandler request. CoreAdminHandler#handleCreateAction always calls dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
[ https://issues.apache.org/jira/browse/SOLR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092843#comment-13092843 ] Yury Kats commented on SOLR-2675: - Sorry, for the delay, just back from internet-free vacation. Thanks for accepting the patch! I'll update the wiki. Support core properties when creating cores via REST API (CoreAdminHandler) --- Key: SOLR-2675 URL: https://issues.apache.org/jira/browse/SOLR-2675 Project: Solr Issue Type: Improvement Components: multicore Reporter: Yury Kats Assignee: Hoss Man Fix For: 3.4, 4.0 Attachments: SOLR-2675.patch, coreadmin.patch When crating cores through solr.xml, I am able to specify custom properties, to be referenced in solrconfig.xml. For example: cores adminPath=/admin/cores defaultCoreName=master core name=master instanceDir=core1 shard=shard1 collection=myconf property name=enable.master value=true / /core core name=slave instanceDir=core2 shard=shard2 collection=myconf property name=enable.slave value=true / property name=masterHost value=node2:8983 / /core /cores There does not seem a way to specify such properties when creating cores through the CoreAdminHandler request. CoreAdminHandler#handleCreateAction always calls dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2326) Replication command indexversion fails to return index version
[ https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082360#comment-13082360 ] Yury Kats commented on SOLR-2326: - OK, after some troubleshooting, my case is more obscure, but exposes the same problem. I have a master core with an index. Replication is configured after startup and after commit. I start Solr and ReplicationHandler reports correct information. indexversion is non-zero and details shows me a filelist for a specific index generation. All is well, replication is running fine. Now, my application RELOADs the master core (either by using /admin/cores?action=RELOAD or by using action=CREATE to recreate the same core in the same place. In both cases the index is preserved). Once the core is RELOADed, replication details still shows correct indexversion and generation, but the filelist is gone. And once a new commit happens on the RELOADed core, indexversion command starts reporting zero and never recovers. Therefore replication stops for good. The only way to make it replicate again is to restart Solr. Replication command indexversion fails to return index version -- Key: SOLR-2326 URL: https://issues.apache.org/jira/browse/SOLR-2326 Project: Solr Issue Type: Bug Components: replication (java) Environment: Branch 3x latest Reporter: Eric Pugh Assignee: Mark Miller Fix For: 3.4, 4.0 To test this, I took the /example/multicore/core0 solrconfig and added a simple replication handler: requestHandler name=/replication class=solr.ReplicationHandler lst name=master str name=replicateAftercommit/str str name=replicateAfterstartup/str str name=confFilesschema.xml/str /lst /requestHandler When I query the handler for details I get back the indexVersion that I expect: http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true But when I ask for just the indexVersion I get back a 0, which prevent the slaves from pulling updates: http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2326) Replication command indexversion fails to return index version
[ https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082390#comment-13082390 ] Yury Kats commented on SOLR-2326: - Could ReplicationHandler be holding on to a stale core instance after RELOAD? Replication command indexversion fails to return index version -- Key: SOLR-2326 URL: https://issues.apache.org/jira/browse/SOLR-2326 Project: Solr Issue Type: Bug Components: replication (java) Environment: Branch 3x latest Reporter: Eric Pugh Assignee: Mark Miller Fix For: 3.4, 4.0 To test this, I took the /example/multicore/core0 solrconfig and added a simple replication handler: requestHandler name=/replication class=solr.ReplicationHandler lst name=master str name=replicateAftercommit/str str name=replicateAfterstartup/str str name=confFilesschema.xml/str /lst /requestHandler When I query the handler for details I get back the indexVersion that I expect: http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true But when I ask for just the indexVersion I get back a 0, which prevent the slaves from pulling updates: http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-2326) Replication command indexversion fails to return index version
[
https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082425#comment-13082425
]
Yury Kats edited comment on SOLR-2326 at 8/10/11 4:02 PM:
--
Looks like all failing code paths in ReplicationHandler lead to
{code}
core.getDeletionPolicy()
{code}
So either ReplicationHandler holds on to stale {{core}} instance or core's
{{DeletionPolicy}} is not properly initialized when the core is being reloaded.
was (Author: ykats):
Looks like all failing code paths in ReplicationHandler lead to
{code}
core.getDeletionPolicy()
{code}
So other ReplicationHandler holds on to stale {{core}} instance or core's
DeletionPolicy is not properly initialized when the core is being reloaded.
Replication command indexversion fails to return index version
--
Key: SOLR-2326
URL: https://issues.apache.org/jira/browse/SOLR-2326
Project: Solr
Issue Type: Bug
Components: replication (java)
Environment: Branch 3x latest
Reporter: Eric Pugh
Assignee: Mark Miller
Fix For: 3.4, 4.0
To test this, I took the /example/multicore/core0 solrconfig and added a
simple replication handler:
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str name=confFilesschema.xml/str
/lst
/requestHandler
When I query the handler for details I get back the indexVersion that I
expect:
http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true
But when I ask for just the indexVersion I get back a 0, which prevent the
slaves from pulling updates:
http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2326) Replication command indexversion fails to return index version
[
https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082425#comment-13082425
]
Yury Kats commented on SOLR-2326:
-
Looks like all failing code paths in ReplicationHandler lead to
{code}
core.getDeletionPolicy()
{code}
So other ReplicationHandler holds on to stale {{core}} instance or core's
DeletionPolicy is not properly initialized when the core is being reloaded.
Replication command indexversion fails to return index version
--
Key: SOLR-2326
URL: https://issues.apache.org/jira/browse/SOLR-2326
Project: Solr
Issue Type: Bug
Components: replication (java)
Environment: Branch 3x latest
Reporter: Eric Pugh
Assignee: Mark Miller
Fix For: 3.4, 4.0
To test this, I took the /example/multicore/core0 solrconfig and added a
simple replication handler:
requestHandler name=/replication class=solr.ReplicationHandler
lst name=master
str name=replicateAftercommit/str
str name=replicateAfterstartup/str
str name=confFilesschema.xml/str
/lst
/requestHandler
When I query the handler for details I get back the indexVersion that I
expect:
http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true
But when I ask for just the indexVersion I get back a 0, which prevent the
slaves from pulling updates:
http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2326) Replication command indexversion fails to return index version
[ https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082512#comment-13082512 ] Yury Kats commented on SOLR-2326: - I have the same feeling :) Do you want me to open s new issue? The problem is reproducible on the stock multicore example - launch multicore Solr example - index some example docs - ask for commits: http://localhost:8983/solr/core0/replication?command=commits - reload core0: http://localhost:8983/solr/admin/cores?action=RELOADcore=core0 - ask for commits again: http://localhost:8983/solr/core0/replication?command=commits - observe no commits being returned after reload. Replication command indexversion fails to return index version -- Key: SOLR-2326 URL: https://issues.apache.org/jira/browse/SOLR-2326 Project: Solr Issue Type: Bug Components: replication (java) Environment: Branch 3x latest Reporter: Eric Pugh Assignee: Mark Miller Fix For: 3.4, 4.0 To test this, I took the /example/multicore/core0 solrconfig and added a simple replication handler: requestHandler name=/replication class=solr.ReplicationHandler lst name=master str name=replicateAftercommit/str str name=replicateAfterstartup/str str name=confFilesschema.xml/str /lst /requestHandler When I query the handler for details I get back the indexVersion that I expect: http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true But when I ask for just the indexVersion I get back a 0, which prevent the slaves from pulling updates: http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2705) On reload, IndexWriterProvider holds onto the initial SolrCore it was created with
[ https://issues.apache.org/jira/browse/SOLR-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082549#comment-13082549 ] Yury Kats commented on SOLR-2705: - Thanks, I will try. Looking at the patch, it's not clear to me whether the reloaded core would return proper Commits right after it's been reloaded, or only after the subsequent commit. Can Junit check for indexversion/commits to be same right before and right after coreReload? On reload, IndexWriterProvider holds onto the initial SolrCore it was created with -- Key: SOLR-2705 URL: https://issues.apache.org/jira/browse/SOLR-2705 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2705.patch dug up by Yury Kats in SOLR-2326 The IWP needs to be updated to ref the new core on reload - else if some settings have changed (eg newIndexDir change caused by replication), the IndexWriter will be incorrectly reopened. This should really only be an issue when replication and core reloads are involved for the most part. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2705) On reload, IndexWriterProvider holds onto the initial SolrCore it was created with
[ https://issues.apache.org/jira/browse/SOLR-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082567#comment-13082567 ] Yury Kats commented on SOLR-2705: - First quick test looks good! On reload, IndexWriterProvider holds onto the initial SolrCore it was created with -- Key: SOLR-2705 URL: https://issues.apache.org/jira/browse/SOLR-2705 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0 Attachments: SOLR-2705.patch dug up by Yury Kats in SOLR-2326 The IWP needs to be updated to ref the new core on reload - else if some settings have changed (eg newIndexDir change caused by replication), the IndexWriter will be incorrectly reopened. This should really only be an issue when replication and core reloads are involved for the most part. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2326) Replication command indexversion fails to return index version
[ https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081880#comment-13081880 ] Yury Kats commented on SOLR-2326: - I'm running into the same problem as well. /replication?command=indexversion returns a non-zero value upon startup, but turns into a zero after a commit. An optimze does not seem to bring it back. Replication command indexversion fails to return index version -- Key: SOLR-2326 URL: https://issues.apache.org/jira/browse/SOLR-2326 Project: Solr Issue Type: Bug Components: replication (java) Environment: Branch 3x latest Reporter: Eric Pugh Assignee: Mark Miller Fix For: 3.4, 4.0 To test this, I took the /example/multicore/core0 solrconfig and added a simple replication handler: requestHandler name=/replication class=solr.ReplicationHandler lst name=master str name=replicateAftercommit/str str name=replicateAfterstartup/str str name=confFilesschema.xml/str /lst /requestHandler When I query the handler for details I get back the indexVersion that I expect: http://localhost:8983/solr/core0/replication?command=detailswt=jsonindent=true But when I ask for just the indexVersion I get back a 0, which prevent the slaves from pulling updates: http://localhost:8983/solr/core0/replication?command=indexversionwt=jsonindent=true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size
[ https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081165#comment-13081165 ] Yury Kats commented on SOLR-2698: - Mark, is this good to go or are you waiting for an updated patch from me? Just double checking. Enhance CoreAdmin STATUS command to return index size - Key: SOLR-2698 URL: https://issues.apache.org/jira/browse/SOLR-2698 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Assignee: Mark Miller Attachments: SOLR-2698.patch CoreAdmin STATUS command returns all kinds of index info for all cores on the server, except for the index size. However, indexSize can be retrieved for an individual core via a /replicationcommand=details request. I have N Solrs servers, running M cores each. My application is monitoring the status of all cores, including their index size. As it stands today, I need to issue N status requests plus N*M replication requests to get all the information I need. If STATUS command returned indexSize, number of requests would be just N. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size
[ https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2698: Attachment: SOLR-2698.patch This patch adds index size to CoreAdminHandler#getCoreStatus Enhance CoreAdmin STATUS command to return index size - Key: SOLR-2698 URL: https://issues.apache.org/jira/browse/SOLR-2698 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Attachments: SOLR-2698.patch CoreAdmin STATUS command returns all kinds of index info for all cores on the server, except for the index size. However, indexSize can be retrieved for an individual core via a /replicationcommand=details request. I have N Solrs servers, running M cores each. My application is monitoring the status of all cores, including their index size. As it stands today, I need to issue N status requests plus N*M replication requests to get all the information I need. If STATUS command returned indexSize, number of requests would be just N. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size
[ https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079423#comment-13079423 ] Yury Kats commented on SOLR-2698: - I don't see why not. I'm very new to the solr codebase and thus just looked how the same function is already implemented. ReplicationHandler also converts size into a readable string. For consistency sake CoreAdminHandler could do the same (ReplicationHandler#readableSize could be a shared util). Enhance CoreAdmin STATUS command to return index size - Key: SOLR-2698 URL: https://issues.apache.org/jira/browse/SOLR-2698 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Attachments: SOLR-2698.patch CoreAdmin STATUS command returns all kinds of index info for all cores on the server, except for the index size. However, indexSize can be retrieved for an individual core via a /replicationcommand=details request. I have N Solrs servers, running M cores each. My application is monitoring the status of all cores, including their index size. As it stands today, I need to issue N status requests plus N*M replication requests to get all the information I need. If STATUS command returned indexSize, number of requests would be just N. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size
[ https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079428#comment-13079428 ] Yury Kats commented on SOLR-2698: - FileUtils.byteCountToDisplaySize could produce a different result than what's being returned now. http://www.discursive.com/books/cjcook/reference/io-network-sect-printing-human-readable mentions: FileUtils.byteCountToDisplaySize( ) will not round the size of a file; a 2.9 MB file will have a display size of 2 MB. If that's true, it's not very useful. We could go a step further and return index size in bytes AND as a readable string in the response. If need to choose one or the other, my preference would be for just bytes (long). If it's a String, any application processing the response will need to convert it into bytes anyway to do any meaningful analysis. Enhance CoreAdmin STATUS command to return index size - Key: SOLR-2698 URL: https://issues.apache.org/jira/browse/SOLR-2698 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Assignee: Mark Miller Attachments: SOLR-2698.patch CoreAdmin STATUS command returns all kinds of index info for all cores on the server, except for the index size. However, indexSize can be retrieved for an individual core via a /replicationcommand=details request. I have N Solrs servers, running M cores each. My application is monitoring the status of all cores, including their index size. As it stands today, I need to issue N status requests plus N*M replication requests to get all the information I need. If STATUS command returned indexSize, number of requests would be just N. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2698) Enhance CoreAdmin STATUS command to return index size
[ https://issues.apache.org/jira/browse/SOLR-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079435#comment-13079435 ] Yury Kats commented on SOLR-2698: - bq. I see the following JIRA issue as well: https://issues.apache.org/jira/browse/IO-226 Funny how it was closed not a bug. Who needs a method that returns 1 GB for a 1.99GB file? humanReadableUnits looks good. Maybe add TB? Storage is getting cheaper by the day. bq. I think both is nice myself - but of course not really necessary - a nicety though, in the case an application wants to display this, nice if we simply do the work for them. +1 on two values in the response. In CoreAdminHandler and ReplicationHandler. Enhance CoreAdmin STATUS command to return index size - Key: SOLR-2698 URL: https://issues.apache.org/jira/browse/SOLR-2698 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Assignee: Mark Miller Attachments: SOLR-2698.patch CoreAdmin STATUS command returns all kinds of index info for all cores on the server, except for the index size. However, indexSize can be retrieved for an individual core via a /replicationcommand=details request. I have N Solrs servers, running M cores each. My application is monitoring the status of all cores, including their index size. As it stands today, I need to issue N status requests plus N*M replication requests to get all the information I need. If STATUS command returned indexSize, number of requests would be just N. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2691) solr.xml persistence is broken for multicore (by SOLR-2331)
[ https://issues.apache.org/jira/browse/SOLR-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078832#comment-13078832 ] Yury Kats commented on SOLR-2691: - Thanks, guys. Appreciate the quick turn around! solr.xml persistence is broken for multicore (by SOLR-2331) --- Key: SOLR-2691 URL: https://issues.apache.org/jira/browse/SOLR-2691 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Assignee: Mark Miller Priority: Critical Fix For: 4.0 Attachments: SOLR-2691.patch, SOLR-2691.patch, jira2691.patch With the trunk build, running SolrCloud, if I issue a PERSIST CoreAdmin command, the solr.xml gets overwritten with only the last core, repeated as many times as there are cores. It used to work fine with a trunk build from a couple of months ago, so it looks like something broke solr.xml persistence. It appears to have been introduced by SOLR-2331: CoreContainer#persistFile creates the map for core attributes (coreAttribs) outside of the loop that iterates over cores. Therefore, all cores reuse the same map of attributes and hence only the values from the last core are preserved and used for all cores in the list. I'm running SolrCloud, using: -Dbootstrap_confdir=/opt/solr/solr/conf -Dcollection.configName=hcpconf -DzkRun I'm starting Solr with four cores listed in solr.xml: solr persistent=true cores adminPath=/admin/cores defaultCoreName=master1 core name=master1 instanceDir=master1 shard=shard1 collection=hcpconf / core name=master2 instanceDir=master2 shard=shard2 collection=hcpconf / core name=slave1 instanceDir=slave1 shard=shard1 collection=hcpconf / core name=slave2 instanceDir=slave2 shard=shard2 collection=hcpconf / /cores /solr I then issue a PERSIST request: http://localhost:8983/solr/admin/cores?action=PERSIST And the solr.xml turns into: solr persistent=true cores defaultCoreName=master1 adminPath=/admin/cores zkClientTimeout=1 hostPort=8983 hostContext=solr core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ /cores /solr -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2691) solr.xml persistence is broken for multicore (by SOLR-2331)
solr.xml persistence is broken for multicore (by SOLR-2331) --- Key: SOLR-2691 URL: https://issues.apache.org/jira/browse/SOLR-2691 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Priority: Critical With the trunk build, running SolrCloud, if I issue a PERSIST CoreAdmin command, the solr.xml gets overwritten with only the last core, repeated as many times as there are cores. It used to work fine with a trunk build from a couple of months ago, so it looks like something broke solr.xml persistence. It appears to have been introduced by SOLR-2331: CoreContainer#persistFile creates the map for core attributes (coreAttribs) outside of the loop that iterates over cores. Therefore, all cores reuse the same map of attributes and hence only the values from the last core are preserved and used for all cores in the list. I'm running SolrCloud, using: -Dbootstrap_confdir=/opt/solr/solr/conf -Dcollection.configName=hcpconf -DzkRun I'm starting Solr with four cores listed in solr.xml: solr persistent=true cores adminPath=/admin/cores defaultCoreName=master1 core name=master1 instanceDir=master1 shard=shard1 collection=hcpconf / core name=master2 instanceDir=master2 shard=shard2 collection=hcpconf / core name=slave1 instanceDir=slave1 shard=shard1 collection=hcpconf / core name=slave2 instanceDir=slave2 shard=shard2 collection=hcpconf / /cores /solr I then issue a PERSIST request: http://localhost:8983/solr/admin/cores?action=PERSIST And the solr.xml turns into: solr persistent=true cores defaultCoreName=master1 adminPath=/admin/cores zkClientTimeout=1 hostPort=8983 hostContext=solr core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ /cores /solr -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2331) Refactor CoreContainer's SolrXML serialization code and improve testing
[ https://issues.apache.org/jira/browse/SOLR-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078526#comment-13078526 ] Yury Kats commented on SOLR-2331: - Looks like this introduced a regression in solr.xml persistence. See SOLR-2691. Refactor CoreContainer's SolrXML serialization code and improve testing --- Key: SOLR-2331 URL: https://issues.apache.org/jira/browse/SOLR-2331 Project: Solr Issue Type: Improvement Components: multicore Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.0 Attachments: SOLR-2331-fix-windows-file-deletion-failure.patch, SOLR-2331-fix-windows-file-deletion-failure.patch, SOLR-2331.patch CoreContainer has enough code in it - I'd like to factor out the solr.xml serialization code into SolrXMLSerializer or something - which should make testing it much easier and lightweight. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2691) solr.xml persistence is broken for multicore (by SOLR-2331)
[ https://issues.apache.org/jira/browse/SOLR-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2691: Attachment: jira2691.patch Patch. Create map of attributes inside the loop. solr.xml persistence is broken for multicore (by SOLR-2331) --- Key: SOLR-2691 URL: https://issues.apache.org/jira/browse/SOLR-2691 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Priority: Critical Attachments: jira2691.patch With the trunk build, running SolrCloud, if I issue a PERSIST CoreAdmin command, the solr.xml gets overwritten with only the last core, repeated as many times as there are cores. It used to work fine with a trunk build from a couple of months ago, so it looks like something broke solr.xml persistence. It appears to have been introduced by SOLR-2331: CoreContainer#persistFile creates the map for core attributes (coreAttribs) outside of the loop that iterates over cores. Therefore, all cores reuse the same map of attributes and hence only the values from the last core are preserved and used for all cores in the list. I'm running SolrCloud, using: -Dbootstrap_confdir=/opt/solr/solr/conf -Dcollection.configName=hcpconf -DzkRun I'm starting Solr with four cores listed in solr.xml: solr persistent=true cores adminPath=/admin/cores defaultCoreName=master1 core name=master1 instanceDir=master1 shard=shard1 collection=hcpconf / core name=master2 instanceDir=master2 shard=shard2 collection=hcpconf / core name=slave1 instanceDir=slave1 shard=shard1 collection=hcpconf / core name=slave2 instanceDir=slave2 shard=shard2 collection=hcpconf / /cores /solr I then issue a PERSIST request: http://localhost:8983/solr/admin/cores?action=PERSIST And the solr.xml turns into: solr persistent=true cores defaultCoreName=master1 adminPath=/admin/cores zkClientTimeout=1 hostPort=8983 hostContext=solr core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ core shard=shard2 instanceDir=slave2/ name=slave2 collection=hcpconf/ /cores /solr -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2683) Solr classpath is not setup correctly if core's instanceDir does not exist on startup
Solr classpath is not setup correctly if core's instanceDir does not exist on startup - Key: SOLR-2683 URL: https://issues.apache.org/jira/browse/SOLR-2683 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 4.0 Reporter: Yury Kats When I launch Solr and the core's instanceDir does not exist, the directory is created, but none of the JARs listed in solrconfig.xml in lib entries are added to the classpath, thus resulting in ClassNotFound exceptions at runtime. lib entries in solrconfig.xml are relative to core's instanceDir. It seems that lib entries are processed before instanceDir is created and therefore can't be resolved. Example solr.xml: cores adminPath=/admin/cores defaultCoreName=master1 core name=master1 instanceDir=master1 shard=shard1 /core core name=master2 instanceDir=master2 shard=shard2 /core /cores solrconfig.xml: ... lib dir=../../dist / ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
Support core properties when creating cores via REST API (CoreAdminHandler) --- Key: SOLR-2675 URL: https://issues.apache.org/jira/browse/SOLR-2675 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 4.0 Reporter: Yury Kats When crating cores through solr.xml, I am able to specify custom properties, to be referenced in solrconfig.xml. For example: cores adminPath=/admin/cores defaultCoreName=master core name=master instanceDir=core1 shard=shard1 collection=myconf property name=enable.master value=true / /core core name=slave instanceDir=core2 shard=shard2 collection=myconf property name=enable.slave value=true / property name=masterHost value=node2:8983 / /core /cores There does not seem a way to specify such properties when creating cores through the CoreAdminHandler request. CoreAdminHandler#handleCreateAction always calls dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
[ https://issues.apache.org/jira/browse/SOLR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2675: Attachment: coreadmin.patch Patch against the trunk. CoreAdminHandler#handleCreateAction looks at request parameters in format property.name=value and uses them as name=value properties when creating a core. Support core properties when creating cores via REST API (CoreAdminHandler) --- Key: SOLR-2675 URL: https://issues.apache.org/jira/browse/SOLR-2675 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Attachments: coreadmin.patch When crating cores through solr.xml, I am able to specify custom properties, to be referenced in solrconfig.xml. For example: cores adminPath=/admin/cores defaultCoreName=master core name=master instanceDir=core1 shard=shard1 collection=myconf property name=enable.master value=true / /core core name=slave instanceDir=core2 shard=shard2 collection=myconf property name=enable.slave value=true / property name=masterHost value=node2:8983 / /core /cores There does not seem a way to specify such properties when creating cores through the CoreAdminHandler request. CoreAdminHandler#handleCreateAction always calls dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2675) Support core properties when creating cores via REST API (CoreAdminHandler)
[ https://issues.apache.org/jira/browse/SOLR-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats updated SOLR-2675: Component/s: (was: Build) multicore Support core properties when creating cores via REST API (CoreAdminHandler) --- Key: SOLR-2675 URL: https://issues.apache.org/jira/browse/SOLR-2675 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.0 Reporter: Yury Kats Attachments: coreadmin.patch When crating cores through solr.xml, I am able to specify custom properties, to be referenced in solrconfig.xml. For example: cores adminPath=/admin/cores defaultCoreName=master core name=master instanceDir=core1 shard=shard1 collection=myconf property name=enable.master value=true / /core core name=slave instanceDir=core2 shard=shard2 collection=myconf property name=enable.slave value=true / property name=masterHost value=node2:8983 / /core /cores There does not seem a way to specify such properties when creating cores through the CoreAdminHandler request. CoreAdminHandler#handleCreateAction always calls dcore.setCoreProperties(null); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
