Re: [PR] SOLR-15857: Add AWS Secret Manager support for ZK ACL credentials [solr]

2024-04-03 Thread via GitHub


laminelam commented on PR #1994:
URL: https://github.com/apache/solr/pull/1994#issuecomment-2035996505

   > Are we sure this fits as a Solr module? Since this is client-side solrj 
code, it could be in e.g. `solrj-aws-secret` instead?
   
   Actually, this is a server side code.
   When Solr starts, it reads ZK creds from a local (clear) text file and uses 
them to connect to ZK. 
   With this contribution, Solr would get the ZK creds from an AWS Secret 
Manager, and then proceed to connect to ZK.
   
   Now, from SolrJ side we have 3 options:
   - Use the existing mechanism. Get the ZK creds and set them in System Props 
using the standard way
   - The client can connect to AWS SM to get the creds before passing them to 
System Props.
   - This module can be used to connect directly to AWS SM and inject the creds 
into SolrJ. Though, the libs have to
   be added to class path.
   ```
   System.setProperty("zkACLProvider", 
"org.apache.solr.common.cloud.DigestZkACLProvider");
   System.setProperty("zkCredentialsProvider", 
"org.apache.solr.common.cloud.DigestZkCredentialsProvider");
   System.setProperty("zkCredentialsInjector", 
"org.apache.solr.secret.zk.AWSSecretManagerCredentialsInjector");
   System.setProperty("zkCredentialsAWSSecretName", "myZkSecret");
   System.setProperty("zkCredentialsAWSRegion", "us-east-1");
   
   CloudSolrClient client = new CloudHttp2SolrClient.Builder(zkHosts)...
   ```
   
   Somewhere down the line SolrZkClient [will 
instantiate](https://github.com/apache/solr/blob/main/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/SolrZkClient.java#L307)
 an _AWSSecretManagerCredentialsInjector_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [I] Shards in a down state after an HPA scale up / scale down event. [solr-operator]

2024-04-03 Thread via GitHub


HoustonPutman closed issue #682: Shards in a down state after an HPA scale up / 
scale down event.
URL: https://github.com/apache/solr-operator/issues/682


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] Fix scaling when using ingress-addressed nodes [solr-operator]

2024-04-03 Thread via GitHub


HoustonPutman merged PR #692:
URL: https://github.com/apache/solr-operator/pull/692


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] Use hostContext property for RewriteHandler rules [solr]

2024-04-03 Thread via GitHub


epugh commented on PR #2388:
URL: https://github.com/apache/solr/pull/2388#issuecomment-2035531253

   IIRC it was actually not well supported in recent versions of Solr, it may 
even not have worked at all in the 8x line...   With the V2 api's starting to 
live under `/api`, we want to make `/solr` and `/api` fixed paths.   I don't 
recall why, but this did faciliate the v2 api stuff...   Maybe @gerlowskija  
can shed osme light.
   
   @wwelling I'd love to hear the use cases that you would *want* this for..  
make sure we haven't shut the door on some reasons..


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-15857: Add AWS Secret Manager support for ZK ACL credentials [solr]

2024-04-03 Thread via GitHub


janhoy commented on PR #1994:
URL: https://github.com/apache/solr/pull/1994#issuecomment-2035476333

   Are we sure this fits as a Solr module? Since this is client-side sloth 
code, it should be in `solrj-aws-secret` instead?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-13350: Multithreaded search [solr]

2024-04-03 Thread via GitHub


dsmiley commented on code in PR #2248:
URL: https://github.com/apache/solr/pull/2248#discussion_r1550359158


##
solr/core/src/java/org/apache/solr/core/CoreContainer.java:
##
@@ -445,6 +447,17 @@ public CoreContainer(NodeConfig config, CoresLocator 
locator, boolean asyncSolrC
 cfg.getIndexSearcherExecutorThreads(), // thread count
 cfg.getIndexSearcherExecutorThreads(), // queue size
 new SolrNamedThreadFactory("searcherCollector"));
