Just an FYI to my question below. I went back and examined my camel endpoint configuration for JMS versus my raw DMLC configuration for non camel JMS endpoints. The one major difference was the cache setting.
When I added this to the jmsconfig, the OOM problems on the activemq broker went away: <property name="cacheLevelName" value="CACHE_CONSUMER"/> chudak wrote > > Did you ever solve this problem? > > I've been using atomikos, spring DMLC and activemq for several years. > Recently I started using camel and we are having this exact same problem. > With the camel endpoints polling (which effectively doubled the number of > message listener containers I previously had) empty queues I am having > this same problem where after 12 or so hours the activemq heap blows up (I > have mine set at 512MB) and then activemq starts throwing errors and my > application crashes and cannot recover (cannot reconnect to the activemq > broker). > > > > James Black wrote >> >> Hi >> >> ok the problems seems to be that the connection is getting dropped by the >> ActiveMQ broker on the server. >> >> I have now verified that the issue occurs when ActiveMQ runs out of heap >> available. >> >> I have ran two specific tests. >> >> Note: Although these tests do not allocate that much heap to AMQ we have >> seen these issues with much more heap available and believe they would >> occur eventually no matter how much heap was allocated. >> >> === Test 1 === >> >> Connected our client Tomcat applications to the broker and left them >> running overnight. >> >> I configured the AMQ instance to have only 90MB of heap available to >> speed up the process. >> With nothing at all occurring on the queues and single topic, the >> ActiveMQ installation ran out of heap memory after two hours. >> >> Again there is nothing on the queues or topic during this time. >> >> All that is happening is that the Spring DMLC are polling for new >> messages. >> >> This then caused the JMS errors related to Atomikos in the application >> logs. >> >> You can see the GC trying desperately to reclaim memory as the limit is >> approached but you can also see a gradual decrease in the amount of >> memory that can be GC'ed as time progresses. >> >> === Test 2 === >> >> Connected out Tomcat client applications to the broker and ran tests that >> pass hundreds of messages per second through the channels. >> >> Again with a setting of 90MB of heap available to ActiveMQ after a period >> of 30 minutes AMQ ran out of memory and we could see that GC was making >> no difference. I.e. as in test 1 the memory that could be reclaimed with >> GC was decreasing as time went on. >> >> We are using persistent storage for our queue and single topic. >> Our topic is also durable. >> >> There is very little in the AMQ server logs, occasionally the Out of >> memory error will be logged and the disconnection when the heap runs out >> can be seen. >> >> Has anyone seen similar behaviour or have any suggestions as to where to >> go next? >> >> I have application snapshots (VisualVM) of this issue occurring in test >> 1. >> >> Thanks to Gary Tully for his help and suggestions previously :> >> >> Thanks, >> >> James >> > -- View this message in context: http://activemq.2283324.n4.nabble.com/Transaction-not-started-XA-problems-tp3565540p4345014.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
