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.