+((ExecutorUtil.MDCAwareThreadPoolExecutor) 
collectorExecutor).setRejectedExecutionHandler(new RejectedExecutionHandler() {

Review Comment:
   I think that's an anti-pattern or broken and isn't what I meant in JIRA.  We 
could use a SynchronousQueue (with fairness) if we want to block for a thread 
-- probably what we should do.  FYI that queue is the default for 
`Executors.newCachedThreadPool()`.The "caller runs" behavior I meant could 
be done via an ExecutorService delegate that catches RejectedException and 
simply runs the Runnable.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Commented] (SOLR-17158) Terminate distributed processing quickly when query limit is reached

2024-04-03 Thread David Smiley (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833722#comment-17833722
 ] 

David Smiley commented on SOLR-17158:
-

Fail vs Success should be based on {{shards.tolerant}} -- 
https://solr.apache.org/guide/solr/latest/deployment-guide/solrcloud-distributed-requests.html#shards-tolerant-parameter

> Terminate distributed processing quickly when query limit is reached
> 
>
> Key: SOLR-17158
> URL: https://issues.apache.org/jira/browse/SOLR-17158
> Project: Solr
>  Issue Type: Sub-task
>  Components: Query Limits
>Reporter: Andrzej Bialecki
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Solr should make sure that when query limits are reached and partial results 
> are not needed (and not wanted) then both the processing in shards and in the 
> query coordinator should be terminated as quickly as possible, and Solr 
> should minimize wasted resources spent on eg. returning data from the 
> remaining shards, merging responses in the coordinator, or returning any data 
> back to the user.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Commented] (SOLR-17205) De-couple SolrJ required Java version from server Java version (main)

2024-04-03 Thread David Smiley (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833703#comment-17833703
 ] 

David Smiley commented on SOLR-17205:
-

While I'm supportive of this change, a user can continue to use a SolrJ for the 
previous release.  We might even invest in some changes there for such users.

> De-couple SolrJ required Java version from server Java version (main)
> -
>
> Key: SOLR-17205
> URL: https://issues.apache.org/jira/browse/SOLR-17205
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: main (10.0)
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Solr 9.x requires Java 11, both for server and solrj client.
> In Solr 10 we will likely bump required java version to Java 17, or maybe 
> even 21, and since we are a standalone app we can do that - on the 
> server-side.
> However, to give SolrJ client a broadest possible compatibility with customer 
> application environments, we should consider de-coupling SolrJ's java 
> requirement from the server-side. That would allow us to be progressive on 
> the server side Java without forcing users to stay on latest Java in their 
> apps.
> I don't know if it makes much sense to be compatible too far back on EOL java 
> versions, but perhaps let SolrJ stay one LTS version behind the server for 
> broad compatibility.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Resolved] (SOLR-17211) HttpJdkSolrClient: Support Async

2024-04-03 Thread James Dyer (Jira)


 [ 
https://issues.apache.org/jira/browse/SOLR-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer resolved SOLR-17211.
---
Resolution: Fixed

> HttpJdkSolrClient:  Support Async
> -
>
> Key: SOLR-17211
> URL: https://issues.apache.org/jira/browse/SOLR-17211
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses 
> *java.net.http.HttpClient* internally.  This JDK client supports asynchronous 
> requests, so the Jdk Solr Client likewise can have async support.  This 
> ticket is to:
> 1. Extract from *Http2SolrClient* method
> {code:java}
>  public Cancellable asyncRequest(
>   SolrRequest solrRequest,
>   String collection,
>   AsyncListener> asyncListener)
> {code}
> 2. Implement on *HttpJdkSolrClient*
> 3. Add javadoc for both clients.
> 4. Add unit tests for both clients.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Commented] (SOLR-17211) HttpJdkSolrClient: Support Async

2024-04-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833686#comment-17833686
 ] 

ASF subversion and git services commented on SOLR-17211:


Commit defe5227b7c18747df2ce4145fd1562d38cf9545 in solr's branch 
refs/heads/branch_9x from James Dyer
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=defe5227b7c ]

SOLR-17211:  HttpJdkSolrClient Support Async requests (#2374)



> HttpJdkSolrClient:  Support Async
> -
>
> Key: SOLR-17211
> URL: https://issues.apache.org/jira/browse/SOLR-17211
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses 
> *java.net.http.HttpClient* internally.  This JDK client supports asynchronous 
> requests, so the Jdk Solr Client likewise can have async support.  This 
> ticket is to:
> 1. Extract from *Http2SolrClient* method
> {code:java}
>  public Cancellable asyncRequest(
>   SolrRequest solrRequest,
>   String collection,
>   AsyncListener> asyncListener)
> {code}
> 2. Implement on *HttpJdkSolrClient*
> 3. Add javadoc for both clients.
> 4. Add unit tests for both clients.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] Use hostContext property for RewriteHandler rules [solr]

2024-04-03 Thread via GitHub


wwelling commented on PR #2388:
URL: https://github.com/apache/solr/pull/2388#issuecomment-2035026777

   @HoustonPutman thanks for the quick reply. I have been reading about that in 
the Jira and previous issues/PRs.
   
   I noticed `hostContext` is still used in 
