Can you share the results of the testing? I’m having a hard time tracking how adding the transaction does not incur latency.
> On Sep 14, 2022, at 2:03 PM, Nikita Shupletsov <nshup...@amazon.com.INVALID> > wrote: > > Yeah, I agree that there is some overhead because of transactions. but our > tests didn't show any significant impact on the performance. > > We use JMS transactions, not XA, so there is no transaction prepare > operations. From my understanding nothing gets written to disk for > non-persistent messages regardless the transaction they are in. > > And our tests also didn't show any issues with non-persistent messages. > > On 9/13/22 18:31, Étienne Hossack wrote: >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> An issue one could possible see with adding transactions is the memory and >> speed overhead. >> >> Have you tested this with very large messages or high throughput? What's the >> impact there? >> I would expect that because the transaction "prepare"s MUST be written to >> disk, it would limit the modes in which this could be run (not that it >> really would make sense to enable replication for a broker with in-memory >> only messages), but you couldn't for example have delayed paging right?. >> >> -- >> Étienne >> >> On Tue, 13 Sep 2022, at 4:55 PM, Nikita Shupletsov wrote: >>> Greetings. >>> >>> It's a gentle reminder of the change I have been working on - an >>> Asynchronous Replication plugin for ActiveMQ “Classic” >>> https://issues.apache.org/jira/browse/AMQ-8354. >>> The latest changes can be found here: >>> https://github.com/apache/activemq/pull/848. I would really appreciate >>> comments and feedback. >>> >>> We started wrapping the original message and the corresponding >>> replication message in a transaction(if the original message already has >>> a transaction, we will add the replication message to the same >>> transaction. If not, we will create a new one). The idea behind is to >>> make both writes atomic so that we can preserve consistency. >>> I would be glad to get any opinion on that. >>> >>> We are still in the phase of active development and bug fixing, so any >>> input is welcome! >>> >>> On 6/10/22 17:15, Nikita Shupletsov wrote: >>>> Greetings. >>>> >>>> My name is Nikita Shupletsov. I am a software development engineer at >>>> Amazon MQ. >>>> >>>> I have been working on an Asynchronous Replication plugin for ActiveMQ >>>> “Classic” that was proposed by Étienne Hossack last year: >>>> https://issues.apache.org/jira/browse/AMQ-8354. Étienne published a >>>> high level design document >>>> (https://github.com/ehossack-aws/activemq-replication-design/tree/initial-design) >>>> though I’m not sure if many of you would have reviewed it or provided >>>> feedback. >>>> >>>> I have published my latest changes >>>> here:https://github.com/amazon-mq/upstreaming-activemq/pull/1 and >>>> would appreciate comments and feedback from anyone. >>>> >>>> To be perfectly clear, this repository is only going to be used for >>>> working on changes that we (Amazon MQ) plan to submit upstream to the >>>> Apache ActiveMQ community. We are not planning to maintain a fork of >>>> ActiveMQ - the purpose is solely to upstream changes. >>>> >>>> Currently the plugin supports: >>>> >>>> * create/delete destinations >>>> * send message to queues and topics(except temporary destinations >>>> and advisory topics) >>>> * durable subscribers >>>> * message acknowledge for queues and topic durable subscribers >>>> * transactions and XA transaction >>>> >>>> We are still working on the infrastructure part of the story such as: >>>> >>>> * error handling and message retries >>>> * JMX metrics to monitor the health of the replication >>>> * the plugin structure >>>> * testing, looking for missed functionality and bugs >>>> >>>> >>>> We are still in the phase of active development, so any early input is >>>> welcome!
