[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 I have moved this into 2.6.x but I had to manually make the changes.. can you check 2.6.x please? ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 just one nit-pick.. this test should be on QueueImplTest, away from timing... (integration-tests) can you move it? ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 can you rebase here? what to do with this? ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @clebertsuconic Ok, let me try with the examples too... ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 please watch the examples. On my private CI an example failed on your branch. ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @michaelandrepearce there are no changes around the journal... We already have a profile that will ignore a lot of tests.. and anyone running the full testsuite would still be able to capture regressions. I will take a look on the failures, but if this is indeed environmental we should move them to the ignore-list on the -Pfast-tests ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @clebertsuconic before i went on holiday it didnt seem to error as much as it is now, i wonder if some recent merge has destabilized the build? I would worry about ignoring it, as its a concurrency test so it maybe actually highlighting an issue thats been introduced by some recent change / merge. Has there been any changes around the journals? ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 so are you adding a test? ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @michaelandrepearce would be too much of a hack to add a -Ptravis profile and add a property to ignore those tests? Those tests run at least daily on my CI and they never fail. ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @michaelandrepearce ahah fine! > btw how you get a clean PR build ? without the damn MultiThreadAsynchronousFileTest failing...like it has been for most PR's recently? That's a nice question indeed...it isn't an intermittent failures? Probably I've been lucky...or unlucky depends on the point of views :P ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 once you do fix for this with test and this is merged, ill fix exclusive quickly, as then i can just rip your hard work :P :P :P ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 > exclusive yes i think would have similar issue, after all it followed the same logic of message groups in part. It would be easy to fix, as in the same place / if statement just check for the exclusive flag. Nice, I suppose that would be better to raise a different issue/PR for that even if I'm tempted to do it fro this one: it is indeed fixing a similar but different issue. I'm anyway opened to do it differently too :+1: > what if all consumers are busy and a message group isnt assigned? it would still spin i assume. I the message group isn't assigned it will use round robin between the consumers until noDeliver == size: in that case it will stop spinning without burning any CPU, because deliverAsync won't be called anymore. ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 i exclusive yes i think would have similar issue, after all it followed the same logic of message groups in part. ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @franz1981 make a test that will exercise the loop. Try to get a synchronize on Queue... if the test hangs.. it's a bug... use a timeout tag on the test. ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 I have already run the entire test suite that is already filled of AMQP and CORE JMS message group tests AFAIK. About the performance implications (not anymore 100% CPU) I don't know what could I write to validate it with a test... ---
[GitHub] activemq-artemis issue #2203: ARTEMIS-1999 Broker uses 100% core's CPU time ...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2203 @clebertsuconic Please take a look if the change seems to break any other logic and @michaelandrepearce if exclusive consumers should be affected by a similar issue (IMO it shouldn't be the case) ---
