Re: Unable to create core in Solr 8.6.0

2020-08-09 Thread Chris Larsson
Just to provide a little closure, it appears that this issue is fixed in
Java 14.0.2.

Chris

On Mon, Jul 27, 2020 at 5:38 PM Chris Larsson  wrote:

> Nice... That's the code I was just looking at.
>
>
> https://github.com/apache/lucene-solr/blob/branch_8_6/solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java
>
> From the stack trace:
> Caused by: java.time.format.DateTimeParseException: Text
> '2020-07-27T18:02:42.069Z' could not be parsed: null
> at
> java.base/java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:2021)
> at
> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1924)
> at
> org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.parseInstant(ParseDateFieldUpdateProcessorFactory.java:233)
> at
> org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.validateFormatter(ParseDateFieldUpdateProcessorFactory.java:217)
> ... 56 more
> Caused by: java.lang.NullPointerException
> at
> java.base/java.time.format.DateTimeFormatterBuilder$PrefixTree.prefixLength(DateTimeFormatterBuilder.java:4538)
> at
> java.base/java.time.format.DateTimeFormatterBuilder$PrefixTree.add0(DateTimeFormatterBuilder.java:4407)
>
>
> It seems to like the DateTimeFormatter.parse fails after being called by
> line 233 in ParseDateFieldUpdateProcessorFactory.java:233.  But if
> I understand, which may be a stretch, it seems like the formatter itself is
> created earlier in the code at line 189.  I guess I was concerned that the
> formatter creation was the problem since the fix seems to be to impose a
> locale using java.locale.providers=JRE,SPI.  If I understand this
> https://www.oracle.com/java/technologies/javase/jdk14-suported-locales.html#providers
>  using
> JRE  =  COMPAT  and COMPAT says "Represents the locale sensitive services
> that are compatible with the prior JDK releases up to JDK 8."  Is it
> possible that the formatter being created is not compatible with Java 14
> and that's why setting the locale back to 8 makes it work?
>
> Again I thank you for your responses.
>
> C
>
> On Mon, Jul 27, 2020 at 5:13 PM Erick Erickson 
> wrote:
>
>> I just remembered the issue and relayed the JIRA ;).
>>
>> As to why I suspect the Java issue, if this was a core Solr issue I’d
>> expect it to be a show stopper,
>> Solr isn’t much good if you can’t create cores. Of course weirder things
>> have happened. Plus,
>> the date is fine: "2020-07-27T18:02:42.069Z"
>>
>> If you have the bandwidth, I’d log all the inputs in
>> ParseDateFieldUpdateProcessor.validateFormatter,
>> which looks at a glance to be where the exception is caught. The code
>> looks like this:
>>
>> public static void validateFormatter(DateTimeFormatter formatter) {
>>   // check it's valid via round-trip
>>   try {
>> parseInstant(formatter, formatter.format(Instant.now()), new
>> ParsePosition(0));
>>   } catch (Exception e) {
>> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
>> "Bad or unsupported pattern: " + formatter.toFormat().toString(),
>> e);
>>   }
>> }
>>
>> I suspect the message is a bit misleading and the formatter in that call
>> is null or some such. Why I
>> haven’t a clue.
>>
>> Best,
>> Erick
>>
>>
>> > On Jul 27, 2020, at 3:54 PM, Chris Larsson 
>> wrote:
>> >
>> > Thank you Erick.  I appreciate you taking the time to respond.  I have
>> seen
>> > the post you shared and I know the work around does solve the issue.  I
>> am
>> > more concerned about why Solr doesn't work with the default settings.
>> I am
>> > also not convinced it is solely a Java issue, but I would like to
>> > investigate that further so I ask what makes you say it is a Java issue
>> as
>> > opposed to being a Solr issue?  I see David's comment, but he seems to
>> be
>> > approaching the solution as an end user as opposed to a Solr developer.
>> >
>> >
>> > On Mon, Jul 27, 2020 at 3:43 PM Erick Erickson > >
>> > wrote:
>> >
>> >> Take a look at:
>> >>
>> >> https://issues.apache.org/jira/browse/SOLR-13606
>> >>
>> >> It’s actually a weirdness with Java. In that JIRA David Smiley
>> >> suggest a way to deal with it, but I confess I haven’t a clue
>> >> about the nuances there.
>> >>
>> >> Best,
>> >> Erick
>> >>
>> >>
>> >>
>> >>> On Jul 27, 2020, at 3:12 PM, Chris Larsson 
>> wrote:
>> >>>
>> >>> Ran into an issue attempting to create a core on a new install of Solr
>> >>> 8.6.  The system is CentOS 8 fully updated and using Java OpenJDK
>> version
>> >>> 14.0.1.
>> >>>
>> >>> # java -version
>> >>> openjdk version "14.0.1" 2020-04-14
>> >>> OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
>> >>> OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)
>> >>>
>> >>> Attempting to create a core from the command line results in the
>> >> following
>> >>> messages:
>> >>>
>> >>> # cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
>> >>> WARNING: Using _default configset with data driven schema
>> functionality.
>> 