[solr-jetty-context.xml](https://github.com/apache/solr/blob/main/solr/server/contexts/solr-jetty-context.xml#L4).
   
   To you by chance now why Solr is removing ability to configure its context 
path?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


uschindler commented on PR #2387:
URL: https://github.com/apache/solr/pull/2387#issuecomment-2034997136

   > Will take another look at the javadoc links. What gradle command do I run 
to build javadocs that should have substituted local javadocs? Do I have to 
unzip some jdk javadoc file into my git checkout and then run gradlew javadocs?
   
   See those commits: 
https://github.com/apache/lucene/commit/dfce6ee8d29da75b67fa0679e192c4defa9f9f78
 and 
https://github.com/apache/lucene/commit/5aaaeaee391934363b207718c6eea7853db3ca81
   
   The coresponding file can be found in the ZIP download of JDK (it may be 
named 'package-list' or 'element-list'. You can also get it from the official 
Javadocs page by appending that filename instaed of index.html. Maybe we should 
generate an automated task to regenerate ist.
   
   To generate the javadocs on Lucene, run `gradlew documentation`, this will 
build both local Javadocs as well as full site. If you want to quickly test a 
single project use: `gradlew :solr:xyz:javadoc`


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17205 De-couple SolrJ Java version from server Java version [solr]

2024-04-03 Thread via GitHub


HoustonPutman commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2034982016

   Currently yes, but there's a PR for one that might be SolrJ compatible: 
https://github.com/apache/solr/pull/1994. Just thinking about an eventual 
possibility.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] fix: gen-pkcs12-keystore adds ca.crt input option if it exists (#684) [solr-operator]

2024-04-03 Thread via GitHub


HoustonPutman commented on code in PR #685:
URL: https://github.com/apache/solr-operator/pull/685#discussion_r1550003188


##
controllers/util/solr_tls_util.go:
##
@@ -707,8 +707,11 @@ func (tls *TLSConfig) 
generatePkcs12InitContainer(imageName string, imagePullPol
},
}
 
-   cmd := "openssl pkcs12 -export -in " + DefaultKeyStorePath + "/" + 
TLSCertKey + " -in " + DefaultKeyStorePath +
-   "/ca.crt -inkey " + DefaultKeyStorePath + "/tls.key -out " + 
DefaultKeyStorePath +
+   caCrtFileName := DefaultKeyStorePath + "/ca.crt"
+
+   cmd := "OPTIONAL_CACRT=$(test -e " + caCrtFileName + " && echo ' -in " 
+ caCrtFileName + "'); " +

Review Comment:
   One suggestion here is to put the `$(...)` inside of quotations, to make 
sure that the spaces are taken care of well. 
   ```suggestion
cmd := "OPTIONAL_CACRT=\"$(test -e " + caCrtFileName + " && echo ' -in 
" + caCrtFileName + "')\"; " +
   ```
   
   We would need to test it out to make sure that they are happy though
   



##
controllers/solrcloud_controller_tls_test.go:
##
@@ -522,7 +522,7 @@ func expectTLSConfigOnPodTemplateWithGomega(g Gomega, 
solrCloud *solrv1beta1.Sol
break
}
}
-   expCmd := "openssl pkcs12 -export -in /var/solr/tls/tls.crt -in 
/var/solr/tls/ca.crt -inkey /var/solr/tls/tls.key -out 
/var/solr/tls/pkcs12/keystore.p12 -passout pass:${SOLR_SSL_KEY_STORE_PASSWORD}"
+   expCmd := "OPTIONAL_CACRT=$(test -e /var/solr/tls/ca.crt && 
echo ' -in /var/solr/tls/ca.crt'); openssl pkcs12 -export -in 
/var/solr/tls/tls.crt $OPTIONAL_CACRT -inkey /var/solr/tls/tls.key -out 
/var/solr/tls/pkcs12/keystore.p12 -passout pass:${SOLR_SSL_KEY_STORE_PASSWORD}"

