[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-543381734 No further comments from me atm other bits and bobs can always be added later in future prs /version and refined over time. Thanks for this @jbertram was prob the last big ticket for artemis to be in feature parity with activemq5. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-542081191 I mean running this a little more than just an integration test. E.g. actually deploying to a real environment and do bits like failover, outage, client disconnects This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-541822492 So im getting odd behaviour after restarts. Trying to work out what is going on. Have you done much destructive testing on this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-540423943 @jbertram im busy this week with some priority bits at work, thus also not had time tonrespin the amqp nms release. Im hoping to get time next week to look at this again This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-538579769 @jbertram tbh im struggling to understand still the issue, if an address is paging to disk, ring queue still gets new messages delivered. on address-settings front thanks, that seems to make things work for custom wildcards. When i have a large retro-active queue, and a new consumer joins, and that consumer may take 5 minutes to process those messages, im seeing some nasty GC spikes at the initial few seconds, from debugging that seems to be when the messages are copied back to route to original address and the new queue, as the broker goes as fast as it can regardless of the consumer speed. This kind of behaviour could destabilise the broker. Ideas to solve or limit this issue: 1) is there a way to control the copy over so its not done as one big bang (e.g. as fast as broker can possible do), but feed the new queue at the rate the consumer is consuming there for avoiding the very big spike in object creation. 2) Is it possible to make it so that we dont have to copy, but it simply is a message ref? 3) If 2 is not possible because a separate address, could we have a toggle that will deploy under the original address and when deployed like such a copy isnt needed and simply message ref is added to the queue, so then its a choice for end users. this then gives a kind of flexibility depending on end user case, with trade off for either, but at least then its up for the end user. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-536763958 It def shouldnt break if paging occurs. One of the bits myself and clebert have discussed once a time ago. Was the idea that you could have an address paging by default to achive this feature. And then could even have retro active for several days. Should you need replay etc. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-535292298 This feature would be more powerful if support for a timebased or bytes size retention, e.g. retro active for last hour etc. I realise that this may not be possible on this initial feature pr but this should impact the way we think about how we design the configuration so its most flexible for future expansion once the abilty for a queue to be ringqueue by byte size or time. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-535288242 On the retroactive queue, would want a flag to tell us its a retro queue, thats then exposed to jmx so that metrics systems can get the tag, and so alerting rules on queue depths can ignore these queues automatically based on that flag. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis] michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses
michaelandrepearce commented on issue #2850: ARTEMIS-2504 implement retroactive addresses URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-535272144 A few bits as havent fully explored the feature just yet. How does someone control if the retroactive address will behave when full, e.g. page, block, drop? How or where can someone configure the naming of a retroactive address so they can control their names to avoid conflict or for security settings. For a specific address it would be good to be able to configure the retroactive queue fully, eg at the address level define a queue (like we can others) and then specify the queue to use. E.g. for cases where retroactive you may want LVQ behaviour. For queues created for retroactive, if there is a very high number of message groups and someone is using buckets so that the group map doesnt explode in size, how is this being avoided in the retroactive queue? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