Re: Unable to create core in Solr 8.6.0

2020-07-27 Thread Chris Larsson
Nice... That's the code I was just looking at.

https://github.com/apache/lucene-solr/blob/branch_8_6/solr/core/src/java/org/apache/solr/update/processor/ParseDateFieldUpdateProcessorFactory.java

>From the stack trace:
Caused by: java.time.format.DateTimeParseException: Text
'2020-07-27T18:02:42.069Z' could not be parsed: null
at
java.base/java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:2021)
at
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1924)
at
org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.parseInstant(ParseDateFieldUpdateProcessorFactory.java:233)
at
org.apache.solr.update.processor.ParseDateFieldUpdateProcessorFactory.validateFormatter(ParseDateFieldUpdateProcessorFactory.java:217)
... 56 more
Caused by: java.lang.NullPointerException
at
java.base/java.time.format.DateTimeFormatterBuilder$PrefixTree.prefixLength(DateTimeFormatterBuilder.java:4538)
at
java.base/java.time.format.DateTimeFormatterBuilder$PrefixTree.add0(DateTimeFormatterBuilder.java:4407)


It seems to like the DateTimeFormatter.parse fails after being called by
line 233 in ParseDateFieldUpdateProcessorFactory.java:233.  But if
I understand, which may be a stretch, it seems like the formatter itself is
created earlier in the code at line 189.  I guess I was concerned that the
formatter creation was the problem since the fix seems to be to impose a
locale using java.locale.providers=JRE,SPI.  If I understand this
https://www.oracle.com/java/technologies/javase/jdk14-suported-locales.html#providers
using
JRE  =  COMPAT  and COMPAT says "Represents the locale sensitive services
that are compatible with the prior JDK releases up to JDK 8."  Is it
possible that the formatter being created is not compatible with Java 14
and that's why setting the locale back to 8 makes it work?

Again I thank you for your responses.

C

On Mon, Jul 27, 2020 at 5:13 PM Erick Erickson 
wrote:

> I just remembered the issue and relayed the JIRA ;).
>
> As to why I suspect the Java issue, if this was a core Solr issue I’d
> expect it to be a show stopper,
> Solr isn’t much good if you can’t create cores. Of course weirder things
> have happened. Plus,
> the date is fine: "2020-07-27T18:02:42.069Z"
>
> If you have the bandwidth, I’d log all the inputs in
> ParseDateFieldUpdateProcessor.validateFormatter,
> which looks at a glance to be where the exception is caught. The code
> looks like this:
>
> public static void validateFormatter(DateTimeFormatter formatter) {
>   // check it's valid via round-trip
>   try {
> parseInstant(formatter, formatter.format(Instant.now()), new
> ParsePosition(0));
>   } catch (Exception e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
> "Bad or unsupported pattern: " + formatter.toFormat().toString(),
> e);
>   }
> }
>
> I suspect the message is a bit misleading and the formatter in that call
> is null or some such. Why I
> haven’t a clue.
>
> Best,
> Erick
>
>
> > On Jul 27, 2020, at 3:54 PM, Chris Larsson  wrote:
> >
> > Thank you Erick.  I appreciate you taking the time to respond.  I have
> seen
> > the post you shared and I know the work around does solve the issue.  I
> am
> > more concerned about why Solr doesn't work with the default settings.  I
> am
> > also not convinced it is solely a Java issue, but I would like to
> > investigate that further so I ask what makes you say it is a Java issue
> as
> > opposed to being a Solr issue?  I see David's comment, but he seems to be
> > approaching the solution as an end user as opposed to a Solr developer.
> >
> >
> > On Mon, Jul 27, 2020 at 3:43 PM Erick Erickson 
> > wrote:
> >
> >> Take a look at:
> >>
> >> https://issues.apache.org/jira/browse/SOLR-13606
> >>
> >> It’s actually a weirdness with Java. In that JIRA David Smiley
> >> suggest a way to deal with it, but I confess I haven’t a clue
> >> about the nuances there.
> >>
> >> Best,
> >> Erick
> >>
> >>
> >>
> >>> On Jul 27, 2020, at 3:12 PM, Chris Larsson 
> wrote:
> >>>
> >>> Ran into an issue attempting to create a core on a new install of Solr
> >>> 8.6.  The system is CentOS 8 fully updated and using Java OpenJDK
> version
> >>> 14.0.1.
> >>>
> >>> # java -version
> >>> openjdk version "14.0.1" 2020-04-14
> >>> OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
> >>> OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)
> >>>
> >>> Attempting to create a core from the command line results in the
> >> following
> >>> messages:
> >>>
> >>> # cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
> >>> WARNING: Using _default configset with data driven schema
> functionality.
> >>> NOT RECOMMENDED for production use.
> >>>To turn off: bin/solr config -c foocore -p 8983 -action
> >>> set-user-property -property update.autoCreateFields -value false
> >>>
> >>> ERROR: Error CREATEing SolrCore 'foocore': Unable to create core
> >> [foocore]
> >>> Caused by: null
> >>>
> >>>
> >>> The Solr 

