[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925083#comment-16925083 ] Noble Paul commented on SOLR-13677: --- As planned, I have committed the revert to [SOLR-13677_3|https://github.com/apache/lucene-solr/tree/jira/SOLR-13677_3]. I'll give it a few hours. run some testing and merge this to master / branch_8x > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13677: - Assignee: (was: Noble Paul) > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925033#comment-16925033 ] Noble Paul commented on SOLR-13677: --- Yes, I'm planning to do this ASAP. Why should I be the only one bothered about a memory leak > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924738#comment-16924738 ] Noble Paul edited comment on SOLR-13677 at 9/7/19 6:30 AM: --- [~ab] My plan of action * I'll revert *all* the changes I have made as a part of this issue in the branch [SOLR-13677_3|https://github.com/apache/lucene-solr/tree/jira/SOLR-13677_3]. * This will also mean I'll "Ignore" the tests which are failing due to this * I'll leave it there for a couple of days for you to take any further action. I mean fix the original issue * After that I'll merge those changes back into master & branch_8x was (Author: noble.paul): [~ab] My plan of action * I'll revert *all* the changes I have made as a part of this issue in the branch [SOLR-13677_3|https://github.com/apache/lucene-solr/tree/jira/SOLR-13677_3]. * This will also mean I'll "Ignore" the tests which are failing due to this * I'll leave it there for a couple of days for you to take any further action * After that I'll merge those changes back into master & branch_8x > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924738#comment-16924738 ] Noble Paul commented on SOLR-13677: --- [~ab] My plan of action * I'll revert *all* the changes I have made as a part of this issue in the branch [SOLR-13677_3|https://github.com/apache/lucene-solr/tree/jira/SOLR-13677_3]. * This will also mean I'll "Ignore" the tests which are failing due to this * I'll leave it there for a couple of days for you to take any further action * After that I'll merge those changes back into master & branch_8x > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Blocker > Fix For: 8.3 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924657#comment-16924657 ] Noble Paul commented on SOLR-13661: --- [~janhoy] I think we can leverage the package discovery dependency management done in your PoC. My efforts are mainly focussed on efficiently loading/reloading the binaries inside Solr so that there is no disruption to the cluster and the requests in flight. I'm glad that [~ichattopadhyaya] is looking into this > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Labels: package > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Description:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
* The name of the file is the {{sha256}} of the file/payload
* The blob is agnostic of the content of the file/payload
h2. How it works?
A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
locally & all nodes are instructed to download it from this node or from any
other available node. If a node comes up later, it can query other nodes in the
system and download the blobs as required
h2. {{add-package}} command
{code:java}
curl -X POST -H 'Content-type:application/json' --data-binary '{
"add-package": {
"name": "my-package" ,
"sha256":""
}}' http://localhost:8983/api/cluster
{code}
The {{sha256}} is the same as the file name. It gets hold of the jar using the
following steps
* check the local file system for the blob
* If not available locally, query other live nodes if they have the blob (one
by one)
* if a node has it , it's downloaded and persisted to it's local {{blob}} dir
h2. Security
The blob upload does not check for the content of the payload and it does not
verify the file. However, the {{add-package}} , {{update-package}} commands
check for the signatures (if enabled) .
The size of the file is limited to 5MB,to avoid (OOM). This can be changed
using a system property {{runtime.lib.size}} .
was:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
* The name of the file is the {{sha256}} of the file/payload
* The blob is agnostic of the content of the file/payload
h2. How it works?
A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
locally & all nodes are instructed to download it from this node or from any
other available node. If a node comes up later, it can query other nodes in the
system and download the blobs as required
h2. {{add-package}} command
{code:java}
curl -X POST -H 'Content-type:application/json' --data-binary '{
"add-package": {
"name": "my-package" ,
"sha256":""
}}' http://localhost:8983/api/cluster
{code}
The {{sha256}} is the same as the file name. It gets hold of the jar using the
following steps
* check the local file system for the blob
* If not query other live nodes if they have the blob (one by one)
* if a node has it , it's downloaded and persisted to it's local {{blob}} dir
h2. Security
The blob upload does not check for the content of the payload and it does not
verify the file. However, the {{add-package}} , {{update-package}} commands
check for the signatures (if enabled) .
The size of the file is limited to 5MB,to avoid (OOM). This can be changed
using a system property {{runtime.lib.size}} .
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required. An external URL leads to
> unreliability because the service may go offline or it can be DDoSed if/when
> too many requests are sent to them
>
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
> * The name of the file is the {{sha256}} of the file/payload
> * The blob is agnostic of the content of the
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Description:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
* The name of the file is the {{sha256}} of the file/payload
* The blob is agnostic of the content of the file/payload
h2. How it works?
A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
locally & all nodes are instructed to download it from this node or from any
other available node. If a node comes up later, it can query other nodes in the
system and download the blobs as required
h2. {{add-package}} command
{code:java}
curl -X POST -H 'Content-type:application/json' --data-binary '{
"add-package": {
"name": "my-package" ,
"sha256":""
}}' http://localhost:8983/api/cluster
{code}
The {{sha256}} is the same as the file name. It gets hold of the jar using the
following steps
* check the local file system for the blob
* If not query other live nodes if they have the blob (one by one)
* if a node has it , it's downloaded and persisted to it's local {{blob}} dir
h2. Security
The blob upload does not check for the content of the payload and it does not
verify the file. However, the {{add-package}} , {{update-package}} commands
check for the signatures (if enabled) .
The size of the file is limited to 5MB,to avoid (OOM). This can be changed
using a system property {{runtime.lib.size}} .
was:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
h2. How it works?
A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
locally & all nodes are instructed to download it from this node or from any
other available node. If a node comes up later, it can query other nodes in the
system and download the blobs as required
h2. {{add-package}} command
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required. An external URL leads to
> unreliability because the service may go offline or it can be DDoSed if/when
> too many requests are sent to them
>
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
> * The name of the file is the {{sha256}} of the file/payload
> * The blob is agnostic of the content of the file/payload
> h2. How it works?
> A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
> locally & all nodes are instructed to download it from this node or from any
> other available node. If a node comes up later, it can query other nodes in
> the system and download the blobs as required
> h2. {{add-package}} command
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "add-package": {
>"name": "my-package" ,
> "sha256":""
> }}' http://localhost:8983/api/cluster
> {code}
> The {{sha256}} is the same as the file name. It gets hold of the jar using
> the following steps
> * check the local file system for the blob
> * If not query other live nodes if they have the blob (one by one)
> * if a node has it , it's downloaded and persisted to it's local {{blob}} dir
> h2. Security
> The blob upload does not check for the content of the payload and it does not
> verify the
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Description:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
h2. How it works?
A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
locally & all nodes are instructed to download it from this node or from any
other available node. If a node comes up later, it can query other nodes in the
system and download the blobs as required
h2. {{add-package}} command
was:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
Subsequently, when a node is started, it tries to get all the available blobs
from one of the live nodes where it is available.
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required. An external URL leads to
> unreliability because the service may go offline or it can be DDoSed if/when
> too many requests are sent to them
>
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
> h2. How it works?
> A blob that is POSTed to the {{/api/cluster/blob}} end point is persisted
> locally & all nodes are instructed to download it from this node or from any
> other available node. If a node comes up later, it can query other nodes in
> the system and download the blobs as required
> h2. {{add-package}} command
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13731) javabin must support a 1:1 mapping of the JSOn update format
[ https://issues.apache.org/jira/browse/SOLR-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13731: -- Summary: javabin must support a 1:1 mapping of the JSOn update format (was: Javabin update must support a 1:1 mapping of the JSOn update format) > javabin must support a 1:1 mapping of the JSOn update format > - > > Key: SOLR-13731 > URL: https://issues.apache.org/jira/browse/SOLR-13731 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Objects like SolrInputDocument is serialized in such a way that the size is > known in advance. All objects should ideally support streaming friendly types. > This is backward compatible . basically javabin will continue to serialize > using the old format , but will accept more efficient formats as input -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13731) javabin must support a 1:1 mapping of the JSON update format
[ https://issues.apache.org/jira/browse/SOLR-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13731: -- Summary: javabin must support a 1:1 mapping of the JSON update format (was: javabin must support a 1:1 mapping of the JSOn update format) > javabin must support a 1:1 mapping of the JSON update format > - > > Key: SOLR-13731 > URL: https://issues.apache.org/jira/browse/SOLR-13731 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Objects like SolrInputDocument is serialized in such a way that the size is > known in advance. All objects should ideally support streaming friendly types. > This is backward compatible . basically javabin will continue to serialize > using the old format , but will accept more efficient formats as input -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13731) Javabin update must support a 1:1 mapping of the JSOn update format
[ https://issues.apache.org/jira/browse/SOLR-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13731: -- Summary: Javabin update must support a 1:1 mapping of the JSOn update format (was: Javabin to support more streaming friendly formats) > Javabin update must support a 1:1 mapping of the JSOn update format > --- > > Key: SOLR-13731 > URL: https://issues.apache.org/jira/browse/SOLR-13731 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Objects like SolrInputDocument is serialized in such a way that the size is > known in advance. All objects should ideally support streaming friendly types. > This is backward compatible . basically javabin will continue to serialize > using the old format , but will accept more efficient formats as input -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923220#comment-16923220
]
Noble Paul edited comment on SOLR-13722 at 9/5/19 9:03 AM:
---
There is no "blobs" collection. There is a "blob" directory in every node. All
blobs are always available in every node
was (Author: noble.paul):
There is no "blobs" collection. There is a "blob" directory in every node
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required. An external URL leads to
> unreliability because the service may go offline or it can be DDoSed if/when
> too many requests are sent to them
>
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923220#comment-16923220
]
Noble Paul commented on SOLR-13722:
---
There is no "blobs" collection. There is a "blob" directory in every node
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required. An external URL leads to
> unreliability because the service may go offline or it can be DDoSed if/when
> too many requests are sent to them
>
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-13650:
-
Assignee: Noble Paul
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Description:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required. An external URL leads to
unreliability because the service may go offline or it can be DDoSed if/when
too many requests are sent to them
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
Subsequently, when a node is started, it tries to get all the available blobs
from one of the live nodes where it is available.
was:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required.
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
Subsequently, when a node is started, it tries to get all the available blobs
from one of the live nodes where it is available.
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required. An external URL leads to
> unreliability because the service may go offline or it can be DDoSed if/when
> too many requests are sent to them
>
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option & avoid remote url
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Summary: A cluster-wide blob upload package option & avoid remote url
(was: A cluster-wide blob upload package option)
> A cluster-wide blob upload package option & avoid remote url
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13650:
--
Description:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"add-package": {
"name": "my-package" ,
"sha512":""
}
}' http://localhost:8983/api/cluster
{code}
This means that Solr creates a globally accessible classloader with a name
{{my-package}} which contains all the jars of that package.
A component should be able to use the package by using the {{"package" :
"my-package"}}.
eg:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"create-searchcomponent": {
"name": "my-searchcomponent" ,
"class" : "my.path.to.ClassName",
"package" : "my-package"
}
}' http://localhost:8983/api/c/mycollection/config
{code}
was:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"add-package": {
"name": "my-package" ,
"url" : "http://host:port/url/of/jar;,
"sha512":""
}
}' http://localhost:8983/api/cluster
{code}
This means that Solr creates a globally accessible classloader with a name
{{my-package}} which contains all the jars of that package.
A component should be able to use the package by using the {{"package" :
"my-package"}}.
eg:
{code:json}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"create-searchcomponent": {
"name": "my-searchcomponent" ,
"class" : "my.path.to.ClassName",
"package" : "my-package"
}
}' http://localhost:8983/api/c/mycollection/config
{code}
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Labels: package
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)
[ https://issues.apache.org/jira/browse/SOLR-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-13723. --- Fix Version/s: 8.3 Resolution: Fixed > JettySolrRunner should support /api/* (the v2 end point) > > > Key: SOLR-13723 > URL: https://issues.apache.org/jira/browse/SOLR-13723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Labels: test-framework > Fix For: 8.3 > > Time Spent: 20m > Remaining Estimate: 0h > > Today we are not able to write proper v2 API testcases because of this -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)
[ https://issues.apache.org/jira/browse/SOLR-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13723: - Assignee: Noble Paul > JettySolrRunner should support /api/* (the v2 end point) > > > Key: SOLR-13723 > URL: https://issues.apache.org/jira/browse/SOLR-13723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Labels: test-framework > Time Spent: 20m > Remaining Estimate: 0h > > Today we are not able to write proper v2 API testcases because of this -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13731) Javabin to support more streaming friendly formats
[ https://issues.apache.org/jira/browse/SOLR-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13731: - Assignee: Noble Paul > Javabin to support more streaming friendly formats > -- > > Key: SOLR-13731 > URL: https://issues.apache.org/jira/browse/SOLR-13731 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > Objects like SolrInputDocument is serialized in such a way that the size is > known in advance. All objects should ideally support streaming friendly types. > This is backward compatible . basically javabin will continue to serialize > using the old format , but will accept more efficient formats as input -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13731) Javabin to support more streaming friendly formats
[ https://issues.apache.org/jira/browse/SOLR-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13731: -- Description: Objects like SolrInputDocument is serialized in such a way that the size is known in advance. All objects should ideally support streaming friendly types. This is backward compatible . basically javabin will continue to serialize using the old format , but will accept more efficient formats as input was:Objects like SolrInputDocument is serialized in such a way that the size is known in advance. All objects should ideally support streaming friendly types > Javabin to support more streaming friendly formats > -- > > Key: SOLR-13731 > URL: https://issues.apache.org/jira/browse/SOLR-13731 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > Objects like SolrInputDocument is serialized in such a way that the size is > known in advance. All objects should ideally support streaming friendly types. > This is backward compatible . basically javabin will continue to serialize > using the old format , but will accept more efficient formats as input -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13731) Javabin to support more streaming friendly formats
Noble Paul created SOLR-13731: - Summary: Javabin to support more streaming friendly formats Key: SOLR-13731 URL: https://issues.apache.org/jira/browse/SOLR-13731 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Objects like SolrInputDocument is serialized in such a way that the size is known in advance. All objects should ideally support streaming friendly types -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Labels: package (was: )
> A cluster-wide blob upload package option
> -
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13722) A cluster-wide blob upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-13722:
-
Assignee: Noble Paul
> A cluster-wide blob upload package option
> -
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Summary: A cluster-wide blob upload package option (was: A cluster-wide
upload package option)
> A cluster-wide blob upload package option
> -
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Description:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required.
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
Subsequently, when a node is started, it tries to get all the available blobs
from one of the live nodes where it is available.
was:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required.
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/package/mypkg
{code}
This does the following operations
* Check if a package {{mypkg}} is already available , if yes , it is
equivalent to an {{update-package}} command. if not, this is like an
{{add-package}}
* Upload this jar to all the live nodes in the system
* Creates a package called {{mypkg}} with appropriate sha256
the end-point {{/api/cluster/package}} to list all the available packages
Subsequently, when a node is started, it tries to get all the available
packages from one of the live nodes where it is available.
> A cluster-wide upload package option
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918563#comment-16918563 ] Noble Paul commented on SOLR-13677: --- let's make the changes/reverts in [https://github.com/apache/lucene-solr/tree/jira/SOLR-13677_3]. > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13721) TestApiFramework#testFramework failing in master consistently
[ https://issues.apache.org/jira/browse/SOLR-13721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917449#comment-16917449 ] Noble Paul commented on SOLR-13721: --- no recent failures though [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24622/] > TestApiFramework#testFramework failing in master consistently > - > > Key: SOLR-13721 > URL: https://issues.apache.org/jira/browse/SOLR-13721 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24612/testReport/junit/org.apache.solr.handler.admin/TestApiFramework/testFramework/] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13661: -- Labels: package (was: plugin) > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Labels: package > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13661: -- Labels: package (was: ) > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Labels: package > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13661) A package management system for Solr
[ https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13661: -- Labels: plugin (was: package) > A package management system for Solr > > > Key: SOLR-13661 > URL: https://issues.apache.org/jira/browse/SOLR-13661 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Labels: plugin > > Solr needs a unified cohesive package management system so that users can > deploy/redeploy plugins in a safe manner. This is an umbrella issue to > eventually build that solution -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13650:
--
Labels: package (was: )
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Labels: package
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)
[ https://issues.apache.org/jira/browse/SOLR-13723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13723: -- Labels: test-framework (was: ) > JettySolrRunner should support /api/* (the v2 end point) > > > Key: SOLR-13723 > URL: https://issues.apache.org/jira/browse/SOLR-13723 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Minor > Labels: test-framework > Time Spent: 10m > Remaining Estimate: 0h > > Today we are not able to write proper v2 API testcases because of this -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13723) JettySolrRunner should support /api/* (the v2 end point)
Noble Paul created SOLR-13723: - Summary: JettySolrRunner should support /api/* (the v2 end point) Key: SOLR-13723 URL: https://issues.apache.org/jira/browse/SOLR-13723 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Today we are not able to write proper v2 API testcases because of this -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13722) A cluster-wide upload package option
Noble Paul created SOLR-13722:
-
Summary: A cluster-wide upload package option
Key: SOLR-13722
URL: https://issues.apache.org/jira/browse/SOLR-13722
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required.
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/package/mypkg
{code}
This does the following operations
* Check if a package {{mypkg}} is already available , if yes , it is
equivalent to an {{update-package}} command. if not, this is like an
{{add-package}}
* Upload this jar to all the live nodes in the system
* Creates a package called {{mypkg}} with appropriate sha256
the end-point {{/api/cluster/package}} to list all the available packages
Subsequently, when a node is started, it tries to get all the available
packages from one of the live nodes where it is available.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916373#comment-16916373
]
Noble Paul commented on SOLR-13650:
---
I've beasted this 10x and it's passing now. let's see how this goes
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13710) Persist package jars locally & expose them over http
[
https://issues.apache.org/jira/browse/SOLR-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13710:
--
Description:
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha256 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/node/blob}} will list the
available jars
example
{code:json}
{
"blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
"79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983/api/node/blob/}}
was:
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha512 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/node/blob}} will list the
available jars
example
{code:json}
{
"blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
"79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983/api/node/blob/}}
> Persist package jars locally & expose them over http
>
>
> Key: SOLR-13710
> URL: https://issues.apache.org/jira/browse/SOLR-13710
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
> * The file names will be the sha256 hash of the files.
> * Before downloading the a jar from a location, it's first checked in the
> local directory
> * A new API end point {{http://localhost://8983/api/node/blob}} will list the
> available jars
> example
> {code:json}
> {
> "blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
> "79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
> }
> {code}
> * The jar will be downloadable at
> {{http://localhost://8983/api/node/blob/}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13710) Persist package jars locally & expose them over http
[
https://issues.apache.org/jira/browse/SOLR-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13710:
--
Description:
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha512 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/node/blob}} will list the
available jars
example
{code:json}
{
"blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
"79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983/api/node/blob/}}
was:
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha512 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/blob}} will list the
available jars
example
{code:json}
{
"blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
"79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983//api/blobs/}}
> Persist package jars locally & expose them over http
>
>
> Key: SOLR-13710
> URL: https://issues.apache.org/jira/browse/SOLR-13710
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
> * The file names will be the sha512 hash of the files.
> * Before downloading the a jar from a location, it's first checked in the
> local directory
> * A new API end point {{http://localhost://8983/api/node/blob}} will list the
> available jars
> example
> {code:json}
> {
> "blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
> "79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
> }
> {code}
> * The jar will be downloadable at
> {{http://localhost://8983/api/node/blob/}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13710) Persist package jars locally & expose them over http
[
https://issues.apache.org/jira/browse/SOLR-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-13710:
-
Assignee: Noble Paul
> Persist package jars locally & expose them over http
>
>
> Key: SOLR-13710
> URL: https://issues.apache.org/jira/browse/SOLR-13710
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
> * The file names will be the sha512 hash of the files.
> * Before downloading the a jar from a location, it's first checked in the
> local directory
> * A new API end point {{http://localhost://8983/api/blob}} will list the
> available jars
> example
> {code:json}
> {
> "blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
> "79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
> }
> {code}
> * The jar will be downloadable at
> {{http://localhost://8983//api/blobs/}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13710) Persist package jars locally & expose them over http
[
https://issues.apache.org/jira/browse/SOLR-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13710:
--
Description:
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha512 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/blob}} will list the
available jars
example
{code:json}
{
"blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
"79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983//api/blobs/}}
was:
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha512 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/blobs}} will list the
available jars
example
{code:json}
{
"blobs":["d01b51de67ae1680a84a813983b1de3b592fc32f1a22b662fc9057da5953abd1b72476388ba342cad21671cd0b805503c78ab9075ff2f3951fdf75fa16981420",
"bc5ce45ad281b6a08fb7e529b1eb475040076834816570902acb6ebdd809410e31006efdeaa7f78a6c35574f3504963f5f7e4d92247d0eb4db3fc9abdda5d417"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983//api/blobs/}}
> Persist package jars locally & expose them over http
>
>
> Key: SOLR-13710
> URL: https://issues.apache.org/jira/browse/SOLR-13710
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
> * The file names will be the sha512 hash of the files.
> * Before downloading the a jar from a location, it's first checked in the
> local directory
> * A new API end point {{http://localhost://8983/api/blob}} will list the
> available jars
> example
> {code:json}
> {
> "blob":["e1f9e23988c19619402f1040c9251556dcd6e02b9d3e3b966a129ea1be5c70fc",
> "79298d7d5c3e60d91154efe7d72f4536eac46698edfa22ab894b85492d562ed4"]
> }
> {code}
> * The jar will be downloadable at
> {{http://localhost://8983//api/blobs/}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13721) TestApiFramework#testFramework failing in master consistently
[
https://issues.apache.org/jira/browse/SOLR-13721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916239#comment-16916239
]
Noble Paul commented on SOLR-13721:
---
diagnosis : The response of the API is getting the same set of objects but in
different order. This is only happening in {{branch_8x}} and not in {{master}}
(most likely b/c it uses java8 vs. java11) .
> TestApiFramework#testFramework failing in master consistently
> -
>
> Key: SOLR-13721
> URL: https://issues.apache.org/jira/browse/SOLR-13721
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24612/testReport/junit/org.apache.solr.handler.admin/TestApiFramework/testFramework/]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13721) TestApiFramework#testFramework failing in master consistently
[ https://issues.apache.org/jira/browse/SOLR-13721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13721: - Assignee: Noble Paul > TestApiFramework#testFramework failing in master consistently > - > > Key: SOLR-13721 > URL: https://issues.apache.org/jira/browse/SOLR-13721 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24612/testReport/junit/org.apache.solr.handler.admin/TestApiFramework/testFramework/] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13721) TestApiFramework#testFramework failing in master consistently
Noble Paul created SOLR-13721: - Summary: TestApiFramework#testFramework failing in master consistently Key: SOLR-13721 URL: https://issues.apache.org/jira/browse/SOLR-13721 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24612/testReport/junit/org.apache.solr.handler.admin/TestApiFramework/testFramework/] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916076#comment-16916076
]
Noble Paul edited comment on SOLR-13650 at 8/26/19 7:11 PM:
It was cherry-picked from master when I committed another ticket. I've put it
back
was (Author: noble.paul):
It was cherry-picked from master when I committed another ticket.
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916076#comment-16916076
]
Noble Paul commented on SOLR-13650:
---
It was cherry-picked from master when I committed another ticket.
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "url" : "http://host:port/url/of/jar;,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13699) maxChars no longer working on CopyField with Javabin
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-13699. --- Fix Version/s: 8.3 Assignee: Noble Paul (was: Erick Erickson) Resolution: Fixed > maxChars no longer working on CopyField with Javabin > > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Noble Paul >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13699.patch, SOLR-13699.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. > > The issue seems to be limited to Javabin, docs indexed in other formats > (where values come in as strings) are working fine. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13238) BlobHandler generates non-padded md5
[
https://issues.apache.org/jira/browse/SOLR-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915105#comment-16915105
]
Noble Paul commented on SOLR-13238:
---
LGTM
> BlobHandler generates non-padded md5
>
>
> Key: SOLR-13238
> URL: https://issues.apache.org/jira/browse/SOLR-13238
> Project: Solr
> Issue Type: Bug
> Components: blobstore
>Affects Versions: 6.0, 6.6.5, 7.0, 7.6, 7.7
>Reporter: Jeff Walraven
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Introduced in SOLR-6787
> The blob handler currently uses the following logic for generating/storing
> the md5 for uploads:
> {code:java}
> MessageDigest m = MessageDigest.getInstance("MD5");
> m.update(payload.array(), payload.position(), payload.limit());
> String md5 = new BigInteger(1, m.digest()).toString(16);
> {code}
> Unfortunately, this method does not provide padding for any md5 with less
> than 0x10 for its most significant byte. This means that on many occasions it
> could end up with a md5 hash of 31 characters instead of 32.
> I have opened a PR with the following recommended change:
> {code:java}
> String md5 = new String(Hex.encodeHex(m.digest()));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914711#comment-16914711 ] Noble Paul commented on SOLR-13699: --- You can submit a PR and I can merge it > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13699.patch, SOLR-13699.patch > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13710) Persist package jars locally & expose them over http
Noble Paul created SOLR-13710:
-
Summary: Persist package jars locally & expose them over http
Key: SOLR-13710
URL: https://issues.apache.org/jira/browse/SOLR-13710
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
* All jars for packages downloaded are stored in a dir SOLR_HOME/blobs.
* The file names will be the sha512 hash of the files.
* Before downloading the a jar from a location, it's first checked in the local
directory
* A new API end point {{http://localhost://8983/api/blobs}} will list the
available jars
example
{code:json}
{
"blobs":["d01b51de67ae1680a84a813983b1de3b592fc32f1a22b662fc9057da5953abd1b72476388ba342cad21671cd0b805503c78ab9075ff2f3951fdf75fa16981420",
"bc5ce45ad281b6a08fb7e529b1eb475040076834816570902acb6ebdd809410e31006efdeaa7f78a6c35574f3504963f5f7e4d92247d0eb4db3fc9abdda5d417"]
}
{code}
* The jar will be downloadable at
{{http://localhost://8983//api/blobs/}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13707) API to expose the currently used package name, details for each plugin
[
https://issues.apache.org/jira/browse/SOLR-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13707:
--
Description:
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information. This helps the users to debug
and know if the correct version of the plugin is being used to serve the
request.
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent/get?meta=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
was:
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information. This helps the users to debug
and know if the correct version of the plugin is being used to serve the
request.
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent?componentName=get=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
> API to expose the currently used package name, details for each plugin
> --
>
> Key: SOLR-13707
> URL: https://issues.apache.org/jira/browse/SOLR-13707
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> If a plugin is loaded from a package, the config API can expose the details
> of the package where it is loaded from. This API will accept an extra
> parameter {{meta=true}} to fetch this extra information. This helps the users
> to debug and know if the correct version of the plugin is being used to serve
> the request.
> {{curl
> http://localhost:8983/solr/gettingstarted/config/searchComponent/get?meta=true}}
> {code:json}
> {
>"config": {
> "searchComponent": {
> "get": {
> "name": "get",
> "class": "org.apache.solr.core.RuntimeLibSearchComponent",
> "package": "pkg-name",
> "_packageinfo_": {
> "name": "pkg-name",
> "url": "http://localhost:50876/jar1.jar;,
> "sha512" : "thes-sha512-string",
> "znodeVersion": 0
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13707) API to expose the currently used package name, details for each plugin
[
https://issues.apache.org/jira/browse/SOLR-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13707:
--
Description:
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information. This helps the users to debug
and know if the correct version of the plugin is being used to serve the
request.
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent?componentName=get=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
was:
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information. This helps the users to debug
and know if the correct version of the plugin is being used to serve the
request.
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent?compnentName=get=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
> API to expose the currently used package name, details for each plugin
> --
>
> Key: SOLR-13707
> URL: https://issues.apache.org/jira/browse/SOLR-13707
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> If a plugin is loaded from a package, the config API can expose the details
> of the package where it is loaded from. This API will accept an extra
> parameter {{meta=true}} to fetch this extra information. This helps the users
> to debug and know if the correct version of the plugin is being used to serve
> the request.
> {{curl
> http://localhost:8983/solr/gettingstarted/config/searchComponent?componentName=get=true}}
> {code:json}
> {
>"config": {
> "searchComponent": {
> "get": {
> "name": "get",
> "class": "org.apache.solr.core.RuntimeLibSearchComponent",
> "package": "pkg-name",
> "_packageinfo_": {
> "name": "pkg-name",
> "url": "http://localhost:50876/jar1.jar;,
> "sha512" : "thes-sha512-string",
> "znodeVersion": 0
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13707) API to expose the currently used package name, details for each plugin
[
https://issues.apache.org/jira/browse/SOLR-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-13707:
-
Assignee: Noble Paul
> API to expose the currently used package name, details for each plugin
> --
>
> Key: SOLR-13707
> URL: https://issues.apache.org/jira/browse/SOLR-13707
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> If a plugin is loaded from a package, the config API can expose the details
> of the package where it is loaded from. This API will accept an extra
> parameter {{meta=true}} to fetch this extra information. This helps the users
> to debug and know if the correct version of the plugin is being used to serve
> the request.
> {{curl
> http://localhost:8983/solr/gettingstarted/config/searchComponent?compnentName=get=true}}
> {code:json}
> {
>"config": {
> "searchComponent": {
> "get": {
> "name": "get",
> "class": "org.apache.solr.core.RuntimeLibSearchComponent",
> "package": "pkg-name",
> "_packageinfo_": {
> "name": "pkg-name",
> "url": "http://localhost:50876/jar1.jar;,
> "sha512" : "thes-sha512-string",
> "znodeVersion": 0
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13707) API to expose the currently used package name, details for each plugin
[
https://issues.apache.org/jira/browse/SOLR-13707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13707:
--
Description:
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information. This helps the users to debug
and know if the correct version of the plugin is being used to serve the
request.
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent?compnentName=get=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
was:
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent?compnentName=get=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
> API to expose the currently used package name, details for each plugin
> --
>
> Key: SOLR-13707
> URL: https://issues.apache.org/jira/browse/SOLR-13707
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> If a plugin is loaded from a package, the config API can expose the details
> of the package where it is loaded from. This API will accept an extra
> parameter {{meta=true}} to fetch this extra information. This helps the users
> to debug and know if the correct version of the plugin is being used to serve
> the request.
> {{curl
> http://localhost:8983/solr/gettingstarted/config/searchComponent?compnentName=get=true}}
> {code:json}
> {
>"config": {
> "searchComponent": {
> "get": {
> "name": "get",
> "class": "org.apache.solr.core.RuntimeLibSearchComponent",
> "package": "pkg-name",
> "_packageinfo_": {
> "name": "pkg-name",
> "url": "http://localhost:50876/jar1.jar;,
> "sha512" : "thes-sha512-string",
> "znodeVersion": 0
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13707) API to expose the currently used package name, details for each plugin
Noble Paul created SOLR-13707:
-
Summary: API to expose the currently used package name, details
for each plugin
Key: SOLR-13707
URL: https://issues.apache.org/jira/browse/SOLR-13707
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
If a plugin is loaded from a package, the config API can expose the details of
the package where it is loaded from. This API will accept an extra parameter
{{meta=true}} to fetch this extra information
{{curl
http://localhost:8983/solr/gettingstarted/config/searchComponent?compnentName=get=true}}
{code:json}
{
"config": {
"searchComponent": {
"get": {
"name": "get",
"class": "org.apache.solr.core.RuntimeLibSearchComponent",
"package": "pkg-name",
"_packageinfo_": {
"name": "pkg-name",
"url": "http://localhost:50876/jar1.jar;,
"sha512" : "thes-sha512-string",
"znodeVersion": 0
}
}
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12666) Support multiple AuthenticationPlugin's simultaneoulsy
[
https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912135#comment-16912135
]
Noble Paul edited comment on SOLR-12666 at 8/21/19 9:55 AM:
In principle +1 to multiple auth plugins. Let's assume that people may have a
max of 2 -3 auth plugins and , 99% of the people are likely to use only one.
The following should be fine
{code:js}
{
"authentication": {
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}},
"authentication2" : {},
"authentication3":{},
"authorization":{}
}
{code}
was (Author: noble.paul):
In principle +1 to multiple auth plugins. Let's assume that people may have a
max of 2 -3 auth plugins and , 99% of the people are likely to use only one.
The following should be fine
{code:js}
{
"authentication":{
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
authentication2 : {},
authentication3:{},
"authorization":{}
}
{code}
> Support multiple AuthenticationPlugin's simultaneoulsy
> --
>
> Key: SOLR-12666
> URL: https://issues.apache.org/jira/browse/SOLR-12666
> Project: Solr
> Issue Type: New Feature
> Components: Authentication, security
>Reporter: Jan Høydahl
>Priority: Major
> Labels: authentication
>
> Solr is getting support for more authentication plugins year by year, and
> customers have developed their own in-house plugins as well.
> At the same time we see more and more JIRAs to add *BasicAuth* support for
> various clients and use cases, such as SOLR-12584 (Solr Exporter), SOLR-9779
> (Streaming expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213
> (JDBC), SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming
> expression daemon), SOLR-12860 (metrics history), SOLR-11759
> (DocExpirationUpdateProcessor), SOLR-11959 (CDCR), SOLR-12359 (LIR) and
> probably more. Some of these may be bugs that can be fixed with PKI though...
> Currently the framework supports *only one active Auth method* (except PKI
> which is special). Which means that if you use something else than BasicAuth,
> you're lucky if you get any of the above features to work with your cluster.
> -Even the AdminUI only supports BasicAuth (implicit via browser).- Admin UI
> has explicit support for a few plugins only.
> I think the solution is to allow more than one auth plugin to be active at
> the same time, allowing people to use their custom fancy auth which is
> tightly integrated with their environment, and at the same time activate e.g.
> BasicAuth or JWTAuth for use with other clients that do not support the
> primary auth method.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12666) Support multiple AuthenticationPlugin's simultaneoulsy
[
https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912135#comment-16912135
]
Noble Paul commented on SOLR-12666:
---
In principle +1 to multiple auth plugins. Let's assume that people may have a
max of 2 -3 auth plugins and , 99% of the people are likely to use only one.
The following should be fine
{code:js}
{
"authentication":{
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
authentication2 : {},
authentication3:{},
"authorization":{}
}
{code}
> Support multiple AuthenticationPlugin's simultaneoulsy
> --
>
> Key: SOLR-12666
> URL: https://issues.apache.org/jira/browse/SOLR-12666
> Project: Solr
> Issue Type: New Feature
> Components: Authentication, security
>Reporter: Jan Høydahl
>Priority: Major
> Labels: authentication
>
> Solr is getting support for more authentication plugins year by year, and
> customers have developed their own in-house plugins as well.
> At the same time we see more and more JIRAs to add *BasicAuth* support for
> various clients and use cases, such as SOLR-12584 (Solr Exporter), SOLR-9779
> (Streaming expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213
> (JDBC), SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming
> expression daemon), SOLR-12860 (metrics history), SOLR-11759
> (DocExpirationUpdateProcessor), SOLR-11959 (CDCR), SOLR-12359 (LIR) and
> probably more. Some of these may be bugs that can be fixed with PKI though...
> Currently the framework supports *only one active Auth method* (except PKI
> which is special). Which means that if you use something else than BasicAuth,
> you're lucky if you get any of the above features to work with your cluster.
> -Even the AdminUI only supports BasicAuth (implicit via browser).- Admin UI
> has explicit support for a few plugins only.
> I think the solution is to allow more than one auth plugin to be active at
> the same time, allowing people to use their custom fancy auth which is
> tightly integrated with their environment, and at the same time activate e.g.
> BasicAuth or JWTAuth for use with other clients that do not support the
> primary auth method.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12666) Support multiple AuthenticationPlugin's simultaneoulsy
[ https://issues.apache.org/jira/browse/SOLR-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911768#comment-16911768 ] Noble Paul commented on SOLR-12666: --- Can you tell us how the security.json will look like with multiple auth plugins? > Support multiple AuthenticationPlugin's simultaneoulsy > -- > > Key: SOLR-12666 > URL: https://issues.apache.org/jira/browse/SOLR-12666 > Project: Solr > Issue Type: New Feature > Components: Authentication, security >Reporter: Jan Høydahl >Priority: Major > Labels: authentication > > Solr is getting support for more authentication plugins year by year, and > customers have developed their own in-house plugins as well. > At the same time we see more and more JIRAs to add *BasicAuth* support for > various clients and use cases, such as SOLR-12584 (Solr Exporter), SOLR-9779 > (Streaming expressions), SOLR-11356 (ConcurrentUpdateSolrClient), SOLR-8213 > (JDBC), SOLR-12583 (Subquery docTransformer) and SOLR-10322 (Streaming > expression daemon), SOLR-12860 (metrics history), SOLR-11759 > (DocExpirationUpdateProcessor), SOLR-11959 (CDCR), SOLR-12359 (LIR) and > probably more. Some of these may be bugs that can be fixed with PKI though... > Currently the framework supports *only one active Auth method* (except PKI > which is special). Which means that if you use something else than BasicAuth, > you're lucky if you get any of the above features to work with your cluster. > -Even the AdminUI only supports BasicAuth (implicit via browser).- Admin UI > has explicit support for a few plugins only. > I think the solution is to allow more than one auth plugin to be active at > the same time, allowing people to use their custom fancy auth which is > tightly integrated with their environment, and at the same time activate e.g. > BasicAuth or JWTAuth for use with other clients that do not support the > primary auth method. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13706) Config API output is broken for "highlight" component
[ https://issues.apache.org/jira/browse/SOLR-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911744#comment-16911744 ] Noble Paul commented on SOLR-13706: --- This is not fixed. I have just ignored the "highlight" component for the time being > Config API output is broken for "highlight" component > - > > Key: SOLR-13706 > URL: https://issues.apache.org/jira/browse/SOLR-13706 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > The output is mangled and it is not consumable -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13706) Config API output is broken for "highlight" component
Noble Paul created SOLR-13706: - Summary: Config API output is broken for "highlight" component Key: SOLR-13706 URL: https://issues.apache.org/jira/browse/SOLR-13706 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul The output is mangled and it is not consumable -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13687) Enable the bin/solr script to accept a solr url to run commands
[
https://issues.apache.org/jira/browse/SOLR-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911091#comment-16911091
]
Noble Paul commented on SOLR-13687:
---
bq. But you can say the same thing about a Solr URL if Solr hasn't been secured.
Both are orthogonal. You must secure your Solr irrespective of whether your ZK
is secure or not
bq. I'd love for ZK to be a background detail we can hide from people, but
right now I think it's a little unrealistic...
This ticket is not about removing an existing functionality. This is to enhance
our existing commands to support both
> Enable the bin/solr script to accept a solr url to run commands
>
>
> Key: SOLR-13687
> URL: https://issues.apache.org/jira/browse/SOLR-13687
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> The problem we have today with our {{bin/solr}} script is that we have to run
> it from one of the nodes where Solr is running. This is a security issue b/c
> only admins are usaully be allowed to login to a machine where solr is
> running.If you have multiple cluster running in that host we don't know which
> one it's going to use. It is much easier to write a simple script that works
> over a url and the user has no ambiguity as to how it works. You can just
> unpack a solr distribution to your local machine and start using the script
> without bothering to install solr .
> The following commands can easily be executed remotely. These commands can
> accept the base url of any solr node in the cluster and perform the opertaion
> * healthcheck
> * create
> * create_core
> * create_collection
> * delete, version,
> * config
> * autoscaling
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13677: - Assignee: Noble Paul > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13687) Enable the bin/solr script to accept a solr url to run commands
[
https://issues.apache.org/jira/browse/SOLR-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910896#comment-16910896
]
Noble Paul commented on SOLR-13687:
---
Ideally, we should minimize access to ZK from hosts outside of of solr nodes.
It's a security hole. If you have access to ZK , you can edit the
{{security.json}} or any other file in zookeeper. Most of these operations do
not need access to ZK.
We should make usage of solr as a service that runs over HTTP. If an operation
can be performed over HTTP, it should be. People should just be required to
know the url of a solr node to use a solr cluster.
> Enable the bin/solr script to accept a solr url to run commands
>
>
> Key: SOLR-13687
> URL: https://issues.apache.org/jira/browse/SOLR-13687
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> The problem we have today with our {{bin/solr}} script is that we have to run
> it from one of the nodes where Solr is running. This is a security issue b/c
> only admins are usaully be allowed to login to a machine where solr is
> running.If you have multiple cluster running in that host we don't know which
> one it's going to use. It is much easier to write a simple script that works
> over a url and the user has no ambiguity as to how it works. You can just
> unpack a solr distribution to your local machine and start using the script
> without bothering to install solr .
> The following commands can easily be executed remotely. These commands can
> accept the base url of any solr node in the cluster and perform the opertaion
> * healthcheck
> * create
> * create_core
> * create_collection
> * delete, version,
> * config
> * autoscaling
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909489#comment-16909489 ] Noble Paul edited comment on SOLR-13699 at 8/16/19 11:51 PM: - Let's limit all the changes to DocumentBuilder. Eventually, we have to convert our tests to run on all the 3 formats * JSON * XML * javabin Sticking to XML alone in tests can lead to many unforseen problems. was (Author: noble.paul): Let's limit all the changes to DocumentBuilder > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13699.patch, SOLR-13699.patch > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909489#comment-16909489 ] Noble Paul commented on SOLR-13699: --- Let's limit all the changes to DocumentBuilder > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13699.patch, SOLR-13699.patch > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13699) maxChars no longer working as designed on CopyField
[ https://issues.apache.org/jira/browse/SOLR-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13699: -- Attachment: SOLR-13699.patch > maxChars no longer working as designed on CopyField > --- > > Key: SOLR-13699 > URL: https://issues.apache.org/jira/browse/SOLR-13699 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7, 7.7.1, 7.7.2, 8.0, 8.0.1, 8.1, 8.2, 7.7.3, 8.1.1, > 8.1.2 >Reporter: Chris Troullis >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13699.patch, SOLR-13699.patch > > > We recently upgraded from Solr 7.3 to 8.1, and noticed that the maxChars > property on a copy field is no longer functioning as designed, while indexing > via SolrJ. Per the most recent documentation it looks like there have been no > intentional changes as to the functionality of this property, so I assume > this is a bug. > > In debugging the issue, it looks like the bug was caused by SOLR-12992. In > DocumentBuilder where the maxChar limit is applied, it first checks if the > value is instanceof String. As of SOLR-12992, string values are now coming in > as ByteArrayUtf8CharSequence (unless they are above a certain size as defined > by JavaBinCodec.MAX_UTF8_SZ), so they are failing the instanceof String > check, and the maxChar truncation is not being applied. I am currently not > sure if this issue is limited to indexing via SolrJ or if it applies to > documents indexed via any means -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-13682.
---
Resolution: Fixed
Fix Version/s: 8.3
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[ https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-13688. --- Resolution: Fixed Fix Version/s: 8.3 > Make the bin/solr export command to run one thread per shard > > > Key: SOLR-13688 > URL: https://issues.apache.org/jira/browse/SOLR-13688 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 8.3 > > > This can be run in parallel with one dedicated thread for each shard and > (distrib=false) option > this will be the only option -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[
https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13688:
--
Description:
This can be run in parallel with one dedicated thread for each shard and
(distrib=false) option
this will be the only option
was:
This can be run in parallel with one dedicated thread for each shard and
(distrib=false) option
use the {{-parallel}} option
example
{code}
bin/solr export -url http://localhost:8983/solr/gettingstarted -parallel
{code}
> Make the bin/solr export command to run one thread per shard
>
>
> Key: SOLR-13688
> URL: https://issues.apache.org/jira/browse/SOLR-13688
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> This can be run in parallel with one dedicated thread for each shard and
> (distrib=false) option
> this will be the only option
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[ https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-13688: - Assignee: Noble Paul > Make the bin/solr export command to run one thread per shard > > > Key: SOLR-13688 > URL: https://issues.apache.org/jira/browse/SOLR-13688 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > This can be run in parallel with one dedicated thread for each shard and > (distrib=false) option > this will be the only option -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[
https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13688:
--
Description:
This can be run in parallel with one dedicated thread for each shard and
(distrib=false) option
use the {{-parallel}} option
example
{code}
bin/solr export -url http://localhost:8983/solr/gettingstarted -parallel
{code}
was:This can be run in parallel with one dedicated thread for each shard and
(distrib=false) option
> Make the bin/solr export command to run one thread per shard
>
>
> Key: SOLR-13688
> URL: https://issues.apache.org/jira/browse/SOLR-13688
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> This can be run in parallel with one dedicated thread for each shard and
> (distrib=false) option
> use the {{-parallel}} option
> example
> {code}
> bin/solr export -url http://localhost:8983/solr/gettingstarted -parallel
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13689) add a command line option bin/solr import to import jsonl/javabin file
Noble Paul created SOLR-13689:
-
Summary: add a command line option bin/solr import to import
jsonl/javabin file
Key: SOLR-13689
URL: https://issues.apache.org/jira/browse/SOLR-13689
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
example
{code}
bin/solr import -url [http://localhost:8983/solr/gettingstarted] -file
data.javabin
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13688) Make the bin/solr export command to run one thread per shard
Noble Paul created SOLR-13688: - Summary: Make the bin/solr export command to run one thread per shard Key: SOLR-13688 URL: https://issues.apache.org/jira/browse/SOLR-13688 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul This can be run in parallel with one dedicated thread for each shard and (distrib=false) option -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13687) Enable the bin/solr script to accept a solr url to run commands
[
https://issues.apache.org/jira/browse/SOLR-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13687:
--
Description:
The problem we have today with our {{bin/solr}} script is that we have to run
it from one of the nodes where Solr is running. This is a security issue b/c
only admins are usaully be allowed to login to a machine where solr is
running.If you have multiple cluster running in that host we don't know which
one it's going to use. It is much easier to write a simple script that works
over a url and the user has no ambiguity as to how it works. You can just
unpack a solr distribution to your local machine and start using the script
without bothering to install solr .
The following commands can easily be executed remotely. These commands can
accept the base url of any solr node in the cluster and perform the opertaion
* healthcheck
* create
* create_core
* create_collection
* delete, version,
* config
* autoscaling
was:
The following commands can easily be executed remotely. These commands can
accept the base url of any solr node in the cluster and perform the opertaion
* healthcheck
* create
* create_core
* create_collection
* delete, version,
* config
* autoscaling
> Enable the bin/solr script to accept a solr url to run commands
>
>
> Key: SOLR-13687
> URL: https://issues.apache.org/jira/browse/SOLR-13687
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> The problem we have today with our {{bin/solr}} script is that we have to run
> it from one of the nodes where Solr is running. This is a security issue b/c
> only admins are usaully be allowed to login to a machine where solr is
> running.If you have multiple cluster running in that host we don't know which
> one it's going to use. It is much easier to write a simple script that works
> over a url and the user has no ambiguity as to how it works. You can just
> unpack a solr distribution to your local machine and start using the script
> without bothering to install solr .
> The following commands can easily be executed remotely. These commands can
> accept the base url of any solr node in the cluster and perform the opertaion
> * healthcheck
> * create
> * create_core
> * create_collection
> * delete, version,
> * config
> * autoscaling
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904287#comment-16904287
]
Noble Paul edited comment on SOLR-13682 at 8/10/19 1:21 AM:
The problem we have today with our {{bin/solr}} script is that we have to run
it from one of the nodes where Solr is running. This is a security issue b/c
only admins are usaully be allowed to login to a machine where solr is
running.If you have multiple cluster running in that host we don't know which
one it's going to use. It is much easier to write a simple script that works
over a url and the user has no ambiguity as to how it works. You can just
unpack a solr distribution to your local machine and start using the script
without bothering to install solr .
I've opened SOLR-13687
was (Author: noble.paul):
The problem we have today with our {{bin/solr}} script is that we have to run
it from one of the nodes where Solr is running. This is a security issue b/c
only admins are usaully be allowed to login to a machine where solr is
running.If you have multiple cluster running in that host we don't know which
one it's going to use. It is much easier to write a simple script that works
over a url and the user has no ambiguity as to how it works. You can just
unpack a solr distribution to your local machine and start using the script
without bothering to install solr .
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13687) Enable the bin/solr script to accept a solr url to run commands
Noble Paul created SOLR-13687: - Summary: Enable the bin/solr script to accept a solr url to run commands Key: SOLR-13687 URL: https://issues.apache.org/jira/browse/SOLR-13687 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul The following commands can easily be executed remotely. These commands can accept the base url of any solr node in the cluster and perform the opertaion * healthcheck * create * create_core * create_collection * delete, version, * config * autoscaling -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904287#comment-16904287
]
Noble Paul commented on SOLR-13682:
---
The problem we have today with our {{bin/solr}} script is that we have to run
it from one of the nodes where Solr is running. This is a security issue b/c
only admins are usaully be allowed to login to a machine where solr is
running.If you have multiple cluster running in that host we don't know which
one it's going to use. It is much easier to write a simple script that works
over a url and the user has no ambiguity as to how it works. You can just
unpack a solr distribution to your local machine and start using the script
without bothering to install solr .
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903691#comment-16903691
]
Noble Paul commented on SOLR-13682:
---
bq. But that would be a new JIRA
Yes we should support the url param for most commands
bq.meantime I'm more thinking about being consistent with current practices.
TBH , it doesn't make sense to give multiple options when there is one sensible
option. Users just look at the ref guide or they get the command help and
execute it. Consistency is overrated
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902778#comment-16902778
]
Noble Paul edited comment on SOLR-13682 at 8/9/19 7:18 AM:
---
bq. Perhaps optimize for the normal case of exporting a collection in the local
cluster,
this is for the most common usecase . the last part is the collection name.
Only when you are playing with Solr you run all these from the local box.
Ideally, you will be running a cluster with a handful of nodes and you would
want to run your export in another machine where Solr is not running.
TBH we should let all the commands take in a url. Most of the commands can be
run from any node by just pointing to a solr base url. We just don't do it and
I would say it's bad user UX.
bq. Also, consider making the default format jsonl
OK
bq. and default output stdout
That would be a bad experience , we are gonna emit a few megabytes of data. We
can have an extra option to do so
was (Author: noble.paul):
bq. Perhaps optimize for the normal case of exporting a collection in the local
cluster,
this is for the most common usecase . the last part is the collection name.
Only when you are playing with Solr you run all these from the local box.
Ideally, you will be running a cluster with a handful of nodes and you would
want to run your export in another machine where Solr is not running.
bq. Also, consider making the default format jsonl
OK
bq. and default output stdout
That would be a bad experience , we are gonna emit a few megabytes of data. We
can have an extra option to do so
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
* {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the docs
h2. Importing using {{curl}}
importing json file
{code:java}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
{code}
importing javabin format file
{code:java}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin
http://localhost:7574/solr/gettingstarted/update?commit=true
{code}
was:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
* {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the docs
h2. Importing using {{curl}}
importing json file
{code:java}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/copy/update/json/docs?commit=true
{code}
importing javabin format file
{code:java}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
{code}
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-13682:
-
Assignee: Noble Paul
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/copy/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902778#comment-16902778
]
Noble Paul edited comment on SOLR-13682 at 8/9/19 4:49 AM:
---
bq. Perhaps optimize for the normal case of exporting a collection in the local
cluster,
this is for the most common usecase . the last part is the collection name.
Only when you are playing with Solr you run all these from the local box.
Ideally, you will be running a cluster with a handful of nodes and you would
want to run your export in another machine where Solr is not running.
bq. Also, consider making the default format jsonl
OK
bq. and default output stdout
That would be a bad experience , we are gonna emit a few megabytes of data. We
can have an extra option to do so
was (Author: noble.paul):
bq. Perhaps optimize for the normal case of exporting a collection in the local
cluster,
this is for the most common usecase . the last part is the collection name
bq. Also, consider making the default format jsonl
OK
bq. and default output stdout
That would be a bad experience , we are gonna emit a few megabytes of data. We
can have an extra option to do so
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/copy/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
* {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the docs
h2. Importing using {{curl}}
importing json file
{code:java}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/copy/update/json/docs?commit=true
{code}
importing javabin format file
{code:java}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
{code}
was:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
h2. Importing using {{curl}}
importing json file
{code:java}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/copy/update/json/docs?commit=true
{code}
importing javabin format file
{code:java}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
{code}
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/copy/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
h2. Importing using {{curl}}
importing json file
{code:java}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/copy/update/json/docs?commit=true
{code}
importing javabin format file
{code:java}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
{code}
was:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name .(if this starts with "http://; the output will
be piped to that url. Can be used to pipe docs to another cluster)
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
h2. Importing using {{curl}}
importing json file
{code}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/copy/update/json/docs?commit=true
{code}
importing javabin format file
{code}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
{code}
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/copy/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name .(if this starts with "http://; the output will
be piped to that url. Can be used to pipe docs to another cluster)
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
h2. Importing using {{curl}}
importing json file
{code}
curl -X POST -d @gettingstarted.json
http://localhost:18983/solr/copy/update/json/docs?commit=true
{code}
importing javabin format file
{code}
curl -X POST --header "Content-Type: application/javabin" --data-binary
@gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
{code}
was:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name .(if this starts with "http://; the output will
be piped to that url. Can be used to pipe docs to another cluster)
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name .(if this starts with "http://; the output will
> be piped to that url. Can be used to pipe docs to another cluster)
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> h2. Importing using {{curl}}
> importing json file
> {code}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/copy/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13684) failOnVersionConflicts param should be added to the DistributedUpdateProcessor whitelist params
Noble Paul created SOLR-13684: - Summary: failOnVersionConflicts param should be added to the DistributedUpdateProcessor whitelist params Key: SOLR-13684 URL: https://issues.apache.org/jira/browse/SOLR-13684 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Assignee: Noble Paul This param should be passed on to the leader when forwarding -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export -url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.json}}
additional options are
* {{format}} : {{jsonl}} (default) or {{javabin}}
* {{out}} : export file name .(if this starts with "http://; the output will
be piped to that url. Can be used to pipe docs to another cluster)
* {{query}} : a custom query , default is **:**
* {{fields}}: a comma separated list of fields to be exported
was:
example
{code:java}
bin/solr export --url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.javabin}}
additional options are
* format : jsonl or javabin
* out : export file name
* .(if this starts with "http://; the output will be piped to that url. Can be
used to pipe docs to another cluster)
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name .(if this starts with "http://; the output will
> be piped to that url. Can be used to pipe docs to another cluster)
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export --url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.javabin}}
additional options are
* format : jsonl or javabin
* out : export file name
* .(if this starts with "http://; the output will be piped to that url. Can be
used to pipe docs to another cluster)
was:
example
{code:java}
bin/solr export --url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.javabin}}
additional options are
* format : jsonl or javabin
* out : export file name
* .(if this starts with "http://; the output will be piped to that url. Can be
used to pipe docs to another cluster). Or
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export --url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.javabin}}
> additional options are
> * format : jsonl or javabin
> * out : export file name
> * .(if this starts with "http://; the output will be piped to that url. Can
> be used to pipe docs to another cluster)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13682:
--
Description:
example
{code:java}
bin/solr export --url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.javabin}}
additional options are
* format : jsonl or javabin
* out : export file name
* .(if this starts with "http://; the output will be piped to that url. Can be
used to pipe docs to another cluster). Or
was:
example
{code}
bin/solr export --url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.javabin}}
additional options are
* format : jsonl or javabin
* file : export file name .(if this starts with "http://; the output will be
piped to that url. Can be used to pipe docs to another cluster)
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export --url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.javabin}}
> additional options are
> * format : jsonl or javabin
> * out : export file name
> * .(if this starts with "http://; the output will be piped to that url. Can
> be used to pipe docs to another cluster). Or
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902778#comment-16902778
]
Noble Paul commented on SOLR-13682:
---
bq. Perhaps optimize for the normal case of exporting a collection in the local
cluster,
this is for the most common usecase . the last part is the collection name
bq. Also, consider making the default format jsonl
OK
bq. and default output stdout
That would be a bad experience , we are gonna emit a few megabytes of data. We
can have an extra option to do so
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code}
> bin/solr export --url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.javabin}}
> additional options are
> * format : jsonl or javabin
> * file : export file name .(if this starts with "http://; the output will be
> piped to that url. Can be used to pipe docs to another cluster)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13682) command line option to export data to a file
Noble Paul created SOLR-13682:
-
Summary: command line option to export data to a file
Key: SOLR-13682
URL: https://issues.apache.org/jira/browse/SOLR-13682
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
example
{code}
bin/solr export --url http://localhost:8983/solr/gettingstarted
{code}
This will export all the docs in a collection called {{gettingstarted}} into a
file called {{gettingstarted.javabin}}
additional options are
* format : jsonl or javabin
* file : export file name .(if this starts with "http://; the output will be
piped to that url. Can be used to pipe docs to another cluster)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902043#comment-16902043 ] Noble Paul commented on SOLR-13677: --- [~ab] please take a look at the new PR > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901459#comment-16901459 ] Noble Paul commented on SOLR-13677: --- bq.the tag properly represents the object or group of objects with the same life-cycle -... I think this is a better solution. I was not sure about the implications of such a change. I will try to implement it and you can review it > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901418#comment-16901418
]
Noble Paul commented on SOLR-13677:
---
[~cpoerschke], the problem is not with adding those {{remember()}} {{forget()}}
methods. There is no way to ensure that those methods are invoked . We may be
able to check them today. But who will ensure that about the future components.
The advantage of piggybacking on {{close()}} is that it is a well known and
usually close is called always
> All Metrics Gauges should be unregistered by the objects that registered them
> -
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if
> the lifecycle of the object is different from that of the core itself, these
> objects will never be unregistered from the metrics registry. This will lead
> to memory leaks
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900424#comment-16900424
]
Noble Paul edited comment on SOLR-13677 at 8/6/19 4:46 AM:
---
bq. In {{SolrMetricProducer}} instead of using {{AutoCloseable.close()}} simply
add a different default method eg. {{unregisterMetrics()}}.
I thought of doing it. But the problem is that there is a chance that
{{unregisterMetrics()}} is not invoked at all, as it is not the responsibility
of the metrics framework. {{AutoCloseable.close()}} is called anyway. All the
cleanup should be performed there. Even if we have an {{unregisterMetrics()}}
method, we should automatically call it from the {{AutoCloseable.close()}}
method.
bq.I don't think we should expose {{GaugeWrapper}} outside of
{{SolrMetricManager}}, this is really an internal detail.
I have changed the branch to not expose the GaugeWrapper
was (Author: noble.paul):
bq. In {{SolrMetricProducer}} instead of using {{AutoCloseable.close()}} simply
add a different default method eg. {{unregisterMetrics()}}.
I thought of doing it. But the problem is that there is a chance that
{{unregisterMetrics()}} is not invoked at all as it is not the responsibility
of the metrics framework. {{AutoCloseable.close()}} is called anyway and any
and all the cleanup should be performed there. Even if we have an
{{unregisterMetrics()}} method, we should automatically call it from the
{{AutoCloseable.close()}} method.
bq.I don't think we should expose {{GaugeWrapper}} outside of
{{SolrMetricManager}}, this is really an internal detail. ..
The call to unregister should be just as simple as a method call
{{someObject.unregister()}} . As a component writer, I don't want to gather the
various parameters required by the metrics framework to unregister my
component. It should be totally hidden outside of the metrics framework. I
agree that the {{GaugeWrapper}} is an internal component. It may make sense to
rename it and keep it as a top level class.
> All Metrics Gauges should be unregistered by the objects that registered them
> -
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if
> the lifecycle of the object is different from that of the core itself, these
> objects will never be unregistered from the metrics registry. This will lead
> to memory leaks
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900424#comment-16900424
]
Noble Paul commented on SOLR-13677:
---
bq. In {{SolrMetricProducer}} instead of using {{AutoCloseable.close()}} simply
add a different default method eg. {{unregisterMetrics()}}.
I thought of doing it. But the problem is that there is a chance that
{{unregisterMetrics()}} is not invoked at all as it is not the responsibility
of the metrics framework. {{AutoCloseable.close()}} is called anyway and any
and all the cleanup should be performed there. Even if we have an
{{unregisterMetrics()}} method, we should automatically call it from the
{{AutoCloseable.close()}} method.
bq.I don't think we should expose {{GaugeWrapper}} outside of
{{SolrMetricManager}}, this is really an internal detail. ..
The call to unregister should be just as simple as a method call
{{someObject.unregister()}} . As a component writer, I don't want to gather the
various parameters required by the metrics framework to unregister my
component. It should be totally hidden outside of the metrics framework. I
agree that the {{GaugeWrapper}} is an internal component. It may make sense to
rename it and keep it as a top level class.
> All Metrics Gauges should be unregistered by the objects that registered them
> -
>
> Key: SOLR-13677
> URL: https://issues.apache.org/jira/browse/SOLR-13677
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The life cycle of Metrics producers are managed by the core (mostly). So, if
> the lifecycle of the object is different from that of the core itself, these
> objects will never be unregistered from the metrics registry. This will lead
> to memory leaks
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899269#comment-16899269 ] Noble Paul commented on SOLR-13677: --- What we need is avoid notifications for commits to all the JIRA branches . Using a feature branch is good for collaboration. Every committer automatically had access to your branch > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5381) Split Clusterstate and scale
[ https://issues.apache.org/jira/browse/SOLR-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul closed SOLR-5381. > Split Clusterstate and scale > - > > Key: SOLR-5381 > URL: https://issues.apache.org/jira/browse/SOLR-5381 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 5.0 > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > clusterstate.json is a single point of contention for all components in > SolrCloud. It would be hard to scale SolrCloud beyond a few thousand nodes > because there are too many updates and too many nodes need to be notified of > the changes. As the no:of nodes go up the size of clusterstate.json keeps > going up and it will soon exceed the limit impossed by ZK. > The first step is to store the shards information in separate nodes and each > node can just listen to the shard node it belongs to. We may also need to > split each collection into its own node and the clusterstate.json just > holding the names of the collections . > This is an umbrella issue -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5381) Split Clusterstate and scale
[ https://issues.apache.org/jira/browse/SOLR-5381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-5381. -- Resolution: Fixed Fix Version/s: 5.0 > Split Clusterstate and scale > - > > Key: SOLR-5381 > URL: https://issues.apache.org/jira/browse/SOLR-5381 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 5.0 > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > clusterstate.json is a single point of contention for all components in > SolrCloud. It would be hard to scale SolrCloud beyond a few thousand nodes > because there are too many updates and too many nodes need to be notified of > the changes. As the no:of nodes go up the size of clusterstate.json keeps > going up and it will soon exceed the limit impossed by ZK. > The first step is to store the shards information in separate nodes and each > node can just listen to the shard node it belongs to. We may also need to > split each collection into its own node and the clusterstate.json just > holding the names of the collections . > This is an umbrella issue -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-13677: -- Component/s: metrics > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
