that's fair... Panic is over.. when I first read your message I thought you had completely changed semantics.. and it's not that deep.
On Wed, May 10, 2017 at 4:08 PM, nigro_franz <[email protected]> wrote: > Hi Clebert! > > Before reverting anything I think could be good to perform some tests to be > sure of regressions, AFAIK the are only performance improving, but the final > word I think will go to proper load tests. > > Instead, I've already done sanity tests trying to push IOPS over the limits > with the 2 TimedBuffer implementations (old and new one) and both suffer > from the same issue, simply in different ways, but TBH, as I've said before, > is not a big issue: it's more a possible chance of improvement from what we > have now. > > The test I'm talking is in this branch (using the original TimedBuffer): > https://github.com/franz1981/activemq-artemis/tree/timed_buffer_iops_test > Is the shouldNotFlushUntilTimeout test > <https://github.com/franz1981/activemq-artemis/blob/12c34475f16a73d669c3307999e6fa03601c6cb3/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/core/journal/impl/TimedBufferTest.java#L137-L137> > , but I can build another couples of tests that do something similar and > producing the same effect. > > What the test verify is straightforward: a TimedBuffer can't accept 2 > flushes to happen before the timeout expiration, because this would force a > disk to perform too many IOPS than expected...and the test fails for both > the TimedBuffer. > > As I've said I propose to wait proper load tests before reverting it, > considering that the test shows that the original version was suffering the > same issue. > What do you think? > > Franz > > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-IOPS-Limiter-strategy-tp4725875p4725924.html > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Clebert Suconic
