Michael,
Thanks for the response. Below is the stack trace.
Note: Our environment is 64 bit and the Initial Pool size is set to 4GB and
Max pool size is 12GB so it doesn't makes sense why it tries to allocate
24GB (even that is available as the total RAM is 64GB).
This issue doesn't come with SOLR 1.4
-----------------------------------------
SEVERE: Error waiting for multi-thread deployment of directories to
completehostConfig.deployWar=Deploying web application archive {0}
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
classblock allocation, 1535880 loaded, 1536K footprint, in check_alloc
(src/jvm/model/classload/classalloc.c:215).
Attempting to allocate 24000M bytes
There is insufficient native memory for the Java
Runtime Environment to continue.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Disable compressed references (-XXcompressedRefs=false)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.apache.catalina.startup.HostConfig.deployDirectories(
HostConfig.java:1018)
at org.apache.catalina.startup.HostConfig.deployApps(
HostConfig.java:475)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1412)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(
HostConfig.java:312)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
LifecycleBase.java:91)
at org.apache.catalina.util.LifecycleBase.setStateInternal(
LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.setState(
LifecycleBase.java:346)
at org.apache.catalina.core.ContainerBase.startInternal(
ContainerBase.java:1117)
at org.apache.catalina.core.StandardHost.startInternal(
StandardHost.java:782)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(
ContainerBase.java:1526)
at org.apache.catalina.core.ContainerBase$StartChild.call(
ContainerBase.java:1515)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:139)
at java.util.concurrent.ThreadPoolExecutor$Worker.
runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:909)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.OutOfMemoryError: classblock allocation, 1535880
loaded, 1536K footprint, in check_alloc (src/jvm/model/classload/
classalloc.c:215).
Attempting to allocate 24000M bytes
There is insufficient native memory for the Java
Runtime Environment to continue.
Possible reasons:
The system is out of physical RAM or swap space
In 32 bit mode, the process size limit was hit
Possible solutions:
Reduce memory load on the system
Increase physical memory or swap space
Check if swap backing store is full
Use 64 bit Java on a 64 bit OS
Decrease Java heap size (-Xmx/-Xms)
Decrease number of Java threads
Decrease Java thread stack sizes (-Xss)
Disable compressed references (-XXcompressedRefs=false)
at sun.misc.Unsafe.defineClass(Native Method)
at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
at sun.reflect.MethodAccessorGenerator$1.run(
MethodAccessorGenerator.java:381)
at sun.reflect.MethodAccessorGenerator.generate(
MethodAccessorGenerator.java:377)
at sun.reflect.MethodAccessorGenerator.generateConstructor(
MethodAccessorGenerator.java:76)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(
NativeConstructorAccessorImpl.java:30)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:147)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:233)
at javax.xml.parsers.SAXParserFactory.newInstance(
SAXParserFactory.java:128)
at org.apache.tomcat.util.digester.Digester.getFactory(
Digester.java:470)
at org.apache.tomcat.util.digester.Digester.getParser(Digester.java:677)
at org.apache.catalina.startup.ContextConfig.init(
ContextConfig.java:780)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(
ContextConfig.java:320)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(
LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(
LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(
LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:866)
at org.apache.catalina.core.ContainerBase.addChild(
ContainerBase.java:842)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
at org.apache.catalina.startup.HostConfig.deployDirectory(
HostConfig.java:1095)
at org.apache.catalina.startup.HostConfig$DeployDirectory.
run(HostConfig.java:1617)
at java.util.concurrent.Executors$RunnableAdapter.
call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.
runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:908)
... 1 more
Jun 7, 2012 4:03:04 AM org.apache.coyote.AbstractProtocol start
On Mon, Jul 16, 2012 at 2:20 AM, Michael Della Bitta <
michael.della.bi...@appinions.com> wrote:
> Hello, Salman,
>
> It would probably be helpful if you included the text/stack trace of
> the error you're encountering, plus any other pertinent system
> information you can think of.
>
> One thing to remember is the memory usage you tune with Xmx is only
> the maximum size of the heap, and there are other types of memory
> usage by the JVM that don't fall under that (Permgen space, memory
> mapped files, etc).
>
> Michael Della Bitta
>
> ------------------------------------------------
> Appinions, Inc. -- Where Influence Isn’t a Game.
> http://www.appinions.com
>
>
> On Sun, Jul 15, 2012 at 3:19 PM, Salman Akram
> <salman.ak...@northbaysolutions.net> wrote:
> > We used JRockit with SOLR1.4 as default JVM had mem issues (not only it
> was consuming more mem but didn't restrict to the max mem allocated to
> tomcat - jrockit did restrict to max mem). However, JRockit gives an error
> while using it with SOLR3.4/3.5. Any ideas, why?
> >
> > *** This Message Has Been Sent Using BlackBerry Internet Service from
> Mobilink ***
>
--
Regards,
Salman Akram
Project Manager - Intelligize
NorthBay Solutions
410-G4 Johar Town, Lahore
Off: +92-42-35290152
Cell: +92-302-8495621
