Re: Unreliable checks in tests for string presence in GridStringLogger contents

Hi, Sergey! Your note sounds convincing. +1 for adding throwing version of {{check}}. Best regards, Andrey Kuznetsov. вт, 29 янв. 2019, 19:14 Sergey macrerg...@gmail.com: > Hi! > I appreciate your efforts in replcacing GridStringLogger, just a remark. > I think it was a mistake to change check(

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Hi! I appreciate your efforts in replcacing GridStringLogger, just a remark. I think it was a mistake to change check() to boolean. I supppose method should have not be changed, but added as both methods are useful. Now we've lost error description messages existed in previous implementation. I m

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Thanks for comments, I have filed a ticket [1] and will implement it if you don't mind. 1. https://issues.apache.org/jira/browse/IGNITE-10023 пт, 26 окт. 2018 г. в 15:56, Dmitrii Ryabov : > > > waitForCondition(lsnr::check, timeout); > Agree, it is more convenient to use. > пт, 26 окт. 2018 г. в

Re: Unreliable checks in tests for string presence in GridStringLogger contents

> waitForCondition(lsnr::check, timeout); Agree, it is more convenient to use. пт, 26 окт. 2018 г. в 13:01, Pavel Pereslegin : > > Nikita, > personally, I don’t like that "check()" throws an AssertionError, but in > the case of a composite listener, it will indicate which of the conditions > did no

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Nikita, personally, I don’t like that "check()" throws an AssertionError, but in the case of a composite listener, it will indicate which of the conditions did not work. Btw, your case can be solved with custom listener, but I think it's good improvement, let's do it. чт, 25 окт. 2018 г. в 21:31,

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Nikita, I like your suggestion. It looks more expressive for me than existing throwing version. чт, 25 окт. 2018 г. в 21:07, Nikita Amelchev : > Hi, Igniters. > > I suggest improving new listening test logger. > > I found usage case when needs wait for conditions for test duration > optimization

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Hi, Igniters. I suggest improving new listening test logger. I found usage case when needs wait for conditions for test duration optimization. For example, that messages A and B will be logged. For now, LogListener.check() doesn't return checking result as boolean. It throws the exception if con

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Thanks, Vyacheslav. Created the issue [1] based on your idea. [1] https://issues.apache.org/jira/browse/IGNITE-8570 2018-05-23 12:41 GMT+03:00 Vyacheslav Daradur : > Hi, Andrey, I have faced this problem too. > > I'd suggest introducing new logger for tests instead of extending API > of *Grid

Re: Unreliable checks in tests for string presence in GridStringLogger contents

Hi, Andrey, I have faced this problem too. I'd suggest introducing new logger for tests instead of extending API of *GridStringLogger*. The new logger should be some kind of *listened*, for example with the folowing API: void addListener(String pattern, CountDownLatch latch); void addListener(Ig

Unreliable checks in tests for string presence in GridStringLogger contents

Folks, While testing my PR on TeamCity I found a floating test failure. Sometimes we use {{GridStringLogger}} test facility to capture Ignite node logs and then check whether some marker strings exist in log output. Since logger's buffer is limited (32K chars by default) unrelated changes that add