[jira] [Commented] (SOLR-13724) Reject v1 API updates for (non-routed) multi-collection aliases
[
https://issues.apache.org/jira/browse/SOLR-13724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918122#comment-16918122
]
Jason Gerlowski commented on SOLR-13724:
Here's a quick way to reproduce the behavior:
{code}
➜ solr git:(fcbe46c28ce) ✗ bin/solr start -c
Waiting up to 180 seconds to see Solr running on port 8983 [\]
Started Solr server on port 8983 (pid=20921). Happy searching!
➜ solr git:(fcbe46c28ce) ✗ bin/solr create -c foo
Created collection 'foo' with 1 shard(s), 1 replica(s) with config-set 'foo'
➜ solr git:(fcbe46c28ce) ✗ bin/solr create -c bar
Created collection 'bar' with 1 shard(s), 1 replica(s) with config-set 'bar'
➜ solr git:(fcbe46c28ce) ✗ curl -ilk -X GET
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=my_alias=foo,bar;
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 57
{
"responseHeader":{
"status":0,
"QTime":128}}
➜ solr git:(fcbe46c28ce) ✗ curl -ilk -X POST -H "Content-type:
application/json" "http://localhost:8983/solr/my_alias/update?commit=true; -d
'[{"id": "asdf", "val_i": 4}]'
HTTP/1.1 200 OK
Content-Type: text/plain;charset=utf-8
Content-Length: 69
{
"responseHeader":{
"rf":1,
"status":0,
"QTime":373}}
{code}
> Reject v1 API updates for (non-routed) multi-collection aliases
> ---
>
> Key: SOLR-13724
> URL: https://issues.apache.org/jira/browse/SOLR-13724
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1, master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> The intent of SOLR-13407 was to block all updates on aliases that represent
> multiple collections. Currently, this works for deletes, commits, and
> optimize requests. Users get a message like: {{Update request to non-routed
> multi-collection alias not supported}}.
> But currently we still allow document adds/updates to go through.
> We should either close this last hole, so _no_ update requests are allowed,
> or document it so the behavior clearer.
--
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-13724) Reject v1 API updates for (non-routed) multi-collection aliases
Jason Gerlowski created SOLR-13724:
--
Summary: Reject v1 API updates for (non-routed) multi-collection
aliases
Key: SOLR-13724
URL: https://issues.apache.org/jira/browse/SOLR-13724
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.1, master (9.0)
Reporter: Jason Gerlowski
The intent of SOLR-13407 was to block all updates on aliases that represent
multiple collections. Currently, this works for deletes, commits, and optimize
requests. Users get a message like: {{Update request to non-routed
multi-collection alias not supported}}.
But currently we still allow document adds/updates to go through.
We should either close this last hole, so _no_ update requests are allowed, or
document it so the behavior clearer.
--
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-13539) Atomic Update Multivalue remove does not work for field types UUID, Enums, Bool and Binary
[ https://issues.apache.org/jira/browse/SOLR-13539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911848#comment-16911848 ] Jason Gerlowski commented on SOLR-13539: bq. When you say all the cast issues are fixed on master and 8x, does that include the small patch I added to this ticket, for the removeregex multi-value situation? It doesn't. But I have bundled that in with Thomas' changes in my local testing and will make sure it makes it to master and branch_8x. Speaking of which, test "beast" runs look pretty good, so I'll go forward with committing this later this week, or this weekend. > Atomic Update Multivalue remove does not work for field types UUID, Enums, > Bool and Binary > --- > > Key: SOLR-13539 > URL: https://issues.apache.org/jira/browse/SOLR-13539 > Project: Solr > Issue Type: Bug > Components: UpdateRequestProcessors >Affects Versions: 7.7.2, 8.1, 8.1.1 >Reporter: Thomas Wöckinger >Priority: Critical > Attachments: SOLR-13539.patch > > Time Spent: 6h 50m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > This is related to following field types: UUID, Enums, Bool and Binary -- 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=16910929#comment-16910929
]
Jason Gerlowski commented on SOLR-13687:
Sure. My main point was less about url vs zk-conn-string (I think either is
fine...though there is prior art around the ZK_HOST setting). My point was
just that a solr.in.sh property fits well with how other similar things are
done today. Whether you add an explicit flag or not, users would probably
expect this to be set-able in solr.in.sh.
bq. Ideally, we should minimize access to ZK from hosts outside of of solr
nodes. It's a security hole.
Two things about this:
1. ZK has security mechanisms. If you don't use those, then yes, it's a
security hole. But you can say the same thing about a Solr URL if Solr hasn't
been secured.
2. 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 to try abstracting from clients, given
how fundamental it is to Solr. ZK-conn-strings are stickier and more useful to
use in cloud environments, where individual Solr nodes might join and leave a
cluster frequently. etc
That said, I don't really have a dog in the conn-string vs url fight. Just
thinking aloud about pros/cons. I think adding a flag/solr.in.sh option for
either would be an improvement.
> 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] [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=16910728#comment-16910728
]
Jason Gerlowski commented on SOLR-13687:
This is already partially possible: several of the commands above have an
explicit "zk-host" option that allows you to point them at remote clusters.
You can also point at a remote cluster by setting ZK_HOST in solr.in.sh.
If {{create_collection}}, {{delete}}, etc don't accept ZK_HOST currently,
adding ZK_HOST support is probably the easiest and most uniform path forward.
> 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] [Commented] (SOLR-13407) Reject updates sent to non-routed multi collection aliases
[
https://issues.apache.org/jira/browse/SOLR-13407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910567#comment-16910567
]
Jason Gerlowski commented on SOLR-13407:
Hey [~ab], I noticed recently that I can seemingly still use (standard) aliases
to index documents.
Am I missing something here? I ran {{git checkout
releases/lucene-solr/8.1.1}}, rebuilt, and can still see the behavior below:
{code}
➜ solr git:(fcbe46c28ce) ✗ bin/solr start -c
Waiting up to 180 seconds to see Solr running on port 8983 [\]
Started Solr server on port 8983 (pid=20921). Happy searching!
➜ solr git:(fcbe46c28ce) ✗ bin/solr create -c foo
Created collection 'foo' with 1 shard(s), 1 replica(s) with config-set 'foo'
➜ solr git:(fcbe46c28ce) ✗ bin/solr create -c bar
Created collection 'bar' with 1 shard(s), 1 replica(s) with config-set 'bar'
➜ solr git:(fcbe46c28ce) ✗ curl -ilk -X GET
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=my_alias=foo,bar;
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 57
{
"responseHeader":{
"status":0,
"QTime":128}}
➜ solr git:(fcbe46c28ce) ✗ curl -ilk -X POST -H "Content-type:
application/json" "http://localhost:8983/solr/my_alias/update?commit=true; -d
'[{"id": "asdf", "val_i": 4}]'
HTTP/1.1 200 OK
Content-Type: text/plain;charset=utf-8
Content-Length: 69
{
"responseHeader":{
"rf":1,
"status":0,
"QTime":373}}
{code}
> Reject updates sent to non-routed multi collection aliases
> --
>
> Key: SOLR-13407
> URL: https://issues.apache.org/jira/browse/SOLR-13407
> Project: Solr
> Issue Type: Improvement
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13407.patch
>
>
> Spin-off from SOLR-13262.
> Currently Solr uses a convention that updates sent to multi-collection
> aliases are applied only to the first collection on the list, which is
> nonintuitive and may hide bugs or accidental configuration changes made
> either in Solr or in client applications.
> This issue proposes to reject all such updates with an error.
--
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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-13622. Resolution: Fixed fucit.org doesn't show any StreamExpressionTest failures in the last 4 days, so I'm closing this accordingly. Thanks again for catching the test issue Hoss, that's my bad. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13539) Atomic Update Multivalue remove does not work for field types UUID, Enums, Bool and Binary
[
https://issues.apache.org/jira/browse/SOLR-13539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904660#comment-16904660
]
Jason Gerlowski commented on SOLR-13539:
bq. To be honest, this whole situation with the javabin change is getting
confusing, with various partial fixes
I agree, the situation has become quite confused. Partially to blame is my
slowness in reviewing some of Thomas' PRs. Also contributing is that this bug
was found and reported in a handful of different JIRAs, each reporting various
levels of progress and not kept up to date.
(This is worth apologizing again for: I thought tags on github PRs were making
it through my email filters, but apparently not. My inattention on Thomas'
PR's is embarassing. Sorry Thomas. I'm glad you tagged me on jira.)
So let's try to clarify. My understanding is that all of the atomic-update
ByteArrayUtf8CharSequence cast issues have been fixed on {{master}} and
{{branch_8x}}. All the remaining open PRs are test improvements. Thomas has
two PR's open: PR #665 and PR #755. It looks to me like #665 depends on #755
(755 introduces a new test-base, 665 changes some existing tests to use this
new class). And Tim has proposed some additional unit tests in SOLR-9505 (as
well as suggesting a change to our documentation). At a glance both of these
sets of test changes are complimentary to each other, and we can merge both of
them after review.
Does that match your understanding of things [~thomas.woeckinger]?
bq. it's not clear to me which fixes are on the 7.x branch. Right now, 7.7.2
standard is effectively broken.
Thomas is right- I haven't made an attempt to backport this to the 7x code
line. Primarily because I don't expect any more 7x releases. There might be a
7.7.3 if some serious security issue is found, but even in that case the aim
would be to introduce as little change into 7.7.3 as possible, and only fix the
security issue itself. I can make a case for backporting if a 7.7.3 comes up,
but there might be pushback depending on the release manager.
> Atomic Update Multivalue remove does not work for field types UUID, Enums,
> Bool and Binary
> ---
>
> Key: SOLR-13539
> URL: https://issues.apache.org/jira/browse/SOLR-13539
> Project: Solr
> Issue Type: Bug
> Components: UpdateRequestProcessors
>Affects Versions: 7.7.2, 8.1, 8.1.1
>Reporter: Thomas Wöckinger
>Priority: Critical
> Attachments: SOLR-13539.patch
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> When using JavaBinCodec the values of collections are of type
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove
> Operation does not have any effect.
> This is related to following field types: UUID, Enums, Bool and Binary
--
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-13573) Add getters to SolrRangeQuery for lower and upper values
[ https://issues.apache.org/jira/browse/SOLR-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13573: --- Resolution: Fixed Fix Version/s: 8.3 master (9.0) Status: Resolved (was: Patch Available) Hey Brian, Thanks for the suggestion and the patch. I've committed this and you should see it available starting in 8.3 > Add getters to SolrRangeQuery for lower and upper values > > > Key: SOLR-13573 > URL: https://issues.apache.org/jira/browse/SOLR-13573 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.7, 8.1.1 >Reporter: Brian Rhees >Assignee: Jason Gerlowski >Priority: Minor > Fix For: master (9.0), 8.3 > > Attachments: SOLR-13573.patch > > > SolrRangeQuery has no getters for the lower/upper values once set (other than > calling toString). Adding getters will help users extract those values after > an object has been created. -- 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-13573) Add getters to SolrRangeQuery for lower and upper values
[ https://issues.apache.org/jira/browse/SOLR-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-13573: -- Assignee: Jason Gerlowski > Add getters to SolrRangeQuery for lower and upper values > > > Key: SOLR-13573 > URL: https://issues.apache.org/jira/browse/SOLR-13573 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.7, 8.1.1 >Reporter: Brian Rhees >Assignee: Jason Gerlowski >Priority: Minor > Attachments: SOLR-13573.patch > > > SolrRangeQuery has no getters for the lower/upper values once set (other than > calling toString). Adding getters will help users extract those values after > an object has been created. -- 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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902933#comment-16902933 ] Jason Gerlowski commented on SOLR-13622: The test issue should be resolved now; thanks for pointing it out Hoss. I'll close this in a few days if the test failures on Windows are truly resolved. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902342#comment-16902342 ] Jason Gerlowski commented on SOLR-13622: Sorry, that's my mistake. Dumb mistake. I'll fix it right away. Joel, I'll do the rename while I'm at it. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900113#comment-16900113 ] Jason Gerlowski commented on SOLR-13622: That rename would be fine with me. I'm not strongly attached to the name. But if we change it we'll have to remember to update the ref-guide docs as well. Are you going to make this change or would you like me to? > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13649) BasicAuth's 'blockUnknown' param should default to true
[
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898014#comment-16898014
]
Jason Gerlowski commented on SOLR-13649:
I agree with Noble that this is a backwards compatible change. But if we hold
off on introducing it until 9.0, I don't see any problems with that. We direct
users to re-evaluate all config files on a major version upgrade already. So
the only people who might be bitten by this change in defaults would have to be
(1) going against that prescribed update step and (2) not paying attention to
the release notes and CHANGES.txt where this is called out.
It might take a little extra documentation in the short term (a bullet point in
release-notes), and I'm all for avoiding documentation bloat. But I think
keeping the docs concise needs to be secondary to making security easy to get
right.
[~janhoy] I'm +1 on seeing this change happen, assuming it's made clear in
release notes and only introduced at the major version.
> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the
> {{blockUnknown}} parameter, the default value is {{false}}. That default
> behavior is a bit counterintuitive because if someone wishes to enable basic
> authentication, you would expect that they would want all unknown users to
> need to authenticate by default. I can imagine cases where you would not, but
> those cases would be less frequent.
--
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-13649) BasicAuth's 'blockUnknown' param should default to true
[
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-13649:
---
Summary: BasicAuth's 'blockUnknown' param should default to true (was:
When Using Basic Authentication, the blockUnknown Value should be True)
> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
>Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the
> {{blockUnknown}} parameter, the default value is {{false}}. That default
> behavior is a bit counterintuitive because if someone wishes to enable basic
> authentication, you would expect that they would want all unknown users to
> need to authenticate by default. I can imagine cases where you would not, but
> those cases would be less frequent.
--
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-13629) Remove trailing whitespace from analytics package
[ https://issues.apache.org/jira/browse/SOLR-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13629: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Remove trailing whitespace from analytics package > - > > Key: SOLR-13629 > URL: https://issues.apache.org/jira/browse/SOLR-13629 > Project: Solr > Issue Type: Task >Affects Versions: 8.1.1 >Reporter: Neal Sidhwaney >Assignee: Jason Gerlowski >Priority: Trivial > Attachments: SOLR-13629.patch > > > I"m making some changes to analytics and noticed that the guidelines ask to > create separate patches for formatting/whitespace changes. This issue is > meant for the patch to remove trailing whitespace, but preserves newlines if > the trailing whitespace was on a line with only whitespace. -- 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-13629) Remove trailing whitespace from analytics package
[ https://issues.apache.org/jira/browse/SOLR-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894832#comment-16894832 ] Jason Gerlowski commented on SOLR-13629: Thanks for separating out your changes Neal. Merged your path to master and branch_8x. > Remove trailing whitespace from analytics package > - > > Key: SOLR-13629 > URL: https://issues.apache.org/jira/browse/SOLR-13629 > Project: Solr > Issue Type: Task >Affects Versions: 8.1.1 >Reporter: Neal Sidhwaney >Assignee: Jason Gerlowski >Priority: Trivial > Attachments: SOLR-13629.patch > > > I"m making some changes to analytics and noticed that the guidelines ask to > create separate patches for formatting/whitespace changes. This issue is > meant for the patch to remove trailing whitespace, but preserves newlines if > the trailing whitespace was on a line with only whitespace. -- 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-13629) Remove trailing whitespace from analytics package
[ https://issues.apache.org/jira/browse/SOLR-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-13629: -- Assignee: Jason Gerlowski > Remove trailing whitespace from analytics package > - > > Key: SOLR-13629 > URL: https://issues.apache.org/jira/browse/SOLR-13629 > Project: Solr > Issue Type: Task >Affects Versions: 8.1.1 >Reporter: Neal Sidhwaney >Assignee: Jason Gerlowski >Priority: Trivial > Attachments: SOLR-13629.patch > > > I"m making some changes to analytics and noticed that the guidelines ask to > create separate patches for formatting/whitespace changes. This issue is > meant for the patch to remove trailing whitespace, but preserves newlines if > the trailing whitespace was on a line with only whitespace. -- 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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-13622. Resolution: Fixed Fix Version/s: 8.3 > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892736#comment-16892736
]
Jason Gerlowski commented on SOLR-13622:
I merged the initial version of this to {{master}} and {{branch_8x}}. I only
made two changes of note since my last post here:
* I changed the name of the expression from {{fileStream}} to {{files}}.
* I changed the chroot to be based out of a directory called
{{$SOLR_HOME/userfiles}}. The {{userfiles}} directory gets created if it
doesn't exist upon Solr startup and users can put files in after that point.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
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-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-13622:
---
Attachment: SOLR-13622.patch
Status: Open (was: Open)
This is getting pretty close to committing. I've fixed the argument formatting
errors for {{fileStream}}, changed the paths to be relative to the core's data
directory, and added tests.
Going to let this sit for a day or two while I work on docs and then commit.
One thing in particular that I'd like feedback on is what to use as the
root/sandbox dir that provided filepaths are relative to. Right now this patch
uses the data directory for the particular Solr core that processes the
request. This might be inconvenient though for users whose cores aren't
stationary: users manually adding/removing replicas, users with autoscaling
enabled, etc. Maybe having paths relative to SOLR_HOME (and not
core/collection specific) would be a better optionhappy to get feedback
here.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch, SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
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-13600) Basic Authentication for read role is not working
[
https://issues.apache.org/jira/browse/SOLR-13600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-13600.
Resolution: Invalid
> Basic Authentication for read role is not working
> -
>
> Key: SOLR-13600
> URL: https://issues.apache.org/jira/browse/SOLR-13600
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authorization
>Affects Versions: 8.1.1
> Environment: DEV environment
>Reporter: Nitin Asati
>Priority: Major
> Labels: security
>
> Hello Team,
> I have upgraded the SOLR instance from 7.x to 8.1.1 and my READ role users
> are not able to search results.
> Upon trying to access below URL, getting the error:
> [http://localhost:8984/solr/testcore/select?q=*%3A*|http://localhost:8984/solr/xcelerate/select?q=*%3A*]
> h2. HTTP ERROR 403
> Problem accessing /solr/xcelerate/select. Reason:
> Unauthorized request, Response code: 403
>
> Below is the content of security.json file.
>
> {
> "authentication":{
> "blockUnknown":true,
> "class":"solr.BasicAuthPlugin",
> "credentials":{
> "solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=",
> "searchuser":"hzx9wjm6baNqx08LpfevT8dNaojdMqIJMAF8cXanL1o=
> CLDitkrBjs2FbqhOZN9Ey9Qc+5xcOJHfQTbPMC2p1eU=",
> "solradmin":"ovgoJKFnFo43fgt5Pd7bfXBwq3+vfCO3uZXVRUi7H0Q=
> gKRUTDGkg5RtTIgXDiKFkefuaelAWU18KlRTAv4LfFQ="},
> "realm":"My Solr users",
> "forwardCredentials":false,
> "":\{"v":0}},
> "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "permissions":[
> {
> "name":"all",
> "role":"admin",
> "index":1},
> {
> "name":"read",
> "role":"search",
> "index":2}],
> "user-role":{
> "solr":"admin",
> "searchuser":["read"],
> "solradmin":["admin"]},
> "":\{"v":0}}}
--
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-13600) Basic Authentication for read role is not working
[
https://issues.apache.org/jira/browse/SOLR-13600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16886083#comment-16886083
]
Jason Gerlowski commented on SOLR-13600:
The Solr JIRA is not a support portal. We try to keep it clear of everything
except confirmed bugs and proposed improvements.
If you're still looking for help with this issue, please start a thread on the
solr-user mailing list or ask in our IRC channel.
(Before doing so, you might want to read some about what order permissions are
evaluated in, and how that can affect authz results. "all" rules should almost
always come last in your security.json.)
> Basic Authentication for read role is not working
> -
>
> Key: SOLR-13600
> URL: https://issues.apache.org/jira/browse/SOLR-13600
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authorization
>Affects Versions: 8.1.1
> Environment: DEV environment
>Reporter: Nitin Asati
>Priority: Major
> Labels: security
>
> Hello Team,
> I have upgraded the SOLR instance from 7.x to 8.1.1 and my READ role users
> are not able to search results.
> Upon trying to access below URL, getting the error:
> [http://localhost:8984/solr/testcore/select?q=*%3A*|http://localhost:8984/solr/xcelerate/select?q=*%3A*]
> h2. HTTP ERROR 403
> Problem accessing /solr/xcelerate/select. Reason:
> Unauthorized request, Response code: 403
>
> Below is the content of security.json file.
>
> {
> "authentication":{
> "blockUnknown":true,
> "class":"solr.BasicAuthPlugin",
> "credentials":{
> "solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=",
> "searchuser":"hzx9wjm6baNqx08LpfevT8dNaojdMqIJMAF8cXanL1o=
> CLDitkrBjs2FbqhOZN9Ey9Qc+5xcOJHfQTbPMC2p1eU=",
> "solradmin":"ovgoJKFnFo43fgt5Pd7bfXBwq3+vfCO3uZXVRUi7H0Q=
> gKRUTDGkg5RtTIgXDiKFkefuaelAWU18KlRTAv4LfFQ="},
> "realm":"My Solr users",
> "forwardCredentials":false,
> "":\{"v":0}},
> "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "permissions":[
> {
> "name":"all",
> "role":"admin",
> "index":1},
> {
> "name":"read",
> "role":"search",
> "index":2}],
> "user-role":{
> "solr":"admin",
> "searchuser":["read"],
> "solradmin":["admin"]},
> "":\{"v":0}}}
--
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-13638) Add verbose debug/trace logging to RuleBasedAuthorizationPlugin
[
https://issues.apache.org/jira/browse/SOLR-13638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-13638:
---
Attachment: SOLR-13638.patch
Status: Open (was: Open)
I've attached a patch with some logging that I've found useful in the past.
* at 'debug' level, administrators get information about which rule-group is
being checked currently (admin rules, rules for the specific collection, rules
for all ("*") collections, etc.), which rule is eventually chosen to govern the
request, and the result.
* at 'trace' level, administrators see the list of rules belonging to each
group, and an explanation of why each rule does or doesn't match the given
request.
Right now to get this logging, Solr administrators would have to bump the
log-level for org.apache.solr.security.RuleBasedAuthorizationPlugin to debug or
trace. This is fine in test and development clusters, but in busy clusters
handling a lot of requests this might produce tons of noise. Another idea I
was toying with was introducing a {{debugAuth=true}} query-parameter flag that
users could include on their request to trigger this additional logging. It's
a little hacky, but it would make it easier to isolate the debug information
for a single given request. I'll probably steer clear of it, unless anyone
particularly likes the idea.
> Add verbose debug/trace logging to RuleBasedAuthorizationPlugin
> ---
>
> Key: SOLR-13638
> URL: https://issues.apache.org/jira/browse/SOLR-13638
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13638.patch
>
>
> Every so often I find myself trying to understand why the
> {{RuleBasedAuthorizationPlugin}} rules in my security.json produce the
> results they do. This would be much easier to troubleshoot if the class had
> logging (either under DEBUG, or TRACE) that was verbose enough to figure out
> what order rules were checked in, and why particular rules didn't match a
> given request.
> This jira covers adding logging that can help administrators better
> understand issues with their security.json.
--
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-13638) Add verbose debug/trace logging to RuleBasedAuthorizationPlugin
Jason Gerlowski created SOLR-13638:
--
Summary: Add verbose debug/trace logging to
RuleBasedAuthorizationPlugin
Key: SOLR-13638
URL: https://issues.apache.org/jira/browse/SOLR-13638
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: security
Affects Versions: master (9.0)
Reporter: Jason Gerlowski
Assignee: Jason Gerlowski
Every so often I find myself trying to understand why the
{{RuleBasedAuthorizationPlugin}} rules in my security.json produce the results
they do. This would be much easier to troubleshoot if the class had logging
(either under DEBUG, or TRACE) that was verbose enough to figure out what order
rules were checked in, and why particular rules didn't match a given request.
This jira covers adding logging that can help administrators better understand
issues with their security.json.
--
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-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized
[
https://issues.apache.org/jira/browse/SOLR-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16885194#comment-16885194
]
Jason Gerlowski commented on SOLR-13472:
bq. Attaching a patch. As per this, the authorization should only be performed
on a node if the request is to be executed on that node. Skips authorization on
a node if the request has to be forwarded to another node.
I like the simplicity of this approach, but have one doubt/concern. Is it a
security/performance issue to be forwarding requests around internally that we
haven't validated yet? The more file-handles, request threads, etc. Solr
spends on requests that haven't been auth'd yet, the easier it would be (in
theory) for a malicious user to gum up the system.
That said, "in theory" is a long way from "in practice". Maybe the additional
resources spent forwarding requests on that would previously have been rejected
at the receiving node are negligible and wouldn't have any sort of real world
impact. Just curious whether you considered or experimented with this at all?
> HTTP requests to a node that does not hold a core of the collection are
> unauthorized
>
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
> Issue Type: Bug
> Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Assignee: Ishan Chattopadhyaya
>Priority: Minor
> Labels: security
> Fix For: 8.2
>
> Attachments: SOLR-13472.patch, SOLR-13472.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When creating collection in SolrCloud, collection is available for queries
> and updates through all Solr nodes, in particular nodes that does not hold
> one of collection's cores. This is expected behaviour that works when using
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for
> HTTP requests:
> - executing request to a node that holds part of the collection (core) obey
> to authorization rules as expected.
> - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following
> security.json file to zookeeper:
>
> {code:java}
> {
> "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
> "solr": "'solr' user password_hash",
> "indexer_app": "'indexer_app' password_hash",
> "read_user": "'read_user' password_hash"
>}
> },
> "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
> {
>"name": "read",
>"role": "*"
> },
> {
>"name": "update",
>"role": [
> "indexer",
> "admin"
>]
> },
> {
>"name": "all",
>"role": "admin"
> }
>],
>"user-role": {
> "solr": "admin",
> "indexer_app": "indexer"
>}
> }
> }{code}
>
> 3. create 'test' collection with one shard on *node_1*.
> --
> The following requests expected to succeed but return 403 status
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true;
> {code}
>
> Authenticated '_solr_' user requests works as expected. My guess is due to
> the special '_all_' role.
--
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-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884805#comment-16884805
]
Jason Gerlowski edited comment on SOLR-13622 at 7/15/19 2:00 AM:
-
I attached a quick-and-dirty POC for this. Right now you can invoke the
streaming expression as:
{{fileStream(/First/absolute/path|/Second/absolute/path|...)}}
Some notes:
* Right now the filepath argument doesn't take quotes, and uses the pipe
character as a delimiter between args. Both of these are temporary things
we'll want to fix, they were just a bit easier to get working in the short term.
* Currently the path argument works with absolute paths. I did this because I
was blanking on how to figure out SOLR_HOME or SOLR_DATA_HOME from SolrJ code.
(The goto for this in solr-core is SolrResourceLoader, but that's not available
in SolrJ where all the streaming expressions are defined.) Maybe this isn't
possible from code that lives in SolrJ...going to have to think this through a
bit. If anyone knows a trick I'm missing, or a way around the problem, please
chime in.
* I haven't implemented the max-lines parameter yet, but that should be pretty
straightforward.
was (Author: gerlowskija):
I attached a quick-and-dirty POC for this. Right now you can invoke the
streaming expression as:
{{fileStream(/First/absolute/path|/Second/absolute/path}}
Some notes:
* Right now the filepath argument doesn't take quotes, and uses the pipe
character as a delimiter between args. Both of these are temporary things
we'll want to fix, they were just a bit easier to get working in the short term.
* Currently the path argument works with absolute paths. I did this because I
was blanking on how to figure out SOLR_HOME or SOLR_DATA_HOME from SolrJ code.
(The goto for this in solr-core is SolrResourceLoader, but that's not available
in SolrJ where all the streaming expressions are defined.) Maybe this isn't
possible from code that lives in SolrJ...going to have to think this through a
bit. If anyone knows a trick I'm missing, or a way around the problem, please
chime in.
* I haven't implemented the max-lines parameter yet, but that should be pretty
straightforward.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
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-13622) Add FileStream Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884805#comment-16884805
]
Jason Gerlowski commented on SOLR-13622:
I attached a quick-and-dirty POC for this. Right now you can invoke the
streaming expression as:
{{fileStream(/First/absolute/path|/Second/absolute/path}}
Some notes:
* Right now the filepath argument doesn't take quotes, and uses the pipe
character as a delimiter between args. Both of these are temporary things
we'll want to fix, they were just a bit easier to get working in the short term.
* Currently the path argument works with absolute paths. I did this because I
was blanking on how to figure out SOLR_HOME or SOLR_DATA_HOME from SolrJ code.
(The goto for this in solr-core is SolrResourceLoader, but that's not available
in SolrJ where all the streaming expressions are defined.) Maybe this isn't
possible from code that lives in SolrJ...going to have to think this through a
bit. If anyone knows a trick I'm missing, or a way around the problem, please
chime in.
* I haven't implemented the max-lines parameter yet, but that should be pretty
straightforward.
> Add FileStream Streaming Expression
> ---
>
> Key: SOLR-13622
> URL: https://issues.apache.org/jira/browse/SOLR-13622
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13622.patch
>
>
> The FileStream will read files from a local filesystem and Stream back each
> line of the file as a tuple.
--
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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13622: --- Attachment: SOLR-13622.patch > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Attachments: SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16884802#comment-16884802 ] Jason Gerlowski commented on SOLR-13622: Joel and I discussed this a bit offline and had some initial thoughts about what this should look like: * file specification could take either files or directories (which would then be processed recursively). Ideally the file parameter would allow a comma-delimited list of files/directories to process. * received filepaths would have to be evaluated relative to a specified particular data directory (to avoid the security issue of allowing reading arbitrary files on the Solr box). Also to this effect, we'd need to do some sanitizing of the file paths that users provide to ensure they're not escaping the sandbox we set up for them. * each emitted tuple could contain the filename/path of the file that the emitted tuple came from, to allow differentiation of lines from multiple files. * we could add a numeric parameter to cap the number of lines that get emitted if users just want to see the first N lines of a large file (or group of files) > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Attachments: SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-13622: -- Assignee: Jason Gerlowski > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- 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-13591) AlreadyClosedException in SolrJ
[
https://issues.apache.org/jira/browse/SOLR-13591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876970#comment-16876970
]
Jason Gerlowski commented on SOLR-13591:
AlreadyClosedException sounds like it _could_ be ZooKeeper connection issues.
Have you looked at the ZK logs to rule that out? With just the stacktrace (for
an IO issue that comes up frequently), I'm not sure this JIRA is very
actionable.
> AlreadyClosedException in SolrJ
> ---
>
> Key: SOLR-13591
> URL: https://issues.apache.org/jira/browse/SOLR-13591
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.1.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> Since upgrading from 7.7 to 8.1, we regulary get the following exception in
> SolrJ. The message is null, the stack trace is:
> {code}
> org.apache.solr.common.AlreadyClosedException
> at
> org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.getZkStateReader(ZkClientClusterStateProvider.java:165)
> at
> org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.connect(BaseCloudSolrClient.java:329)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:779)
> at
> org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
> {code}
> The clients are always 8.1.1, the servers are either 7.5 or 8.1.1. There are
> no indications in the server logs, although they are set to log level WARN.
> We run Zookeeper 3.4.13.
--
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] [Resolved] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-13537. Resolution: Done (I don't want to attach a "Fix Version" here, because this change will never make it into any shipped version of Solr, as it's developer README only) > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Assignee: Jason Gerlowski >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png, Single Line > Badges.png > > Time Spent: 40m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- 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-13537) Build Status Badge in git README
[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875482#comment-16875482
]
Jason Gerlowski commented on SOLR-13537:
I've merged Marcus' PR to master. I was thinking about copying this back to
other branches {{branch_8x}} etc, but after considering it a bit, I'm less sure
that's a good idea. {{master}} is the branch where the build-badges are most
visible. It's also the branch used most by novice developers- the ones most
likely to get use out of the build-badges. (Typically, new contributors offer
patches/PRs against master and it's up to the committer to work with other
branches from there.)
Anyway backporting the build badges to other branches offers less value, and it
also carries a bit more risk. The {{master}} build jobs will be around
indefinitely, since our branching model has us always working off of
{{master}}. Other branches aren't as "sticky" - eventually jobs for other
branches will stop running and get deleted indefinitely, so unless we're going
to remember to remove the badges later it's probably not worth adding them to
{{branch_Yx}} branches.
Unless anyone makes a good argument for porting this to other branches, I'll
close this ticket out. Thanks for the idea and the legwork Marcus.
> Build Status Badge in git README
>
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple
> Artifact Build Badge.png, Simple Artifact Build Badges.png, Single Line
> Badges.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a
> git-driven ecosystem, it would be helpful to see the status builds in the
> README. This is a standard for many open source projects. I think one could
> debate whether we should have a multi-line build badge visual in the README
> because people need to know about the builds for various versions and
> platforms in the case of Lucene/Solr because it is such a large and widely
> used project, in a variety of environments. The badges not only celebrate
> that fact, they support its persistence in the future with new developers who
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each
> platform, Linux, Windows, MacOSX, and Solaris.
--
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] [Assigned] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-13537: -- Assignee: Jason Gerlowski > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Assignee: Jason Gerlowski >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png, Single Line > Badges.png > > Time Spent: 40m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- 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-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-13318:
---
Fix Version/s: 8.1
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: 8.1
>
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871679#comment-16871679
]
Jason Gerlowski commented on SOLR-13318:
Thanks for bringing this up again.
It probably still makes sense to backport. I'm not sure what the odds of a
7.7.3 release are, but the effort required to backport this is low, and if one
occurs, it would be nice to offer this fix to people in it.
I can put it on my todo list for this week, and will make sure I follow up this
time.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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] [Comment Edited] (SOLR-13537) Build Status Badge in git README
[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869799#comment-16869799
]
Jason Gerlowski edited comment on SOLR-13537 at 6/21/19 6:50 PM:
-
I'm considering committing this next week.
The build badges aren't as cool/meaningful as they could be if we had
consistently passing tests, etc. And I don't really buy that it provides any
value for DevOps engineers (all of whom would be using formal releases vetted
through other, stronger processes). But there is at least one tangible benefit
this patch offers: someone encountering a compile issue on {{master}} can look
at the README for a clue to whether their local issue is a legit problem that
the build slaves hit as well, or whether it's just a local environmental issue.
Since the risk of this change is super low, I think that's enough to make it
worth committing.
Wanted to give this one last bump in case Jan or Shawn still had doubts about
the value. If there's no objections, I'll merge this to master Monday or
Tuesday. We can tackle any improvements in follow-up JIRAs.
was (Author: gerlowskija):
I'm considering committing this next week.
The build badges aren't as cool/meaningful as they could be if we had
consistently passing tests, etc. And I don't really buy that it provides any
value for DevOps engineers (all of whom would be using formal releases vetted
through other, stronger processes). But there is at least one tangible benefit
this patch offers: someone encountering a compile issue on {{master}} can look
at the README for a clue to whether their local issue is a legit problem that
the build slaves hit as well, or whether it's just a local environmental issue.
Since the risk of this change is super low, I think that's enough to make it
worth committing.
Wanted to give this one last bump in case Jan or Shawn still had doubts about
the value.
> Build Status Badge in git README
>
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple
> Artifact Build Badge.png, Simple Artifact Build Badges.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a
> git-driven ecosystem, it would be helpful to see the status builds in the
> README. This is a standard for many open source projects. I think one could
> debate whether we should have a multi-line build badge visual in the README
> because people need to know about the builds for various versions and
> platforms in the case of Lucene/Solr because it is such a large and widely
> used project, in a variety of environments. The badges not only celebrate
> that fact, they support its persistence in the future with new developers who
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each
> platform, Linux, Windows, MacOSX, and Solaris.
--
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-13537) Build Status Badge in git README
[
https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869799#comment-16869799
]
Jason Gerlowski commented on SOLR-13537:
I'm considering committing this next week.
The build badges aren't as cool/meaningful as they could be if we had
consistently passing tests, etc. And I don't really buy that it provides any
value for DevOps engineers (all of whom would be using formal releases vetted
through other, stronger processes). But there is at least one tangible benefit
this patch offers: someone encountering a compile issue on {{master}} can look
at the README for a clue to whether their local issue is a legit problem that
the build slaves hit as well, or whether it's just a local environmental issue.
Since the risk of this change is super low, I think that's enough to make it
worth committing.
Wanted to give this one last bump in case Jan or Shawn still had doubts about
the value.
> Build Status Badge in git README
>
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple
> Artifact Build Badge.png, Simple Artifact Build Badges.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a
> git-driven ecosystem, it would be helpful to see the status builds in the
> README. This is a standard for many open source projects. I think one could
> debate whether we should have a multi-line build badge visual in the README
> because people need to know about the builds for various versions and
> platforms in the case of Lucene/Solr because it is such a large and widely
> used project, in a variety of environments. The badges not only celebrate
> that fact, they support its persistence in the future with new developers who
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each
> platform, Linux, Windows, MacOSX, and Solaris.
--
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-13461) Update Parallel SQL docs to be very clear select * isn't supported.
[ https://issues.apache.org/jira/browse/SOLR-13461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13461: --- Fix Version/s: 8.2 > Update Parallel SQL docs to be very clear select * isn't supported. > --- > > Key: SOLR-13461 > URL: https://issues.apache.org/jira/browse/SOLR-13461 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 8.0 >Reporter: Eric Pugh >Assignee: Jason Gerlowski >Priority: Minor > Fix For: master (9.0), 8.2 > > Time Spent: 10m > Remaining Estimate: 0h > > Small tweak to documentation to really highlight select * not supported. -- 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-13461) Update Parallel SQL docs to be very clear select * isn't supported.
[ https://issues.apache.org/jira/browse/SOLR-13461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869427#comment-16869427 ] Jason Gerlowski commented on SOLR-13461: bq. Why not 8.2 as well? No reason; I was just letting it sit overnight as I was a little paranoid I did something wrong in merging the PR on github. Still getting used to that workflow. I've added to branch_8x now as well. bq. Now that Luke is part of the project, would that help in adding future support for select *? To expose my ignorance, I don't _think_ that the Luke module gets us anything in this regard. I don't think it gets us any information we didn't already have access to via the schema APIs and the Luke Request Handler. > Update Parallel SQL docs to be very clear select * isn't supported. > --- > > Key: SOLR-13461 > URL: https://issues.apache.org/jira/browse/SOLR-13461 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 8.0 >Reporter: Eric Pugh >Assignee: Jason Gerlowski >Priority: Minor > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > Small tweak to documentation to really highlight select * not supported. -- 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-13461) Update Parallel SQL docs to be very clear select * isn't supported.
[ https://issues.apache.org/jira/browse/SOLR-13461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869101#comment-16869101 ] Jason Gerlowski commented on SOLR-13461: Thanks for the doc improvement Eric. Merged to master, so this'll appear in the 9.0 ref-guide when that comes out. > Update Parallel SQL docs to be very clear select * isn't supported. > --- > > Key: SOLR-13461 > URL: https://issues.apache.org/jira/browse/SOLR-13461 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 8.0 >Reporter: Eric Pugh >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Small tweak to documentation to really highlight select * not supported. -- 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-13461) Update Parallel SQL docs to be very clear select * isn't supported.
[ https://issues.apache.org/jira/browse/SOLR-13461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13461: --- Resolution: Fixed Assignee: Jason Gerlowski Fix Version/s: master (9.0) Status: Resolved (was: Patch Available) > Update Parallel SQL docs to be very clear select * isn't supported. > --- > > Key: SOLR-13461 > URL: https://issues.apache.org/jira/browse/SOLR-13461 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 8.0 >Reporter: Eric Pugh >Assignee: Jason Gerlowski >Priority: Minor > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > Small tweak to documentation to really highlight select * not supported. -- 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-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865578#comment-16865578 ] Jason Gerlowski commented on SOLR-13537: bq. If we had a way to run just plain unit tests and precommit that would be a better build state badge candidate. Missed this comment of Jan's the first time around. Mark Miller created a jira awhile back for separating out our unit and integration tests so each could be run separately (SOLR-12921). That seems like a prerequisite here. There's a lot of other good reasons to separate out our tests from one another, but this provides an additional little carrot if we want to incorporate unit tests into the badge down the road. > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- 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] [Comment Edited] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865543#comment-16865543 ] Jason Gerlowski edited comment on SOLR-13537 at 6/17/19 12:11 PM: -- Disclaimer: I talked to Marcus about some of this already offline. I want to second one thing that Jan and Shawn have already said: test-flakiness definitely prevents us from doing this on a full test-run right now - the status would be red all the time and pretty useless. So since we can't cover tests: "What's the point?" is a reasonable question. Personally, I think there's still value in basing a badge off of a compile-only, or a compile+precommit Jenkins job. Compilation issues do occasionally sneak in. Precommit failures a little more frequently. A badge would give a way to sanity check that at-a-glance when one of us sees (e.g.) a precommit failure locally. bq. Since github is not the canonical source repository, and as far as I can tell the readme is not rendered by Apache gitbox, I wonder how often our committers would actually see it Maybe I'm wrong, but build status badges are "just images". I would expect them to work anywhere that our markdown gets rendered to HTML. So in that sense they're as portable as tables, text formatting (italics, bold, etc.), or any other markdown syntax. Unless I'm missing something at least. As far as who gets use out of build-badges, I don't use GH much, but judging from the number of PR's we get there, it's very popular among early contributors. So I imagine that even if the badge was GH-only, there'd still be some value there. Unfortunately I don't think we have any nightly or hourly precommit jobs in the Apache jenkins. There's a job or two that just run precommit, but it looks like it triggers on JIRA patches as well as on merged code (maybe through Yetus?) Anyway, I don't think the precommit jobs we have now are super meaningful, so it's tough to incorporate them into a badge. So if we wanted a badge without creating any new Jenkins jobs for it, it'd have to just be compilation. It's not as useful as it could be, but maybe we don't want the perfect to get in the way of the good here. (We could also create a precommit-only nightly job, that'd just take a bit more committer effort.) was (Author: gerlowskija): I want to second one thing that Jan and Shawn have already said: test-flakiness definitely prevents us from doing this on a full test-run right now - the status would be red all the time and pretty useless. So since we can't cover tests: "What's the point?" is a reasonable question. Personally, I think there's still value in basing a badge off of a compile-only, or a compile+precommit Jenkins job. Compilation issues do occasionally sneak in. Precommit failures a little more frequently. A badge would give a way to sanity check that at-a-glance when one of us sees (e.g.) a precommit failure locally. bq. Since github is not the canonical source repository, and as far as I can tell the readme is not rendered by Apache gitbox, I wonder how often our committers would actually see it Maybe I'm wrong, but build status badges are "just images". I would expect them to work anywhere that our markdown gets rendered to HTML. So in that sense they're as portable as tables, text formatting (italics, bold, etc.), or any other markdown syntax. Unless I'm missing something at least. As far as who gets use out of build-badges, I don't use GH much, but judging from the number of PR's we get there, it's very popular among early contributors. So I imagine that even if the badge was GH-only, there'd still be some value there. Unfortunately I don't think we have any nightly or hourly precommit jobs in the Apache jenkins. There's a job or two that just run precommit, but it looks like it triggers on JIRA patches as well as on merged code (maybe through Yetus?) Anyway, I don't think the precommit jobs we have now are super meaningful, so it's tough to incorporate them into a badge. So if we wanted a badge without creating any new Jenkins jobs for it, it'd have to just be compilation. It's not as useful as it could be, but maybe we don't want the perfect to get in the way of the good here. (We could also create a precommit-only nightly job, that'd just take a bit more committer effort.) > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple >
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865543#comment-16865543 ] Jason Gerlowski commented on SOLR-13537: I want to second one thing that Jan and Shawn have already said: test-flakiness definitely prevents us from doing this on a full test-run right now - the status would be red all the time and pretty useless. So since we can't cover tests: "What's the point?" is a reasonable question. Personally, I think there's still value in basing a badge off of a compile-only, or a compile+precommit Jenkins job. Compilation issues do occasionally sneak in. Precommit failures a little more frequently. A badge would give a way to sanity check that at-a-glance when one of us sees (e.g.) a precommit failure locally. bq. Since github is not the canonical source repository, and as far as I can tell the readme is not rendered by Apache gitbox, I wonder how often our committers would actually see it Maybe I'm wrong, but build status badges are "just images". I would expect them to work anywhere that our markdown gets rendered to HTML. So in that sense they're as portable as tables, text formatting (italics, bold, etc.), or any other markdown syntax. Unless I'm missing something at least. As far as who gets use out of build-badges, I don't use GH much, but judging from the number of PR's we get there, it's very popular among early contributors. So I imagine that even if the badge was GH-only, there'd still be some value there. Unfortunately I don't think we have any nightly or hourly precommit jobs in the Apache jenkins. There's a job or two that just run precommit, but it looks like it triggers on JIRA patches as well as on merged code (maybe through Yetus?) Anyway, I don't think the precommit jobs we have now are super meaningful, so it's tough to incorporate them into a badge. So if we wanted a badge without creating any new Jenkins jobs for it, it'd have to just be compilation. It's not as useful as it could be, but maybe we don't want the perfect to get in the way of the good here. (We could also create a precommit-only nightly job, that'd just take a bit more committer effort.) > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- 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-13285) ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during replication
[
https://issues.apache.org/jira/browse/SOLR-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862232#comment-16862232
]
Jason Gerlowski commented on SOLR-13285:
Jan is right. A partial fix (I thought it was complete at the time) was
committed in SOLR-13331 and put into 7.7.2. Only this morning when I saw the
mail about this, did I realize the contributor on SOLR-13331 mentioned finding
other issues and bundled fixes for them into a PR that had previously just been
test-improvements.
Sorry for the miscommunication on my part. This second half of this issue is
now being followed up on in SOLR-13538 and SOLR-13539 (one of which will be
closed as a duplicate of the other soon).
> ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during
> replication
> -
>
> Key: SOLR-13285
> URL: https://issues.apache.org/jira/browse/SOLR-13285
> Project: Solr
> Issue Type: Bug
> Components: replication (java), SolrCloud, SolrJ
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: centos 7
> solrcloud 7.7.1, 8.1.0
>Reporter: Karl Stoney
>Assignee: Noble Paul
>Priority: Major
> Labels: newbie, replication
> Fix For: 7.7.2, 8.1
>
> Attachments: SOLR-13285.patch, SOLR-13285.patch
>
>
> Since upgrading to 7.7 (also tried 7.7.1, and 8.1.0) from 6.6.4, we're seeing
> the following errors in the SolrCloud elected master for a given collection
> when updates are written. This was after a full reindex of data (fresh
> build).
> {code:java}
> request:
> http://solr-1.search-solr.preprod.k8.atcloud.io:80/solr/at-uk_shard1_replica_n2/update?update.distrib=FROMLEADER=http%3A%2F%2Fsolr-2.search-solr.preprod.k8.atcloud.io%3A80%2Fsolr%2Fat-uk_shard1_replica_n1%2F=javabin=2
> Remote error message: org.apache.solr.common.util.ByteArrayUtf8CharSequence
> cannot be cast to java.lang.String
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:385)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:183)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
> Following this through to the replica, you'll see:
> {code:java}
> 08:35:22.060 [qtp1540374340-20] ERROR org.apache.solr.servlet.HttpSolrCall -
> null:java.lang.ClassCastException:
> org.apache.solr.common.util.ByteArrayUtf8CharSequence cannot be cast to
> java.lang.String
> at
> org.apache.solr.common.util.JavaBinCodec.readEnumFieldValue(JavaBinCodec.java:813)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:339)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:640)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:337)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.readMapEntry(JavaBinCodec.java:819)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:341)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:295)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:333)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
> at
>
[jira] [Commented] (SOLR-13347) Error writing Transaction log for UUIDField
[ https://issues.apache.org/jira/browse/SOLR-13347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862200#comment-16862200 ] Jason Gerlowski commented on SOLR-13347: Hey Noble, you -1'd Thomas's PR here: https://github.com/apache/lucene-solr/pull/681 a bit over a week ago, and he's since addressed your concerns I think. The PR looks good to me, but I don't understand the implications of the Codec changes as well as you do. (Your explanation above was a very helpful explanation though) Anyway, do you have time to re-review PR 681 soon? > Error writing Transaction log for UUIDField > --- > > Key: SOLR-13347 > URL: https://issues.apache.org/jira/browse/SOLR-13347 > Project: Solr > Issue Type: Bug > Components: Server >Affects Versions: 7.7, 7.7.1, 8.0 >Reporter: Thomas Wöckinger >Priority: Major > Labels: pull-request-available, ready-to-commit, test > Attachments: SOLR-13347.patch > > Time Spent: 3h 50m > Remaining Estimate: 0h > > When using Atomic Update, adding a value leads to following Exception > org.apache.solr.common.SolrException: TransactionLog doesn't know how to > serialize class java.util.UUID; try implementing ObjectResolver? > at > org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263) > at > org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252) > at > org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437) > at > org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100) > at > org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160) > at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684) > at > org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51) > at > org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657) > at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552) > at > org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236) > at > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76) > at > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700) > at > org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) > at > org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126) > at > org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123) > at > org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70) > at >
[jira] [Comment Edited] (SOLR-13347) Error writing Transaction log for UUIDField
[ https://issues.apache.org/jira/browse/SOLR-13347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862200#comment-16862200 ] Jason Gerlowski edited comment on SOLR-13347 at 6/12/19 3:11 PM: - Hey [~noble.paul], you -1'd Thomas's PR here: https://github.com/apache/lucene-solr/pull/681 a bit over a week ago, and he's since addressed your concerns I think. The PR looks good to me, but I don't understand the implications of the Codec changes as well as you do. (Your explanation above was a very helpful explanation though) Anyway, do you have time to re-review PR 681 soon? was (Author: gerlowskija): Hey Noble, you -1'd Thomas's PR here: https://github.com/apache/lucene-solr/pull/681 a bit over a week ago, and he's since addressed your concerns I think. The PR looks good to me, but I don't understand the implications of the Codec changes as well as you do. (Your explanation above was a very helpful explanation though) Anyway, do you have time to re-review PR 681 soon? > Error writing Transaction log for UUIDField > --- > > Key: SOLR-13347 > URL: https://issues.apache.org/jira/browse/SOLR-13347 > Project: Solr > Issue Type: Bug > Components: Server >Affects Versions: 7.7, 7.7.1, 8.0 >Reporter: Thomas Wöckinger >Priority: Major > Labels: pull-request-available, ready-to-commit, test > Attachments: SOLR-13347.patch > > Time Spent: 3h 50m > Remaining Estimate: 0h > > When using Atomic Update, adding a value leads to following Exception > org.apache.solr.common.SolrException: TransactionLog doesn't know how to > serialize class java.util.UUID; try implementing ObjectResolver? > at > org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263) > at > org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252) > at > org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437) > at > org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100) > at > org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160) > at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684) > at > org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51) > at > org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657) > at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552) > at > org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236) > at > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76) > at > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700) > at > org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) > at > org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300) > at
[jira] [Comment Edited] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862186#comment-16862186 ] Jason Gerlowski edited comment on SOLR-13331 at 6/12/19 3:00 PM: - bq. Fixes missing for BinaryField, BoolField, UUIDField and a corner case for EnumField Oh no. I completely missed this update from Thomas, which indicated that there were still non-test issues to tackle in this JIRA. I hadn't realized this until now. Sorry for not catching it sooner. I agree with Jan. We'll need to handle subsequent fixes in additional JIRA tickets to avoid ambiguity about which part of the fix is available where. Will chime in over on 13538/9. was (Author: gerlowskija): > Fixes missing for BinaryField, BoolField, UUIDField and a corner case for > EnumField Oh no. I completely missed this update from Thomas, which indicated that there were still non-test issues to tackle in this JIRA. I hadn't realized this until now. Sorry for not catching it sooner. I agree with Jan. We'll need to handle subsequent fixes in additional JIRA tickets to avoid ambiguity about which part of the fix is available where. Will chime in over on 13538/9. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862186#comment-16862186 ] Jason Gerlowski commented on SOLR-13331: > Fixes missing for BinaryField, BoolField, UUIDField and a corner case for > EnumField Oh no. I completely missed this update from Thomas, which indicated that there were still non-test issues to tackle in this JIRA. I hadn't realized this until now. Sorry for not catching it sooner. I agree with Jan. We'll need to handle subsequent fixes in additional JIRA tickets to avoid ambiguity about which part of the fix is available where. Will chime in over on 13538/9. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859233#comment-16859233
]
Jason Gerlowski commented on SOLR-13523:
I noticed this yesterday and just saw this JIRA open for it. I attached a
script I've been using to reproduce it. Just drop that in the root of your
source checkout and run {{./reproduce.sh}} to trigger the bug.
I ran a git-bisect on {{master}} to figure out what might've caused this, and
the first failing commit was:
{code}
➜ lucene-solr git:(8527ec11af8) ✗ git bisect bad 8527ec11af8
8527ec11af8099f86953ffad1182ad43c752f95b is the first bad commit
commit 8527ec11af8099f86953ffad1182ad43c752f95b
Author: Moshe
Date: Wed Apr 10 03:02:59 2019 -0400
SOLR-12638: Partial/Atomic updates of nested docs.
and [child] now works in RTG.
{code}
Tagging [~moshebla] and [~dsmiley], since they worked on that ticket. Does
this error message look familiar to either of you guys? The NPE occurs on the
first line of this method in AtomicUpdateDocumentMerger.
{code}
/**
*
* @param completeHierarchy SolrInputDocument that represents the nested
document hierarchy from its root
* @param fieldPath the path to fetch, seperated by a '/' e.g.
/children/grandChildren
* @return the SolrInputField of fieldPath
*/
public static SolrInputField getFieldFromHierarchy(SolrInputDocument
completeHierarchy, String fieldPath) {
// substr to remove first '/'
final List docPaths = StrUtils.splitSmart(fieldPath.substring(1),
'/');
Pair subPath;
SolrInputField sifToReplace = null;
SolrInputDocument currDoc = completeHierarchy;
for (String subPathString: docPaths) {
subPath = getPathAndIndexFromNestPath(subPathString);
sifToReplace = currDoc.getField(subPath.getLeft());
currDoc = (SolrInputDocument)
((List)sifToReplace.getValues()).get(subPath.getRight());
}
return sifToReplace;
}
{code}
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API, update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Priority: Major
> Attachments: XUBrk.png, Xn1RW.png, reproduce.sh
>
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
>
[jira] [Updated] (SOLR-13523) Atomic Update results in NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-13523:
---
Attachment: reproduce.sh
> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API, update
>Affects Versions: 8.0
> Environment: * Operating system: Win10 v1803 build 17143.766
> * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
> * solr-spec: 8.1.1
> * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:20:01
> * lucene-spec: 8.1.1
> * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab -
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Priority: Major
> Attachments: XUBrk.png, Xn1RW.png, reproduce.sh
>
>
> Partially update a document via an atomic update, when I do so, the web sever
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{
> "trace":"java.lang.NullPointerException\r\n\tat
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>
> org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:507)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:145)\r\n\tat
>
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:121)\r\n\tat
>
[jira] [Commented] (SOLR-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856829#comment-16856829
]
Jason Gerlowski commented on SOLR-13510:
I retested things this morning, and confirm that this seems to have fixed the
auth issues for queries. I also tried reproducing the problem with index
updates/deletions, but wasn't able to. (We've only gotten reports of this for
queries, but I figured it made sense to double check updates, since they can
also be routed between nodes.)
Curious to hear whether this fixes things for Colvin as well.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13510.patch
>
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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] [Resolved] (SOLR-13421) Intermittent error 401 with JSON Facet query to retrieve count all collections
[
https://issues.apache.org/jira/browse/SOLR-13421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-13421.
Resolution: Duplicate
> Intermittent error 401 with JSON Facet query to retrieve count all collections
> --
>
> Key: SOLR-13421
> URL: https://issues.apache.org/jira/browse/SOLR-13421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: 8.0
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
> Labels: BasicAuth
>
> I am using the below JSON Facet to retrieve the count of all the different
> collections in one query.
>
>
> [https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6=0={categories|https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6=0=%7Bcategories]
> : \{type : terms,field : content_type,limit : 100}}
>
>
> Previously, in Solr 7.6 and Solr 7.7, this query can work correctly and we
> are able to produce the correct output.
>
> {
> "responseHeader":
> { "zkConnected":true, "status":0, "QTime":24}
> ,
> "response":
> {"numFound":41200,"start":0,"maxScore":12.993215,"docs":[] }
> ,
> "facets":{
> "count":41200,
> "categories":{
> "buckets":[
> { "val":"collection1", "count":26213}
> ,
>
> { "val":"collection2", "count":12075}
> ,
>
> { "val":"collection3", "count":1947}
> ,
>
> { "val":"collection4", "count":850}
> ,
>
> { "val":"collection5", "count":111}
> ,
>
> { "val":"collection6", "count":4}
> ]}}}
>
>
> However, in the new Solr 8.0.0, this query can only work if we put only one
> collection in the shards (can be any collection). If we put 2 collections,
> there will not be error 90% of the time (only 10% of the time the issue will
> occur with the 'Error 401 require authentication').
> However, once we put 3 or more collections (can be any of the collections),
> this issue of 'Error 401 require authentication' will keep occurring.
>
> {
> "responseHeader":
> { "zkConnected":true, "status":401, "QTime":11}
> ,
> "error":{
> "metadata":[
>
> "error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException",
>
> "root-error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/collection6/select. Reason:\n require
> authentication\n\n\n",
> "code":401}}
>
> This issue does not occur in Solr 7.6 and Solr 7.7, even though I have set
> up the same authentication for all the versions.
>
>
> Below is the format of my security.json:
>
> {
> "authentication":
> { "blockUnknown": true, "class":"solr.BasicAuthPlugin",
> "credentials":
> {"user1":"hyHXXuJSqcZdNgdSTGUvrQZRpqrYFUQ2ffmlWQ4GUTk=
> E0w3/2FD+rlxulbPm2G7i9HZqT+2gMBzcyJCcGcMWwA="}
> },
> "authorization":
> { "class":"solr.RuleBasedAuthorizationPlugin", "user-role":
> {"user1":"admin"}
> ,
> "permissions":[
> {"name":"security-edit", "role":"admin"}
> ]
> }}
--
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-13421) Intermittent error 401 with JSON Facet query to retrieve count all collections
[
https://issues.apache.org/jira/browse/SOLR-13421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856820#comment-16856820
]
Jason Gerlowski commented on SOLR-13421:
+1, I had forgotten about this issue. But now that Dat's put together a fix on
the other JIRA, I'm going to close this out as a duplicate.
Thanks for the initial report Edwin, and for seconding it Colvin.
> Intermittent error 401 with JSON Facet query to retrieve count all collections
> --
>
> Key: SOLR-13421
> URL: https://issues.apache.org/jira/browse/SOLR-13421
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: 8.0
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
> Labels: BasicAuth
>
> I am using the below JSON Facet to retrieve the count of all the different
> collections in one query.
>
>
> [https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6=0={categories|https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6=0=%7Bcategories]
> : \{type : terms,field : content_type,limit : 100}}
>
>
> Previously, in Solr 7.6 and Solr 7.7, this query can work correctly and we
> are able to produce the correct output.
>
> {
> "responseHeader":
> { "zkConnected":true, "status":0, "QTime":24}
> ,
> "response":
> {"numFound":41200,"start":0,"maxScore":12.993215,"docs":[] }
> ,
> "facets":{
> "count":41200,
> "categories":{
> "buckets":[
> { "val":"collection1", "count":26213}
> ,
>
> { "val":"collection2", "count":12075}
> ,
>
> { "val":"collection3", "count":1947}
> ,
>
> { "val":"collection4", "count":850}
> ,
>
> { "val":"collection5", "count":111}
> ,
>
> { "val":"collection6", "count":4}
> ]}}}
>
>
> However, in the new Solr 8.0.0, this query can only work if we put only one
> collection in the shards (can be any collection). If we put 2 collections,
> there will not be error 90% of the time (only 10% of the time the issue will
> occur with the 'Error 401 require authentication').
> However, once we put 3 or more collections (can be any of the collections),
> this issue of 'Error 401 require authentication' will keep occurring.
>
> {
> "responseHeader":
> { "zkConnected":true, "status":401, "QTime":11}
> ,
> "error":{
> "metadata":[
>
> "error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException",
>
> "root-error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/collection6/select. Reason:\n require
> authentication\n\n\n",
> "code":401}}
>
> This issue does not occur in Solr 7.6 and Solr 7.7, even though I have set
> up the same authentication for all the versions.
>
>
> Below is the format of my security.json:
>
> {
> "authentication":
> { "blockUnknown": true, "class":"solr.BasicAuthPlugin",
> "credentials":
> {"user1":"hyHXXuJSqcZdNgdSTGUvrQZRpqrYFUQ2ffmlWQ4GUTk=
> E0w3/2FD+rlxulbPm2G7i9HZqT+2gMBzcyJCcGcMWwA="}
> },
> "authorization":
> { "class":"solr.RuleBasedAuthorizationPlugin", "user-role":
> {"user1":"admin"}
> ,
> "permissions":[
> {"name":"security-edit", "role":"admin"}
> ]
> }}
--
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-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855646#comment-16855646
]
Jason Gerlowski commented on SOLR-13510:
bq. with your understanding of the situation, are you able to create a patch
with a failing unit test?
Probably? I might be able to get to it if it's trivial, but I'm tight on time
today. "Luckily" this has proved pretty easy to reproduce on the command line
though, so we still have an easy test (even though its a bit more manual).
bq. ... setting -Dsolr.http1=true when starting Solr ...
I tried this out by putting {{SOLR_OPTS="$SOLR_OPTS -Dsolr.http1=true"}} in my
solr.in.sh. Still seeing the intermittent errors. Has anyone else tried this
to confirm? It might still be Http2 related (it sounds plausible to me at
least), but we don't have any evidence for that yet. And we might have some
against it.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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-13510) Intermittent 401's for internode requests with basicauth enabled
[
https://issues.apache.org/jira/browse/SOLR-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854605#comment-16854605
]
Jason Gerlowski commented on SOLR-13510:
The 401 appears to be on an inter-node request, which is odd since those
typically use PKI for authentication. Following up on this I added
{{"forwardCredentials": "true}} as an authentication property in security.json,
and the behavior goes away. The behavior persists though if the
"forwardCredentials" property is either "false", or missing entirely.
This seems like a bug in the handling of this new property. It seems that
sometimes requests are sent without PKI, even when forwardCredentials=false
would indicate that they should be.
[~janhoy] do you have any guesses why this might be? I think you were involved
in the new "forwardCredentials" change. It seems easy enough to reproduce if
you get a few minutes to take a look.
> Intermittent 401's for internode requests with basicauth enabled
>
>
> Key: SOLR-13510
> URL: https://issues.apache.org/jira/browse/SOLR-13510
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Priority: Major
>
> We recently got a bug report on the mailing list:
> {quote}
> On Solr 8.1.1, using our previously working security.json, running queries
> (through the admin UI currently) I non-deterministically get 401 responses
> on queries when a collection has more than 1 shard. Increasing the number
> of shards in the collection makes the errors more likely.
> {
> "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":30,
> "params":{
> "q":"*:*",
> "_":"1559474550365"}},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
> "root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
> require authentication\n\n\n",
> "code":401}}
> {quote}
> The reporter (credit to Colvin Cowie) also gives reproduction steps:
> {quote}
># Extract solr 8.1.1.
># bin\solr start -e cloud
> 1 node / [default port] / [default collection name] / 4 shards / 1
> replica / [_default configuration]
># server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
> /security.json
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
> Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [{ "name": "all", "role": "admin"} ],
> "user-role": {"solradmin": "admin"}
> }
> }
> {quote}
> (Minor edits for conciseness)
> I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
> like they're impacted by the topography of the collection and cluster. But
> this doesn't seem affected by that at all (401's occur on inter-node requests
> regardless of the recipient of the initial request, and even when all nodes
> have a shard replica).
--
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-13510) Intermittent 401's for internode requests with basicauth enabled
Jason Gerlowski created SOLR-13510:
--
Summary: Intermittent 401's for internode requests with basicauth
enabled
Key: SOLR-13510
URL: https://issues.apache.org/jira/browse/SOLR-13510
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Authentication
Affects Versions: master (9.0)
Reporter: Jason Gerlowski
We recently got a bug report on the mailing list:
{quote}
On Solr 8.1.1, using our previously working security.json, running queries
(through the admin UI currently) I non-deterministically get 401 responses
on queries when a collection has more than 1 shard. Increasing the number
of shards in the collection makes the errors more likely.
{
"responseHeader":{
"zkConnected":true,
"status":401,
"QTime":30,
"params":{
"q":"*:*",
"_":"1559474550365"}},
"error":{
"metadata":[
"error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException",
"root-error-class","org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException"],
"msg":"Error from server at null: Expected mime type
application/octet-stream but got text/html. \n\n\nError 401 require
authentication\n\nHTTP ERROR 401\nProblem
accessing /solr/gettingstarted_shard4_replica_n6/select. Reason:\n
require authentication\n\n\n",
"code":401}}
{quote}
The reporter (credit to Colvin Cowie) also gives reproduction steps:
{quote}
# Extract solr 8.1.1.
# bin\solr start -e cloud
1 node / [default port] / [default collection name] / 4 shards / 1
replica / [_default configuration]
# server\scripts\cloud-scripts\zkcli -zkhost localhost:9983 -cmd putfile
/security.json
{
"authentication": {
"blockUnknown": true,
"class": "solr.BasicAuthPlugin",
"credentials": {
"solradmin": "PIWZwkGnEKxKnqUs3X08xmbmYBaYyAeP3FiKp7fmeHc=
Lnbp6bEbE7Ap8lXvQDKkUX2Xw53QDgP6Ae8QRT0P5/A="
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [{ "name": "all", "role": "admin"} ],
"user-role": {"solradmin": "admin"}
}
}
{quote}
(Minor edits for conciseness)
I'm able to reproduce this bug as well. Other auth issues (SOLR-13472) look
like they're impacted by the topography of the collection and cluster. But
this doesn't seem affected by that at all (401's occur on inter-node requests
regardless of the recipient of the initial request, and even when all nodes
have a shard replica).
--
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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846819#comment-16846819 ] Jason Gerlowski commented on SOLR-13331: bq. It's not an abstraction. it is an optimization. We will not be a make changes confidently unless we have proper test coverage. Of course Noble. I'm not trying to argue against improving the tests. I'm trying to make the point that even with better tests, this BAUCS decision will be biting us for awhile, and we should consider other changes too. Before the BAUCS change, devs didn't have to think about the wire-format at all while parsing requests. Now the wire format matters. So the BAUCS change has taken something that was relatively simple for devs and that happens a bazillion times in our codebase and it made it harder (or at least trappier). You, David, Thomas, and I all know about this problem now and we'll probably remember it the next time we write NamedList parsing code. But the 200 or so other Solr contributors won't. And the thousands of SolrJ users exposed to this definitely won't. Mistakes are going to be made. Improved test coverage will catch some of these issues. And that's great. But if we wake up tomorrow with a test base that randomizes the wire-format, and everything changed over to use it...our test coverage is still full of gaps. Issues are still going to get through. Absolutely we should attend to our tests. But it'd be foolish to not also reconsider the reason NamedList parsing code is now more difficult in the first place. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845818#comment-16845818 ] Jason Gerlowski commented on SOLR-13331: Also, I haven't forgotten about your PR Thomas. I'm hoping to review it soon. That said, SOLR-11872 has gained some recent attention, and that might be a better path forward for expanding our JavaBinCodec test coverage in the long term. That JIRA is a much larger effort, but would ultimately bring codec randomization to a large group of tests, since many already use the base class involved there. Hard to tell whether that removes the need for your proposed EmbeddedSolrTestBase or not until I find time to take a look. But apologies again for the delay and I'm hoping to get to it soon. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845806#comment-16845806 ] Jason Gerlowski commented on SOLR-13331: bq. We need to ensure that tests run with json+ javabin too. I'm totally behind any effort to better randomize the wire format used by our tests. David's SOLR-11872 would be a huge step forward in that regard. I'm for that effort independent of this issue here. That said, I don't think better testing really fixes the issue here if the underlying abstraction remains broken. We're addressing the "symptoms" (serialization issues with individual APIs/features), but ignoring the "disease" (the broken BAUCS abstraction). Without fixing that, we're going to see these issues crop up for years as new features get added. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized
[
https://issues.apache.org/jira/browse/SOLR-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840760#comment-16840760
]
Jason Gerlowski commented on SOLR-13472:
I haven't tried out your example yet, so I can't speak to what is causing the
behavior you're seeing. I hope to look into it soon.
But I can offer one point of clarification on why the behavior might differ in
SolrJ vs a curl request. I suspect what's happening is that your SolrJ code
makes use of CloudSolrClient. CloudSolrClient is data-aware for collections,
meaning that it makes requests directly to the nodes hosting your data (saving
users some extra hops). So if the behavior is only triggered when a request
arrives at a node that _doesnt_ host your data, it makes sense that SolrJ (or
at least CloudSolrClient) is unable to trigger it.
> HTTP requests to a node that does not hold a core of the collection are
> unauthorized
>
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Priority: Minor
> Labels: security
>
> When creating collection in SolrCloud, collection is available for queries
> and updates through all Solr nodes, in particular nodes that does not hold
> one of collection's cores. This is expected behaviour that works when using
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for
> HTTP requests:
> - executing request to a node that holds part of the collection (core) obey
> to authorization rules as expected.
> - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following
> security.json file to zookeeper:
>
> {code:java}
> {
> "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
> "solr": "'solr' user password_hash",
> "indexer_app": "'indexer_app' password_hash",
> "read_user": "'read_user' password_hash"
>}
> },
> "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
> {
>"name": "read",
>"role": "*"
> },
> {
>"name": "update",
>"role": [
> "indexer",
> "admin"
>]
> },
> {
>"name": "all",
>"role": "admin"
> }
>],
>"user-role": {
> "solr": "admin",
> "indexer_app": "indexer"
>}
> }
> }{code}
>
> 3. create 'test' collection with one shard on *node_1*.
> --
> The following requests expected to succeed but return 403 status
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true;
> {code}
>
> Authenticated '_solr_' user requests works as expected. My guess is due to
> the special '_all_' role.
--
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-13331) Atomic Update Multivalue remove does not work
[
https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834821#comment-16834821
]
Jason Gerlowski commented on SOLR-13331:
Base things off of master, if you can. Generally changes get merged to
{{master}} first, and then are backported to particular release branches as
needed once. So it's almost always master-first.
> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
> Labels: patch
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch,
> SOLR-13331.patch
>
>
> When using JavaBinCodec the values of collections are of type
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method
> doRemove.
> The method parameter fieldVal contains the collection values of type
> ByteArrayUtf8CharSequence, the variable original contains the collection of
> Strings
--
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-13446) Improve default heap size and related handling
[ https://issues.apache.org/jira/browse/SOLR-13446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834812#comment-16834812 ] Jason Gerlowski commented on SOLR-13446: To offer an unpopular opinion (you did ask for bike-shedding), I think the default max-heap is fine where it is. Yes, 512mb can be problematic for production use cases, but it's ideal for local development and testing, where resources are tighter and developers have lots of other apps competing for RAM. Bumping up Solr's max-heap to 2gb would be a pain for developers already stretching their workstations thin. It's a bit counter-intuitive, but I think the current max-heap is ideal for production too, at least in one narrow sense. As a community, we advocate in the strongest terms for Solr admins to examine and harden their config before going to production - including their heap settings. Not following this advice is going to hurt users in the long run. So it's good then, when inexperienced admins run into performance problems early on in their testing, and realize that Solr has a max heap of 512mb. It nudges them into complying with our best practices around config-hardening. 512mb is "so bad it's good" :) With a less obviously-bad max-heap, I think we'd find more deployments going live with unhardened-configs, ultimately hurting users/admins more. Consider this opinion a -0 though. I don't want to block progress if I'm clearly in the minority, which I might be. I'm all in favor of the other suggestion here: adding a warning log message on startup if max-heap is below a particular threshold. > Improve default heap size and related handling > -- > > Key: SOLR-13446 > URL: https://issues.apache.org/jira/browse/SOLR-13446 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: 8.0 >Reporter: Shawn Heisey >Priority: Minor > > Solr's scripts have a default max heap setting of 512MB. I think it's fair > to say that for a production install, this is ridiculously small. Nearly > everyone who runs a Solr server will need to increase this value. > I think it would be useful to issue a warning in the log when the heap size > is below a certain value. Text like "Detected max heap size is . It > might be necessary to increase the heap size for proper operation. See > https://lucene.apache.org/solr/path/to/ref/guide/location for details." > For people who are running very small servers, there should be a config > option to turn off that logging when somebody knows that the default heap > size is perfectly fine for their setup. > At the same time, we also need to improve the default heap size. I'm going > to ask everyone to bikeshed about what the new default should be. Initial > thought is a 2GB default, to be made smaller automatically if detected system > memory is low. If the admin has explicitly set the heap size, then none of > this will take place. -- 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-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833752#comment-16833752
]
Jason Gerlowski commented on SOLR-13318:
Yes, I'd like to backport to 7.7.2 but ran out of time last night. If I have
time after work today I'm still aiming for 7.7.2, as long as there's not an RC
or a freeze before then.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833710#comment-16833710
]
Jason Gerlowski commented on SOLR-13318:
bq. Would this be okay from a user's perspective?
I agree it's not great, but hopefully its good enough. The approach that I
took here causes anyone currently using BucketBasedJsonFacet to potentially
update their code twice. That's not ideal. You're right. But I also didn't
want new users coming in to 9.0 to see method names that were inconsistent with
the rest of that group of classes (e.g. "What does that "count" suffix mean on
{{getNumBucketsCount}}? Nothing else has that, maybe it doesn't mean what I
think"). Both options are non-ideal, but we have to choose one.
I tried to choose the option that would affect the fewest users. As of 7.x and
8.0, BucketBasedJsonFacet throws an undeclared exception when used with any
multi-shard collection. This is a huge problem, and makes the methods arguably
unusable. Because of this, there are probably very few BBJF users. So I opted
to cause those few users a bit of extra work, in favor of having a more
consistent interface for the users coming on in 9.x, now that the class is
safer.
So anyway, there are negative aspects of this approach, but hopefully
outweighed or mitigated by other things.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833692#comment-16833692 ] Jason Gerlowski commented on SOLR-13331: Yes, if that's how you prefer to package things up. Committers who have configured their accounts correctly should be able to merge PRs directly from the Github UI. I had some trouble doing this the last time I tried, but this will be a good opportunity to force me to fix that. Please tag me in the comments of your PR if you put one together, so I don't miss it. (username: gerlowskija) > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831535#comment-16831535 ] Jason Gerlowski commented on SOLR-13331: Hi Thomas, no need. I committed a fix for this, and it'll be available in 7.7.2, and starting in 8.1. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch > Fix For: 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13331: --- Fix Version/s: 7.7.2 > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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-5970) Create collection API always has status 0
[
https://issues.apache.org/jira/browse/SOLR-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829569#comment-16829569
]
Jason Gerlowski commented on SOLR-5970:
---
Thanks for seeing this through Ishan, and thanks for updating my patch
Kesharee. Sorry to leave it hanging. I let it sit for a few hoping for
feedback before committing and then it fell off my radar. Glad this will make
it into 8.1!
> Create collection API always has status 0
> -
>
> Key: SOLR-5970
> URL: https://issues.apache.org/jira/browse/SOLR-5970
> Project: Solr
> Issue Type: Bug
>Reporter: Abraham Elmahrek
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-5970-test.patch, SOLR-5970.patch, SOLR-5970.patch,
> SOLR-5970_branch_8x.patch, bad.jar, schema.xml, solrconfig.xml
>
>
> The responses below are from a successful create collection API
> (https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-CreateormodifyanAliasforaCollection)
> call and an unsuccessful create collection API call. It seems the 'status'
> is always 0.
> Success:
> {u'responseHeader': {u'status': 0, u'QTime': 4421}, u'success': {u'':
> {u'core': u'test1_shard1_replica1', u'responseHeader': {u'status': 0,
> u'QTime': 3449
> Failure:
> {u'failure':
> {u'':
> u"org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error
> CREATEing SolrCore 'test43_shard1_replica1': Unable to create core:
> test43_shard1_replica1 Caused by: Could not find configName for collection
> test43 found:[test1]"},
> u'responseHeader': {u'status': 0, u'QTime': 17149}
> }
> It seems like the status should be 400 or something similar for an
> unsuccessful attempt?
--
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-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829170#comment-16829170
]
Jason Gerlowski commented on SOLR-13318:
Hi Munendra, thanks for the reminder. I looked at the patches when you
uploaded them, but haven't found time to test in more detail. I promise to get
this in for 8.1 though.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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] [Resolved] (SOLR-13343) Diagnostic Browser Log Spacing issues.
[ https://issues.apache.org/jira/browse/SOLR-13343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-13343. Resolution: Fixed Assignee: Jason Gerlowski Fix Version/s: master (9.0) 8.1 > Diagnostic Browser Log Spacing issues. > -- > > Key: SOLR-13343 > URL: https://issues.apache.org/jira/browse/SOLR-13343 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.4, 7.5, 7.6, 7.7.1 >Reporter: Marcus Eagan >Assignee: Jason Gerlowski >Priority: Trivial > Fix For: 8.1, master (9.0) > > Attachments: How_it_is_now.png, How_it_should_be.png, Screen Shot > 2019-04-06 at 8.28.28 AM.png > > > There is a small issue with the browser log for the count of how long Solr > has been alive. It affects all versions since the library was added to Solr. > Here is the pull request: > [https://github.com/apache/lucene-solr/pull/592] -- 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-13343) Diagnostic Browser Log Spacing issues.
[ https://issues.apache.org/jira/browse/SOLR-13343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827631#comment-16827631 ] Jason Gerlowski commented on SOLR-13343: Hey Marcus, thanks for digging into this and providing a fix. Sorry it took me a bit to get it through. Even trivial javascript is not my comfort zone. Should see it fixed on master (9.0) and branch_8x (8.1). > Diagnostic Browser Log Spacing issues. > -- > > Key: SOLR-13343 > URL: https://issues.apache.org/jira/browse/SOLR-13343 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.4, 7.5, 7.6, 7.7.1 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: How_it_is_now.png, How_it_should_be.png, Screen Shot > 2019-04-06 at 8.28.28 AM.png > > > There is a small issue with the browser log for the count of how long Solr > has been alive. It affects all versions since the library was added to Solr. > Here is the pull request: > [https://github.com/apache/lucene-solr/pull/592] -- 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-13417) SolrJ's JsonFacetingResponse mishandles stat-facets on date fields
Jason Gerlowski created SOLR-13417:
--
Summary: SolrJ's JsonFacetingResponse mishandles stat-facets on
date fields
Key: SOLR-13417
URL: https://issues.apache.org/jira/browse/SOLR-13417
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: 8.0, 7.7, master (9.0)
Reporter: Jason Gerlowski
SolrJ has some classes which simplify access to JSON Faceting responses. These
classes parse the response and maintain a Map of facet names to their values.
Currently, this section has a bug where it only records stat facets in this Map
if the facet value is a {{Number}}. (When writing this code, I mistakenly
assumed that stat functions could be used on date fields).
We should fix JsonFacetingResponse so that it handles date-based facets
correctly.
--
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] [Resolved] (SOLR-13355) RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
[
https://issues.apache.org/jira/browse/SOLR-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-13355.
Resolution: Fixed
Fix Version/s: master (9.0)
8.1
7.7.2
Yes, sorry Jan, this was fixed a few weeks ago. Thanks for the reminder.
> RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
> ---
>
> Key: SOLR-13355
> URL: https://issues.apache.org/jira/browse/SOLR-13355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Affects Versions: 7.5, 8.0, master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13355.patch
>
>
> RuleBasedAuthorizationPlugin defines a set of predefined permission rules
> that users can use ootb to lock down sets of APIs to different roles (and
> ultimately, users). The widest of these, the "all" permission is intended to
> be a catch-all that covers all requests not handled by an earlier rule.
> But in practice, "all" doesn't seem to have any effect on most endpoints.
> For example, the security.json below will still allow the readonly user to
> hit almost all endpoints!
> {code}
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "readonly": "",
> "admin": ""}},
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {"name":"read","role": "*"},
> {"name":"schema-read", "role":"*"},
> {"name":"config-read", "role":"*"},
> {"name":"collection-admin-read", "role":"*"},
> {"name":"metrics-read", "role":"*"},
> {"name":"core-admin-read","role":"*"},
> {"name": "all", "role": "admin_role"}
> ],
> "user-role": {
> "readonly": "readonly_role",
> "admin": "admin_role"
> }}}
> {code}
> It looks like this happens because we neglect to check for the "all" special
> case in the branch of code that gets triggered for Handlers that implement
> PermissionNameProvider. See
> [here|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L122].
> e.g. With the security.json above if the "readonly" user makes a request to
> {{/admin/authorization}}, the PermissionNameProvider will return
> {{SECURITY_EDIT}}. When deciding whether the "all" permission applies to
> that endpoint, the code compares SECURITY_EDIT to ALL, sees they don't match,
> and decides that "all" doesn't apply.
--
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] [Resolved] (SOLR-13383) auto-scaling not working in solr7.4 - autoaddreplica
" : "execute_plan",
> "class": "solr.ExecutePlanAction"
>}
> ]
> }
> }'
> Note the same policy(2,3) not working in 7.4
> Errors:
> {code:java}
> [Mon Apr 08 11:52:00 UTC root@hawkeye-common ~]# curl
> http://localhost:8983/solr/admin/autoscaling -H
> 'Content-type:application/json' -d '{
> > "set-trigger": {
> > "name" : "node_added_trigger",
> > "event" : "nodeAdded",
> > "waitFor" : "5s",
> > "preferredOperation": "ADDREPLICA",
> > "enabled" : true,
> > "actions" : [
> >{
> > "name" : "compute_plan",
> > "class": "solr.ComputePlanAction"
> >},
> >{
> > "name" : "execute_plan",
> > "class": "solr.ExecutePlanAction"
> >}
> > ]
> > }
> > }'
> {
> "responseHeader":{
> "status":400,
> "QTime":5},
> "result":"failure",
> "WARNING":"This response format is experimental. It is likely to change in
> the future.",
> "error":{
> "metadata":[
> "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
> "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
> "details":[{
> "set-trigger":{
> "name":"node_added_trigger",
> "event":"nodeAdded",
> "waitFor":"5s",
> "preferredOperation":"ADDREPLICA",
> "enabled":true,
> "actions":[{
> "name":"compute_plan",
> "class":"solr.ComputePlanAction"},
> {
> "name":"execute_plan",
> "class":"solr.ExecutePlanAction"}]},
> "errorMessages":["Error validating trigger config node_added_trigger:
> TriggerValidationException{name=node_added_trigger,
> details='{preferredOperation=unknown property}'}"]}],
> "msg":"Error in command payload",
> "code":400}}
> [Mon Apr 08 11:52:09 UTC root@hawkeye-common ~]#
> [Mon Apr 08 11:52:16 UTC root@hawkeye-common ~]# curl
> http://localhost:8983/solr/admin/autoscaling -H
> 'Content-type:application/json' -d '{
> > "set-trigger": {
> > "name" : "node_lost_trigger",
> > "event" : "nodeLost",
> > "waitFor" : "5s",
> > "preferredOperation": "DELETENODE",
> > "enabled" : true,
> > "actions" : [
> >{
> > "name" : "compute_plan",
> > "class": "solr.ComputePlanAction"
> >},
> >{
> > "name" : "execute_plan",
> > "class": "solr.ExecutePlanAction"
> >}
> > ]
> > }
> > }'
> {
> "responseHeader":{
> "status":400,
> "QTime":1},
> "result":"failure",
> "WARNING":"This response format is experimental. It is likely to change in
> the future.",
> "error":{
> "metadata":[
> "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
> "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
> "details":[{
> "set-trigger":{
> "name":"node_lost_trigger",
> "event":"nodeLost",
> "waitFor":"5s",
> "preferredOperation":"DELETENODE",
> "enabled":true,
> "actions":[{
> "name":"compute_plan",
> "class":"solr.ComputePlanAction"},
> {
> "name":"execute_plan",
> "class":"solr.ExecutePlanAction"}]},
> "errorMessages":["Error validating trigger config node_lost_trigger:
> TriggerValidationException{name=node_lost_trigger,
> details='{preferredOperation=unknown property}'}"]}],
> "msg":"Error in command payload",
> "code":400}}
> {code}
> if any new sever added into that cluster the data(collection) must be added
> as a replica in that cluster.[AddReplica Automatically added in version 7.5]
> https://i.stack.imgur.com/DgEbL.png
> Kindly help me to resolve this case.
> I need a exact trigger which will perform a AutoAddReplica Action
--
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-13285) ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during replication
[
https://issues.apache.org/jira/browse/SOLR-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816508#comment-16816508
]
Jason Gerlowski commented on SOLR-13285:
Yeah, I'll try to take a look at it this weekend. I need to backport
SOLR-13331 anyways.
> ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during
> replication
> -
>
> Key: SOLR-13285
> URL: https://issues.apache.org/jira/browse/SOLR-13285
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java), SolrCloud, SolrJ
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: centos 7
> solrcloud 7.7.1, 8.1.0
>Reporter: Karl Stoney
>Assignee: Noble Paul
>Priority: Major
> Labels: newbie, replication
> Attachments: SOLR-13285.patch, SOLR-13285.patch
>
>
> Since upgrading to 7.7 (also tried 7.7.1, and 8.1.0) from 6.6.4, we're seeing
> the following errors in the SolrCloud elected master for a given collection
> when updates are written. This was after a full reindex of data (fresh
> build).
> {code:java}
> request:
> http://solr-1.search-solr.preprod.k8.atcloud.io:80/solr/at-uk_shard1_replica_n2/update?update.distrib=FROMLEADER=http%3A%2F%2Fsolr-2.search-solr.preprod.k8.atcloud.io%3A80%2Fsolr%2Fat-uk_shard1_replica_n1%2F=javabin=2
> Remote error message: org.apache.solr.common.util.ByteArrayUtf8CharSequence
> cannot be cast to java.lang.String
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:385)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:183)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
> Following this through to the replica, you'll see:
> {code:java}
> 08:35:22.060 [qtp1540374340-20] ERROR org.apache.solr.servlet.HttpSolrCall -
> null:java.lang.ClassCastException:
> org.apache.solr.common.util.ByteArrayUtf8CharSequence cannot be cast to
> java.lang.String
> at
> org.apache.solr.common.util.JavaBinCodec.readEnumFieldValue(JavaBinCodec.java:813)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:339)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:640)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:337)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.readMapEntry(JavaBinCodec.java:819)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:341)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:295)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:333)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:191)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
> at
>
[jira] [Commented] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header
[
https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816338#comment-16816338
]
Jason Gerlowski commented on SOLR-13270:
Spent some more time testing the attached patch, and I'm still not confident
it's working the way we hoped. I debugged things through SolrJ and verified
that with the patch the custom RequestConfig does _not_ get overridden by the
default RequestConfig. The custom RequestConfig makes it into HttpClient-land.
Which is good. But I'm still not seeing an "Expect" header from the request.
I spent a bit of time tracing it through the HttpComponent code last night, but
couldn't find anywhere that uses RequestConfig's "expect" getter. Surely I'm
just missing it, but I'm not sure how to proceed without help from someone with
more HttpComponent know-how.
[~erlendfg] can you double check me, and verify whether the patch fixes the
problem for you?
> SolrJ does not send "Expect: 100-continue" header
> -
>
> Key: SOLR-13270
> URL: https://issues.apache.org/jira/browse/SOLR-13270
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7
>Reporter: Erlend Garåsen
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13270.patch
>
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's
> configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
> the client correctly, so we have a reason to believe there is a bug in
> SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
> https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small
> Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and
> HttpClient code where the header is present.
>
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
> HttpClient httpClient = builder.build();
> // Start Solr and create a core named "test".
> String baseUrl = "http://localhost:8983/solr/test;;
> // Test using SolrJ — no expect 100 header
> HttpSolrClient client = new HttpSolrClient.Builder()
> .withHttpClient(httpClient)
> .withBaseSolrUrl(baseUrl).build();
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> client.query(query);
> // Test using HttpClient directly — expect 100 header shows up:
> HttpPost httpPost = new HttpPost(baseUrl);
> HttpEntity entity = new InputStreamEntity(new
> ByteArrayInputStream("test".getBytes()));
> httpPost.setEntity(entity);
> httpClient.execute(httpPost);
> {code}
> When using the last HttpClient test, the expect 100 header appears in
> missing-header.log:
> {noformat}
> http-outgoing-1 >> Expect: 100-continue{noformat}
--
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-13285) ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during replication
[
https://issues.apache.org/jira/browse/SOLR-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814463#comment-16814463
]
Jason Gerlowski commented on SOLR-13285:
The Atomic-update "remove" and "regexremove" instances of this problem are
tracked on SOLR-13331, which was just resolved recently. [~lyle_wang] or
[~jbnas], your issues should be fixed starting in 8.1. (If you want to double
check me on this, please use a nightly build of Solr of build from source on
the {{master}} or {{branch_8x}} branches and let me know if you still run into
the issue over on SOLR-13331.
> ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during
> replication
> -
>
> Key: SOLR-13285
> URL: https://issues.apache.org/jira/browse/SOLR-13285
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java), SolrCloud, SolrJ
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: centos 7
> solrcloud 7.7.1, 8.1.0
>Reporter: Karl Stoney
>Assignee: Noble Paul
>Priority: Major
> Labels: newbie, replication
> Attachments: SOLR-13285.patch, SOLR-13285.patch
>
>
> Since upgrading to 7.7 (also tried 7.7.1, and 8.1.0) from 6.6.4, we're seeing
> the following errors in the SolrCloud elected master for a given collection
> when updates are written. This was after a full reindex of data (fresh
> build).
> {code:java}
> request:
> http://solr-1.search-solr.preprod.k8.atcloud.io:80/solr/at-uk_shard1_replica_n2/update?update.distrib=FROMLEADER=http%3A%2F%2Fsolr-2.search-solr.preprod.k8.atcloud.io%3A80%2Fsolr%2Fat-uk_shard1_replica_n1%2F=javabin=2
> Remote error message: org.apache.solr.common.util.ByteArrayUtf8CharSequence
> cannot be cast to java.lang.String
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:385)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:183)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
> ~[metrics-core-3.2.6.jar:3.2.6]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 -
> ishan - 2019-02-23 02:39:09]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
> Following this through to the replica, you'll see:
> {code:java}
> 08:35:22.060 [qtp1540374340-20] ERROR org.apache.solr.servlet.HttpSolrCall -
> null:java.lang.ClassCastException:
> org.apache.solr.common.util.ByteArrayUtf8CharSequence cannot be cast to
> java.lang.String
> at
> org.apache.solr.common.util.JavaBinCodec.readEnumFieldValue(JavaBinCodec.java:813)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:339)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:640)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:337)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.common.util.JavaBinCodec.readMapEntry(JavaBinCodec.java:819)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:341)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:295)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:333)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
> at
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> at
[jira] [Resolved] (SOLR-13377) NestableJsonFacet ClassCastException in SolrJ 7.6+
[ https://issues.apache.org/jira/browse/SOLR-13377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-13377. Resolution: Duplicate Hi Owen, thanks for reporting. We're already tracking (and working on this issue) under SOLR-13318, so I'm going to close this copy out as a duplicate. Feel free to continue the discussion over there. > NestableJsonFacet ClassCastException in SolrJ 7.6+ > -- > > Key: SOLR-13377 > URL: https://issues.apache.org/jira/browse/SOLR-13377 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.6, 7.7, 7.7.1 >Reporter: Owen Clarke >Priority: Major > Attachments: SOLR-13377.patch > > > Identified by Gerald Bonfiglio on the mailing list: > [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201903.mbox/%3C2B629E99E8E563409788D895FACA8198AA754A96%40mbx031-w1-co-4.exch031.domain.local%3E] > I have also encountered this issue where NestableJsonFacet occasionally > receives the facet count as a Long value but blindly casts to int when > assigning to domainCount, causing a ClassCastExcption. I have a fix to > instead check if the count value is instanceof Number, then use > Number.longValue() to safely unbox to long. -- 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] [Comment Edited] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812026#comment-16812026
]
Jason Gerlowski edited comment on SOLR-13318 at 4/8/19 2:15 AM:
Thanks for the patch Munendra. I agree with the comments you left in the patch
- we'll have to change the types of our instance vars where you pointed them
out, as well as some method return types.
You're also right that changing those return types would run afoul of our
back-compat policy. We've got a few options:
1. Only fix this in master, and requires users wait until 9.0 for the fix.
2. Keep the int-returning methods and leave their signatures as-is, while
introducing near-duplicate methods that return the correct types. Deprecate
the int-returning versions with references to these new methods.
3. Make a special request on the dev-list to exempt this change from our
back-compat policy. I think there's an "ok" argument for doing that here...our
backcompat policy is intended to help us serve our users. Slavishly
maintaining backcompat and keeping the buggy versions of these methods around
meets the letter of that law, but totally fails to meet the spirit. We're not
doing our users any favors by keeping these methods around.
So to answer your question ("Should I create different patches"), I'm not
entirely decided. I might appeal to the dev-list to see if anyone cares in
this case. But most likely I'll pursue option 2. In that case, I'll build off
of your patch and introduce the duplicate methods and deprecation warnings.
I'll try to have something ready on this sometime this week.
was (Author: gerlowskija):
Thanks for the patch Munendra. I agree with the comments you left in the patch
- we'll have to change the types of our instance vars where you pointed them
out, as well as some method return types.
You're also right that changing those return types would run afoul of our
back-compat policy. We've got a few options:
1. Only fix this in master, and requires users wait until 9.0 for the fix.
2. Keep the int-returning methods and leave their signatures as-is, while
introducing near-duplicate methods that return the correct types. Deprecate
the int-returning versions with references to these new methods.
3. Make a special request on the dev-list to exempt this change from our
back-compat policy. I think there's an "ok" argument for doing that here...our
backcompat policy is intended to help us serve our users. Slavishly
maintaining backcompat and keeping the buggy versions of these methods around
meets the letter of that law, but totally fails to meet the spirit. We're not
doing our users any favors by keeping these methods around.
So to answer your question ("Should I create different patches"), I'm not
entirely decided. I might appeal to the dev-list to see if anyone cares in
this case. But most likely I'll pursue option 2. In that case, I'll build off
of your patch and introduce the duplicate methods and deprecation warnings.
I'll try to something ready on this sometime this week.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs
[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812026#comment-16812026
]
Jason Gerlowski commented on SOLR-13318:
Thanks for the patch Munendra. I agree with the comments you left in the patch
- we'll have to change the types of our instance vars where you pointed them
out, as well as some method return types.
You're also right that changing those return types would run afoul of our
back-compat policy. We've got a few options:
1. Only fix this in master, and requires users wait until 9.0 for the fix.
2. Keep the int-returning methods and leave their signatures as-is, while
introducing near-duplicate methods that return the correct types. Deprecate
the int-returning versions with references to these new methods.
3. Make a special request on the dev-list to exempt this change from our
back-compat policy. I think there's an "ok" argument for doing that here...our
backcompat policy is intended to help us serve our users. Slavishly
maintaining backcompat and keeping the buggy versions of these methods around
meets the letter of that law, but totally fails to meet the spirit. We're not
doing our users any favors by keeping these methods around.
So to answer your question ("Should I create different patches"), I'm not
entirely decided. I might appeal to the dev-list to see if anyone cares in
this case. But most likely I'll pursue option 2. In that case, I'll build off
of your patch and introduce the duplicate methods and deprecation warnings.
I'll try to something ready on this sometime this week.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
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-13270) SolrJ does not send "Expect: 100-continue" header
[
https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811918#comment-16811918
]
Jason Gerlowski commented on SOLR-13270:
Thinking about this again this morning. I think there's a few snags that
weren't apparent at first.
As best as I can tell, _all_ HttpClient's have a RequestConfig object that they
fall back to as a default. That is, even if the user doesn't explicitly
specify one when creating the HttpClient, the client still has a RequestConfig.
So we can't do the simple solution here of "always using the RequestConfig on
the client, if it exists". Further complicating things, HttpClient doesn't
provide any accessor for getting at the RequestConfig. So even if we knew a
user wanted to use the RequestConfig attached to a given HttpClient, we
couldn't do anything fancy like calling {{RequestConfig.copy}} and tweaking
particular settings.
(I'm not an expert on HttpComponent stuff. Happy to take correction if
anything above is wrong.)
We do still have a few options though. The best one probably is to add a
setter on our SolrClientBuilders that controls whether or not we override
RequestConfig. It would set a flag, and based on this, HttpSolrClient could
avoid calling {{HttpClientUtils.createDefaultRequestConfigBuilder}}. This has
some downsides: what happens when RequestConfig invalidates some other
SolrClient settings (e.g. read timeout), what happens when a user sets this
flag but doesn't provide a HttpClient, etc. But a lot of these issues can be
minimized by advertising the setter as an "expert-level" option, and making the
issues very clear in the Javadocs. It's not elegant, but it'll get the job
done.
I'll upload and test out a patch with this change. If no one has any concerns
with the approach, I'll go forward with it soon.
> SolrJ does not send "Expect: 100-continue" header
> -
>
> Key: SOLR-13270
> URL: https://issues.apache.org/jira/browse/SOLR-13270
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7
>Reporter: Erlend Garåsen
>Assignee: Jason Gerlowski
>Priority: Major
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's
> configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
> the client correctly, so we have a reason to believe there is a bug in
> SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
> https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small
> Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and
> HttpClient code where the header is present.
>
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
> HttpClient httpClient = builder.build();
> // Start Solr and create a core named "test".
> String baseUrl = "http://localhost:8983/solr/test;;
> // Test using SolrJ — no expect 100 header
> HttpSolrClient client = new HttpSolrClient.Builder()
> .withHttpClient(httpClient)
> .withBaseSolrUrl(baseUrl).build();
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> client.query(query);
> // Test using HttpClient directly — expect 100 header shows up:
> HttpPost httpPost = new HttpPost(baseUrl);
> HttpEntity entity = new InputStreamEntity(new
> ByteArrayInputStream("test".getBytes()));
> httpPost.setEntity(entity);
> httpClient.execute(httpPost);
> {code}
> When using the last HttpClient test, the expect 100 header appears in
> missing-header.log:
> {noformat}
> http-outgoing-1 >> Expect: 100-continue{noformat}
--
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-13343) Diagnostic Browser Log Spacing issues.
[ https://issues.apache.org/jira/browse/SOLR-13343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811566#comment-16811566 ] Jason Gerlowski commented on SOLR-13343: I'm not seeing the spacing issue you mentioned (screenshot attached) Are there some particular steps needed to reproduce this? Am I looking in the wrong place? !Screen Shot 2019-04-06 at 8.28.28 AM.png! > Diagnostic Browser Log Spacing issues. > -- > > Key: SOLR-13343 > URL: https://issues.apache.org/jira/browse/SOLR-13343 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.4, 7.5, 7.6, 7.7.1 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Screen Shot 2019-04-06 at 8.28.28 AM.png > > > There is a small issue with the browser log for the count of how long Solr > has been alive. It affects all versions since the library was added to Solr. > Here is the pull request: > [https://github.com/apache/lucene-solr/pull/592] -- 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-13343) Diagnostic Browser Log Spacing issues.
[ https://issues.apache.org/jira/browse/SOLR-13343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-13343: --- Attachment: Screen Shot 2019-04-06 at 8.28.28 AM.png > Diagnostic Browser Log Spacing issues. > -- > > Key: SOLR-13343 > URL: https://issues.apache.org/jira/browse/SOLR-13343 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.4, 7.5, 7.6, 7.7.1 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Screen Shot 2019-04-06 at 8.28.28 AM.png > > > There is a small issue with the browser log for the count of how long Solr > has been alive. It affects all versions since the library was added to Solr. > Here is the pull request: > [https://github.com/apache/lucene-solr/pull/592] -- 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-13331) Atomic Update Multivalue remove does not work
[
https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808006#comment-16808006
]
Jason Gerlowski commented on SOLR-13331:
Hi Thomas. Thanks for putting in some real legwork on this. Particularly for
testing with all the different field types.
Adding the {{ByteArrayUtf8CharSequence}}->{{String}} conversion to the base
{{FieldType}} class as you suggest will fix a lot of these errors. I'm a
little leery that it might have side effects we don't want, but I'm still
investigating and hopefully I can rule that out.
[~noble.paul] Any thoughts on using {{FieldType.toNativeType}} to correct this
issue? You've got more context on how some of the other
ByteArrayUtf8CharSequence issues were handled, figured I'd see if this fix
looked OK to you...
If nothing else turns up, I'll put together a test for this and merge in a day
or two.
> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
> Labels: patch
> Fix For: 8.0
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch
>
>
> When using JavaBinCodec the values of collections are of type
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method
> doRemove.
> The method parameter fieldVal contains the collection values of type
> ByteArrayUtf8CharSequence, the variable original contains the collection of
> Strings
--
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] [Resolved] (SOLR-13362) SolrJ's LukeRequest should support "includeIndexFieldFlags"
[
https://issues.apache.org/jira/browse/SOLR-13362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-13362.
Resolution: Fixed
Fix Version/s: master (9.0)
8.1
> SolrJ's LukeRequest should support "includeIndexFieldFlags"
> ---
>
> Key: SOLR-13362
> URL: https://issues.apache.org/jira/browse/SOLR-13362
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13362.patch
>
>
> SOLR-7799 introduces the query-param flag "includeIndexFieldFlags", which
> tells Solr that the index flags aren't needed and can be skipped. Fetching
> these flags takes some time, so specifying {{includeIndexFieldFlags=false}}
> on requests can save some time for if users don't need that information and
> have collections with a lot of fields.
> Support for this flag was never added to the SolrJ class used to trigger
> requests to Luke though. It's a pain to use the flag in SolrJ as LukeRequest
> is currently written.
--
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-13362) SolrJ's LukeRequest should support "includeIndexFieldFlags"
Jason Gerlowski created SOLR-13362:
--
Summary: SolrJ's LukeRequest should support
"includeIndexFieldFlags"
Key: SOLR-13362
URL: https://issues.apache.org/jira/browse/SOLR-13362
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: master (9.0)
Reporter: Jason Gerlowski
Assignee: Jason Gerlowski
SOLR-7799 introduces the query-param flag "includeIndexFieldFlags", which tells
Solr that the index flags aren't needed and can be skipped. Fetching these
flags takes some time, so specifying {{includeIndexFieldFlags=false}} on
requests can save some time for if users don't need that information and have
collections with a lot of fields.
Support for this flag was never added to the SolrJ class used to trigger
requests to Luke though. It's a pain to use the flag in SolrJ as LukeRequest
is currently written.
--
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] [Comment Edited] (SOLR-13344) Admin UI inaccessible with RuleBasedAuthorizationPlugin
[
https://issues.apache.org/jira/browse/SOLR-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806914#comment-16806914
]
Jason Gerlowski edited comment on SOLR-13344 at 4/1/19 3:33 PM:
Your PR looks good to me such as it is. I was worried about str comparison on
the path being brittle, but I'm reassured that we already do this for
authentication.
My only question on the code itself: For authentication, we check against the
paths {{/}} and {{/solr/}}, but in your PR you're only checking against {{/}}.
Is there a reason for that?
As for the functionality of your patch, I tested it quickly myself and can
confirm that I am prompted for credentials by the expected "Basic Auth" splash
screen when I first load the admin UI, which is an improvement. And when I
provide credentials for an admin user, the admin UI appears as expected.
But if I provide credentials for a user with readonly permissions (read,
schema-read, config-read, core-admin-read, collection-admin-read), the Admin UI
appears, but looks pretty crippled (see attached screenshot). This isn't a bug
per-se...the logged-in user just didn't have the right permissions. And really
it has nothing to do with the login-page...this same behavior happens in Solr
versions before the login screen was introduced. But now that we have a nice
page that prompts the user about logging in, maybe it's worth adding a short
warning about this situation to the text there? Something like:
bq. Solr's Admin UI interacts with Solr using its public APIs. When rule-based
authorization is in use, login users not authorized to access the full range of
these APIs may see some sections of the UI that appear blank or "broken". For
best results, the Admin UI should only be accessed by logins with full API
access.
Maybe that's too wordy...Just an idea. The patch has my +1 with or without it.
was (Author: gerlowskija):
Your PR looks good to me such as it is. I was worried about str comparison on
the path being brittle, but I'm reassured that we already do this for
authentication.
My only question on the code itself: For authentication, we check against the
paths {{/}} and {{/solr/}}, but in your PR you're only checking against {{/}}.
Is there a reason for that?
As for the functionality of your patch, I tested it quickly myself and can
confirm that I am prompted for credentials by the expected "Basic Auth" splash
screen when I first load the admin UI, which is an improvement. And when I
provide credentials for an admin user, the admin UI appears as expected.
But if I provide credentials for a user with readonly permissions (read,
schema-read, config-read, core-admin-read, collection-admin-read), the Admin UI
appears, but looks pretty crippled (see attached screenshot). This isn't a bug
per-se...the logged-in user just didn't have the right permissions. And really
it has nothing to do with the login-page...this same behavior happens in Solr
versions before the login screen was introduced.
But now that we have a nice page that prompts the user about logging in, maybe
it's worth adding a short warning about this situation to the text there?
Something like: {{Solr's Admin UI interacts with Solr using its public APIs.
When rule-based authorization is in use, login users not authorized to access
the full range of these APIs may see some sections of the UI that appear blank
or "broken". For best results, Solr's Admin UI should only be accessed by
logins with full API access.}}. Maybe that's too wordy...
Just throwing that out there as an idea. The patch has my +1 with or without
it.
> Admin UI inaccessible with RuleBasedAuthorizationPlugin
> ---
>
> Key: SOLR-13344
> URL: https://issues.apache.org/jira/browse/SOLR-13344
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Authentication
>Affects Versions: 7.7, 8.0
>Reporter: Märt
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SOLR-7896 made some changes to the admin ui login. After the changes I can no
> longer log in at all.
> I'm running standalone solr 7.7 (same with 8.0) with the following
> security.json:
> {code}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "all",
> "role": "admin"
> }
> ],
> "user-role": {
[jira] [Commented] (SOLR-13344) Admin UI inaccessible with RuleBasedAuthorizationPlugin
[
https://issues.apache.org/jira/browse/SOLR-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806914#comment-16806914
]
Jason Gerlowski commented on SOLR-13344:
Your PR looks good to me such as it is. I was worried about str comparison on
the path being brittle, but I'm reassured that we already do this for
authentication.
My only question on the code itself: For authentication, we check against the
paths {{/}} and {{/solr/}}, but in your PR you're only checking against {{/}}.
Is there a reason for that?
As for the functionality of your patch, I tested it quickly myself and can
confirm that I am prompted for credentials by the expected "Basic Auth" splash
screen when I first load the admin UI, which is an improvement. And when I
provide credentials for an admin user, the admin UI appears as expected.
But if I provide credentials for a user with readonly permissions (read,
schema-read, config-read, core-admin-read, collection-admin-read), the Admin UI
appears, but looks pretty crippled (see attached screenshot). This isn't a bug
per-se...the logged-in user just didn't have the right permissions. And really
it has nothing to do with the login-page...this same behavior happens in Solr
versions before the login screen was introduced.
But now that we have a nice page that prompts the user about logging in, maybe
it's worth adding a short warning about this situation to the text there?
Something like: {{Solr's Admin UI interacts with Solr using its public APIs.
When rule-based authorization is in use, login users not authorized to access
the full range of these APIs may see some sections of the UI that appear blank
or "broken". For best results, Solr's Admin UI should only be accessed by
logins with full API access.}}. Maybe that's too wordy...
Just throwing that out there as an idea. The patch has my +1 with or without
it.
> Admin UI inaccessible with RuleBasedAuthorizationPlugin
> ---
>
> Key: SOLR-13344
> URL: https://issues.apache.org/jira/browse/SOLR-13344
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Authentication
>Affects Versions: 7.7, 8.0
>Reporter: Märt
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SOLR-7896 made some changes to the admin ui login. After the changes I can no
> longer log in at all.
> I'm running standalone solr 7.7 (same with 8.0) with the following
> security.json:
> {code}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "all",
> "role": "admin"
> }
> ],
> "user-role": {
> "solr": "admin"
> }
> }
> }
> {code}
> Opening the UI at http://localhost:8080/solr/ shows an error page with 401.
> The login page is not displayed because of the "all" permission being
> required. The browser's basic auth popup is not shown because the
> WWW-Authenticate header is not present. Changing the
> RuleBasedAuthorizationPlugin required permission from "all" to
> "security-edit" makes the login page appear.
> The bug can be reproduced as follows:
> # unpack solr-8.0.0.zip
> # copy the security.json example from
> https://lucene.apache.org/solr/guide/7_7/basic-authentication-plugin.html
> into server/solr/ and replace "name":"security-edit" with "name":"all"
> # start with bin/solr -f -p 8080
> # open http://localhost:8080/
> The bug was discussed on solr-user list
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201903.mbox/%3C7629BDDD-3D22-4203-9188-0E0A8DCF2FEE%40cominvent.com%3E
--
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-13355) RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
[
https://issues.apache.org/jira/browse/SOLR-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805202#comment-16805202
]
Jason Gerlowski commented on SOLR-13355:
I attached a patch fixing this behavior. When I go to commit, I'll probably
split this into two pieces: (1) a refactor to make it easier to understand
what's going on in the code involved but no functional changes, and (2) a small
functional change with some tests. Will commit over the weekend if further
testing looks good.
> RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
> ---
>
> Key: SOLR-13355
> URL: https://issues.apache.org/jira/browse/SOLR-13355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Affects Versions: 7.5, 8.0, master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13355.patch
>
>
> RuleBasedAuthorizationPlugin defines a set of predefined permission rules
> that users can use ootb to lock down sets of APIs to different roles (and
> ultimately, users). The widest of these, the "all" permission is intended to
> be a catch-all that covers all requests not handled by an earlier rule.
> But in practice, "all" doesn't seem to have any effect on most endpoints.
> For example, the security.json below will still allow the readonly user to
> hit almost all endpoints!
> {code}
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "readonly": "",
> "admin": ""}},
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {"name":"read","role": "*"},
> {"name":"schema-read", "role":"*"},
> {"name":"config-read", "role":"*"},
> {"name":"collection-admin-read", "role":"*"},
> {"name":"metrics-read", "role":"*"},
> {"name":"core-admin-read","role":"*"},
> {"name": "all", "role": "admin_role"}
> ],
> "user-role": {
> "readonly": "readonly_role",
> "admin": "admin_role"
> }}}
> {code}
> It looks like this happens because we neglect to check for the "all" special
> case in the branch of code that gets triggered for Handlers that implement
> PermissionNameProvider. See
> [here|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L122].
> e.g. With the security.json above if the "readonly" user makes a request to
> {{/admin/authorization}}, the PermissionNameProvider will return
> {{SECURITY_EDIT}}. When deciding whether the "all" permission applies to
> that endpoint, the code compares SECURITY_EDIT to ALL, sees they don't match,
> and decides that "all" doesn't apply.
--
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-13355) RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
[
https://issues.apache.org/jira/browse/SOLR-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-13355:
---
Attachment: SOLR-13355.patch
> RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
> ---
>
> Key: SOLR-13355
> URL: https://issues.apache.org/jira/browse/SOLR-13355
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Affects Versions: 7.5, 8.0, master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13355.patch
>
>
> RuleBasedAuthorizationPlugin defines a set of predefined permission rules
> that users can use ootb to lock down sets of APIs to different roles (and
> ultimately, users). The widest of these, the "all" permission is intended to
> be a catch-all that covers all requests not handled by an earlier rule.
> But in practice, "all" doesn't seem to have any effect on most endpoints.
> For example, the security.json below will still allow the readonly user to
> hit almost all endpoints!
> {code}
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "readonly": "",
> "admin": ""}},
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {"name":"read","role": "*"},
> {"name":"schema-read", "role":"*"},
> {"name":"config-read", "role":"*"},
> {"name":"collection-admin-read", "role":"*"},
> {"name":"metrics-read", "role":"*"},
> {"name":"core-admin-read","role":"*"},
> {"name": "all", "role": "admin_role"}
> ],
> "user-role": {
> "readonly": "readonly_role",
> "admin": "admin_role"
> }}}
> {code}
> It looks like this happens because we neglect to check for the "all" special
> case in the branch of code that gets triggered for Handlers that implement
> PermissionNameProvider. See
> [here|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L122].
> e.g. With the security.json above if the "readonly" user makes a request to
> {{/admin/authorization}}, the PermissionNameProvider will return
> {{SECURITY_EDIT}}. When deciding whether the "all" permission applies to
> that endpoint, the code compares SECURITY_EDIT to ALL, sees they don't match,
> and decides that "all" doesn't apply.
--
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-13344) Admin UI inaccessible with RuleBasedAuthorizationPlugin
[
https://issues.apache.org/jira/browse/SOLR-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805112#comment-16805112
]
Jason Gerlowski commented on SOLR-13344:
Yeah, putting in some sort of special case like that might make sense, but it's
definitely not there now. Are the admin UI files served up by a particular
request handler that we could add a check for? It's ugly, but there are
already instanceof checks in there on the request handler...
Alternatively we might be able to put in a special case based on the path of
the request, but that seems potentially dangerous... I'd worry about that
allowing other things through unless we test it very well.
> Admin UI inaccessible with RuleBasedAuthorizationPlugin
> ---
>
> Key: SOLR-13344
> URL: https://issues.apache.org/jira/browse/SOLR-13344
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Authentication
>Affects Versions: 7.7, 8.0
>Reporter: Märt
>Priority: Major
>
> SOLR-7896 made some changes to the admin ui login. After the changes I can no
> longer log in at all.
> I'm running standalone solr 7.7 (same with 8.0) with the following
> security.json:
> {code}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "all",
> "role": "admin"
> }
> ],
> "user-role": {
> "solr": "admin"
> }
> }
> }
> {code}
> Opening the UI at http://localhost:8080/solr/ shows an error page with 401.
> The login page is not displayed because of the "all" permission being
> required. The browser's basic auth popup is not shown because the
> WWW-Authenticate header is not present. Changing the
> RuleBasedAuthorizationPlugin required permission from "all" to
> "security-edit" makes the login page appear.
> The bug can be reproduced as follows:
> # unpack solr-8.0.0.zip
> # copy the security.json example from
> https://lucene.apache.org/solr/guide/7_7/basic-authentication-plugin.html
> into server/solr/ and replace "name":"security-edit" with "name":"all"
> # start with bin/solr -f -p 8080
> # open http://localhost:8080/
> The bug was discussed on solr-user list
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201903.mbox/%3C7629BDDD-3D22-4203-9188-0E0A8DCF2FEE%40cominvent.com%3E
--
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-13355) RuleBasedAuthorizationPlugin ignores "all" permission for most handlers
Jason Gerlowski created SOLR-13355:
--
Summary: RuleBasedAuthorizationPlugin ignores "all" permission for
most handlers
Key: SOLR-13355
URL: https://issues.apache.org/jira/browse/SOLR-13355
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: security
Affects Versions: 8.0, 7.5, master (9.0)
Reporter: Jason Gerlowski
Assignee: Jason Gerlowski
RuleBasedAuthorizationPlugin defines a set of predefined permission rules that
users can use ootb to lock down sets of APIs to different roles (and
ultimately, users). The widest of these, the "all" permission is intended to
be a catch-all that covers all requests not handled by an earlier rule.
But in practice, "all" doesn't seem to have any effect on most endpoints. For
example, the security.json below will still allow the readonly user to hit
almost all endpoints!
{code}
{
"authentication": {
"blockUnknown": true,
"class": "solr.BasicAuthPlugin",
"credentials": {
"readonly": "",
"admin": ""}},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"permissions": [
{"name":"read","role": "*"},
{"name":"schema-read", "role":"*"},
{"name":"config-read", "role":"*"},
{"name":"collection-admin-read", "role":"*"},
{"name":"metrics-read", "role":"*"},
{"name":"core-admin-read","role":"*"},
{"name": "all", "role": "admin_role"}
],
"user-role": {
"readonly": "readonly_role",
"admin": "admin_role"
}}}
{code}
It looks like this happens because we neglect to check for the "all" special
case in the branch of code that gets triggered for Handlers that implement
PermissionNameProvider. See
[here|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L122].
e.g. With the security.json above if the "readonly" user makes a request to
{{/admin/authorization}}, the PermissionNameProvider will return
{{SECURITY_EDIT}}. When deciding whether the "all" permission applies to that
endpoint, the code compares SECURITY_EDIT to ALL, sees they don't match, and
decides that "all" doesn't apply.
--
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-13344) Admin UI inaccessible with RuleBasedAuthorizationPlugin
[
https://issues.apache.org/jira/browse/SOLR-13344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804915#comment-16804915
]
Jason Gerlowski commented on SOLR-13344:
I'm not the most familiar with the admin UI, but I'm looking into
RuleVasedAuthorizationPlugin and the "all" permission for other issues atm, so
I can offer a bit of info on that side of things.
bq. debugging why the admin UI is blocked by the "all" rule
As far as I can tell, there's no special casing in RuleBasedAuthorizationPlugin
for the Admin UI. When I go to the Admin UI in my browser
("http://localhost:8983/solr/;), the RBAP sees that as a request for the
context {{userPrincipal: [null] type: [UNKNOWN], collections: [], Path: [/]
path : / params :null}}, finds the matching "all" rule that locks things down
to the "solr" user, and rejects the request because there's no user/principal
specified. (See the line
[here|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L150]).
Did you expect something different to happen, or did you expect a special
codepath for the admin UI?
Noble added the "all" permission in SOLR-8428, maybe he could chime in on how
this is supposed to work with admin-ui requests? [~noble.paul]
> Admin UI inaccessible with RuleBasedAuthorizationPlugin
> ---
>
> Key: SOLR-13344
> URL: https://issues.apache.org/jira/browse/SOLR-13344
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Authentication
>Affects Versions: 7.7, 8.0
>Reporter: Märt
>Priority: Major
>
> SOLR-7896 made some changes to the admin ui login. After the changes I can no
> longer log in at all.
> I'm running standalone solr 7.7 (same with 8.0) with the following
> security.json:
> {code}
> {
> "authentication": {
> "class": "solr.BasicAuthPlugin",
> "blockUnknown": true,
> "credentials": {
> "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
> Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
> },
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "all",
> "role": "admin"
> }
> ],
> "user-role": {
> "solr": "admin"
> }
> }
> }
> {code}
> Opening the UI at http://localhost:8080/solr/ shows an error page with 401.
> The login page is not displayed because of the "all" permission being
> required. The browser's basic auth popup is not shown because the
> WWW-Authenticate header is not present. Changing the
> RuleBasedAuthorizationPlugin required permission from "all" to
> "security-edit" makes the login page appear.
> The bug can be reproduced as follows:
> # unpack solr-8.0.0.zip
> # copy the security.json example from
> https://lucene.apache.org/solr/guide/7_7/basic-authentication-plugin.html
> into server/solr/ and replace "name":"security-edit" with "name":"all"
> # start with bin/solr -f -p 8080
> # open http://localhost:8080/
> The bug was discussed on solr-user list
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201903.mbox/%3C7629BDDD-3D22-4203-9188-0E0A8DCF2FEE%40cominvent.com%3E
--
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] [Assigned] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski reassigned SOLR-13331: -- Assignee: Jason Gerlowski > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch > Fix For: 8.0 > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch > > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- 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] (LUCENE-8733) retrospectively add @since javadocs for 'intervals' classes
[
https://issues.apache.org/jira/browse/LUCENE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799218#comment-16799218
]
Jason Gerlowski commented on LUCENE-8733:
-
bq. I don't really like having them on internal classes though, they're an
implementation detail, and users of intervals shouldn't need to know about them
at all.
True, but if the package-private Javadocs aren't published, is this really a
concern? If these internal Javadocs are only exposed to those browsing in an
IDE, users are only going to stumble across them if they've already decided
they want (or need) to look at Lucene's internals. They're going to see the
internals with or without the @since.
Am I missing something here? I don't see anything wrong with adding the tags
if it makes lives easier for some developers, but maybe I just don't understand
the argument against...
> retrospectively add @since javadocs for 'intervals' classes
> ---
>
> Key: LUCENE-8733
> URL: https://issues.apache.org/jira/browse/LUCENE-8733
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8733-branch-7-4.patch
>
>
> LUCENE-8196 started 'intervals' and subsequent tickets extended it.
> This ticket proposes to retrospectively add {{@since X.Y}} javadocs for all
> the classes (and to then going forward perhaps continue to add them).
> And perhaps we could have an 'intervals' or similar JIRA components choice
> too?
--
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-13318) JsonFacetingResponse classes should record provide access to count fields as longs
Jason Gerlowski created SOLR-13318:
--
Summary: JsonFacetingResponse classes should record provide
access to count fields as longs
Key: SOLR-13318
URL: https://issues.apache.org/jira/browse/SOLR-13318
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: 7.7.1
Reporter: Jason Gerlowski
Assignee: Jason Gerlowski
JsonFacetingResponse and its series of dependent classes hold a variety of
count fields for bucket counts and various optional properties ({{allBuckets}},
{{numBuckets}}, etc.). Currently, some of the code that parses these values
out of the originating NamedList either stores or casts the values as ints.
When doc counts are low this works fine. But when the doc counts become larger
and stray into "long" territory, SolrJ is liable to blow up with
ClassCastExceptions.
A user on the list reported on of these with the partial stack trace:
{code}
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
java.lang.Integer
at
org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
at
org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
at
org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
{code}
We should fix this so that these classes can be used without incident for any
doc counts.
--
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] [Assigned] (SOLR-13270) SolrJ does not send "Expect: 100-continue" header
[
https://issues.apache.org/jira/browse/SOLR-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski reassigned SOLR-13270:
--
Assignee: Jason Gerlowski
> SolrJ does not send "Expect: 100-continue" header
> -
>
> Key: SOLR-13270
> URL: https://issues.apache.org/jira/browse/SOLR-13270
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.7
>Reporter: Erlend Garåsen
>Assignee: Jason Gerlowski
>Priority: Major
>
> SolrJ does not set the "Expect: 100-continue" header, even though it's
> configured in HttpClient:
> {code:java}
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());{code}
> A HttpClient developer has reviewed the code and says we're setting up
> the client correctly, so we have a reason to believe there is a bug in
> SolrJ. It's actually a problem we are facing in ManifoldCF, explained in:
> https://issues.apache.org/jira/browse/CONNECTORS-1564
> The problem can be reproduced by building and running the following small
> Maven project:
> [http://folk.uio.no/erlendfg/solr/missing-header.zip]
> The application runs SolrJ code where the header does not show up and
> HttpClient code where the header is present.
>
> {code:java}
> HttpClientBuilder builder = HttpClients.custom();
> // This should add an Expect: 100-continue header:
> builder.setDefaultRequestConfig(RequestConfig.custom().setExpectContinueEnabled(true).build());
> HttpClient httpClient = builder.build();
> // Start Solr and create a core named "test".
> String baseUrl = "http://localhost:8983/solr/test;;
> // Test using SolrJ — no expect 100 header
> HttpSolrClient client = new HttpSolrClient.Builder()
> .withHttpClient(httpClient)
> .withBaseSolrUrl(baseUrl).build();
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> client.query(query);
> // Test using HttpClient directly — expect 100 header shows up:
> HttpPost httpPost = new HttpPost(baseUrl);
> HttpEntity entity = new InputStreamEntity(new
> ByteArrayInputStream("test".getBytes()));
> httpPost.setEntity(entity);
> httpClient.execute(httpPost);
> {code}
> When using the last HttpClient test, the expect 100 header appears in
> missing-header.log:
> {noformat}
> http-outgoing-1 >> Expect: 100-continue{noformat}
--
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
