You are totally correct, sorry about that. I actually find the JMS API a tad convoluted. Since I do actually change the delivery mode per message in my library, I knew it was possible, and was like "ah, there it is" when I found that setter on the message.
When changing to using 'producer.send(msg, deliveryMode, pri, ttl)', that "further finding" disappears! Great. The original and main point still seems to stand though. If you want me to send that to the user list then I'll do that. I've updated the repo. Each test is time for sending and in case of 'Transactional', committing, [1000] messages no store, non-Transactional, non-Persistent: [4.36516976] ms no store, non-Transactional, Persistent: [27.665534] ms no store, Transactional, non-Persistent: [29.056998] ms no store, Transactional, Persistent: [30.520276] ms ALWAYS, non-Transactional, non-Persistent: [4.41806886] ms <-- (This is great, avoiding the hit.) ALWAYS, non-Transactional, Persistent: [4107.414315] ms ALWAYS, Transactional, non-Persistent: [4118.322262] ms <-- This one is unfortunate! ALWAYS, Transactional, Persistent: [4143.173852] ms PERIODIC, non-Transactional, non-Persistent: [4.453423] ms PERIODIC, non-Transactional, Persistent: [58.694872] ms PERIODIC, Transactional, non-Persistent: [28.286106] ms PERIODIC, Transactional, Persistent: [64.690608] ms On Tue, Feb 1, 2022 at 7:22 PM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > You should post such things to the users list. > > Your further finding is not as interesting as it may first seem, it > makes an invalid assumption that you get 'semantically exactly the > same messages sent' by using the jmsMessage.setJMSDeliveryMode(..) > method, which JMS defines that you do not. This method (and several > others like it) is specifically not meant for application usage and > actually shouldnt have any influence on what happens during send. It > is only for use by a JMS implementation itself to stamp the actual > details for observation after send returns, and exist to allow for the > case when it is operating on message objects created by another JMS > implementation. Only the producer's own setting or its send method > override argument has influence on the deliveryMode when sending. > > > https://docs.oracle.com/javaee/7/api/javax/jms/Message.html#setJMSDeliveryMode-int- > > setJMSDeliveryMode(int deliveryMode) > Sets the DeliveryMode value for this message. > > This method is for use by JMS providers only to set this field when a > message is sent. This message cannot be used by clients to configure > the delivery mode of the message. This method is public to allow a JMS > provider to set this field when sending a message whose implementation > is not its own. > > > On Sat, 29 Jan 2022 at 14:20, Endre Stølsvik <en...@stolsvik.com> wrote: > > > > Further interesting finding: > > Only the jmsProducer.setDeliveryMode(..) have any effect on the timing: > If > > employing the jmsMessage.setJMSDeliveryMode(..) method to get > semantically > > exactly the same messages sent with same DeliveryMode (that is, > PERSISTENT > > vs. NON_PERSISTENT), you lose out on those blazing fast > "non-Transactional, > > non-Persistent" timings. > > > > Each test is time for sending and in case of 'Transactional', committing, > > [1000] messages > > no store, non-Transactional, non-Persistent: [32.237903] ms <- This > is > > no longer superfast > > no store, non-Transactional, Persistent: [27.756596] ms > > no store, Transactional, non-Persistent: [37.082023] ms > > no store, Transactional, Persistent: [35.110782] ms > > ALWAYS, non-Transactional, non-Persistent: [4108.457421] ms <- ... > and > > neither this > > ALWAYS, non-Transactional, Persistent: [4102.393857] ms > > ALWAYS, Transactional, non-Persistent: [3954.603762] ms > > ALWAYS, Transactional, Persistent: [3978.435732] ms > > PERIODIC, non-Transactional, non-Persistent: [58.224914] ms <- .. nor > > this > > PERIODIC, non-Transactional, Persistent: [81.982655] ms > > PERIODIC, Transactional, non-Persistent: [67.837032] ms > > PERIODIC, Transactional, Persistent: [58.78441] ms > > > > On Sat, Jan 29, 2022 at 4:26 AM Endre Stølsvik <en...@stolsvik.com> > wrote: > > > > > Hi! > > > > > > I observed a performance/timing situation that I found a bit > surprising, > > > and made a little test for it. You may find that here: > > > https://github.com/stolsvik/activemq_perf_issue > > > > > > When running ActiveMQ with default config, it uses KahaDB as backend > with > > > JournalDiskSyncStrategy.ALWAYS which flushes to disk after every > > > operation. This is to live up to the JMS promises of persistent > messaging > > > where operations should actually have been stored to disk when e.g. > > > producer.send() or session.commit() returns. > > > > > > This constant flushing gives a very heavy performance impact, and one > > > should really consider the pros and cons of using PERIODIC instead. > > > > > > However, I was a bit surprised by an observation: If you run the JMS > > > Session in Transactional mode, but also do > > > producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT), one might > believe > > > that there wouldn't be a need to flush the disk, as one has > specifically > > > told the system that "this doesn't really matter". However, the > performance > > > impact from "Transactional, non-Persistent" is just as heavy as with > > > non-Transactional+Persistent and Transactional+Persistent. > > > > > > With non-Transactional + non-Persistent, even with > > > JournalDiskSyncStrategy.ALWAYS, the speed is blazing. > > > > > > One might argue, well don't use Transactional then. But Transactional > also > > > brings another feature, whereby you may receive a message, and send a > > > message, and have these two operations inside a transactional boundary. > > > This aspect of Transactional is valuable even if though the messages > are > > > non-Persistent. And the broker evidently handles this logic already > even > > > without persistence, since if you say > BrokerService.setPersistent(false) > > > and thus turn off the entire storage of the broker, it still handles > this > > > aspect of Transactional messaging. > > > > > > It would have been valuable to be able to "selectively" turn off this > > > pretty massive hit of flushing to disk if the messages inside the > > > Transaction was non-Persistent. > > > > > > Note: The Java class in this repo uses an in-vm broker, with the > "vm://" > > > connection. However, this situation was first observed with a remote > > > broker, so the effects of interest are the same over TCP or over VM. > > > > > > Each test is time for sending and in case of 'Transactional', > committing, [1000] messages > > > > > > no store, non-Transactional, non-Persistent: [4.26321216] ms > > > no store, non-Transactional, Persistent: [26.784713] ms > > > no store, Transactional, non-Persistent: [32.404009] ms > > > no store, Transactional, Persistent: [46.314925] ms > > > ALWAYS, non-Transactional, non-Persistent: [3.9833712400000003] ms > > > ALWAYS, non-Transactional, Persistent: [4235.887625] ms > > > ALWAYS, Transactional, non-Persistent: [4040.549101] ms <-- This > one is unfortunate! > > > ALWAYS, Transactional, Persistent: [3902.525469] ms > > > PERIODIC, non-Transactional, non-Persistent: [3.85038125] ms > > > PERIODIC, non-Transactional, Persistent: [78.012904] ms > > > PERIODIC, Transactional, non-Persistent: [39.030052] ms > > > PERIODIC, Transactional, Persistent: [94.339609] ms > > > > > > > > > >
