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 server.
The problem occures when there is a connection exception in an outbound
endpoint. I have a retry each second, and when this continues for several
days, the hea
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.
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
...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
Are there any progress on this issue. I see that there hasn't been mutch
activity on the CAMEL-5963 issue.
This must be something that is crucial for many camel users using smpp?
Are there any possible workarrounds to support smpp TRX with camel? Any
other components that can serve as the smpp TRX
