Re: [PR] SOLR-17525: Text Embedder Query Parser [solr]
alessandrobenedetti commented on PR #2809: URL: https://github.com/apache/solr/pull/2809#issuecomment-2520803184 Thanks guys, I updated the PR with additional minor changes in response to @dsmiley and other people feedback. I completely agree on merging this and iterate. It's not meant to be final in any way, to me it's just a big enabler, an entry point. It will be my pleasure to iterate on it when I have time and I encourage anyone interested to iterate on it and improve it! I'll leave it here another 3-4 days and then I'll merge it! In the meantime if you notice any blocker let me know! I'll also do all checks and gradle stuff to make sure it's ok -- 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-17525: Text Embedder Query Parser [solr]
alessandrobenedetti commented on code in PR #2809:
URL: https://github.com/apache/solr/pull/2809#discussion_r1871650626
##
solr/modules/llm/src/java/org/apache/solr/llm/texttovector/model/SolrTextToVectorModel.java:
##
@@ -63,12 +64,21 @@ public static SolrEmbeddingModel getInstance(
var builder = modelClass.getMethod("builder").invoke(null);
if (params != null) {
/**
Review Comment:
my bad, it's apparent I don't do comments very much, fixed!
--
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-17525: Text Embedder Query Parser [solr]
epugh commented on PR #2809: URL: https://github.com/apache/solr/pull/2809#issuecomment-2520472327 > Eric, you demonstrate how to save some arbitrary file into the cluster to the so-called "file store". But didn't demonstrate how anything in Solr would use it. But that's in a separate world/namespace from a new LLM-specific model store Alessandro wishes to add that is also distinct from LTR's similar one (do you know of it?). I'm dubious that we need ones specific to LLM or LTR. If the file store came first (it came after LTR actually), I suspect LTR's wouldn't exist and then Alessandro wouldn't have imitated it here. Both those by default save stuff in ZK in SolrCloud mode but are configurable to use the file system which could probably point to the file store. Oh my. Options, options; too many probably. Once added; good luck removing unless we are very clear about "experimental". Maybe Eric you have more familiarity and can add to the discussion. Honestly, I may be derailing this specific PR... I would like us to move to a single more robust file store. However, honestly, that is probably a orthagonal concern to this PR... Let's get this in, and in the future, we can work on potentially consolidating down to one great solution. I don't think this PR, using the Managed Resources more, makes it harder to eventually figure out how to retire/consolidate down the number of options! -- 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] chore(deps): update org.apache.logging.log4j:* to v2.24.1 - autoclosed [solr]
risdenk commented on PR #2047: URL: https://github.com/apache/solr/pull/2047#issuecomment-2520466098 Ah thanks @janhoy not sure how I missed that comment. I'll take a closer look -- 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] [Updated] (SOLR-17585) CodeCache full during Gradle builds
[
https://issues.apache.org/jira/browse/SOLR-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christos Malliaridis updated SOLR-17585:
Description:
We are facing again issues similar to SOLR-16103 where we run out of CodeCache
space. However, this may be caused in a different context now.
One assumption is that updating the CodeCache in our gradle.properties
(template.gradle.properties) may fix the issue. Setting the jvm argument
{{-XX:ReservedCodeCacheSize=120m}} may fix the issue, but it would be best to
identify the cause, if possible.
One occurence of this issue is in
[https://github.com/apache/solr/actions/runs/12073580646/job/33669959917]
(probably not the best job/commit to use for reproducing the issue).
was:
We are facing again issues similar to SOLR-16103 where CodeCache becomes full.
However, this may be caused in a different context now.
One assumption is that updating the CodeCache in our gradle.properties
(template.gradle.properties) may fix the issue. Setting the jvm argument
{{-XX:ReservedCodeCacheSize=120m}} may fix the issue, but it would be best to
identify the cause, if possible.
One occurence of this issue is in
[https://github.com/apache/solr/actions/runs/12073580646/job/33669959917]
(probably not the best job/commit to use for reproducing the issue).
> CodeCache full during Gradle builds
> ---
>
> Key: SOLR-17585
> URL: https://issues.apache.org/jira/browse/SOLR-17585
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Gradle
>Reporter: Christos Malliaridis
>Priority: Major
>
> We are facing again issues similar to SOLR-16103 where we run out of
> CodeCache space. However, this may be caused in a different context now.
> One assumption is that updating the CodeCache in our gradle.properties
> (template.gradle.properties) may fix the issue. Setting the jvm argument
> {{-XX:ReservedCodeCacheSize=120m}} may fix the issue, but it would be best to
> identify the cause, if possible.
> One occurence of this issue is in
> [https://github.com/apache/solr/actions/runs/12073580646/job/33669959917]
> (probably not the best job/commit to use for reproducing the issue).
--
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-16781: Remove solrconfig.xml directives [solr]
dsmiley commented on PR #2875: URL: https://github.com/apache/solr/pull/2875#issuecomment-2519697587 > My vote would be to tear it out. +1 I'm glad to hear you suggest this. I thought I might have been alone in this thinking. I don't think we should "support" this idea; it's too burdensome for us to uphold this concept to a good standard. -- 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 12276 angularjs to angular migration [solr]
NikolaiJDev commented on PR #2818: URL: https://github.com/apache/solr/pull/2818#issuecomment-2520090026 > Yes, what I (and probably others as well) would like to see is how it would integrate into the current project (which is as described above an open TODO), how someone would work and test the code base (like running the UI with `npm ng serve`), and where the webapp can be accessed / seen (like at `localhost:3000`). I believe the module's / angular project's README file is the best place to tell other developers how to get started with this sub-project. Angular already provides some basic information, this could be extended.  It will be integrated same way as it was done before because it has to be shipped together with main application then using Gradle service is a great practice, you asked me to be waved out current application from new one, so I removed the concept of integration for time being. However, the refactoring of the Gradle job and few changes to the web.xml might be required to provide to fully support the current approach. As I've already mentioned to you previously - It might be also required to make some tweaks and changes in the Backend filter, what we can only understand on the stage of integration, I hope it won't be required, but It may. > > I meant starting and poking around, yes. So there is no state yet that makes request to a Solr backend, is that correct? > > I think you removed a few too manyfiles in your latest updates. The environment files under `/src/environments` are missing and causing an error when launching the app with `ng serve`. > > And one last tip, it's fine and also recommended to include `package-lock.json` in the VCS, as it ensures reproducable states of the project. :) Well, git shows me that envs are in place, I trigger the update as well for that. As well, I want to inform to run correctly app, you need to have either docker container with working solr application or it must run from the same hostname, just for clarification localhost that you are running from isn't same as for backend, CORS will appear to avoid it you need to make a proxy configuration such as Nginx server which will locate UI and middle tier application under same umbrella scope. It will help browser to avoid this issue. Because we will emulate same patter as if it will be run from same space or machine as backend application. -- 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] chore(deps): update org.apache.logging.log4j:* to v2.24.1 - autoclosed [solr]
janhoy commented on PR #2047: URL: https://github.com/apache/solr/pull/2047#issuecomment-2520020161 > @janhoy where did you see that log4j requires JDK 17? I don't see that based on https://logging.apache.org/log4j/2.x/release-notes.html > > I found [apache/logging-log4j2#1922](https://github.com/apache/logging-log4j2/issues/1922) that affects the 2.21 version we use in Solr and we use the `notEmpty` so it actually produces more verbose logging. > > I think we can upgrade log4j2 If you can make it work without compile failure then go for it. Last I tried I ran into issues https://github.com/apache/solr/pull/2047#issuecomment-1971765269 -- 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] [Created] (SOLR-17585) CodeCache full during Gradle builds
Christos Malliaridis created SOLR-17585:
---
Summary: CodeCache full during Gradle builds
Key: SOLR-17585
URL: https://issues.apache.org/jira/browse/SOLR-17585
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: Gradle
Reporter: Christos Malliaridis
We are facing again issues similar to SOLR-16103 where CodeCache becomes full.
However, this may be caused in a different context now.
One assumption is that updating the CodeCache in our gradle.properties
(template.gradle.properties) may fix the issue. Setting the jvm argument
{{-XX:ReservedCodeCacheSize=120m}} may fix the issue, but it would be best to
identify the cause, if possible.
One occurence of this issue is in
[https://github.com/apache/solr/actions/runs/12073580646/job/33669959917]
(probably not the best job/commit to use for reproducing the issue).
--
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] [Regression] security.json is not uploaded during the first initialization of SolrCloud [solr-operator]
mcarroll1 commented on issue #720: URL: https://github.com/apache/solr-operator/issues/720#issuecomment-2521532629 This is also blocking an upgrade for our team. Per @erwanval , it does seem like the zkcli returns error code `1` regardless of the issue. Would it be acceptable to rely on the string error messages (e.g. `NoNode for /security.json`)? I'm interested in working on this next week if that solution is acceptable, or if we can find a reasonable alternative. -- 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
