Spring Tomcat C3P0PooledConnectionPoolManager creates a memory leak [duplicate] - java

I configured tomcat to work with a different external open source.
However, after the tomcat is running for a few minutes I get:
SEVERE: The web application [/MyProject] created a ThreadLocal with
key of type [java.lang.ThreadLocal] (value
[java.lang.ThreadLocal#1b3f02f]) and a value of type
[org.apache.axis.MessageContext] (value
[org.apache.axis.MessageContext#5dbd4e]) but failed to remove it when
the web application was stopped. This is very likely to create a
memory leak.
What could cause it?
Where do I have to look? Could it be datapooling on Tomcat?
And what does it mean Threads in Tomcat?
EDITED
Here is my full trace. The application seems to reloads its context while it's still running - and I don't know why!
Mar 13, 2011 10:56:12 PM org.apache.catalina.core.StandardContext reload
INFO: Reloading this Context has started
Mar 13, 2011 10:56:12 PM org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
Mar 13, 2011 10:56:13 PM org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
Mar 13, 2011 10:56:14 PM org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
Mar 13, 2011 10:56:14 PM org.apache.catalina.core.ApplicationContext log
INFO: Closing Spring root WebApplicationContext
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/MyProject] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/MyProject] registered the JBDC driver [oracle.jdbc.driver.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [NioSocketAcceptor-1] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [NioProcessor-1] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [NioProcessor-4] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [bitronix-disk-force-batcher] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [bitronix-scheduler] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] is still processing a request that has yet to finish. This is very likely to create a memory leak. You can control the time allowed for requests to finish by using the unloadDelay attribute of the standard Context implementation.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [NioProcessor-7] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/MyProject] appears to have started a thread named [NioProcessor-2] but has failed to stop it. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal#1b5a8e1]) and a value of type [org.mvel2.debug.DebuggerContext] (value [org.mvel2.debug.DebuggerContext#16259fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value [org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder#84b0b4]) and a value of type [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl] (value [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl#16d2cfa]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [null] (value [com.sun.faces.util.Util$1#16bbac9]) and a value of type [java.util.HashMap] (value [{com.sun.faces.patternCache={ = }}]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal#1b3f02f]) and a value of type [org.apache.axis.MessageContext] (value [org.apache.axis.MessageContext#5dbd4e]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value [org.apache.axis.utils.XMLUtils$ThreadLocalDocumentBuilder#84b0b4]) and a value of type [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl] (value [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl#378584]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [org.springframework.core.NamedThreadLocal] (value [Transactional resources]) and a value of type [java.util.HashMap] (value [{org.hibernate.impl.SessionFactoryImpl#ccc27b=org.springframework.orm.hibernate3.SessionHolder#4f6ada}]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
Mar 13, 2011 10:56:15 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SEVERE: The web application [/MyProject] created a ThreadLocal with key of type [null] (value [com.sun.faces.application.ApplicationAssociate$1#1f01fcf]) and a value of type [com.sun.faces.application.ApplicationAssociate] (value [com.sun.faces.application.ApplicationAssociate#1b85528]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
2011-03-13 22:57:27,734 ERROR ( ContextLoader.java:220) - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager' defined in class path resource [applicationContext-hibernate.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [applicationContext-hibernate.xml]: Invocation of init method failed; nested exception is java.lang.OutOfMemoryError: Java heap space
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1325)

The message is actually pretty clear: something creates a ThreadLocal with value of type org.apache.axis.MessageContext - this is a great hint. It most likely means that Apache Axis framework forgot/failed to cleanup after itself. The same problem occurred for instance in Logback. You shouldn't bother much, but reporting a bug to Axis team might be a good idea.
Tomcat reports this error because the ThreadLocals are created per HTTP worker threads. Your application is undeployed but HTTP threads remain - and these ThreadLocals as well. This may lead to memory leaks (org.apache.axis.MessageContext can't be unloaded) and some issues when these threads are reused in the future.
For details see: http://wiki.apache.org/tomcat/MemoryLeakProtection

I added the following to #PreDestroy method in my CDI #ApplicationScoped bean, and when I shutdown TomEE 1.6.0 (tomcat7.0.39, as of today), it clears the thread locals.
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package pf;
import java.lang.ref.WeakReference;
import java.lang.reflect.Array;
import java.lang.reflect.Field;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
*
* #author Administrator
*
* google-gson issue # 402: Memory Leak in web application; comment # 25
* https://code.google.com/p/google-gson/issues/detail?id=402
*/
public class ThreadLocalImmolater {
final Logger logger = LoggerFactory.getLogger(ThreadLocalImmolater.class);
Boolean debug;
public ThreadLocalImmolater() {
debug = true;
}
public Integer immolate() {
int count = 0;
try {
final Field threadLocalsField = Thread.class.getDeclaredField("threadLocals");
threadLocalsField.setAccessible(true);
final Field inheritableThreadLocalsField = Thread.class.getDeclaredField("inheritableThreadLocals");
inheritableThreadLocalsField.setAccessible(true);
for (final Thread thread : Thread.getAllStackTraces().keySet()) {
count += clear(threadLocalsField.get(thread));
count += clear(inheritableThreadLocalsField.get(thread));
}
logger.info("immolated " + count + " values in ThreadLocals");
} catch (Exception e) {
throw new Error("ThreadLocalImmolater.immolate()", e);
}
return count;
}
private int clear(final Object threadLocalMap) throws Exception {
if (threadLocalMap == null)
return 0;
int count = 0;
final Field tableField = threadLocalMap.getClass().getDeclaredField("table");
tableField.setAccessible(true);
final Object table = tableField.get(threadLocalMap);
for (int i = 0, length = Array.getLength(table); i < length; ++i) {
final Object entry = Array.get(table, i);
if (entry != null) {
final Object threadLocal = ((WeakReference)entry).get();
if (threadLocal != null) {
log(i, threadLocal);
Array.set(table, i, null);
++count;
}
}
}
return count;
}
private void log(int i, final Object threadLocal) {
if (!debug) {
return;
}
if (threadLocal.getClass() != null &&
threadLocal.getClass().getEnclosingClass() != null &&
threadLocal.getClass().getEnclosingClass().getName() != null) {
logger.info("threadLocalMap(" + i + "): " +
threadLocal.getClass().getEnclosingClass().getName());
}
else if (threadLocal.getClass() != null &&
threadLocal.getClass().getName() != null) {
logger.info("threadLocalMap(" + i + "): " + threadLocal.getClass().getName());
}
else {
logger.info("threadLocalMap(" + i + "): cannot identify threadlocal class name");
}
}
}

The key "Transactional Resources" looks like you are talking to the database without a proper transaction. Make sure transaction management is configured properly and no invocation path to the DAO exists that doesn't run under a #Transactional annotation. This can easily happen when you configured transaction management on the Controller level but are invoking DAOs in a timer or are using #PostConstruct annotations. I wrote it up here http://georgovassilis.blogspot.nl/2014/01/tomcat-spring-and-memory-leaks-when.html
Edit: It looks like this is (also?) a bug with spring-data-jpa which has been fixed with v1.4.3. I looked it up in the spring-data-jpa sources of LockModeRepositoryPostProcessor which sets the "Transactional Resources" key. In 1.4.3 it also clears the key again.

Sometimes this has to do with configuration changes. When we upgraded from Tomncat 6.0.14 to 6.0.26, we had seen something similar. here is the solution
http://www.skill-guru.com/blog/2010/08/22/tomcat-6-0-26-shutdown-reports-a-web-application-created-a-threadlocal-threadlocal-has-been-forcibly-removed/

This problem appears when we are using any third party solution, without using the handlers for the cleanup activitiy.
For me this was happening for EhCache. We were using EhCache in our project for caching.
And often we used to see following error in the logs
SEVERE: The web application [/products] appears to have started a thread named [products_default_cache_configuration] but has failed to stop it. This is very likely to create a memory leak.
Aug 07, 2017 11:08:36 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/products] appears to have started a thread named [Statistics Thread-products_default_cache_configuration-1] but has failed to stop it. This is very likely to create a memory leak.
And we often noticed tomcat failing for OutOfMemory error during development where we used to do backend changes and deploy the application multiple times for reflecting our changes.
This is the fix we did
<listener>
<listener-class>
net.sf.ehcache.constructs.web.ShutdownListener
</listener-class>
</listener>
So point I am trying to make is check the documentation of the third party libraries which you are using. They should be providing some mechanisms to clean up the threads during shutdown. Which you need to use in your application.
No need to re-invent the wheel unless its not provided by them. The worst case is to provide your own implementation.
Reference for EHCache Shutdown
http://www.ehcache.org/documentation/2.8/operations/shutdown.html

Related

Why does a servlet container synchronise access for multiple requests to a particular resource/ servlet?

By default, the servlet container loads only a single instance of a
servlet. Requests serviced by the servlet are run in separate threads,
but share the same instance. This enables applications to be
responsive and scalable, since it requires fewer resources and uses
them efficiently.
Almost everyone knows that this is the default threading model.
This question/discussion is a follow-up on this particular stackoverflow thread.
But the output happens to be completely different in my case,
May 21, 2016 1:57:59 PM com.stackoverflow.question8011138.MyServlet doGet
INFO: [doGet] Test before // 1st thread
May 21, 2016 1:58:26 PM com.stackoverflow.question8011138.MyServlet doGet
INFO: [doGet] Test before // 2nd thread
May 21, 2016 1:58:59 PM com.stackoverflow.question8011138.MyServlet doGet
INFO: [doGet] Test after // 1st thread
May 21, 2016 1:59:26 PM com.stackoverflow.question8011138.MyServlet doGet
INFO: [doGet] Test after // 2nd thread
Even though I hit the url mapped to this particlular servlet in 2 browser windows of the same browser, the difference b/w these 2 hitting ~1 second, but I see the below output
May 21, 2016 1:58:26 PM com.stackoverflow.question8011138.MyServlet doGet
INFO: [doGet] Test before // 2nd thread
after seconds more than that previously mentioned ~1 second,
i.e to this,
May 21, 2016 1:57:59 PM com.stackoverflow.question8011138.MyServlet doGet
INFO: [doGet] Test before // 1st thread
Why?
Clearly, from the output above, the second request is not served after the first has been served completely, but in b/w, contrary to what the OP to that question suggested.
What exactly is going on?
Why 2 different outputs to the same scenario?
The result/ output clearly shows that the server is not synchronizing the 2 requests.

Starting 2 hazelcast instances synchronously on a single machine (with hazelcast.initial.min.cluster.size=2)

How can I configure Hazelcast (optimally the version I currently use: 3.1.2) to run 2 hazelcast instances on a single machine, and block the first instance during startup until both instances are present?
hazelcast.initial.min.cluster.size
The blocking behavior described above can be implemented with the help of hazelcast.initial.min.cluster.size when running both instances on different machines: With the configuration:
Config cfg = new Config();
cfg.setProperty("hazelcast.initial.min.cluster.size",
Integer.toString(minimumInitialMembersInHazelCluster));
cfg.getGroupConfig().setName(clusterName);
hazelInst = Hazelcast.newHazelcastInstance(cfg);
run on different machines, I get the output
Apr 15, 2014 9:31:39 AM com.hazelcast.instance.DefaultAddressPicker
INFO: Prefer IPv4 stack is true.
Apr 15, 2014 9:31:39 AM com.hazelcast.instance.DefaultAddressPicker
INFO: Picked Address[192.168.31.105]:5701, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5701], bind any local is true
Apr 15, 2014 9:31:40 AM com.hazelcast.system
INFO: [192.168.31.105]:5701 [dev] Hazelcast Community Edition 3.1.2 (20131120) starting at Address[192.168.31.105]:5701
Apr 15, 2014 9:31:40 AM com.hazelcast.system
INFO: [192.168.31.105]:5701 [dev] Copyright (C) 2008-2013 Hazelcast.com
Apr 15, 2014 9:31:40 AM com.hazelcast.instance.Node
INFO: [192.168.31.105]:5701 [dev] Creating MulticastJoiner
Apr 15, 2014 9:31:40 AM com.hazelcast.core.LifecycleService
INFO: [192.168.31.105]:5701 [dev] Address[192.168.31.105]:5701 is STARTING
Apr 15, 2014 9:31:43 AM com.hazelcast.cluster.MulticastJoiner
INFO: [192.168.31.105]:5701 [dev]
Members [1] {
Member [192.168.31.105]:5701 this
}
Apr 15, 2014 9:31:43 AM com.hazelcast.core.LifecycleService
INFO: [192.168.31.105]:5701 [dev] Address[192.168.31.105]:5701 is STARTED
Apr 15, 2014 9:31:43 AM HazelMultiInstanceExp <init>
SEVERE: debug: joined via JoinConfig{multicastConfig=MulticastConfig [enabled=true, multicastGroup=224.2.2.3, multicastPort=54327, multicastTimeToLive=32, multicastTimeoutSeconds=2, trustedInterfaces=[]], tcpIpConfig=TcpIpConfig [enabled=false, connectionTimeoutSeconds=5, members=[], requiredMember=null], awsConfig=AwsConfig{enabled=false, region='us-east-1', securityGroupName='null', tagKey='null', tagValue='null', hostHeader='ec2.amazonaws.com', connectionTimeoutSeconds=5}} with 1 members.
Apr 15, 2014 9:31:43 AM com.hazelcast.instance.DefaultAddressPicker
INFO: Prefer IPv4 stack is true.
Apr 15, 2014 9:31:43 AM com.hazelcast.instance.DefaultAddressPicker
INFO: Picked Address[192.168.31.105]:5702, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5702], bind any local is true
Apr 15, 2014 9:31:43 AM com.hazelcast.system
INFO: [192.168.31.105]:5702 [dev] Hazelcast Community Edition 3.1.2 (20131120) starting at Address[192.168.31.105]:5702
Apr 15, 2014 9:31:43 AM com.hazelcast.system
INFO: [192.168.31.105]:5702 [dev] Copyright (C) 2008-2013 Hazelcast.com
Apr 15, 2014 9:31:43 AM com.hazelcast.instance.Node
INFO: [192.168.31.105]:5702 [dev] Creating MulticastJoiner
Apr 15, 2014 9:31:43 AM com.hazelcast.core.LifecycleService
INFO: [192.168.31.105]:5702 [dev] Address[192.168.31.105]:5702 is STARTING
Apr 15, 2014 9:31:43 AM com.hazelcast.nio.SocketConnector
INFO: [192.168.31.105]:5702 [dev] Connecting to /192.168.31.105:5701, timeout: 0, bind-any: true
Apr 15, 2014 9:31:43 AM com.hazelcast.nio.SocketAcceptor
INFO: [192.168.31.105]:5701 [dev] Accepting socket connection from /192.168.31.105:60803
Apr 15, 2014 9:31:43 AM com.hazelcast.nio.TcpIpConnectionManager
INFO: [192.168.31.105]:5702 [dev] 60803 accepted socket connection from /192.168.31.105:5701
Apr 15, 2014 9:31:43 AM com.hazelcast.nio.TcpIpConnectionManager
INFO: [192.168.31.105]:5701 [dev] 5701 accepted socket connection from /192.168.31.105:60803
Apr 15, 2014 9:31:49 AM com.hazelcast.cluster.ClusterService
INFO: [192.168.31.105]:5702 [dev]
Members [2] {
Member [192.168.31.105]:5701
Member [192.168.31.105]:5702 this
}
but run with two instances on one machine, I get
Apr 15, 2014 9:25:14 AM com.hazelcast.instance.DefaultAddressPicker
INFO: Prefer IPv4 stack is true.
Apr 15, 2014 9:25:14 AM com.hazelcast.instance.DefaultAddressPicker
INFO: Picked Address[192.168.31.105]:5701, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5701], bind any local is true
Apr 15, 2014 9:25:15 AM com.hazelcast.system
INFO: [192.168.31.105]:5701 [test3] Hazelcast Community Edition 3.1.2 (20131120) starting at Address[192.168.31.105]:5701
Apr 15, 2014 9:25:15 AM com.hazelcast.system
INFO: [192.168.31.105]:5701 [test3] Copyright (C) 2008-2013 Hazelcast.com
Apr 15, 2014 9:25:15 AM com.hazelcast.instance.Node
INFO: [192.168.31.105]:5701 [test3] Creating MulticastJoiner
Apr 15, 2014 9:25:15 AM com.hazelcast.core.LifecycleService
INFO: [192.168.31.105]:5701 [test3] Address[192.168.31.105]:5701 is STARTING
Apr 15, 2014 9:25:18 AM com.hazelcast.cluster.MulticastJoiner
INFO: [192.168.31.105]:5701 [test3]
Members [1] {
Member [192.168.31.105]:5701 this
}
Apr 15, 2014 9:25:18 AM com.hazelcast.instance.HazelcastInstanceImpl
INFO: [192.168.31.105]:5701 [test3] HazelcastInstance waiting for cluster size of 2
with the last INFO message repeated ad infinitum.
So the cluster size is the number of nodes in the cluster, not the number of hazelcast instances?
Blocking behavior on a single machine
I use cfg.setProperty("hazelcast.initial.min.cluster.size","2") so the two distributed instances start my distributed algorithm synchronously. Furthermore, it solves the problem that some hazelcast members are not found, see https://stackoverflow.com/a/20716919/750378.
So how do I avoid both problems when running on a single machine? It would be great if the cluster size would simple be the number of running hazelcast instances. Then I could keep my configuration above no matter how I deploy my two instances (on 1 or 2 machines).
Update
I have posted an issue about the cluster size at https://github.com/hazelcast/hazelcast/issues/2292.
You could use the same machine to run multiples Hazelcast instance. Under the hoods, Hazelcast binds differents ports for each instance.
Following, a simple test with two instances:
HazelcastInstance firstInstance = Hazelcast.newHazelcastInstance(new Config());
HazelcastInstance secondInstance = Hazelcast.newHazelcastInstance(new Config());
// Introducing a sample data in a map using the first instance
firstInstance.getMap("TEST_MAP").put("key", "test_value");
// Prints the value using the second instance. The result will be 'test_value'
System.out.println(secondInstance.getMap("TEST_MAP").get("key"));
When this code starts the console output is:
Members [2] {
Member [192.168.216.1]:5702
Member [192.168.216.1]:5703 this
}
As you can see, two instances were registered in the same IP but different ports.
You should start instances in different threads.
See following test:
public static void main(String[] args) throws InterruptedException {
final Config cfg = new Config();
cfg.setProperty(GroupProperties.PROP_INITIAL_MIN_CLUSTER_SIZE, "2");
Runnable runnable = new Runnable() {
public void run() {
final HazelcastInstance instance = Hazelcast.newHazelcastInstance(cfg);
IMap<Object, Object> map = instance.getMap("map");
for (int i = 0; i < 100; i++) {
map.put(i, i);
System.out.println("put:" + i);
}
}
};
Thread thread1 = new Thread(runnable);
Thread thread2 = new Thread(runnable);
thread1.start();
Thread.sleep(1000);
thread2.start();
}
Please see this thread for more information. Based on the info there, your best bet is to:
make sure you're using a configuration which allows for two machines in the cluster, on the same pc (check out the sample config file attached to that thread)
Run both machines on the same JVM (rather than firing up two separate JVMs)
Are running a fairly recent version (3.1.2 should be fine)
Starting two JVMs on the same physical machine might work sometimes if you make sure they don't have conflicting port settings, but you'll likely run into various problems (ie, i bet they won't be able to properly listen to the same multicast port). I'd advise against that approach.

How to declare Stack size in Java/Groovy (Verify Error: Stack too large)

I am getting this error:
Feb 11, 2014 10:32:34 AM org.apache.catalina.core.ApplicationContext log
Information: ContextListener: contextInitialized()
Feb 11, 2014 10:32:34 AM org.apache.catalina.core.ApplicationContext log
Information: SessionListener: contextInitialized()
Feb 11, 2014 10:32:34 AM org.apache.catalina.core.ApplicationContext log
Information: ContextListener: attributeAdded('org.apache.jasper.compiler.TldLocationsCache', 'org.apache.jasper.compiler.TldLocationsCache#6b2c636d')
Feb 11, 2014 10:43:04 AM org.apache.catalina.core.ApplicationContext log
Information: No Spring WebApplicationInitializer types detected on classpath
Feb 11, 2014 10:43:05 AM org.apache.catalina.core.ApplicationContext log
Information: Initializing Spring root WebApplicationContext
Feb 11, 2014 10:43:06 AM org.apache.catalina.core.StandardContext listenerStart
Schwerwiegend: Exception sending context initialized event to listener instance of class org.codehaus.groovy.grails.web.context.GrailsContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'grailsApplication' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.VerifyError: (class: elektrova/UserController, method: $tt__index signature: (Ljava/lang/Integer;Lorg/springframework/transaction/TransactionStatus;)Ljava/lang/Object;) Stack size too large
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.VerifyError: (class: elektrova/UserController, method: $tt__index signature: (Ljava/lang/Integer;Lorg/springframework/transaction/TransactionStatus;)Ljava/lang/Object;) Stack size too large
at java.lang.Class.forName(Class.java:270)
... 5 more
In this method:
def index(Integer max) {
params.max = Math.min(max ?: 10, 100)
if(!session.isAdmin){
Hauler haul = Hauler.get(session.haulerID)
println haul
if(params.firstName)
respond User.findAllWhere([hauler:haul,firstName:params.firstName]), model:[userInstanceCount: User.count()]
else if(params.lastName)
respond User.findAllWhere([hauler:haul,lastName:params.lastName]), model:[userInstanceCount: User.count()]
else if(params.role)
respond User.findAllWhere([hauler:haul,role:params.role]), model:[userInstanceCount: User.count()]
else
respond User.findAllByHauler(haul), model:[userInstanceCount: User.count()]
}else{
if(params.firstName){
model:[userInstanceList: User.findAllByFirstName(params.firstName),userInstanceCount: User.count()]
}else if(params.lastName)
model:[userInstanceList: User.findAllByLastName(params.lastName),userInstanceCount: User.count()]
else if(params.role)
model:[userInstanceList: User.findAllByRole(params.role),userInstanceCount: User.count()]
else
model:[userInstanceList: User.list(params),userInstanceCount: User.count()]
}
}
I found this thread, that solves the problem imho:
VerifyError: Stack size too large (what does it mean?)
but I don't quite get how to calculate and declare the stack size. And I don't understand either, why I have to declare it, since other methods don't need it.
Thanks for any help!
The problem disappeared without me changing anything, I have no idea why

Failed to stop the worker thread, likely to create a Memory leak.

I am using a servlet that implements ServletContextListener to start the quartz scheduler instance # starup. In the contextDestroyed() method, the scheduler instance is stopped.
#Override
public void contextDestroyed(ServletContextEvent sce) {
try {
Scheduler scheduler = QuartzSchedulerUtil.getCurrentScheduler();
scheduler.shutdown(true);
// Sleep for a bit so that we don't get any errors
Thread.sleep(1000);
Driver mySqlDriver = DriverManager.getDriver(hibernateConnectionUrl);
DriverManager.deregisterDriver(mySqlDriver);
} catch (SchedulerException ex) {
Logger.getLogger(QuartzServlet.class.getName()).log(Level.SEVERE, null, ex);
} catch (InterruptedException ex) {
Logger.getLogger(QuartzServlet.class.getName()).log(Level.SEVERE, null, ex);
} catch (SQLException ex) {
Logger.getLogger(QuartzServlet.class.getName()).log(Level.SEVERE, null, ex);
}
System.out.println("THE QUARTZ APP STOPPED");
}
But when the application is deployed i get the memory leak warnings specifying that the woker threads are not stopping.
Jul 10, 2012 3:46:12 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application [/latest-raisin]
appears to have started a thread named [Timer-0] but has failed to
stop it. This is very likely to create a memory leak.
Jul 10, 2012 3:46:12 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application [/latest-raisin]
appears to have started a thread named
[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] but
has failed to stop it. This is very likely to create a memory leak.
Jul 10, 2012 3:46:12 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application [/latest-raisin]
appears to have started a thread named
[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] but
has failed to stop it. This is very likely to create a memory leak.
Jul 10, 2012 3:46:12 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application [/latest-raisin]
appears to have started a thread named
[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2] but
has failed to stop it. This is very likely to create a memory leak.
I tried the solution as mentioned in the post - http://forums.terracotta.org/forums/posts/list/15/4341.page
But still getting the Severe memory leak warnings when the appication is undeployed.
You can set the property in org.quartz.scheduler.interruptJobsOnShutdown to interrupt jobs if they are still in execution when you want to shutdown.

Jade DispatcherException problem when using remote Containers

I have two virtual machines in a private
cloud, and I want to execute Jade both of them. They can access each
other without problems. I started in one of them the Main Container, and
in the other a Container which would connect to the main. However, I get
a Dispatcher exception when this connection tries to take place:
--------
INFO: Adding node <Container-1> to the platform
Jun 22, 2011 12:54:34 PM jade.core.messaging.MessagingService
clearCachedSlice
INFO: Clearing cache
Jun 22, 2011 12:54:34 PM jade.core.messaging.MessagingService
$CommandTargetSink handleNewSlice
WARNING: Error notifying current information to new Messaging-Slice
Container-1
jade.core.IMTPException: Dispatcher error [nested
jade.imtp.leap.DispatcherException: DispatcherException in remote site.
No skeleton for object-id 3447152]
at jade.imtp.leap.NodeStub.accept(NodeStub.java:91)
at jade.core.messaging.MessagingProxy.addRoute(MessagingProxy.java:257)
at jade.core.messaging.MessagingService
$CommandTargetSink.handleNewSlice(MessagingService.java:993)
at jade.core.messaging.MessagingService
$CommandTargetSink.consume(MessagingService.java:906)
at jade.core.CommandProcessor
$SinksFilter.accept(CommandProcessor.java:253)
at jade.core.Filter.filter(Filter.java:89)
at jade.core.Filter.filter(Filter.java:90)
at jade.core.Filter.filter(Filter.java:90)
at
jade.core.CommandProcessor.processIncoming(CommandProcessor.java:229)
at
jade.core.PlatformManagerImpl.issueNewSliceCommand(PlatformManagerImpl.java:744)
at
jade.core.PlatformManagerImpl.localAddSlice(PlatformManagerImpl.java:445)
at
jade.core.PlatformManagerImpl.localAddNode(PlatformManagerImpl.java:293)
at jade.core.PlatformManagerImpl.addNode(PlatformManagerImpl.java:245)
at
jade.imtp.leap.PlatformManagerSkel.executeCommand(PlatformManagerSkel.java:73)
at jade.imtp.leap.Skeleton.processCommand(Skeleton.java:51)
at
jade.imtp.leap.CommandDispatcher.handleCommand(CommandDispatcher.java:949)
at jade.imtp.leap.JICP.JICPServer
$ConnectionHandler.run(JICPServer.java:439)
Nested Exception:
jade.imtp.leap.DispatcherException: DispatcherException in remote site.
No skeleton for object-id 3447152
at
jade.imtp.leap.CommandDispatcher.checkRemoteExceptions(CommandDispatcher.java:516)
at
jade.imtp.leap.CommandDispatcher.dispatchSerializedCommand(CommandDispatcher.java:418)
at
jade.imtp.leap.CommandDispatcher.dispatchCommand(CommandDispatcher.java:343)
at jade.imtp.leap.NodeStub.accept(NodeStub.java:83)
at jade.core.messaging.MessagingProxy.addRoute(MessagingProxy.java:257)
at jade.core.messaging.MessagingService
$CommandTargetSink.handleNewSlice(MessagingService.java:993)
at jade.core.messaging.MessagingService
$CommandTargetSink.consume(MessagingService.java:906)
at jade.core.CommandProcessor
$SinksFilter.accept(CommandProcessor.java:253)
at jade.core.Filter.filter(Filter.java:89)
at jade.core.Filter.filter(Filter.java:90)
at jade.core.Filter.filter(Filter.java:90)
at
jade.core.CommandProcessor.processIncoming(CommandProcessor.java:229)
at
jade.core.PlatformManagerImpl.issueNewSliceCommand(PlatformManagerImpl.java:744)
at
jade.core.PlatformManagerImpl.localAddSlice(PlatformManagerImpl.java:445)
at
jade.core.PlatformManagerImpl.localAddNode(PlatformManagerImpl.java:293)
at jade.core.PlatformManagerImpl.addNode(PlatformManagerImpl.java:245)
at
jade.imtp.leap.PlatformManagerSkel.executeCommand(PlatformManagerSkel.java:73)
at jade.imtp.leap.Skeleton.processCommand(Skeleton.java:51)
at
jade.imtp.leap.CommandDispatcher.handleCommand(CommandDispatcher.java:949)
at jade.imtp.leap.JICP.JICPServer
$ConnectionHandler.run(JICPServer.java:439)
Jun 22, 2011 12:54:34 PM jade.core.PlatformManagerImpl$1 nodeAdded
INFO: --- Node <Container-1> ALIVE ---
Jun 22, 2011 12:54:34 PM
jade.core.nodeMonitoring.BlockingNodeFailureMonitor run
INFO: PING from node Container-1 exited with exception. Dispatcher error
[nested jade.imtp.leap.DispatcherException: DispatcherException in
remote site. No skeleton for object-id 3447152]
Jun 22, 2011 12:54:34 PM jade.core.PlatformManagerImpl$1 nodeUnreachable
WARNING: --- Node <Container-1> UNREACHABLE ---
Jun 22, 2011 12:54:34 PM jade.core.PlatformManagerImpl
removeTerminatedNode
INFO: --- Node <Container-1> TERMINATED ---
Jun 22, 2011 12:54:34 PM jade.core.messaging.MessagingService
clearCachedSlice
---------
In the other node I get the following:
--------
Jun 22, 2011 12:55:35 PM jade.core.AgentContainerImpl joinPlatform
SEVERE: Some problem occurred while joining agent platform.
jade.core.ServiceException: An error occurred during service booting
[nested java.lang.NullPointerException]
at
jade.core.AgentContainerImpl.bootAllServices(AgentContainerImpl.java:465)
at jade.core.AgentContainerImpl.startNode(AgentContainerImpl.java:408)
at
jade.core.AgentContainerImpl.joinPlatform(AgentContainerImpl.java:485)
at jade.core.Runtime.createAgentContainer(Runtime.java:133)
at BookBuyTest2.main(BookBuyTest2.java:25)
Exception in thread "main" java.lang.NullPointerException
at BookBuyTest2.main(BookBuyTest2.java:35)
------
Any ideas about what I am doing wrong?
Thank you very much in advance,
The problem was that in the node I put:
local-host:127.0.0.1
This was solved by putting
local-host: <actual IP of the machine\>
To me, this worked
String[] container = {
"-gui",
"-local-host 127.0.0.1",
"-container",
"Agent1:jogo.agents.Agent1;Agent2:jogo.agents.Agent2" // <- Your custom agents
};
Boot.main(container);

Categories