I have a web service created from a wsdl and have not changed anything, so all I have is an empty application.
After deploying the app, as soon as I click 'stop' (i.e. I have not even called it), I get 'SEVERE' messages from Tomcat and the leak tests reports my app as having multiple instances, and increases every time I stop/start.
I am using CXF 3.1.0 and have even tried downloading the very latest JAXB (reference implementation from website).
The error is as follows:
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(Automati
cWorkQueueImpl.java:353)
java.lang.Thread.run(Thread.java:722)
11-Jun-2015 15:45:33.142 SEVERE [http-nio-8080-exec-2] org.apache.catalina.loade
r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [MyAcces
sAPSServiceN] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassF
actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1#27765bfc]) and a value of t
ype [java.util.WeakHashMap] (value [{class org.apache.cxf.ws.addressing.Attribut
edURIType=java.lang.ref.WeakReference#4b9111a1}]) but failed to remove it when t
he web application was stopped. Threads are going to be renewed over time to try
and avoid a probable memory leak.
11-Jun-2015 15:45:33.143 SEVERE [http-nio-8080-exec-2] org.apache.catalina.loade
r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [MyAcces
sAPSServiceN] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassF
actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1#27765bfc]) and a value of t
ype [java.util.WeakHashMap] (value [{class org.apache.cxf.ws.discovery.wsdl.Hell
oType=java.lang.ref.WeakReference#211c87c9, class javax.xml.ws.wsaddressing.W3CE
ndpointReference$Address=java.lang.ref.WeakReference#5816ae1a, class javax.xml.w
s.wsaddressing.W3CEndpointReference=java.lang.ref.WeakReference#39005a24, class
org.apache.cxf.ws.discovery.wsdl.ScopesType=java.lang.ref.WeakReference#461e0eb8
, class java.util.ArrayList=java.lang.ref.WeakReference#5f5875fe, class javax.xm
l.ws.wsaddressing.W3CEndpointReference$Elements=java.lang.ref.WeakReference#28aa
a799}]) but failed to remove it when the web application was stopped. Threads ar
e going to be renewed over time to try and avoid a probable memory leak.
11-Jun-2015 15:45:33.146 SEVERE [http-nio-8080-exec-2] org.apache.catalina.loade
r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [MyAcces
sAPSServiceN] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassF
actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1#27765bfc]) and a value of t
ype [java.util.WeakHashMap] (value [{class org.apache.cxf.ws.addressing.Attribut
edURIType=java.lang.ref.WeakReference#5be142aa}]) but failed to remove it when t
he web application was stopped. Threads are going to be renewed over time to try
and avoid a probable memory leak.
11-Jun-2015 15:45:33.148 SEVERE [http-nio-8080-exec-2] org.apache.catalina.loade
r.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [MyAcces
sAPSServiceN] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassF
actory$1] (value [com.sun.xml.bind.v2.ClassFactory$1#27765bfc]) and a value of t
ype [java.util.WeakHashMap] (value [{class javax.xml.ws.wsaddressing.W3CEndpoint
Reference$Address=java.lang.ref.WeakReference#21dfd606, class javax.xml.ws.wsadd
ressing.W3CEndpointReference=java.lang.ref.WeakReference#6e5c3549, class org.apa
che.cxf.ws.discovery.wsdl.ScopesType=java.lang.ref.WeakReference#67ae8439, class
java.util.ArrayList=java.lang.ref.WeakReference#726aef5c, class org.apache.cxf.
ws.discovery.wsdl.ByeType=java.lang.ref.WeakReference#4a88bbb3, class javax.xml.
ws.wsaddressing.W3CEndpointReference$Elements=java.lang.ref.WeakReference#56db0a
ff}]) but failed to remove it when the web application was stopped. Threads are
going to be renewed over time to try and avoid a probable memory leak.
This seems to be a known limitation of the JAXB API. Issue claims you can avoid the problem by explicitly closing the Unmarshaller, but I haven't tried that myself.
Related
We are using apache ignite for one of our caching solution,It is perfectly working fine.But while stopping the web container lots of error related to removal of ignite Thread Local is displaying the server log.Since we are not creating any ThreadLocal in our application,how can i remove those Thread local when stopping the server. Some of the errors are mentioned below.
SEVERE: The web application [/webapp-name] created a ThreadLocal with key of type [org.apache.ignite.internal.binary.BinaryThreadLocalContext$1] (value [org.apache.ignite.internal.binary.BinaryThreadLocalContext$1#5826d221]) and a value of type [org.apache.ignite.internal.binary.BinaryThreadLocalContext] (value [org.apache.ignite.internal.binary.BinaryThreadLocalContext#47a32716]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Apr 08, 2021 10:39:34 AM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks
SEVERE: The web application [/webapp-name] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal#63b81d02]) and a value of type [org.apache.ignite.internal.marshaller.optimized.OptimizedObjectStreamRegistry.StreamHolder] (value [org.apache.ignite.internal.marshaller.optimized.OptimizedObjectStreamRegistry$StreamHolder#58474af2]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Apr 08, 2021 10:39:34 AM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks
SEVERE: The web application [/webapp-name] created a ThreadLocal with key of type [java.lang.ThreadLocal.SuppliedThreadLocal] (value [java.lang.ThreadLocal$SuppliedThreadLocal#67782fee]) and a value of type [org.apache.ignite.internal.binary.BinaryContextHolder] (value [org.apache.ignite.internal.binary.BinaryContextHolder#482bfe01]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
I am using Websphere 8.5.5 and I've noted that my first call to a JAX-WS Web Services takes too long to respond. I get this in the LOG (trace level) and after 15 mins it works. I have EclipseLink MOXy as a JAXB provider
jaxb.properties:
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
javax.xml.bind.JAXBException:
Exception Description: Name collision. Two classes have the XML type with uri http://www.w3.org/2001/XMLSchema and name string.
- with linked exception:
[Exception [EclipseLink-50007] (Eclipse Persistence Services - 2.4.2.qualifier): org.eclipse.persistence.exceptions.JAXBException
Exception Description: Name collision. Two classes have the XML type with uri http://www.w3.org/2001/XMLSchema and name string.]
Well, after a lot of research I've found that it seems to be a bug of Websphere because it adds some array classes to the JAXB Context for example (byte[], int[], String[]) the problem is that when it adds String[] to the list of classes for the JAXB Context MOXy can't handle and gives that error.
The good news is that it can be solved by adding a custom property into the "Generic JVM arguments" since Websphere >= 8.5.5.2
Servers > Server Types > WebSphere application servers > server_name >
Java and Process Management > Process definition > Java Virtual
Machine >Generic JVM arguments
-Dcom.ibm.websphere.webservices.jaxwsOptimizeLevelOne=true
In the following resources it doesn't say it does that but after checking JAXBContext creation in EclipseLink you can see that it doesn't send anymore those array classes thus solving the problem.
More information on this:
https://publib.boulder.ibm.com/httpserv/cookbook/WebSphere_Application_Server-WAS_Classic-Web_Services.html
http://www-01.ibm.com/support/docview.wss?uid=swg1PI14203
Log trace to detect how much time it takes to create JAXBContext on Websphere can be activated specifying this log level:
com.ibm.ws.websvcs.JAXBContextTrace=all
[7/7/16 16:34:28:908 CDT] 00000089 JAXBContextTr 3
org.apache.axis2.jaxws.message.databinding.JAXBUtils getJAXBContext
new JAXBContext constructed, elapsed time msec: 1035
I am using Castle Windsor DI container in my WCF app server. In this case the lifetime is per-request: a new service instance is created, container is created and installed, some components are resolved, come work is done and all is disposed.
However, after some amount of requests there is increasing memory consumption of my app server. I was able to find out when I comment out the DI usage the memory problems disappear. But when I install the container and resolve some component, there are some "memory leaks".
I found some articles and posts talking about lifecycles. But all of them are bound to container instance. Since my container lives just during the request there must be everything destroyed when disposing it.
My service implements IDisposable and in the Dispose method I call the container.Dispose as well. However memory usage grows on and on.
Using dotMemory profiler I can see there are survivors and new instances of ProxyGenerationOptions and some other classes.
Am I missing something? Why the container is not releasing all used memory after Dispose is called?
I had a similar problem
I solved it, when I created the proxy class, I served the ModuleScope object
public static class ProxyFactory
{
private static ModuleScope _moduleScope = new ModuleScope(false, false);
public static TClass CreateProxy<TClass>(TClass instance)
{
ProxyGenerator proxy = new ProxyGenerator(new DefaultProxyBuilder(_moduleScope));
List<Type> interfaces = new List<Type>();
interfaces.AddRange(instance.GetType().GetInterfaces());
TClass result = proxy.CreateClassProxyWithTarget(
instance.GetType(),
interfaces.ToArray(),
instance, ......
}
}
Hello currently I am developing an Arquillian extension for Moco framework (https://github.com/dreamhead/moco). Moco is used for testing RESTful services and relies on Netty for dealing with communication. Currently Moco is using Netty 4.0.18.Final.
But I have found a problem when running Moco (and Netty server) inside a container (Arquillian runs tests within the container) and is that it starts correctly but when the application is undeployed and server is shutdown next log error messages are printed:
SEVERE: The web application [/ba32e781-3a18-44b3-9547-7c26787f3fe7] appears to have started a thread named [pool-2-thread-1] but has failed to stop it. This is very likely to create a memory leak.
abr 08, 2014 10:29:06 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/ba32e781-3a18-44b3-9547-7c26787f3fe7] created a ThreadLocal with key of type [io.netty.util.internal.ThreadLocalRandom$2] (value [io.netty.util.internal.ThreadLocalRandom$2#77468cae]) and a value of type [io.netty.util.internal.ThreadLocalRandom] (value [io.netty.util.internal.ThreadLocalRandom#6cd3851]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
Basically it seems that there are some threads that are not closed yet when the server tries to shutdown.
From the point of view of Arquillian extension when the application is deployed into the server the start method of Moco is called and before undeploying the application the stop method from Moco is called.
But let me show you the code of Moco:
public int start(final int port, ChannelHandler pipelineFactory) {
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.childHandler(pipelineFactory);
try {
future = bootstrap.bind(port).sync();
SocketAddress socketAddress = future.channel().localAddress();
address = (InetSocketAddress) socketAddress;
return address.getPort();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
and the stop method looks like:
private void doStop() {
if (future != null) {
future.channel().close().syncUninterruptibly();
future = null;
}
So it seems that the close method returns before killing all the threads and for this reason containers warns you about possible memory leaks.
Because I have never used Netty I was wondering if there is a way to ensure that the whole Netty runtime is closed.
Thank you so much for your help.
I am new to Netty as well (and unfamiliar with Arquillian), but based on the Netty Docs examples I believe you might not be shutting down the EventLoopGroups you created (bossGroup, workerGroup). From the Netty 4.0 User Guide:
Shutting down a Netty application is usually as simple as shutting down all EventLoopGroups you created via shutdownGracefully(). It returns a Future that notifies you when the EventLoopGroup has been terminated completely and all Channels that belong to the group have been closed.
So your doStop() method might look like:
private void doStop() {
workerGroup.shutdownGracefully();
bossGroup.shutdownGracefully();
}
An example in the Netty docs: Http Static File Server Example
I have a class (ZogCheckPublisher) that implements the multithreaded singleton pattern. This class is used within the exposed method (PrintZogChecks) of a WCF service that is hosted by a Windows Service.
public class ProcessKicker : IProcessKicker
{
public void PrintZogChecks(ZogCheckType checkType)
{
ZogCheckPublisher.Instance.ProcessCheckOrCoupon(checkType);
}
}
ZogCheckPublisher keeps track of which 'checkType' is currently in the process of being printed, and rejects requests that duplicate a currently active print request. I am trying to understand ServiceBehaviors and the appropriate behavior to use. I think that this is appropriate:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]
One instance of the service that is multithreaded. If I am understanding things rightly?
Your understanding is correct.
The service behavior will implement a single multithreaded instance of the service.
[ServiceBehaviorAttribute(Name = "Test", InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple]
In a singleton service the configured concurrency mode alone governs the concurrent execution of pending calls. Therefore, if the service instance is configured with ConcurrencyMode.Multiple, concurrent processing of calls from the same client is allowed. Calls will be executed by the service instance as fast as they come off the channel (up to the throttle limit). Of course, as is always the case with a stateful unsynchronized service instance, you must synchronize access to the service instance or risk state corruption.
The following links provide additional Concurrency Management guidance:
Multithreaded Singleton WCF Service
http://msdn.microsoft.com/en-us/library/orm-9780596521301-02-08.aspx
Regards,