...update
If we stop sending messages through the cxf endpoint, the heap growth is
stopped, but it never decreases tp the "normal" level again, leaving a lot
of StackTraceElement instances left in the heap.
Funny thing is that when we do a heapdump from jvisualvm the garbage
collection removes t
Hi.
doing a heap dump with 20 minutes time between shows me that instances of
these classes are increasing:
org.apache.cxf.common.i18n.Message
org.apache.cxf.interceptor.Fault
org.apache.cxf.jaxws.context.WrappedMessageContext
The other classes that are increasing are mainly standard java classe
On Mon, Jan 6, 2014 at 4:11 PM, tkvarenes wrote:
> Hi,
>
> I use camel 2.11.1
>
> It's not that the stack traces elements are any longer than usual, but I
> would expect them not to be referenced any more so the GC could remove them,
> but to me it seems like something is still holding a refence t
Hi,
I use camel 2.11.1
It's not that the stack traces elements are any longer than usual, but I
would expect them not to be referenced any more so the GC could remove them,
but to me it seems like something is still holding a refence to them since
they show up on the heap dump.
I get a lot of t
Hi
What Camel version do you use?
And do you have some more details about those long stacktrace elements?
On Mon, Jan 6, 2014 at 1:07 PM, tkvarenes wrote:
> Hi.
>
> I have an application using Camel that seems to over time builds up heap
> space until it starts using 100%CPU time on a windows
