Thanks for explaining your use-case a bit more. That helps. In my opinion the key statement here is that Artemis isn't working in a vacuum - it actually plays quite a small role in a much larger application. Your overall use-case involves low message volume and low latency requirements.
Can you elaborate any more on what specifically the JMS related code is doing? For example, are you using transactions? What connection factory are you using? Are your clients local or remote or both? How many clients do you have and what kind are they (e.g. producer or consumer)? The more information you can provide the more likely it is we will be able to help. Personally I think comparing Artemis to JBoss Messaging is not terribly useful. We're talking about implementation level details here as they are related to GC. We're not going to move back to JBoss Messaging's architecture and we're not going to drop Netty so let's focus on things we might actually be able to change. It may be that your client code can be optimized or written differently to take advantage of how Artemis is implemented or it may be that you need to tune the GC differently. We can't help much without more data about your use-case, application, environment, etc. Performance related issues like this are typically the most difficult to work through, especially on a mailing list. If you could provide an actual test demonstrating a problem that would be ideal. Justin ----- Original Message ----- From: "jim_b_o" <ja...@inaseq.com> To: dev@activemq.apache.org Sent: Thursday, February 4, 2016 12:17:35 PM Subject: Re: Artemis use of PhantomReference impacting GC performance I think the memory comparison is fair in this case. The main application load is events received via a ResourceAdapter passed to POJOs which process and return responses via the same ResourceAdapter. There is no Web component and EJBs are only for admin functions and not being invoked during these tests. The JMS is an outbound feed of a small subset of the processed events. So the only container code under test is the JMS and a small part of the ResourceAdapter glue although most of that is done using Spring and is the same in both containers. The POJOs and ResourceAdapter are identical in both systems. This does impact application performance. I don't doubt that Artemis can handle more messages and do so faster than the old messaging but it is not operating in a vacuum. The JMS performance is not a critical aspect of this system. The critical aspect is how quickly and reliably the POJOs can receive/process/respond via the ResourceAdapter. These longer stop-the-world GCs that appear to be due to the JMS cause hick-ups in that processing. The JMS is doubling the GC pause time. I'll run another test to confirm if the excess PhantomReferences are from Netty or XNIO. I'm currently connecting the JMS and EJB client simultaneously so I'll separate them. -- View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-use-of-PhantomReference-impacting-GC-performance-tp4706961p4706976.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
