RE: tomee:undeploy is not clean after long timeout since the last deployment

Sure, will do the pull/request. -Original Message- From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Sent: July-25-16 12:00 PM To: users@tomee.apache.org Subject: Re: tomee:undeploy is not clean after long timeout since the last deployment suspect it will need a try/finally on ht

Re: tomee:undeploy is not clean after long timeout since the last deployment

suspect it will need a try/finally on https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/assembler/DeployerEjb.java#L408 do you want to give it a go with a pull/request? You can use tomee github proxy: https://github.com/apache/tomee Romain Manni-

tomee:undeploy is not clean after long timeout since the last deployment

Hi, I'm using tomee maven plugin to undeploy/deploy my war to the remote server and It works pretty well when deployments are executed often, but when there is long a timeout (10 hours for example) it fails to cleanly undeploy the app. There are no logged exceptions in the app log file and in th

Re: Heap leak as JCache provider?

I drilled into the dominator tree to look at some of the data. After I let the app run for 24 hours I can look com.hazelcast.cache.impl.record.CacheDataRecord.expirationTime and see if current time exceeds that time. Since it's replicating data it's going to start off with cached items because I do

Re: Heap leak as JCache provider?

so URLClassLoader is likely common-loader, question is: if hazelcast is loaded from the webapp why does it uses the parent loader? API is there but providing the classloader it shouldn't rely on this. Romain Manni-Bucau @rmannibucau | Blog

Re: Heap leak as JCache provider?

OK, it still is detected by MAT as a leak: // Use TCCL to avoid heap leak cachingProvider = Caching.getCachingProvider(Thread.currentThread().getContextClassLoader()); One instance of "com.hazelcast.cache.impl.CacheService" loaded by "java.net.URLClassLoader @ 0x807026b8" occupies 28,644,400 (36.

Re: Default webapp deployment

Hi Fabien, The alternative is to define it in conf/context.xml (and put it outside of the managed folder (webapps/ per default) or deactivate the auto deployment of webapps/ on the host. Romain Manni-Bucau @rmannibucau | Blog

Default webapp deployment

Hello, I would like to deploy my webapp so that it is the default one on localhost:8080 (tomEE plus 1.7.4). The solution I found [1] is to: 1) clean $(CATALINA_HOME)/webapps/ROOT/* 2) move $(CATALINA_HOME)/webapps/mywebapp/* to $(CATALINA_HOME)/webapps/ROOT Isn't there a cleaner way to do tha

Re: Heap leak as JCache provider?

OK, I deployed the code with this change. I'll report back once the cache has been beat up a little. On Mon, Jul 25, 2016 at 12:18 PM, Romain Manni-Bucau wrote: > Can you give it a try NOT using getCachingProvider() but > getCachingProvider(Thread.currentThread().getContextClassLoader())? That's

Re: Heap leak as JCache provider?

Can you give it a try NOT using getCachingProvider() but getCachingProvider(Thread.currentThread().getContextClassLoader())? That's the way it should work I think, no arg version will use the API cached classloader which is not deterministic and can potentially leak this way. Romain Manni-Bucau @

Re: Heap leak as JCache provider?

I'm using a distributed configuration, but everything else is pretty much default. It's a WAR deployment using a @Singleton bean. Here's the code snip for that: cachingProvider = Caching.getCachingProvider(); log.debug(String.format("cachingProvider: %s", cachingProvider.

Re: Heap leak as JCache provider?

Hi, depends the hz config I think and if you used the right classloader to create the cache (think hazelcast doesn't use TCCL by default) Romain Manni-Bucau @rmannibucau | Blog | Old Wordpress Blog

Heap leak as JCache provider?

I'm using Hazelcast 3.6.4 as a JCache provider under TomEE 7. Using MAT I see One instance of "com.hazelcast.cache.impl.CacheService" loaded by "java.net.URLClassLoader @ 0x805b5050" occupies 162,660,400 (71.07%) bytes. The memory is accumulated in one instance of "com.hazelcast.cache.impl.CachePar

Re: ActiveMQ Connection Failures (Random to Constant)

Iv'e resolved the issue. It seems that one of clustered machines was getting sync'd to vmware only on shutdown and startup and that time was in the past. I'm not sure why but the ActiveMQ lock actually got set to 6 hours in the future and the lock wasn't being removed on restart either (Root Iss