gemmellr commented on PR #4232:
URL: 
https://github.com/apache/activemq-artemis/pull/4232#issuecomment-1257819408

   This seems off, we should essentially never be looking to throw an *extra 20 
seconds* of sleeps at a single test, especially not such a trivial looking one 
which already looks to burn a ridiculous amount of time as it is. This is 
precisely the kind of stuff that makes test suites take so long that folks then 
dont want to / 'cant' run them.
   
   There is very likely a different set of changes that can be made to 
accomplish improving the test reliability as desired, without always throwing 
away a ridiculous amount of time in advance for what is ultimately a pretty 
basic check.
   
   The precise failure modes you see arent mentioned, but taking for example 
addition of 10 seconds sleep before starting the test, presumably that means 
broker startup is async and the initial connections are failing occasionally 
for you? So a couple of alternative options would seem to be to either have the 
test wait for startup to complete before the use of each server (there even 
looks to be a method for checking that, which isnt being used by the test), or 
to have it make the connection factories it creates use a failover URL with 
some startup reconnect allowance so the factory can handle the server not being 
ready in the cases it isnt. Either approach would be seem likely to be quicker 
than just _always_ wasting 10 seconds sleeping before the test begins. 
Especially so in cases where it is currently working without any sleep.
   
   For the other changes, im guessing one of the consumers failed to get a 
message within the allotted 1sec receive timeout? Since those bits fully expect 
to receive a message and fail at the first point they dont, a different change 
is probably just increasing the receive() timeout to something more 
accommodating like 3 seconds. That way extra time is afforded _if needed_, 
during the operation expected to succeed, but is not simply _always_ thrown 
away in advance even when it isnt.


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to