Re: Unable to create core in Solr 8.6.0

2020-07-27 Thread Erick Erickson
I just remembered the issue and relayed the JIRA ;).

As to why I suspect the Java issue, if this was a core Solr issue I’d expect it 
to be a show stopper, 
Solr isn’t much good if you can’t create cores. Of course weirder things have 
happened. Plus, 
the date is fine: "2020-07-27T18:02:42.069Z"

If you have the bandwidth, I’d log all the inputs in 
ParseDateFieldUpdateProcessor.validateFormatter, 
which looks at a glance to be where the exception is caught. The code looks 
like this:

public static void validateFormatter(DateTimeFormatter formatter) {
  // check it's valid via round-trip
  try {
parseInstant(formatter, formatter.format(Instant.now()), new 
ParsePosition(0));
  } catch (Exception e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
"Bad or unsupported pattern: " + formatter.toFormat().toString(), e);
  }
}

I suspect the message is a bit misleading and the formatter in that call is 
null or some such. Why I
haven’t a clue.

Best,
Erick


> On Jul 27, 2020, at 3:54 PM, Chris Larsson  wrote:
> 
> Thank you Erick.  I appreciate you taking the time to respond.  I have seen
> the post you shared and I know the work around does solve the issue.  I am
> more concerned about why Solr doesn't work with the default settings.  I am
> also not convinced it is solely a Java issue, but I would like to
> investigate that further so I ask what makes you say it is a Java issue as
> opposed to being a Solr issue?  I see David's comment, but he seems to be
> approaching the solution as an end user as opposed to a Solr developer.
> 
> 
> On Mon, Jul 27, 2020 at 3:43 PM Erick Erickson 
> wrote:
> 
>> Take a look at:
>> 
>> https://issues.apache.org/jira/browse/SOLR-13606
>> 
>> It’s actually a weirdness with Java. In that JIRA David Smiley
>> suggest a way to deal with it, but I confess I haven’t a clue
>> about the nuances there.
>> 
>> Best,
>> Erick
>> 
>> 
>> 
>>> On Jul 27, 2020, at 3:12 PM, Chris Larsson  wrote:
>>> 
>>> Ran into an issue attempting to create a core on a new install of Solr
>>> 8.6.  The system is CentOS 8 fully updated and using Java OpenJDK version
>>> 14.0.1.
>>> 
>>> # java -version
>>> openjdk version "14.0.1" 2020-04-14
>>> OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
>>> OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)
>>> 
>>> Attempting to create a core from the command line results in the
>> following
>>> messages:
>>> 
>>> # cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
>>> WARNING: Using _default configset with data driven schema functionality.
>>> NOT RECOMMENDED for production use.
>>>To turn off: bin/solr config -c foocore -p 8983 -action
>>> set-user-property -property update.autoCreateFields -value false
>>> 
>>> ERROR: Error CREATEing SolrCore 'foocore': Unable to create core
>> [foocore]
>>> Caused by: null
>>> 
>>> 
>>> The Solr admin site at http://localhost:8983/solr/#/ reports:
>>> 
>>> SolrCore Initialization Failures
>>> foocore:
>>> 
>> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>>> Bad or unsupported pattern:
>>> java.time.format.DateTimeFormatter$ClassicFormat@1c85900d
>>> 
>>> Additional output while the server was running in the foreground:
>>> 
>>> 2020-07-27 18:02:42.104 ERROR (qtp997850486-21) [   ]
>>> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
>>> CREATEing SolrCore 'foocore': Unable to create core [foocore] Caused by:
>>> null
>>> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1312)
>>> at
>>> 
>> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
>>> at
>>> 
>> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
>>> at
>>> 
>> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
>>> at
>>> 
>> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
>>> at
>>> 
>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
>>> at
>> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
>>> at
>>> 
>> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
>>> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
>>> at
>>> 
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
>>> at
>>> 
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
>>> at
>>> 
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
>>> at
>>> 
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
>>> at
>>> 
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>>> at
>>> 
>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
>>> at
>>> 
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>>> at
>>> 

