GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/5575
IGNITE-10535
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10535-1
Alternatively you can review and apply th
Vladimir Ozerov created IGNITE-10535:
Summary: SQL: extract partition mapping logic from
GridReduceQueryExecutor into a separate class
Key: IGNITE-10535
URL: https://issues.apache.org/jira/browse/IGNITE-10535
Github user xtern closed the pull request at:
https://github.com/apache/ignite/pull/3451
---
Anton, I think wrapping every disconnecting node with try-catch will be
less readable than no-op handler.
ср, 5 дек. 2018 г., 9:26 Dmitriy Pavlov dpav...@apache.org:
> Folks let me remind you that Dmitry changed default of ALL tests from noop
> to a meaningful handler. So we should start every me
Github user dgovorukhin closed the pull request at:
https://github.com/apache/ignite/pull/1074
---
Roman Kondakov created IGNITE-10537:
---
Summary: MVCC: Client reconnect tests became unstable after mvcc
coordinator reassign fix.
Key: IGNITE-10537
URL: https://issues.apache.org/jira/browse/IGNITE-10537
Dmitrii,
No-op means "hide any problem", so, we lose the guarantees.
Could you please share some examples where "no-op" better than "strict
try-catch with a check"?
On Wed, Dec 5, 2018 at 11:37 AM Dmitrii Ryabov
wrote:
> Anton, I think wrapping every disconnecting node with try-catch will be
>
Alexander Kalinin created IGNITE-10536:
--
Summary: Incorrect hanlding of error in agent manager
Key: IGNITE-10536
URL: https://issues.apache.org/jira/browse/IGNITE-10536
Project: Ignite
I
Anton,
If I understood this idea right, try-catch will not work because failure
can be thrown into an Ignite thread pool, which catches any exceptions and
errors.
Which code block will do a throw?
Sincerely,
Dmitriy Pavlov
ср, 5 дек. 2018 г. в 12:16, Anton Vinogradov :
> Dmitrii,
>
> No-op me
Hi Srinivas,
You are in! Welcome aboard.
Sincerely,
Dmitriy Pavlov
ср, 5 дек. 2018 г. в 06:03, Srinivas Reddy :
> Can you please add me to contributors group?
>
> Jira : mrsrinivas
>
> Thank you
>
> -
> Srinivas
>
> - Typed on tiny keys. pls ignore typos.{mobile app}
>
> On Tue, 4 Dec, 2018, 04
Hi,
Dmitri,
The meaningful failure handler as a default one looks reasonable.
Thanks a lot.
But what is the reason to fallback to noop for 100+ test?
Does it means these test become failed after changing default failure
handler?
If so, let's create a ticket (may be umbrella) to investigate and f
Vasiliy Sisko created IGNITE-10538:
--
Summary: Web console: Implement common component for empty ui-grid
messages
Key: IGNITE-10538
URL: https://issues.apache.org/jira/browse/IGNITE-10538
Project: Ign
https://issues.apache.org/jira/browse/INFRA-17351
A ticket was created.
On Fri, Nov 30, 2018 at 12:04 AM Denis Magda wrote:
> A request has been submitted.
>
> --
> Denis
>
> On Thu, Nov 29, 2018 at 11:45 AM Dmitriy Pavlov
> wrote:
>
> > Denis, could you please create a new list for Apache Igni
Dmitriy,
>> Which code block will do a throw?
Depends on the test.
Looks like we make the *bad *test even *worse*.
That's not a correct fix.
In case you expect failure you have to check this expectation inside the
special handler.
I'd like to ask you to rollback these changes and replace them w
Artem Malykh created IGNITE-10539:
-
Summary: [ML] Make 'with' methods consistent
Key: IGNITE-10539
URL: https://issues.apache.org/jira/browse/IGNITE-10539
Project: Ignite
Issue Type: Improvem
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5559
---
I will not do any rollback because changes make tests better. Please pay
attention that no-op became default long time ago. Please discuss this
selection with authors of the previous commit. New commit changes
NoOp->FailTest+stopNode.
Please provide a PR to demonstrate your idea how to transfer an
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5472
---
In my opinion, the main senario is the 'in-place' changes via with method.
This is a Java and mutability is normal behaviour.
ср, 5 дек. 2018 г. в 13:05, Artem Malykh (JIRA) :
> Artem Malykh created IGNITE-10539:
> -
>
> Summary: [ML] Make 'with' m
Dmitriy,
As I said before, these changes allow tests to be successful in case of
unexpected failures.
That's not acceptable.
As a reviewer, you have to be ready to provide arguments why these tests
have to be fixed this way and what was the problem, in case you merged such
changes.
That's unaccep
Nikolai Kulagin created IGNITE-10540:
Summary: [TC Bot] "Compare builds" page with Internal Server Error
[500]
Key: IGNITE-10540
URL: https://issues.apache.org/jira/browse/IGNITE-10540
Project: Ig
Anton, please provide PR to demo your idea. Code speaks louder than words
sometimes.
No reason to revert a contribution if someone has an idea, which is not
clear for others.
Again, we should discuss not Dmitrii contribution, but the initial
selection of no-op.
If you will do a test failure fixe
zzzadruga opened a new pull request #87: IGNITE-10540 "Compare builds" page
with Internal Server Error [500]
URL: https://github.com/apache/ignite-teamcity-bot/pull/87
This is an automated message from the Apache Git Service
SomeFire commented on a change in pull request #87: IGNITE-10540 "Compare
builds" page with Internal Server Error [500]
URL: https://github.com/apache/ignite-teamcity-bot/pull/87#discussion_r239018971
##
File path:
ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/tcbot/build
Dmitriy,
That's an incorrect idea to ask me to provide PR or to fix these test
properly since I'm not an author or reviewer.
But, I, as a community member, ask you to explain what problems the fix
fixes.
In case you're not able to provide the explanation I will rollback the
changes.
That's not a
Yury Babak created IGNITE-10542:
---
Summary: [ML] Distributive models with basic algebra
Key: IGNITE-10542
URL: https://issues.apache.org/jira/browse/IGNITE-10542
Project: Ignite
Issue Type: New
Yury Babak created IGNITE-10543:
---
Summary: [ML] Test/train sample generator
Key: IGNITE-10543
URL: https://issues.apache.org/jira/browse/IGNITE-10543
Project: Ignite
Issue Type: New Feature
ololo3000 opened a new pull request #88: IGNITE-10519 JavaDocs added
URL: https://github.com/apache/ignite-teamcity-bot/pull/88
This is an automated message from the Apache Git Service.
To respond to the message, please log o
Yury Babak created IGNITE-10544:
---
Summary: [ML] GMM with fixed components
Key: IGNITE-10544
URL: https://issues.apache.org/jira/browse/IGNITE-10544
Project: Ignite
Issue Type: New Feature
Yury Babak created IGNITE-10545:
---
Summary: [ML] Kullback–Leibler divergence
Key: IGNITE-10545
URL: https://issues.apache.org/jira/browse/IGNITE-10545
Project: Ignite
Issue Type: New Feature
Yury Babak created IGNITE-10547:
---
Summary: [ML] Examples of GMM usage
Key: IGNITE-10547
URL: https://issues.apache.org/jira/browse/IGNITE-10547
Project: Ignite
Issue Type: New Feature
Yury Babak created IGNITE-10541:
---
Summary: [ML] Umbrella: EM (GMM) with adding and removal of
components
Key: IGNITE-10541
URL: https://issues.apache.org/jira/browse/IGNITE-10541
Project: Ignite
Yury Babak created IGNITE-10548:
---
Summary: [ML] Classificator based on GMM
Key: IGNITE-10548
URL: https://issues.apache.org/jira/browse/IGNITE-10548
Project: Ignite
Issue Type: New Feature
Yury Babak created IGNITE-10546:
---
Summary: [ML] GMM with adding and removal of components
Key: IGNITE-10546
URL: https://issues.apache.org/jira/browse/IGNITE-10546
Project: Ignite
Issue Type: N
GitHub user antonovsergey93 opened a pull request:
https://github.com/apache/ignite/pull/5576
IGNITE-10507 idle_verify added CRC sum check and collecting exceptions from
all nodes
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/
Hi Anton,
Could you please summarize what does aforementioned patch made really worse?
As I see, the patch added a very good thing -- meaningful failure
handler in tests. And I think it is really important. But was is the
harm and does it overweight positive result? And why?
ср, 5 дек. 2018 г. в
Alexey Platonov created IGNITE-10549:
Summary: [ML] LogisticRegressionSGDTrainerTest fails with BLAS
Key: IGNITE-10549
URL: https://issues.apache.org/jira/browse/IGNITE-10549
Project: Ignite
Ivan,
Do you mean massive no-op handler restore patch [1]?
[1] https://github.com/apache/ignite/pull/4974/files
On Wed, Dec 5, 2018 at 2:53 PM Павлухин Иван wrote:
> Hi Anton,
>
> Could you please summarize what does aforementioned patch made really
> worse?
>
> As I see, the patch added a ve
Dmitrii Ryabov explained these tests are perfectly ok to have failures as
these tests do test failures.
Anton, there is no reason to revert other's contributions because you know
how to do things better. A lot of people can do things better than me.
Should we revert everything I've contributed? I
Andrew Mashenkov created IGNITE-10550:
-
Summary: MVCC: rework IgniteWalFlush* tests for mvcc.
Key: IGNITE-10550
URL: https://issues.apache.org/jira/browse/IGNITE-10550
Project: Ignite
Iss
Anton,
Yes I meant that patch. And I would like to respell a name "massive
no-op handler restore" to "use no-op failure handler only where it is
assumed".
ср, 5 дек. 2018 г. в 15:09, Dmitriy Pavlov :
>
> Dmitrii Ryabov explained these tests are perfectly ok to have failures as
> these tests do tes
GitHub user avplatonov opened a pull request:
https://github.com/apache/ignite/pull/5577
IGNITE-10549: LogisticRegressionSGDTrainerTest fails with BLAS
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite
Andrew Mashenkov created IGNITE-10551:
-
Summary: MVCC: IgniteWalHistoryReservations tests failed.
Key: IGNITE-10551
URL: https://issues.apache.org/jira/browse/IGNITE-10551
Project: Ignite
Dmitriy Pavlov, Dmitrii Ryabov,
>> Anton, there is no reason to revert other's contributions because you
know
>> how to do things better.
What I see is "We replaced no-op with the proper handler, but . 100+
no-op still here because tests start failing :)"
That's a completely different situati
asfgit closed pull request #87: IGNITE-10540 "Compare builds" page with
Internal Server Error [500]
URL: https://github.com/apache/ignite-teamcity-bot/pull/87
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of pr
Ivan,
>> Yes I meant that patch. And I would like to respell a name "massive
>> no-op handler restore" to "use no-op failure handler only where it is
>> assumed".
How about "we changed some handlers to proper, but keep other no-ops using
explicit copy-paste"? :)
On Wed, Dec 5, 2018 at 3:38 PM An
Anton, I disagree with this approach: "You will ask, other will provide
explanations/excuses/apology and so on". Since you rejecting to chime in
and help this means trying to manage instead of doing.
I don't ask you to re-do this change, I ask to demonstrate any better
approach for tests which int
Guys,
I didn't get. What is the problem in saving No-Op for several tests? Why
should we keep No-Op for all?
On Wed, Dec 5, 2018 at 3:20 PM Павлухин Иван wrote:
> Anton,
>
> Yes I meant that patch. And I would like to respell a name "massive
> no-op handler restore" to "use no-op failure handle
GitHub user sergey-chugunov-1985 opened a pull request:
https://github.com/apache/ignite/pull/5578
IGNITE_DISABLE_WAL_DURING_REBALANCING turned on by default, test for race
between checkpointer and affinity change added
You can merge this pull request into a Git repository by runn
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5499
---
>> I didn't get. What is the problem in saving No-Op for several tests? Why
>> should we keep No-Op for all?
Several (less than 10) is ok to me with the proper explanation why tests
fail and why no-op is a better choice.
100+++ copy-pasted no-op handlers are not ok!
>> I don't ask you to re-do th
GitHub user pavlukhin opened a pull request:
https://github.com/apache/ignite/pull/5579
IGNITE-9322: MVCC deadlock detection
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9322
Alternatively you ca
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5549
---
Anton, if you care enough here will you try to research a couple of these
tests? Or you are asking others to do things for you, aren't you?
I like idea from Andrew to create ticket and check these test to keep
moving towards 010 tests with noop. It is easy to locate these
overridden method now
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5556
---
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/5580
IGNITE-9303 : Fixed flag check on page recycling and changed
PageMemoryTracker to use forced read lock.
You can merge this pull request into a Git repository by running:
$ git pull https://
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/
---
Dmitriy,
It's ok in case someone ready to do this (get rid of all no-op or explain
why it's a better choice).
Explicit confirmation required.
Otherwise, only rollback is an option.
On Wed, Dec 5, 2018 at 4:29 PM Dmitriy Pavlov wrote:
> Anton, if you care enough here will you try to research a
Anton,
I really like your perfectionism. But why should we make all things perfect
in a single fix? The change you want to roll back is definitely useful for
the project: the majority of our tests do not hide potential bugs under
no-op handler anymore, and the small number of tests require additio
Igniters,
I've found that the project's test framework uses
'TcpDiscoveryMulticastIpFinder' as default IP finder for tests and
there are a lot of tests written by Ignite's experts that override it
to 'TcpDiscoveryVmIpFinder'.
Most of our tests starting Ignite nodes in the same JVM, that allows
us
Dmitry,
Do we have TC run results for the PR before massive failure handler
fallbacks were added?
Let's create a ticket to investigate possibility of using any meaningful
failure handler for such tests with TC report attached.
On Wed, Dec 5, 2018 at 4:41 PM Anton Vinogradov wrote:
> Dmitriy,
>
Huge +1
On Wed, Dec 5, 2018 at 5:09 PM Vyacheslav Daradur
wrote:
> Igniters,
>
> I've found that the project's test framework uses
> 'TcpDiscoveryMulticastIpFinder' as default IP finder for tests and
> there are a lot of tests written by Ignite's experts that override it
> to 'TcpDiscoveryVmIpFi
SomeFire opened a new pull request #89: IGNITE-10454 Create page with muted
tests
URL: https://github.com/apache/ignite-teamcity-bot/pull/89
This is an automated message from the Apache Git Service.
To respond to the message
Andrey,
>> But why should we make all things perfect
>> in a single fix?
As I said, I'm ok in case someone ready to continue :)
But, we should avoid such over-copy-pasted commits in the future.
On Wed, Dec 5, 2018 at 5:13 PM Andrey Mashenkov
wrote:
> Dmitry,
>
> Do we have TC run results for th
Hello, Igniters.
I'm agree with Anton Vinogradov.
I think we should avoid commits like [1]
Copy paste coding style is well known anti pattern.
Don't we have another option to do same fix with better styling?
Accepting such patches leads to the further tickets to cleanup mess that
patches brings
Slava,
These are exactly my thoughts, so I fully support you here.
I already wrote about it:
http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
But I kind of abandoned this activity. Feel free to take over it.
Denis
ср, 5 дек. 2018 г. в 17:22, Vladimir Ozerov :
Alexey Kuznetsov created IGNITE-10552:
-
Summary: Web Agent: Improve logging when cluster topology changed
Key: IGNITE-10552
URL: https://issues.apache.org/jira/browse/IGNITE-10552
Project: Ignite
GitHub user akuznetsov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/5581
IGNITE-10552 Web Agent: Improve logging when cluster topology changed
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apac
As I can see from the above discussion,
> Tests in these classes check fail cases when we expect critical failure
like node stop or exception thrown
So, this copy-n-paste-style change is caused by the imperfect logic of
existing tests, that should be reworked in more robust way, e.g. using
custo
++1
On Wed, Dec 5, 2018 at 5:55 PM Denis Mekhanikov
wrote:
> Slava,
>
> These are exactly my thoughts, so I fully support you here.
> I already wrote about it:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
> But I kind of abandoned this activity. Feel
Oleg Ignatenko created IGNITE-10553:
---
Summary: Investigate differences in test lists prior and after
migration of core module tests to Junit 4 (follow-up to IGNITE-10175)
Key: IGNITE-10553
URL: https://issues.ap
Pavel Tupitsyn created IGNITE-10554:
---
Summary: .NET: Jars are not copied to target dir under .NET Core
Key: IGNITE-10554
URL: https://issues.apache.org/jira/browse/IGNITE-10554
Project: Ignite
Vyacheslav Daradur created IGNITE-10555:
---
Summary: Set 'TcpDiscoveryVmIpFinder' as default IP finder for
tests instead of 'TcpDiscoveryMulticastIpFinder'
Key: IGNITE-10555
URL: https://issues.apache.org/jira
Slava,
+1 for your proposal.
Is there any ticket for this?
Denis,
I've just read in nabble thread you suggest to allow multicast finder for
multiJVM tests
and I'd think we shouldn't use multicast in test at all (excepts multicast
Ip finder self tests of course),
but e.g. add an assertion to force
Folks, let me explain one thing which is not related much to fix itself,
but it is more about how we interact. If someone will just come to the list
and say it is not good commit, it is a silly solution and say to others to
rework these patches - it is a road to nowhere.
If someone sees the potent
I filled a task [1].
>> Slava, do you think Platforms tests can be fixed as well or one more ticket
should be created?
I'll try to fix them within one ticket, it should be investigated a bit deeper.
I'll inform about the task's progress in this thread later.
Thanks!
[1] https://issues.apache.o
Pavel Kovalenko created IGNITE-10556:
Summary: Attempt to decrypt data records during read-only
metastorage recovery leads to NPE
Key: IGNITE-10556
URL: https://issues.apache.org/jira/browse/IGNITE-10556
Andrey,
Multi-JVM tests may also use a static IP finder, but it should use some
specific port range instead of being shared.
Something like 127.0.0.1:48500..48509 would do.
Denis
ср, 5 дек. 2018 г. в 18:34, Vyacheslav Daradur :
> I filled a task [1].
>
> >> Slava, do you think Platforms tests c
++1
ср, 5 дек. 2018 г. в 18:38, Denis Mekhanikov :
> Andrey,
>
> Multi-JVM tests may also use a static IP finder, but it should use some
> specific port range instead of being shared.
> Something like 127.0.0.1:48500..48509 would do.
>
> Denis
>
> ср, 5 дек. 2018 г. в 18:34, Vyacheslav Daradur :
GitHub user daradurvs opened a pull request:
https://github.com/apache/ignite/pull/5582
for TC tests
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/daradurvs/ignite ignite-10555
Alternatively you can review and apply these chan
Alexand Polyakov created IGNITE-10557:
-
Summary: Control.sh validate index work long and broke down
Key: IGNITE-10557
URL: https://issues.apache.org/jira/browse/IGNITE-10557
Project: Ignite
Andrew Mashenkov created IGNITE-10558:
-
Summary: MVCC: IgniteWalReader test failed.
Key: IGNITE-10558
URL: https://issues.apache.org/jira/browse/IGNITE-10558
Project: Ignite
Issue Type: B
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/5583
IGNITE-10462: Fix Standalone wal iterator.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10558
Alternativel
Github user AMashenkov closed the pull request at:
https://github.com/apache/ignite/pull/5583
---
GitHub user AMashenkov reopened a pull request:
https://github.com/apache/ignite/pull/5583
IGNITE-10462: Fix Standalone wal iterator.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10558
Alternativ
GitHub user nizhikov opened a pull request:
https://github.com/apache/ignite/pull/5584
IGNITE-8227: Proper NoOpHandler injection.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/nizhikov/ignite IGNITE-8227-fix
Alternatively you
Dmitriy.
I think we should avoid copy paste code instead of thinking about Apache
Way all the time :)
Anyway, I propose to return to the code!
I think we should use some kind of marker base class for a cases with
NoOpHandler.
This has several advantages, comparing with current implementation:
1.
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5522
---
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5547
---
Igor Seliverstov created IGNITE-10559:
-
Summary: MVCC TX: Use extracted partitions to reduce target nodes
for Query Update
Key: IGNITE-10559
URL: https://issues.apache.org/jira/browse/IGNITE-10559
When are going to complete the post-release steps and announce the release?
Once the binaries are available on the website we need to release the docs.
I'm ready to prepare a blog post for blogs.apache.org.
--
Denis
On Mon, Dec 3, 2018 at 11:14 PM Nikolay Izhikov wrote:
> Sorry, Alex.
>
> I m
Thanks, as an improvement to the code, this may be better. But still, it is
not a reason to revert. And Anton mentioned something with better exception
handling/logging. Probably we will see an implementation as well.
This case here is a big thing related to The Apache Way, - and I'll explain
why
Yes, Denis.
I will do my best to complete release steps today.
The only things that blocks me is bintray permissions.
They required to upload rpm and deb packages to corresponding repository.
I've created ticket to the INFRA [1]
Seems, they, resolve it eventually.
We discussed this issue with ot
> Thanks, as an improvement to the code, this may be better.
I can prepare a full patch for NoOp handler.
What do you think?
Anton Vinogradov, do you agree with this approach?
ср, 5 дек. 2018 г. в 20:33, Dmitriy Pavlov :
> Thanks, as an improvement to the code, this may be better. But still,
Dmitriy.
> The closest analog to Noop handler is mute of test failure.
> By this commit, we had unmuted (possible) failures in ~5-~100=~49900
tests, and we’re still concerned about style or minor details if no-op was
copy-pasted, aren’t we?
Can you explain this idea a bit more?
I don't unders
Roman Kondakov created IGNITE-10560:
---
Summary: MVCC: Data loss after rebalance
Key: IGNITE-10560
URL: https://issues.apache.org/jira/browse/IGNITE-10560
Project: Ignite
Issue Type: Bug
Roman Kondakov created IGNITE-10561:
---
Summary: MVCC: Unexpected transaction state after rebalance
Key: IGNITE-10561
URL: https://issues.apache.org/jira/browse/IGNITE-10561
Project: Ignite
I
Dmitriy Pavlov created IGNITE-10562:
---
Summary: [TC Bot] DB contains invalid values for build references
ID maps to value with other ID
Key: IGNITE-10562
URL: https://issues.apache.org/jira/browse/IGNITE-10562
GitHub user rkondakov opened a pull request:
https://github.com/apache/ignite/pull/5585
MVCC: Create "Cache 8" test suite for MVCC mode.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10367
Alterna
Stanislav Lukyanov created IGNITE-10563:
---
Summary: Allow manual fsync for WAL
Key: IGNITE-10563
URL: https://issues.apache.org/jira/browse/IGNITE-10563
Project: Ignite
Issue Type: Impro
1 - 100 of 110 matches
Mail list logo