Review Comment:
   ```suggestion
expCmd := "OPTIONAL_CACRT=\"$(test -e /var/solr/tls/ca.crt && 
echo ' -in /var/solr/tls/ca.crt')\"; openssl pkcs12 -export -in 
/var/solr/tls/tls.crt $OPTIONAL_CACRT -inkey /var/solr/tls/tls.key -out 
/var/solr/tls/pkcs12/keystore.p12 -passout pass:${SOLR_SSL_KEY_STORE_PASSWORD}"
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Commented] (SOLR-17211) HttpJdkSolrClient: Support Async

2024-04-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833652#comment-17833652
 ] 

ASF subversion and git services commented on SOLR-17211:


Commit cc0822831ef5966b6da31701f63061093feafc44 in solr's branch 
refs/heads/main from James Dyer
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=cc0822831ef ]

SOLR-17211:  HttpJdkSolrClient Support Async requests (#2374)



> HttpJdkSolrClient:  Support Async
> -
>
> Key: SOLR-17211
> URL: https://issues.apache.org/jira/browse/SOLR-17211
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses 
> *java.net.http.HttpClient* internally.  This JDK client supports asynchronous 
> requests, so the Jdk Solr Client likewise can have async support.  This 
> ticket is to:
> 1. Extract from *Http2SolrClient* method
> {code:java}
>  public Cancellable asyncRequest(
>   SolrRequest solrRequest,
>   String collection,
>   AsyncListener> asyncListener)
> {code}
> 2. Implement on *HttpJdkSolrClient*
> 3. Add javadoc for both clients.
> 4. Add unit tests for both clients.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17211: HttpJdkSolrClient Support Async requests [solr]

2024-04-03 Thread via GitHub


jdyer1 merged PR #2374:
URL: https://github.com/apache/solr/pull/2374


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17205 De-couple SolrJ Java version from server Java version [solr]

2024-04-03 Thread via GitHub


janhoy commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2034965063

   I might be mis interpreting your statement. But as far as I know, all 
`modules` are server-side only. The two you mentioned both depend on 
`solr-core`. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] Use hostContext property for RewriteHandler rules [solr]

2024-04-03 Thread via GitHub


HoustonPutman commented on PR #2388:
URL: https://github.com/apache/solr/pull/2388#issuecomment-2034928189

   I believe we recently removed the ability to specify a new hostContext in 
`main`. @epugh @gerlowskija 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[PR] Use hostContext property for RewriteHandler rules [solr]

2024-04-03 Thread via GitHub


wwelling opened a new pull request, #2388:
URL: https://github.com/apache/solr/pull/2388

   https://issues.apache.org/jira/browse/SOLR-X
   
   
   
   
   # Description
   
   Please provide a short description of the changes you're making with this 
pull request.
   
   # Solution
   
   Please provide a short description of the approach taken to implement your 
solution.
   
   # Tests
   
   Please describe the tests you've developed or run to confirm this patch 
implements the feature or solves the problem.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my 
code conforms to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `main` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Assigned] (SOLR-17211) HttpJdkSolrClient: Support Async

2024-04-03 Thread James Dyer (Jira)


 [ 
https://issues.apache.org/jira/browse/SOLR-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Dyer reassigned SOLR-17211:
-

Assignee: James Dyer

> HttpJdkSolrClient:  Support Async
> -
>
> Key: SOLR-17211
> URL: https://issues.apache.org/jira/browse/SOLR-17211
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses 
> *java.net.http.HttpClient* internally.  This JDK client supports asynchronous 
> requests, so the Jdk Solr Client likewise can have async support.  This 
> ticket is to:
> 1. Extract from *Http2SolrClient* method
> {code:java}
>  public Cancellable asyncRequest(
>   SolrRequest solrRequest,
>   String collection,
>   AsyncListener> asyncListener)
> {code}
> 2. Implement on *HttpJdkSolrClient*
> 3. Add javadoc for both clients.
> 4. Add unit tests for both clients.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17205 De-couple SolrJ Java version from server Java version [solr]

2024-04-03 Thread via GitHub


HoustonPutman commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2034768833

   > @HoustonPutman Which other modules are you thinking about, except the 
`solrj-*` ones?
   
   @janhoy Sorry I missed this, I'm thinking about the ones that would be used 
by SolrJ, like `hadoop-auth`, or `jwt-auth`. Or more security ones coming in 
the future.
   
   Definitely not a blocker for this, but something to think about in the 
future, when we get these auth schemes working better with things like the CLI 
and SolrJ


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Commented] (SOLR-17153) CloudSolrClient should not throw "Collection not found" with an out-dated ClusterState

2024-04-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833595#comment-17833595
 ] 

ASF subversion and git services commented on SOLR-17153:


Commit 8cf552aa3642be473c6a08ce44feceb9cbe396d7 in solr's branch 
refs/heads/branch_9x from aparnasuresh85
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=8cf552aa364 ]

SOLR-17153: CloudSolrClient should not throw "Collection not found" with an 
out-dated ClusterState (#2363)

ZkClientClusterStateProvider needed to double-check a collection truly doesn't 
exist.  HttpClusterStateProvider is already correct.
HttpSolrCall on the server side was hardened similarly.
This could happen for a highly burdened cluster / zookeeper.

(cherry picked from commit 5c399dd526e62644e257b42b7667c25cf500356f)


> CloudSolrClient should not throw "Collection not found" with an out-dated 
> ClusterState
> --
>
> Key: SOLR-17153
> URL: https://issues.apache.org/jira/browse/SOLR-17153
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: David Smiley
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Today, CloudSolrClient will locally fail if it's asked to send a request to a 
> collection that it thinks does not exist due to its local ClusterState view 
> being out-of-date.  We shouldn't fail!  And most SolrCloud tests should then 
> remove their waitForState calls that follow collection creation!  Other stale 
> state matters are out-of-scope.
> Proposal: CloudSolrClient shouldn't try and be too smart.  Always route a 
> request to Solr (any node); don't presume its state is up-to-date.  Maybe, 
> after a response is received, it can check if its state has been updated and 
> if not then explicitly get a new state.  Or not if that's too complicated.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [I] Run solr-operator and solr helm chart on openshift get error "would violate PodSecurity "restricted:v1.24"" [solr-operator]

2024-04-03 Thread via GitHub


janhoy commented on issue #671:
URL: https://github.com/apache/solr-operator/issues/671#issuecomment-2034596523

   My client uses 
[Kyverno](https://kyverno.io/policies/?policytypes=Pod%2520Security%2520Standards%2520%28Baseline%29)
 to warn or enforce various best practices. They recently added rules to warn 
about deployments that will not run in K8S PSA "restricted" mode: 
https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted.
 I managed to apply these for solr containers and custom init containers, but 
not for the operator-managed init containers.
   
   Since Solr runs well with these restrictions, I support making them standard.
   
   On the POD level:
   ```yaml
   podSecurityContext:
 seccompProfile:
   type: RuntimeDefault
   ```
   
   On the container level:
   ```yaml
   securityContext: 
 allowPrivilegeEscalation: false  
 capabilities:
   drop:
   - ALL
   ```
   
   While OpenShift will require even more changes, the PSA "restricted" mode is 
a generic k8s thing that I support aiming for as default.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


janhoy commented on PR #2387:
URL: https://github.com/apache/solr/pull/2387#issuecomment-2034339316

   Will take another look at the javadoc links. What gradle command do I run to 
build javadocs that should have substituted local javadocs? Do I have to unzip 
some jdk javadoc file into my git checkout and then run gradlew javadocs?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Comment Edited] (SOLR-17224) Getting NPE in apache SOLR 8.11.2 while doing atomic update using add-distinct from java based application

2024-04-03 Thread Puneet Sharma (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833472#comment-17833472
 ] 

Puneet Sharma edited comment on SOLR-17224 at 4/3/24 9:43 AM:
--

[~cpoerschke]

looks like the same kind of issue, but here if we check the SOLR class and the 
stack trace, it is throwing NPE at this line 466, 

Below screenshot taken from this URL : 
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/processor/AtomicUpdateDocumentMerger.java]
 
!image-2024-04-03-15-11-43-947.png!


was (Author: JIRAUSER304723):
looks like the same kind of issue, but here if we check the SOLR class and the 
stack trace, it is throwing NPE at this line 466, 

Below screenshot taken from this URL : 
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/processor/AtomicUpdateDocumentMerger.java]
 
!image-2024-04-03-15-11-43-947.png!

> Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
> add-distinct from java based application
> --
>
> Key: SOLR-17224
> URL: https://issues.apache.org/jira/browse/SOLR-17224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 8.11.2
> Environment: Live in production
>Reporter: Puneet Sharma
>Priority: Major
> Attachments: image-2024-04-03-15-11-43-947.png
>
>
> This issue is happening in my production environment when my java application 
> was trying to update it with document {{{}[SolrInputDocument(fields: 
> [id=10001, promotionType=\{add-distinct=WHOLESALE}, 
> lastUpdatedTime=\{set=1711433462524}])]{}}}, where i am using solr 8.11.2 in 
> production environment, i am not able to reproduce this in my local, in my 
> local its working as expected Can someone help here what can be the possible 
> reason for this NPE?
> Definition of this field "promotionType" in my managed-schema \{ 
> "name":"promotionType", "type":"string", "docValues":true, 
> "multiValued":true, "indexed":false, "stored":true }
> Also, the document was present with id : 10001
> i tried replicating in my local with same SOLR version 8.11.2, but was 
> getting updating properly, in few instances it was failing in production
> Environment difference between local and production,
> {{}}
> in production, we have millions of data and its multi sharded whereas, my 
> local has limited data and single sharded application
>  
> Error Log :
> {{org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error 
> from server at \{hostname}/solr/collection_shard6_replica_t2737: 
> java.lang.NullPointerException at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.doAddDistinct(AtomicUpdateDocumentMerger.java:466)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeDocHavingSameId(AtomicUpdateDocumentMerger.java:174)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDocRecursive(AtomicUpdateDocumentMerger.java:115)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.merge(AtomicUpdateDocumentMerger.java:106)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:730)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:380)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:343)
>  at org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50) 
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:343)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:229)
>  at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.processAdd(DistributedZkUpdateProcessor.java:245)
>  at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) 
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:344)
>  at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:292)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:338) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:245)
>  at 
> org.apache.solr.commo

[jira] [Commented] (SOLR-17224) Getting NPE in apache SOLR 8.11.2 while doing atomic update using add-distinct from java based application

2024-04-03 Thread Puneet Sharma (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833472#comment-17833472
 ] 

Puneet Sharma commented on SOLR-17224:
--

looks like the same kind of issue, but here if we check the SOLR class and the 
stack trace, it is throwing NPE at this line 466, 

Below screenshot taken from this URL : 
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/processor/AtomicUpdateDocumentMerger.java]
 
!image-2024-04-03-15-11-43-947.png!

> Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
> add-distinct from java based application
> --
>
> Key: SOLR-17224
> URL: https://issues.apache.org/jira/browse/SOLR-17224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 8.11.2
> Environment: Live in production
>Reporter: Puneet Sharma
>Priority: Major
> Attachments: image-2024-04-03-15-11-43-947.png
>
>
> This issue is happening in my production environment when my java application 
> was trying to update it with document {{{}[SolrInputDocument(fields: 
> [id=10001, promotionType=\{add-distinct=WHOLESALE}, 
> lastUpdatedTime=\{set=1711433462524}])]{}}}, where i am using solr 8.11.2 in 
> production environment, i am not able to reproduce this in my local, in my 
> local its working as expected Can someone help here what can be the possible 
> reason for this NPE?
> Definition of this field "promotionType" in my managed-schema \{ 
> "name":"promotionType", "type":"string", "docValues":true, 
> "multiValued":true, "indexed":false, "stored":true }
> Also, the document was present with id : 10001
> i tried replicating in my local with same SOLR version 8.11.2, but was 
> getting updating properly, in few instances it was failing in production
> Environment difference between local and production,
> {{}}
> in production, we have millions of data and its multi sharded whereas, my 
> local has limited data and single sharded application
>  
> Error Log :
> {{org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error 
> from server at \{hostname}/solr/collection_shard6_replica_t2737: 
> java.lang.NullPointerException at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.doAddDistinct(AtomicUpdateDocumentMerger.java:466)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeDocHavingSameId(AtomicUpdateDocumentMerger.java:174)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDocRecursive(AtomicUpdateDocumentMerger.java:115)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.merge(AtomicUpdateDocumentMerger.java:106)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:730)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:380)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:343)
>  at org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50) 
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:343)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:229)
>  at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.processAdd(DistributedZkUpdateProcessor.java:245)
>  at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) 
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:344)
>  at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:292)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:338) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:245)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:303) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:196) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:131)
>  at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:122)
>  at org.apache.solr.handler.loader.Ja

[jira] [Updated] (SOLR-17224) Getting NPE in apache SOLR 8.11.2 while doing atomic update using add-distinct from java based application

2024-04-03 Thread Puneet Sharma (Jira)


 [ 
https://issues.apache.org/jira/browse/SOLR-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Puneet Sharma updated SOLR-17224:
-
Attachment: image-2024-04-03-15-11-43-947.png

> Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
> add-distinct from java based application
> --
>
> Key: SOLR-17224
> URL: https://issues.apache.org/jira/browse/SOLR-17224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 8.11.2
> Environment: Live in production
>Reporter: Puneet Sharma
>Priority: Major
> Attachments: image-2024-04-03-15-11-43-947.png
>
>
> This issue is happening in my production environment when my java application 
> was trying to update it with document {{{}[SolrInputDocument(fields: 
> [id=10001, promotionType=\{add-distinct=WHOLESALE}, 
> lastUpdatedTime=\{set=1711433462524}])]{}}}, where i am using solr 8.11.2 in 
> production environment, i am not able to reproduce this in my local, in my 
> local its working as expected Can someone help here what can be the possible 
> reason for this NPE?
> Definition of this field "promotionType" in my managed-schema \{ 
> "name":"promotionType", "type":"string", "docValues":true, 
> "multiValued":true, "indexed":false, "stored":true }
> Also, the document was present with id : 10001
> i tried replicating in my local with same SOLR version 8.11.2, but was 
> getting updating properly, in few instances it was failing in production
> Environment difference between local and production,
> {{}}
> in production, we have millions of data and its multi sharded whereas, my 
> local has limited data and single sharded application
>  
> Error Log :
> {{org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error 
> from server at \{hostname}/solr/collection_shard6_replica_t2737: 
> java.lang.NullPointerException at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.doAddDistinct(AtomicUpdateDocumentMerger.java:466)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeDocHavingSameId(AtomicUpdateDocumentMerger.java:174)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDocRecursive(AtomicUpdateDocumentMerger.java:115)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.merge(AtomicUpdateDocumentMerger.java:106)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:730)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:380)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:343)
>  at org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50) 
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:343)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:229)
>  at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.processAdd(DistributedZkUpdateProcessor.java:245)
>  at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) 
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:344)
>  at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:292)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:338) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:245)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:303) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:196) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:131)
>  at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:122)
>  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70) 
> at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:82)
>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>  at org.apache.solr.core.SolrCore.exe

Re: [PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


janhoy commented on code in PR #2387:
URL: https://github.com/apache/solr/pull/2387#discussion_r1549333462


##
gradle/documentation/render-javadoc.gradle:
##
@@ -370,7 +370,7 @@ class RenderJavadocTask extends DefaultTask {
   opts << [ '-linkoffline', url, dir ]
 }
 
-opts << [ '--release', 11 ]
+opts << [ '--release', project.minJavaVersion.toString() ]

Review Comment:
   That's correct, each project wil have this variable set, so javadoc for 
SolrJ will use 11 while core may use 17 eventually.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


uschindler commented on PR #2387:
URL: https://github.com/apache/solr/pull/2387#issuecomment-2033910058

   P.S.: I missed this in Lucene, there is also a reference to the JDK Javadocs 
and its package file above. We may also make this dynamic.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


cpoerschke commented on code in PR #2387:
URL: https://github.com/apache/solr/pull/2387#discussion_r1549234517


##
gradle/documentation/render-javadoc.gradle:
##
@@ -370,7 +370,7 @@ class RenderJavadocTask extends DefaultTask {
   opts << [ '-linkoffline', url, dir ]
 }
 
-opts << [ '--release', 11 ]
+opts << [ '--release', project.minJavaVersion.toString() ]

Review Comment:
   
https://github.com/apache/solr/blob/2eb9b21d434da748d26ec82cc2b76aa1fd41237b/gradle/globals.gradle#L175
 approximately looks to be where `project.minJavaVersion` comes from.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



Re: [PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


uschindler commented on PR #2387:
URL: https://github.com/apache/solr/pull/2387#issuecomment-2033894291

   The approach you used did not work in Lucene because inputs/outputs and 
"rootProject" was not known in the task instance. Here it is different, if it 
works, +1


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Assigned] (SOLR-17223) Port renderJavadoc task fix from Lucene

2024-04-03 Thread Jira


 [ 
https://issues.apache.org/jira/browse/SOLR-17223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl reassigned SOLR-17223:
--

Assignee: Jan Høydahl

> Port renderJavadoc task fix from Lucene
> ---
>
> Key: SOLR-17223
> URL: https://issues.apache.org/jira/browse/SOLR-17223
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Port [https://github.com/apache/lucene/pull/13132] to solr
> Spinoff from SOLR-17205



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[PR] SOLR-17223 Remove hardcoded java version in renderJavadoc task [solr]

2024-04-03 Thread via GitHub


janhoy opened a new pull request, #2387:
URL: https://github.com/apache/solr/pull/2387

   Oneliner :) 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org



[jira] [Commented] (SOLR-17224) Getting NPE in apache SOLR 8.11.2 while doing atomic update using add-distinct from java based application

2024-04-03 Thread Christine Poerschke (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833423#comment-17833423
 ] 

Christine Poerschke commented on SOLR-17224:


cross-referencing tickets: this sounds a bit similar to (but also different 
from) [~casmith]'s SOLR-17120

> Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
> add-distinct from java based application
> --
>
> Key: SOLR-17224
> URL: https://issues.apache.org/jira/browse/SOLR-17224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.11.2
> Environment: Live in production
>Reporter: Puneet Sharma
>Priority: Major
>
> This issue is happening in my production environment when my java application 
> was trying to update it with document {{{}[SolrInputDocument(fields: 
> [id=10001, promotionType=\{add-distinct=WHOLESALE}, 
> lastUpdatedTime=\{set=1711433462524}])]{}}}, where i am using solr 8.11.2 in 
> production environment, i am not able to reproduce this in my local, in my 
> local its working as expected Can someone help here what can be the possible 
> reason for this NPE?
> Definition of this field "promotionType" in my managed-schema \{ 
> "name":"promotionType", "type":"string", "docValues":true, 
> "multiValued":true, "indexed":false, "stored":true }
> Also, the document was present with id : 10001
> i tried replicating in my local with same SOLR version 8.11.2, but was 
> getting updating properly, in few instances it was failing in production
> Environment difference between local and production,
> {{}}
> in production, we have millions of data and its multi sharded whereas, my 
> local has limited data and single sharded application
>  
> Error Log :
> {{org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error 
> from server at \{hostname}/solr/collection_shard6_replica_t2737: 
> java.lang.NullPointerException at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.doAddDistinct(AtomicUpdateDocumentMerger.java:466)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeDocHavingSameId(AtomicUpdateDocumentMerger.java:174)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDocRecursive(AtomicUpdateDocumentMerger.java:115)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.merge(AtomicUpdateDocumentMerger.java:106)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:730)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:380)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:343)
>  at org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50) 
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:343)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:229)
>  at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.processAdd(DistributedZkUpdateProcessor.java:245)
>  at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) 
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:344)
>  at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:292)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:338) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:245)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:303) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:196) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:131)
>  at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:122)
>  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70) 
> at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:82)
>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>

[jira] [Updated] (SOLR-17224) Getting NPE in apache SOLR 8.11.2 while doing atomic update using add-distinct from java based application

2024-04-03 Thread Christine Poerschke (Jira)


 [ 
https://issues.apache.org/jira/browse/SOLR-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-17224:
---
Component/s: update

> Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
> add-distinct from java based application
> --
>
> Key: SOLR-17224
> URL: https://issues.apache.org/jira/browse/SOLR-17224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 8.11.2
> Environment: Live in production
>Reporter: Puneet Sharma
>Priority: Major
>
> This issue is happening in my production environment when my java application 
> was trying to update it with document {{{}[SolrInputDocument(fields: 
> [id=10001, promotionType=\{add-distinct=WHOLESALE}, 
> lastUpdatedTime=\{set=1711433462524}])]{}}}, where i am using solr 8.11.2 in 
> production environment, i am not able to reproduce this in my local, in my 
> local its working as expected Can someone help here what can be the possible 
> reason for this NPE?
> Definition of this field "promotionType" in my managed-schema \{ 
> "name":"promotionType", "type":"string", "docValues":true, 
> "multiValued":true, "indexed":false, "stored":true }
> Also, the document was present with id : 10001
> i tried replicating in my local with same SOLR version 8.11.2, but was 
> getting updating properly, in few instances it was failing in production
> Environment difference between local and production,
> {{}}
> in production, we have millions of data and its multi sharded whereas, my 
> local has limited data and single sharded application
>  
> Error Log :
> {{org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error 
> from server at \{hostname}/solr/collection_shard6_replica_t2737: 
> java.lang.NullPointerException at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.doAddDistinct(AtomicUpdateDocumentMerger.java:466)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeDocHavingSameId(AtomicUpdateDocumentMerger.java:174)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDocRecursive(AtomicUpdateDocumentMerger.java:115)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.merge(AtomicUpdateDocumentMerger.java:106)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:730)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:380)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:343)
>  at org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50) 
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:343)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:229)
>  at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.processAdd(DistributedZkUpdateProcessor.java:245)
>  at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) 
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:344)
>  at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:292)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:338) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:245)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:303) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:196) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:131)
>  at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:122)
>  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70) 
> at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:82)
>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2637) at 
> org.apache.solr.servlet.HttpSolrCall.execu

[jira] [Updated] (SOLR-17224) Getting NPE in apache SOLR 8.11.2 while doing atomic update using add-distinct from java based application

2024-04-03 Thread Puneet Sharma (Jira)


 [ 
https://issues.apache.org/jira/browse/SOLR-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Puneet Sharma updated SOLR-17224:
-
Summary: Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
add-distinct from java based application  (was: Getting NPE in apache SOLR 
8.11.2 while doing atomic update using add-distinct from my java based 
application)

> Getting NPE in apache SOLR 8.11.2 while doing atomic update using 
> add-distinct from java based application
> --
>
> Key: SOLR-17224
> URL: https://issues.apache.org/jira/browse/SOLR-17224
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.11.2
> Environment: Live in production
>Reporter: Puneet Sharma
>Priority: Major
>
> This issue is happening in my production environment when my java application 
> was trying to update it with document {{{}[SolrInputDocument(fields: 
> [id=10001, promotionType=\{add-distinct=WHOLESALE}, 
> lastUpdatedTime=\{set=1711433462524}])]{}}}, where i am using solr 8.11.2 in 
> production environment, i am not able to reproduce this in my local, in my 
> local its working as expected Can someone help here what can be the possible 
> reason for this NPE?
> Definition of this field "promotionType" in my managed-schema \{ 
> "name":"promotionType", "type":"string", "docValues":true, 
> "multiValued":true, "indexed":false, "stored":true }
> Also, the document was present with id : 10001
> i tried replicating in my local with same SOLR version 8.11.2, but was 
> getting updating properly, in few instances it was failing in production
> Environment difference between local and production,
> {{}}
> in production, we have millions of data and its multi sharded whereas, my 
> local has limited data and single sharded application
>  
> Error Log :
> {{org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error 
> from server at \{hostname}/solr/collection_shard6_replica_t2737: 
> java.lang.NullPointerException at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.doAddDistinct(AtomicUpdateDocumentMerger.java:466)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeDocHavingSameId(AtomicUpdateDocumentMerger.java:174)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDocRecursive(AtomicUpdateDocumentMerger.java:115)
>  at 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.merge(AtomicUpdateDocumentMerger.java:106)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:730)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:380)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:343)
>  at org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50) 
> at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:343)
>  at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:229)
>  at 
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.processAdd(DistributedZkUpdateProcessor.java:245)
>  at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) 
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:344)
>  at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:292)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:338) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:245)
>  at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:303) at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:283) at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:196) at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:131)
>  at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:122)
>  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70) 
> at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:82)
>  at 
> org.apache.solr.handler