Re: Unable to create core in Solr 8.6.0

2020-07-27 Thread Chris Larsson
Thank you Erick.  I appreciate you taking the time to respond.  I have seen
the post you shared and I know the work around does solve the issue.  I am
more concerned about why Solr doesn't work with the default settings.  I am
also not convinced it is solely a Java issue, but I would like to
investigate that further so I ask what makes you say it is a Java issue as
opposed to being a Solr issue?  I see David's comment, but he seems to be
approaching the solution as an end user as opposed to a Solr developer.


On Mon, Jul 27, 2020 at 3:43 PM Erick Erickson 
wrote:

> Take a look at:
>
> https://issues.apache.org/jira/browse/SOLR-13606
>
> It’s actually a weirdness with Java. In that JIRA David Smiley
> suggest a way to deal with it, but I confess I haven’t a clue
> about the nuances there.
>
> Best,
> Erick
>
>
>
> > On Jul 27, 2020, at 3:12 PM, Chris Larsson  wrote:
> >
> > Ran into an issue attempting to create a core on a new install of Solr
> > 8.6.  The system is CentOS 8 fully updated and using Java OpenJDK version
> > 14.0.1.
> >
> > # java -version
> > openjdk version "14.0.1" 2020-04-14
> > OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
> > OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)
> >
> > Attempting to create a core from the command line results in the
> following
> > messages:
> >
> > # cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
> > WARNING: Using _default configset with data driven schema functionality.
> > NOT RECOMMENDED for production use.
> > To turn off: bin/solr config -c foocore -p 8983 -action
> > set-user-property -property update.autoCreateFields -value false
> >
> > ERROR: Error CREATEing SolrCore 'foocore': Unable to create core
> [foocore]
> > Caused by: null
> >
> >
> > The Solr admin site at http://localhost:8983/solr/#/ reports:
> >
> > SolrCore Initialization Failures
> > foocore:
> >
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> > Bad or unsupported pattern:
> > java.time.format.DateTimeFormatter$ClassicFormat@1c85900d
> >
> > Additional output while the server was running in the foreground:
> >
> > 2020-07-27 18:02:42.104 ERROR (qtp997850486-21) [   ]
> > o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
> > CREATEing SolrCore 'foocore': Unable to create core [foocore] Caused by:
> > null
> > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1312)
> > at
> >
> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
> > at
> >
> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
> > at
> >
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
> > at
> >
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
> > at
> >
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> > at
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> > at
> >
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> > at
> >
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> > at
> >
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> > at
> >
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> > at
> >
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> > at
> >
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> > at
> >
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> > at
> >
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> > at
> >
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> > at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> > at
> >
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> > at
> >
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> > at
> >
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> > at
> >
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> > at

Re: Unable to create core in Solr 8.6.0

2020-07-27 Thread Erick Erickson
Is there an echo in here?

Take a look at:

https://issues.apache.org/jira/browse/SOLR-13606

It’s actually a weirdness with Java. In that JIRA David Smiley
suggest a way to deal with it, but I confess I haven’t a clue
about the nuances there. 

Best,
Erick

> On Jul 27, 2020, at 3:01 PM, sa  wrote:
> 
> Having an issue creating a core on a new install of Solr 8.6.  The system
> is CentOS 8 fully updated and using Java OpenJDK version 14.0.1.
> 
> # java -version
> openjdk version "14.0.1" 2020-04-14
> OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
> OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)
> 
> Attempting to create a core from the command line results in the following
> messages:
> 
> # cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
> WARNING: Using _default configset with data driven schema functionality.
> NOT RECOMMENDED for production use.
> To turn off: bin/solr config -c foocore -p 8983 -action
> set-user-property -property update.autoCreateFields -value false
> 
> ERROR: Error CREATEing SolrCore 'foocore': Unable to create core [foocore]
> Caused by: null
> 
> 
> The Solr admin site at http://localhost:8983/solr/#/
>  reports:
> 
> SolrCore Initialization Failures
> foocore:
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> Bad or unsupported pattern:
> java.time.format.DateTimeFormatter$ClassicFormat@1c85900d
> 
> Additional output while the server was running in the foreground:
> 
> 2020-07-27 18:02:42.104 ERROR (qtp997850486-21) [   ]
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
> CREATEing SolrCore 'foocore': Unable to create core [foocore] Caused by:
> null
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1312)
> at
> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
> at
> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
> at
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
> at
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> 

