https://issues.apache.org/jira/secure/attachment/12925603/SOLR-12419.patch
added an extra check in check-source-patterns.groovy though if it's causing
folks issues that could be reverted and once overall standardisation is
complete then the new validLoggerNamePattern check could be included in the
existing validLoggerPattern check.
Christine
From: dev@lucene.apache.org At: 06/29/18 16:59:51To: dev@lucene.apache.org
Subject: Re: OOM on precommit
It’s 64-bit:
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
It’s a fairly old 1.8 though, I’ll try upgrading
On 29 Jun 2018, at 16:52, Uwe Schindler <u...@thetaphi.de> wrote:
Could it be a 32 bit Jvm when it fails? The heap space is different there.
Uwe
Am June 29, 2018 3:45:13 PM UTC schrieb Steve Rowe <sar...@gmail.com>:
I just ran “ant precommit” on the tip of branch_7x, and I’m not seeing an OOM.
My $ANT_OPTS is empty.
$ java -version
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-1~bpo8+1-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)
$ ant -version
Apache Ant(TM) version 1.9.4 compiled on October 7 2014
--
Steve
www.lucidworks.com
On Jun 29, 2018, at 11:29 AM, Alan Woodward <romseyg...@gmail.com> wrote:
I’ve started to get this failure whenever I try and run precommit:
validate-source-patterns:
BUILD FAILED
/Users/romseygeek/projects/lucene-solr-7.x/build.xml:128:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:596)
at java.lang.StringBuilder.append(StringBuilder.java:190)
at
org.codehaus.groovy.runtime.IOGroovyMethods.getText(IOGroovyMethods.java:894)
at
org.codehaus.groovy.runtime.ResourceGroovyMethods.getText(ResourceGroovyMethods.java:608)
at org.codehaus.groovy.runtime.dgm$965.invoke(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
at
check-source-patterns$_run_closure7.doCall(check-source-patterns.groovy:154)
at sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.Closure.call(Closure.java:418)
at groovy.lang.Closure.call(Closure.java:434)
at
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2125)
at
org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1980)
at org.codehaus.groovy.runtime.dgm$160.invoke(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
at check-source-patterns.run(check-source-patterns.groovy:132)
at org.codehaus.groovy.ant.Groovy.parseAndRunScript(Groovy.java:500)
at org.codehaus.groovy.ant.Groovy.execGroovy(Groovy.java:447)
at org.codehaus.groovy.ant.Groovy.execute(Groovy.java:305)
No changes to ant or groovy as far as I can tell, and no changes to any of the
JVM settings either. Is this affecting anyone else?
AW
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
