...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 the StackTraceElement instances and the heap is back to normal. Is there a difference between the normal GC and the GC that is done when a heapdump is made? I guess when making a heapdump, one will ensure that only the instances that are really still into play are shown, so it might be more agressive in any way? But still, there must be something referencing the StackTraceElement / StackTraceelement[] long after the stack trace has happend. We are running a test now, where we are letting the endpoint decribed ealier connect, but responding with a message that fails in the response decoder, to see if we see the same problem. If not there must be something with regards to cxf I guess. /Trond -- View this message in context: http://camel.465427.n5.nabble.com/StackTraceElement-using-heap-tp5745623p5745726.html Sent from the Camel - Users mailing list archive at Nabble.com.