Re: Unable to create core in Solr 8.6.0

2020-07-27 Thread Erick Erickson
Take a look at:

https://issues.apache.org/jira/browse/SOLR-13606

It’s actually a weirdness with Java. In that JIRA David Smiley
suggest a way to deal with it, but I confess I haven’t a clue
about the nuances there. 

Best,
Erick



> On Jul 27, 2020, at 3:12 PM, Chris Larsson  wrote:
> 
> Ran into an issue attempting to create a core on a new install of Solr
> 8.6.  The system is CentOS 8 fully updated and using Java OpenJDK version
> 14.0.1.
> 
> # java -version
> openjdk version "14.0.1" 2020-04-14
> OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
> OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)
> 
> Attempting to create a core from the command line results in the following
> messages:
> 
> # cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
> WARNING: Using _default configset with data driven schema functionality.
> NOT RECOMMENDED for production use.
> To turn off: bin/solr config -c foocore -p 8983 -action
> set-user-property -property update.autoCreateFields -value false
> 
> ERROR: Error CREATEing SolrCore 'foocore': Unable to create core [foocore]
> Caused by: null
> 
> 
> The Solr admin site at http://localhost:8983/solr/#/ reports:
> 
> SolrCore Initialization Failures
> foocore:
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> Bad or unsupported pattern:
> java.time.format.DateTimeFormatter$ClassicFormat@1c85900d
> 
> Additional output while the server was running in the foreground:
> 
> 2020-07-27 18:02:42.104 ERROR (qtp997850486-21) [   ]
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
> CREATEing SolrCore 'foocore': Unable to create core [foocore] Caused by:
> null
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1312)
> at
> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
> at
> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
> at
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
> at
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
> 

Unable to create core in Solr 8.6.0

2020-07-27 Thread Chris Larsson
Ran into an issue attempting to create a core on a new install of Solr
8.6.  The system is CentOS 8 fully updated and using Java OpenJDK version
14.0.1.

# java -version
openjdk version "14.0.1" 2020-04-14
OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)

Attempting to create a core from the command line results in the following
messages:

# cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
WARNING: Using _default configset with data driven schema functionality.
NOT RECOMMENDED for production use.
 To turn off: bin/solr config -c foocore -p 8983 -action
set-user-property -property update.autoCreateFields -value false

ERROR: Error CREATEing SolrCore 'foocore': Unable to create core [foocore]
Caused by: null


The Solr admin site at http://localhost:8983/solr/#/ reports:

SolrCore Initialization Failures
foocore:
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
Bad or unsupported pattern:
java.time.format.DateTimeFormatter$ClassicFormat@1c85900d

Additional output while the server was running in the foreground:

2020-07-27 18:02:42.104 ERROR (qtp997850486-21) [   ]
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
CREATEing SolrCore 'foocore': Unable to create core [foocore] Caused by:
null
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1312)
at
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
at
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
at
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at

Unable to create core in Solr 8.6.0

2020-07-27 Thread sa
Having an issue creating a core on a new install of Solr 8.6.  The system
is CentOS 8 fully updated and using Java OpenJDK version 14.0.1.

# java -version
openjdk version "14.0.1" 2020-04-14
OpenJDK Runtime Environment 20.3 (build 14.0.1+7)
OpenJDK 64-Bit Server VM 20.3 (build 14.0.1+7, mixed mode, sharing)

Attempting to create a core from the command line results in the following
messages:

# cd /opt/solr;  sudo -u solr bin/solr create_core -c foocore
WARNING: Using _default configset with data driven schema functionality.
NOT RECOMMENDED for production use.
 To turn off: bin/solr config -c foocore -p 8983 -action
set-user-property -property update.autoCreateFields -value false

ERROR: Error CREATEing SolrCore 'foocore': Unable to create core [foocore]
Caused by: null


The Solr admin site at http://localhost:8983/solr/#/
 reports:

SolrCore Initialization Failures
foocore:
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
Bad or unsupported pattern:
java.time.format.DateTimeFormatter$ClassicFormat@1c85900d

Additional output while the server was running in the foreground:

2020-07-27 18:02:42.104 ERROR (qtp997850486-21) [   ]
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error
CREATEing SolrCore 'foocore': Unable to create core [foocore] Caused by:
null
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1312)
at
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:95)
at
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:367)
at
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:397)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:181)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:854)
at
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:818)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at