I can cannot execute my SolrJ application

2020-10-21 Thread Raivo Rebane 

Hello

I can compile my project properliy;

But problems arise when I execute it with Maven and got problems
I dont know have these solrj problems or maven problems:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/hydra/workspace1/test/EMBEDDED
Java version: 11.0.8, vendor: Ubuntu, runtime: 
/usr/lib/jvm/java-11-openjdk-amd64

Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-51-generic", arch: "amd64", family: "unix"

[DEBUG] Adding to classpath : 
file:/home/hydra/workspace1/test/target/classes/

[DEBUG] Adding project dependency artifact: solr-solrj to classpath
[DEBUG] Adding project dependency artifact: slf4j-api to classpath
[DEBUG] Adding project dependency artifact: commons-httpclient to classpath
[DEBUG] Adding project dependency artifact: commons-logging to classpath
[DEBUG] Adding project dependency artifact: commons-codec to classpath
[DEBUG] Adding project dependency artifact: commons-io to classpath
[DEBUG] Adding project dependency artifact: commons-fileupload to classpath
[DEBUG] Adding project dependency artifact: wstx-asl to classpath
[DEBUG] Adding project dependency artifact: stax-api to classpath
[DEBUG] Adding project dependency artifact: geronimo-stax-api_1.0_spec 
to classpath

[DEBUG] joining on thread Thread[SolrJExample.main(),5,SolrJExample]
[DEBUG] Setting accessibility to true in order to invoke main().
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time:  53.717 s
[INFO] Finished at: 2020-10-21T09:41:08+03:00
[INFO] 

[ERROR] Failed to execute goal 
org.codehaus.mojo:exec-maven-plugin:1.1:java (default-cli) on project 
test: An exception occured while executing the Java class. null: 
InvocationTargetException: Unresolved compilation problem: -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal org.codehaus.mojo:exec-maven-plugin:1.1:java (default-cli) 
on project test: An exception occured while executing the Java class. null
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
    at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
    at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)

    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
    at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoExecutionException: An exception 
occured while executing the Java class. null

    at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:345)
    at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
    at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)

    ... 20 more
Caused by: java.lang.reflect.InvocationTargetException
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
    at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:290)
    at java.base/java.lang.Thread.run(Thread.

SOLR 6 to SOLR7 Upgrade issue

2020-10-21 Thread Paul Russell 
I updated a three node SOLR cluster from SOLR 6 to SOLR 7.7.3. The cluster
is up and running fine however I cannot add any more collection or add a
replica to any of the current collections. Below is the error that I
receive.

2020-10-14 19:23:21.473 ERROR (qtp1708570683-22) [c:CollectionDev   ]
o.a.s.s.HttpSolrCall null:org.apache.solr.common.SolrException: Only one
extra tag supported for the tag cores in {

  "cores":"#EQUAL",

  "node":"#ANY",

  "strict":"false"}

at
org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)

at
org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:275)

at
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:247)

at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)

at
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:758)

at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:739)

at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:511)

at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:395)

at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:341)

at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)

at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)

at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)

at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)

at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)

at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)

at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)

at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)

at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)

at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)

at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)

at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)

at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)

at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)

at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)

at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)

at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)

at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)

at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)

at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)

at org.eclipse.jetty.server.Server.handle(Server.java:502)

at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)

at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)

at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)

at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)

at
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)

at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)

at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)

at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)

at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)

at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)

at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)

at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)

at java.lang.Thread.run(Thread.java:748)
 Edit

 Email

 Assign

 Resolve



-- 
*Paul Russell*
*VP Integration and Support Services*
*QFlow Systems, LLC*
*Cell: 314-258-0864*
*www.qflow.com *

Re: Backup fails despite allowPaths=* being set

2020-10-21 Thread Jan Høydahl 
Are you sure the * is not eaten by the shell since it’s a special char? You can 
view the sys props in admin UI to check. 

Jan Høydahl

> 16. okt. 2020 kl. 19:39 skrev Philipp Trulson :
> 
> Hello everyone,
> 
> we are having problems with our backup script since we upgraded to Solr
> 8.6.2 on kubernetes. To be more precise the message is
> *Path /data/backup/2020-10-16/collection must be relative to SOLR_HOME,
> SOLR_DATA_HOME coreRootDirectory. Set system property 'solr.allowPaths' to
> add other allowed paths.*
> 
> I executed the script by calling this endpoint
> *curl
> 'http://solr.default.svc.cluster.local/solr/admin/collections?action=BACKUP&name=collection&collection=
> *
> collection*&location=/data/backup/2020-10-16&async=1114'*
> 
> The strange thing is that all 5 nodes are started with *-Dsolr.allowPaths=**,
> so in theory it should work. The folder is an AWS EFS share, that's the
> only reason I can imagine. Or can I check any other options?
> 
> Thank you for your help!
> Philipp
> 
> -- 
> 
> 
> 
> 
> reBuy reCommerce GmbH* · *Potsdamer Str. 188* · 
> *10783 Berlin* · *Geschäftsführer: Dr. Philipp GattnerSitz und 
> Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 109344 B, 
> *USt-ID-Nr.:* DE237458635

json.facet floods the filterCache

2020-10-21 Thread damienk 
Hi,

I'm using a json.facet query on nested facets terms and am seeing very high
filterCache usage. Is it possible to somehow control this? With a fq it's
possible to specify fq={!cache=false}... but I don't see a similar thing
json.facet.

Kind regards,
Damien