[jira] [Commented] (SOLR-12672) Implement Synchronized Disruption into Solr
[
https://issues.apache.org/jira/browse/SOLR-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16585856#comment-16585856
]
Trey Cahill commented on SOLR-12672:
[~elyograg],
{quote}if you ask Java for an explicit GC, it's going to be a full GC. Does
your experience align with this? {quote} - As far as I know, it does a full GC
(although IIRC, it doesn't _have to_ run a GC; it's more of a suggestion).
{quote}Are you tracking how long the System.gc() call takes in your code that
does this synchronization? {quote} - Not explicitly, but it does happen as a
side effect of scheduling the next disruption.
{quote}Do you find that explicit GCs done on a regular basis perform faster
than several seconds? {quote} - I've not looked into that; I'll work on finding
out.
{quote}If a scheduled GC does take several seconds, and this happens on every
machine in the cluster at the same time, that would be a worse problem than an
extra hundred milliseconds every now and then.{quote} - Absolutely and it'd
defeat the purpose of entire PR.
[~mbraun688], it does look like that. It seems like a commonality between
SOLR-6730 and [~varunthacker]'s suggestion is that the cluster is available the
entire time. So, rather than disrupting the entire cluster, only part of the
cluster would be affected.
> Implement Synchronized Disruption into Solr
> ---
>
> Key: SOLR-12672
> URL: https://issues.apache.org/jira/browse/SOLR-12672
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Trey Cahill
>Priority: Trivial
> Attachments: Synchronized Disruption in Solr.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On large Solr clusters, at any given time, there is probably an instance
> running garbage collection. By implementing a synchronized disruption across
> the entire cluster, the response times of a large cluster should decrease as
> it helps prevent random instances from running GC while the rest of the
> cluster is responding to a request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12672) Implement Synchronized Disruption into Solr
[ https://issues.apache.org/jira/browse/SOLR-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583935#comment-16583935 ] Trey Cahill commented on SOLR-12672: [~erickerickson], the disruptions should interrupt the entire cluster (imagine every instance in the cluster running a stop-the-world gc at the same time), so I'd hope that it wouldn't lead to some sort of recovery situation. I have not tried this out on a sufficiently big cluster to verify this though. And hopefully, there is no need to communicate to other nodes that the disruption is occurring because every node should be disrupted (on startup, the node will check Zookeeper for any disruptions). When disruptions are added/removed, the request is sent to all the nodes, rather than communicated through zookeeper (this could be a potential issue, if a single instance failed to add a disruption becoming out of sync with the rest of the cluster). I think [this blog|https://blogs.apache.org/hbase/entry/medium_data_and_universal_data] will help give a better understanding to what it's actually trying to achieve. > Implement Synchronized Disruption into Solr > --- > > Key: SOLR-12672 > URL: https://issues.apache.org/jira/browse/SOLR-12672 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Cahill >Priority: Trivial > Attachments: Synchronized Disruption in Solr.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > On large Solr clusters, at any given time, there is probably an instance > running garbage collection. By implementing a synchronized disruption across > the entire cluster, the response times of a large cluster should decrease as > it helps prevent random instances from running GC while the rest of the > cluster is responding to a request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12672) Implement Synchronized Disruption into Solr
[ https://issues.apache.org/jira/browse/SOLR-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16582829#comment-16582829 ] Trey Cahill commented on SOLR-12672: I've attached a PDF presentation to explain Synchronized Disruption, it's benefits, and resources (specifically, Bloomberg's use of synchronized disruption on HBase). > Implement Synchronized Disruption into Solr > --- > > Key: SOLR-12672 > URL: https://issues.apache.org/jira/browse/SOLR-12672 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Cahill >Priority: Trivial > Attachments: Synchronized Disruption in Solr.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > On large Solr clusters, at any given time, there is probably an instance > running garbage collection. By implementing a synchronized disruption across > the entire cluster, the response times of a large cluster should decrease as > it helps prevent random instances from running GC while the rest of the > cluster is responding to a request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12672) Implement Synchronized Disruption into Solr
Trey Cahill created SOLR-12672: -- Summary: Implement Synchronized Disruption into Solr Key: SOLR-12672 URL: https://issues.apache.org/jira/browse/SOLR-12672 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Trey Cahill Attachments: Synchronized Disruption in Solr.pdf On large Solr clusters, at any given time, there is probably an instance running garbage collection. By implementing a synchronized disruption across the entire cluster, the response times of a large cluster should decrease as it helps prevent random instances from running GC while the rest of the cluster is responding to a request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12672) Implement Synchronized Disruption into Solr
[ https://issues.apache.org/jira/browse/SOLR-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-12672: --- Attachment: Synchronized Disruption in Solr.pdf > Implement Synchronized Disruption into Solr > --- > > Key: SOLR-12672 > URL: https://issues.apache.org/jira/browse/SOLR-12672 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Cahill >Priority: Trivial > Attachments: Synchronized Disruption in Solr.pdf > > > On large Solr clusters, at any given time, there is probably an instance > running garbage collection. By implementing a synchronized disruption across > the entire cluster, the response times of a large cluster should decrease as > it helps prevent random instances from running GC while the rest of the > cluster is responding to a request. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"
[
https://issues.apache.org/jira/browse/SOLR-6630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974743#comment-15974743
]
Trey Cahill commented on SOLR-6630:
---
I'd suggest to rename the implicit router to "userDefined".
I think it would provide the least amount of ambiguity to a new user, as when
using it, the user defines what shard documents are sent too.
> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
> Issue Type: Task
> Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
> all my documents end up on just one of my 24 shards. What
> might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router. that means that
> documents will be indexed on the shard you sent them
> to, not
> routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
> impression that implicit router would use a hash of the
> uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name. It's technically
> correct,
> but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person. This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead? Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log. Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning. If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822124#comment-15822124 ] Trey Cahill edited comment on SOLR-9952 at 1/13/17 6:32 PM: I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also suggested it). See the attachment "Running Solr on S3.pdf". I tested the backup/restore using the HDFS backup repository (just back up and restore thought). was (Author: cahilltr): I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also suggested it). See the attachment "Running Solr on S3". I tested the backup/restore using the HDFS backup repository (just back up and restore thought). > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev > Attachments: Running Solr on S3.pdf > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822124#comment-15822124 ] Trey Cahill edited comment on SOLR-9952 at 1/13/17 6:32 PM: I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also suggested it). See the attachment "Running Solr on S3.pdf". I tested the backup/restore using the HDFS backup repository (just back up and restore though). was (Author: cahilltr): I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also suggested it). See the attachment "Running Solr on S3.pdf". I tested the backup/restore using the HDFS backup repository (just back up and restore thought). > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev > Attachments: Running Solr on S3.pdf > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822124#comment-15822124 ] Trey Cahill commented on SOLR-9952: --- I've done work to run Solr on S3 via HDFS as [~risdenk] described (he also suggested it). See the attachment "Running Solr on S3". I tested the backup/restore using the HDFS backup repository (just back up and restore thought). > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev > Attachments: Running Solr on S3.pdf > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-9952: -- Attachment: Running Solr on S3.pdf > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev > Attachments: Running Solr on S3.pdf > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9939) Ping handler logs each request twice
[
https://issues.apache.org/jira/browse/SOLR-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15809946#comment-15809946
]
Trey Cahill commented on SOLR-9939:
---
[~mkhludnev] good call on clearing rsp.getToLog(); uploaded a patch that does
just that. Ends up being much cleaner.
> Ping handler logs each request twice
>
>
> Key: SOLR-9939
> URL: https://issues.apache.org/jira/browse/SOLR-9939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.4
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-9939.patch, SOLR-9939.patch
>
>
> Requests to the ping handler are being logged twice. The first line has
> "hits" and the second one doesn't, but other than that they have the same
> info.
> These lines are from a 5.3.2-SNAPSHOT version. In the IRC channel,
> [~ctargett] confirmed that this also happens in 6.4-SNAPSHOT.
> {noformat}
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> hits=400271103 status=0 QTime=4
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> status=0 QTime=4
> {noformat}
> Unless there's a good reason to have it that I'm not aware of, the second log
> should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9939) Ping handler logs each request twice
[
https://issues.apache.org/jira/browse/SOLR-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trey Cahill updated SOLR-9939:
--
Attachment: SOLR-9939.patch
> Ping handler logs each request twice
>
>
> Key: SOLR-9939
> URL: https://issues.apache.org/jira/browse/SOLR-9939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.4
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-9939.patch, SOLR-9939.patch
>
>
> Requests to the ping handler are being logged twice. The first line has
> "hits" and the second one doesn't, but other than that they have the same
> info.
> These lines are from a 5.3.2-SNAPSHOT version. In the IRC channel,
> [~ctargett] confirmed that this also happens in 6.4-SNAPSHOT.
> {noformat}
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> hits=400271103 status=0 QTime=4
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> status=0 QTime=4
> {noformat}
> Unless there's a good reason to have it that I'm not aware of, the second log
> should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9939) Ping handler logs each request twice
[
https://issues.apache.org/jira/browse/SOLR-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15808037#comment-15808037
]
Trey Cahill commented on SOLR-9939:
---
The uploaded patch will filter the second request logging line from the Ping
request.
Looking at the thread dump
https://gist.github.com/cahilltr/e957857b7893c871022551f0e4daab28, it looks
like SolrCore.execute() is called twice, which has request logging code in it
(https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/SolrCore.java#L2327).
Not sure if this is intended or filtering the second log message is sufficient.
> Ping handler logs each request twice
>
>
> Key: SOLR-9939
> URL: https://issues.apache.org/jira/browse/SOLR-9939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.4
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-9939.patch
>
>
> Requests to the ping handler are being logged twice. The first line has
> "hits" and the second one doesn't, but other than that they have the same
> info.
> These lines are from a 5.3.2-SNAPSHOT version. In the IRC channel,
> [~ctargett] confirmed that this also happens in 6.4-SNAPSHOT.
> {noformat}
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> hits=400271103 status=0 QTime=4
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> status=0 QTime=4
> {noformat}
> Unless there's a good reason to have it that I'm not aware of, the second log
> should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9939) Ping handler logs each request twice
[
https://issues.apache.org/jira/browse/SOLR-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trey Cahill updated SOLR-9939:
--
Attachment: SOLR-9939.patch
> Ping handler logs each request twice
>
>
> Key: SOLR-9939
> URL: https://issues.apache.org/jira/browse/SOLR-9939
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.4
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-9939.patch
>
>
> Requests to the ping handler are being logged twice. The first line has
> "hits" and the second one doesn't, but other than that they have the same
> info.
> These lines are from a 5.3.2-SNAPSHOT version. In the IRC channel,
> [~ctargett] confirmed that this also happens in 6.4-SNAPSHOT.
> {noformat}
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> hits=400271103 status=0 QTime=4
> 2017-01-06 14:16:37.253 INFO (qtp1510067370-186262) [ x:sparkmain]
> or.ap.so.co.So.Request [sparkmain] webapp=/solr path=/admin/ping params={}
> status=0 QTime=4
> {noformat}
> Unless there's a good reason to have it that I'm not aware of, the second log
> should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8787) TestAuthenticationFramework should not extend TestMiniSolrCloudCluster
[ https://issues.apache.org/jira/browse/SOLR-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312465#comment-15312465 ] Trey Cahill commented on SOLR-8787: --- Added patch, which changes TestAuthenticationFramework to extend LuceneTestCase and not TestMiniSolrCloudCluster. Used functions from TestMiniSolrCloudCluster, but removed any non-needed operations/etc. > TestAuthenticationFramework should not extend TestMiniSolrCloudCluster > -- > > Key: SOLR-8787 > URL: https://issues.apache.org/jira/browse/SOLR-8787 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Shalin Shekhar Mangar >Priority: Minor > Labels: difficulty-easy, newdev > Fix For: 6.0, 6.1 > > Attachments: SOLR-8787.patch > > > TestAuthenticationFramework should not extend TestMiniSolrCloudCluster. The > TestMiniSolrCloudCluster is actually a test for MiniSolrCloudCluster and not > a generic test framework class. I saw a local failure for > TestAuthenticationFramework.testSegmentTerminateEarly which should never be > executed in the first place. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8787) TestAuthenticationFramework should not extend TestMiniSolrCloudCluster
[ https://issues.apache.org/jira/browse/SOLR-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8787: -- Attachment: SOLR-8787.patch > TestAuthenticationFramework should not extend TestMiniSolrCloudCluster > -- > > Key: SOLR-8787 > URL: https://issues.apache.org/jira/browse/SOLR-8787 > Project: Solr > Issue Type: Bug > Components: Tests >Reporter: Shalin Shekhar Mangar >Priority: Minor > Labels: difficulty-easy, newdev > Fix For: 6.0, 6.1 > > Attachments: SOLR-8787.patch > > > TestAuthenticationFramework should not extend TestMiniSolrCloudCluster. The > TestMiniSolrCloudCluster is actually a test for MiniSolrCloudCluster and not > a generic test framework class. I saw a local failure for > TestAuthenticationFramework.testSegmentTerminateEarly which should never be > executed in the first place. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8955) ReplicationHandler should throttle across all requests instead of for each client
[ https://issues.apache.org/jira/browse/SOLR-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15311049#comment-15311049 ] Trey Cahill commented on SOLR-8955: --- I uploaded a patch that will enable throttling for all requests, which is configurable (as per [~gpendleb] request), instead of throttling for each client by setting the parameter "globalthrottling=true". There's a few thing's that I'm not sure about in creating the patch: 1) Is having the parameter "globalthrottling" the best way to set/configure throttling? 2) Is this the best way to throttle for all requests to a node? 3) The best way to test this; currently, the patch uses test cases that started out as copies of the testRateLimitedReplication(). > ReplicationHandler should throttle across all requests instead of for each > client > - > > Key: SOLR-8955 > URL: https://issues.apache.org/jira/browse/SOLR-8955 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Shalin Shekhar Mangar > Labels: difficulty-easy, impact-medium, newdev > Fix For: 6.0, 6.1 > > Attachments: SOLR-8955.patch > > > SOLR-6485 added the ability to throttle the speed of replication but the > implementation rate limits each request. So e.g. the maxWriteMBPerSec is 1 > and 5 slaves request full replication then the effective transfer rate from > the master is 5 MB/second which is not what is often desired. > I propose to make the rate limit global (across all replication requests) > instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8955) ReplicationHandler should throttle across all requests instead of for each client
[ https://issues.apache.org/jira/browse/SOLR-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8955: -- Attachment: SOLR-8955.patch > ReplicationHandler should throttle across all requests instead of for each > client > - > > Key: SOLR-8955 > URL: https://issues.apache.org/jira/browse/SOLR-8955 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Shalin Shekhar Mangar > Labels: difficulty-easy, impact-medium, newdev > Fix For: 6.0, 6.1 > > Attachments: SOLR-8955.patch > > > SOLR-6485 added the ability to throttle the speed of replication but the > implementation rate limits each request. So e.g. the maxWriteMBPerSec is 1 > and 5 slaves request full replication then the effective transfer rate from > the master is 5 MB/second which is not what is often desired. > I propose to make the rate limit global (across all replication requests) > instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8823: -- Attachment: SOLR-8823.patch > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden >Assignee: Kevin Risden > Attachments: SOLR-8823.patch, SOLR-8823.patch, SOLR-8823.patch, > SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251998#comment-15251998 ] Trey Cahill commented on SOLR-8823: --- [~risdenk] Uploaded a patch make the code be more generic. The patch now only makes request to nodes that a collection is on. Also getUniqueKey short circuits now. I did not find a good place for constants like "TABLE_CAT". > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden >Assignee: Kevin Risden > Attachments: SOLR-8823.patch, SOLR-8823.patch, SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8823: -- Attachment: SOLR-8823.patch > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden >Assignee: Kevin Risden > Attachments: SOLR-8823.patch, SOLR-8823.patch, SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8823: -- Attachment: (was: SOLR-8823.patch) > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden >Assignee: Kevin Risden > Attachments: SOLR-8823.patch, SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8823: -- Attachment: SOLR-8823.patch > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden >Assignee: Kevin Risden > Attachments: SOLR-8823.patch, SOLR-8823.patch, SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8847) SolrJ JDBC - Implement "Select *"
[ https://issues.apache.org/jira/browse/SOLR-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204883#comment-15204883 ] Trey Cahill commented on SOLR-8847: --- Added a patch to handle "Select *". It is based off of SOLR-8823, which implements the getColumns that "Select *" uses when rewriting the query. > SolrJ JDBC - Implement "Select *" > -- > > Key: SOLR-8847 > URL: https://issues.apache.org/jira/browse/SOLR-8847 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Trey Cahill > Attachments: SOLR-8847.patch > > > The sql query "Select *" is commonly used, but currently all fields need to > be specified. This can cause some troubles as "Select *" has been used to > pull back column metadata in some JDBC clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8847) SolrJ JDBC - Implement "Select *"
[ https://issues.apache.org/jira/browse/SOLR-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8847: -- Attachment: SOLR-8847.patch > SolrJ JDBC - Implement "Select *" > -- > > Key: SOLR-8847 > URL: https://issues.apache.org/jira/browse/SOLR-8847 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Trey Cahill > Attachments: SOLR-8847.patch > > > The sql query "Select *" is commonly used, but currently all fields need to > be specified. This can cause some troubles as "Select *" has been used to > pull back column metadata in some JDBC clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8819: -- Attachment: SOLR-8819.patch > Implement DatabaseMetaDataImpl getTables() and fix getSchemas() > --- > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden > Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, > SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch > > > DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if > double click on "DB" under connection name then click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15198245#comment-15198245 ] Trey Cahill commented on SOLR-8823: --- Added a patch to get table "columns" from the Solr Collection's fields using a Luke Request and getting the unique key via a SchemaRequest.UniqueKey request. > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Kevin Risden > Attachments: SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197303#comment-15197303 ] Trey Cahill commented on SOLR-8819: --- Was seeing NPE's at times when using DBVisualizer made calls to getTables(). Was able to trace the issue back to a null ZKStateReader in the cloudSolrClient. Calling cloudSolrClient.connect() prevents this from happening. > Implement DatabaseMetaDataImpl getTables() and fix getSchemas() > --- > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden > Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, > SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch > > > DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if > double click on "DB" under connection name then click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8819: -- Attachment: SOLR-8819.patch > Implement DatabaseMetaDataImpl getTables() and fix getSchemas() > --- > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden > Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, > SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch > > > DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if > double click on "DB" under connection name then click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)
[ https://issues.apache.org/jira/browse/SOLR-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8823: -- Attachment: SOLR-8823.patch > Implement DatabaseMetaDataImpl.getColumns(String catalog, String > schemaPattern, String tableNamePattern, String columnNamePattern) > -- > > Key: SOLR-8823 > URL: https://issues.apache.org/jira/browse/SOLR-8823 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Kevin Risden > Attachments: SOLR-8823.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200226#comment-15200226 ] Trey Cahill commented on SOLR-8819: --- [~joel.bernstein] I removed alias support and renamed TablesStreams to TableStream. Also updated the get on cloudSolrClient.getZKStateReader() to only get once instead of twice. > Implement DatabaseMetaDataImpl getTables() and fix getSchemas() > --- > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master, 6.0 >Reporter: Kevin Risden > Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, > SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch > > > DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if > double click on "DB" under connection name then click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15195676#comment-15195676 ] Trey Cahill commented on SOLR-8819: --- Added the ability for Collection Aliases to be considered their own databases and added tests as needed. > Implement DatabaseMetaDataImpl getTables() and fix getSchemas() > --- > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Kevin Risden > Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, > SOLR-8819.patch, SOLR-8819.patch > > > DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if > double click on "DB" under connection name then click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8819) Implement DatabaseMetaDataImpl getTables() and fix getSchemas()
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8819: -- Attachment: SOLR-8819.patch > Implement DatabaseMetaDataImpl getTables() and fix getSchemas() > --- > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Kevin Risden > Attachments: SOLR-8819.patch, SOLR-8819.patch, SOLR-8819.patch, > SOLR-8819.patch, SOLR-8819.patch > > > DbVisualizer NPE when clicking on DB References tab. After connecting, NPE if > double click on "DB" under connection name then click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8847) SolrJ JDBC - Implement "Select *"
[ https://issues.apache.org/jira/browse/SOLR-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8847: -- Issue Type: Sub-task (was: Improvement) Parent: SOLR-8659 > SolrJ JDBC - Implement "Select *" > -- > > Key: SOLR-8847 > URL: https://issues.apache.org/jira/browse/SOLR-8847 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Trey Cahill > > The sql query "Select *" is commonly used, but currently all fields need to > be specified. This can cause some troubles as "Select *" has been used to > pull back column metadata in some JDBC clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8847) SolrJ JDBC - Implement "Select *"
Trey Cahill created SOLR-8847: - Summary: SolrJ JDBC - Implement "Select *" Key: SOLR-8847 URL: https://issues.apache.org/jira/browse/SOLR-8847 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: master Reporter: Trey Cahill The sql query "Select *" is commonly used, but currently all fields need to be specified. This can cause some troubles as "Select *" has been used to pull back column metadata in some JDBC clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8846) SolrJ JDBC - SparkSQL documentation
[ https://issues.apache.org/jira/browse/SOLR-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8846: -- Issue Type: Sub-task (was: Improvement) Parent: SOLR-8659 > SolrJ JDBC - SparkSQL documentation > --- > > Key: SOLR-8846 > URL: https://issues.apache.org/jira/browse/SOLR-8846 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Trey Cahill > > Like SOLR-8521, it would be great to document how SparkSQL can be used with > SolrJ JDBC. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8845) SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC
[ https://issues.apache.org/jira/browse/SOLR-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8845: -- Issue Type: Sub-task (was: Improvement) Parent: SOLR-8659 > SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC > --- > > Key: SOLR-8845 > URL: https://issues.apache.org/jira/browse/SOLR-8845 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Trey Cahill > > Ensure that SparkSQL is able work with SolrJ JDBC. > Currently, in Spark 1.6 there are 2 known issues: > 1. SparkSQL uses a connection.prepareStatement() call, which returns null in > the SolrJ implementation > 2. SparkSQL query's via a "select *" query, which is currently not supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8846) SolrJ JDBC - SparkSQL documentation
Trey Cahill created SOLR-8846: - Summary: SolrJ JDBC - SparkSQL documentation Key: SOLR-8846 URL: https://issues.apache.org/jira/browse/SOLR-8846 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: master Reporter: Trey Cahill Like SOLR-8521, it would be great to document how SparkSQL can be used with SolrJ JDBC. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8845) SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC
Trey Cahill created SOLR-8845: - Summary: SolrJ JDBC - Ensure that SparkSQL works with SolrJ JDBC Key: SOLR-8845 URL: https://issues.apache.org/jira/browse/SOLR-8845 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: master Reporter: Trey Cahill Ensure that SparkSQL is able work with SolrJ JDBC. Currently, in Spark 1.6 there are 2 known issues: 1. SparkSQL uses a connection.prepareStatement() call, which returns null in the SolrJ implementation 2. SparkSQL query's via a "select *" query, which is currently not supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8819) SolrJ JDBC - DbVisualizer NPE when clicking on DB References tab
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190101#comment-15190101 ] Trey Cahill commented on SOLR-8819: --- Added a patch that fixes the NPE caused by clicking on the DB References tab by implementing the getTables() method in DatabaseMetaDataImpl. Removed restriction of requiring the field "TABLE_CAT" when querying _CATALOGS_ by wrapping CatalogsStream in SelectStream. Removed restriction of requiring the both the fields "TABLE_SCHEM" and "TABLE_CATALOG" when querying _SCHEMAS_ by wrapping SchemasStream in SelectStream. Added tests as needed. > SolrJ JDBC - DbVisualizer NPE when clicking on DB References tab > > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Kevin Risden > Attachments: SOLR-8819.patch > > > After connecting, NPE if double click on "DB" under connection name then > click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8819) SolrJ JDBC - DbVisualizer NPE when clicking on DB References tab
[ https://issues.apache.org/jira/browse/SOLR-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trey Cahill updated SOLR-8819: -- Attachment: SOLR-8819.patch > SolrJ JDBC - DbVisualizer NPE when clicking on DB References tab > > > Key: SOLR-8819 > URL: https://issues.apache.org/jira/browse/SOLR-8819 > Project: Solr > Issue Type: Sub-task > Components: SolrJ >Affects Versions: master >Reporter: Kevin Risden > Attachments: SOLR-8819.patch > > > After connecting, NPE if double click on "DB" under connection name then > click on References tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
