Andrey N. Gura created IGNITE-12472:
---
Summary: Checkstyle rule "NewlineAtEndOfFile" is broken on Windows
systems.
Key: IGNITE-12472
URL: https://issues.apache.org/jira/browse/IGNITE-12472
Project:
Igniters,
recently I run build with checkstyle profile on Windows machine and
got 8 issues related to the "NewlineAtEndOfFile" rule while there are
no problems on my Linux machine.
I investigated the problem and suggest explicitly configure this rule
by LF separator. See [1] for more details.
I
Agree with Pavel. But it could broke something in our pipeline.
Maxim, if issue was fixed so it dependency update is better way. But
it seems that this issue in Open status.
On Thu, Dec 19, 2019 at 7:22 PM Pavel Tupitsyn wrote:
>
> Maxim,
>
> The guidelines are not set in stone.
> If we decide
Good news, Anton!
Thanks for your work on PME feature!
> 19 дек. 2019 г., в 21:00, Anton Vinogradov написал(а):
>
> Folks,
> "2.8 + cherrypicked pme-free switch" vs "2.8" check finished, no blockers
> found.
>
Hi Anton,
>> It would be nice to cut off a new branch from the release and run all the
> >> tests with an integrated feature and after that,
> >> if you don’t see new failures and the release engineer agrees with the
> >> result, then and only then this feature can be merged into the release.
> I
>From my point of view, Ignite should provide meaningful metrics for
internal components that could be useful for monitoring and analysis.
All suggested options are meaningless in a sense. Below I'll try
explain why.
>* `get`, `put`, `remove` time histograms. Measured for API calls on the caller
Maxim,
The guidelines are not set in stone.
If we decide that some guideline does not bring any value and only wastes
our time (like this one),
we can (and should) remove it.
On Thu, Dec 19, 2019 at 7:13 PM Maxim Muzafarov wrote:
> Pavel,
>
> It's configured according to accepted Coding
Ivan,
IGFS and Hadoop Accelerator had inherent architectural flaws - the vast
majority of users who tried to use these features failed to achieve
expected results. And yes, at the same time the interest was very high, so
we really needed to take action :)
Scheduler module, on the other hand,
Hello, Andrey.
The goal of the proposed metrics is to measure whole cache operations behavior.
It provides some kind of statistics(histograms) for it.
For more fine-grained analysis one will be use tracing or other «go deeper»
tools.
> > Measured for API calls on the caller node side
> Values
Pavel,
Issue created - https://issues.apache.org/jira/browse/IGNITE-12470
Slava,
Does it mean we able to perform merge once I'll provide check results?
On Thu, Dec 19, 2019 at 4:04 PM Вячеслав Коптилин
wrote:
> Hi Anton,
>
> >> It would be nice to cut off a new branch from the release and run
Pavel Tupitsyn created IGNITE-12471:
---
Summary: .NET Thin Client: WithExpiryPolicy crashes client
connection on old servers
Key: IGNITE-12471
URL: https://issues.apache.org/jira/browse/IGNITE-12471
Pavel Tupitsyn created IGNITE-12473:
---
Summary: .NET: ClientServerCompatibilityTest fails on some agents
because of Maven error
Key: IGNITE-12473
URL: https://issues.apache.org/jira/browse/IGNITE-12473
Hello, Andrey
Is it better to upgrade the checkstyle plugin version?
It seems the issue has been fixed since 8.21 version (currently we have 8.19)
[1] https://checkstyle.org/releasenotes.html#Release_8.21
On Thu, 19 Dec 2019 at 18:09, Andrey Gura wrote:
>
> Igniters,
>
> recently I run build
Folks,
"2.8 + cherrypicked pme-free switch" vs "2.8" check finished, no blockers
found.
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull%2F7165%2Fhead=Latest=pull%2F7102%2Fhead
Any objections to merging?
On Thu, Dec 19, 2019 at 4:20 PM Вячеслав Коптилин
wrote:
>
Anton, Slava
I guess we should have a system property to have ability to turn off PME
free switch behavior if something goes wrong after release.
After feature battle testing we can remove it in the next release.
чт, 19 дек. 2019 г. в 15:26, Anton Vinogradov :
> Slava,
>
> >> It would be nice
Anton Vinogradov created IGNITE-12470:
-
Summary: Pme-free switch feature should be deactivatable
Key: IGNITE-12470
URL: https://issues.apache.org/jira/browse/IGNITE-12470
Project: Ignite
Igniters,
Does this rule bring any value whatsoever for us?
Let's just disable it.
On Thu, Dec 19, 2019 at 6:25 PM Maxim Muzafarov wrote:
> Hello, Andrey
>
> Is it better to upgrade the checkstyle plugin version?
> It seems the issue has been fixed since 8.21 version (currently we have
> 8.19)
Hello Pavel,
Good to hear from you!
> I guess we should have a system property to have ability to turn off PME
free switch behavior if something goes wrong after release.
> After feature battle testing we can remove it in the next release.
Sounds good to me.
Thanks,
S.
чт, 19 дек. 2019 г. в
Pavel,
It's configured according to accepted Coding Guidelines [1].
[1]
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines
On Thu, 19 Dec 2019 at 18:59, Pavel Tupitsyn wrote:
>
> Igniters,
>
> Does this rule bring any value
The API is definitely used with even higher demand for the last
months (overall the demand is comparable to Ignite Kafka and ML). See
attachment.
If the module has some problems let's discuss them separately and see how
to approach first. Do we have a list of the issues tracked anywhere?
-
Igniters,
I'd like to have an open discussion about this IEP in relation to the name
of the parameter that activates the feature:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
Presently selected term ("affinityAwareness") is not accurate and
FYI
I applied the patch.
ср, 18 дек. 2019 г. в 14:46, Ivan Pavlukhin :
>
> So, if nobody objects, I will merge PR [1] on Friday.
>
> [1] https://github.com/apache/ignite/pull/7142
>
> ср, 18 дек. 2019 г. в 13:13, Dmitriy Pavlov :
> >
> > Hi Ivan, Igniters,
> >
> > My proposal is to apply PR and
Denis,
> The API is definitely used with even higher demand for the last months
> (overall the demand is comparable to Ignite Kafka and ML). See attachment.
I do not see the attachement. Where can I find it?
чт, 19 дек. 2019 г. в 20:01, Denis Magda :
>
> The API is definitely used with even
+1, let's rename while we have a chance before 2.8 is released.
Sorry for taking so long, but it has dropped down my priority list :(
I have now provided a github pull request for the logging changes I would like
to make. Please review and let me know whether my patch is acceptable
-Original Message-
From: Sunny Chan, CLSA
Sent: Friday, August 30,
Saikat, excellent start! I wasn't able to attend but watched the
recording later. Thanks for sharing your experience.
-
Denis
On Wed, Dec 18, 2019 at 5:12 PM Saikat Maitra
wrote:
> Hi,
>
>
> The page with the embedded recording and slides link is
>
Saikat,
I watched a recording and found it great! Thank you for that! Would
love to see more materials how Ignite can be used in practice.
пт, 20 дек. 2019 г. в 10:19, Denis Magda :
>
> Saikat, excellent start! I wasn't able to attend but watched the
> recording later. Thanks for sharing your
Stanilovsky Evgeny created IGNITE-12474:
---
Summary: Fix boost compatibility for cpp thin-client-test.
Key: IGNITE-12474
URL: https://issues.apache.org/jira/browse/IGNITE-12474
Project: Ignite
I will vote "+1" for 3.0
On Thu, Dec 19, 2019 at 10:57 AM Anton Vinogradov wrote:
> My Vote was for 3.0
>
> On Thu, Dec 19, 2019 at 10:44 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Is this suggested for 3.0 or 2.8?
> >
> > I tend to agree with Alexey - API
I see no need for haste. These methods do not break anything and could be
in use by community.
+1 to remove in 3.0
чт, 19 дек. 2019 г. в 11:09, Ivan Pavlukhin :
> Guys,
>
> Why some of us are so critical regarding the subject? If I recall
> correctly we decided to drop IGFS and Hadoop support
Stanilovsky Evgeny created IGNITE-12469:
---
Summary: CorruptedTreeException can hold unmutable sensitive data.
Key: IGNITE-12469
URL: https://issues.apache.org/jira/browse/IGNITE-12469
Project:
+1 to Maxim's proposal.
We need some time of testing to make sure nothing is popping up.
чт, 19 дек. 2019 г. в 12:28, Ivan Pavlukhin :
> Not sure that I got the decision about merging "pme-free-switch" to
> 2.8 release branch. Personally I like Maxim's proposal.
> > Let's do the following:
> >
Not sure that I got the decision about merging "pme-free-switch" to
2.8 release branch. Personally I like Maxim's proposal.
> Let's do the following:
> 1. Merge the issue to the master branch.
> 2. Wait for two-three weeks of running tests.
> 3. Check that there are not flaky failures and fix them
Guys,
Why some of us are so critical regarding the subject? If I recall
correctly we decided to drop IGFS and Hadoop support before 2.8
without much debate. And it was a feature users were interested in. I
never saw an interest to IgniteSchedule. My statistics is based on our
User mailing list.
Folks,
We should avoid feature cherrypicking in the later stages of the release
process.
On Thu, Dec 19, 2019 at 1:01 PM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> +1 to Maxim's proposal.
>
> We need some time of testing to make sure nothing is popping up.
>
> чт, 19 дек. 2019 г.
Hello Anton,
> We always have to merge all release features asap to have as much time as
possible to fix all bugs.
Could you please clarify this? What is the reason for that asap merging,
especially the merging into the release branch?
Why the testing cannot be done on the feature branch? You
Feature already tested at the feature branch properly.
Question is about master -> release merge.
So:
1) Testing at master does not equal to testing at release.
Code may fail in the master while it works at the release branch and vice
versa.
2) Master is flakier that release branch, so we able
Hi,
> We're releasing release branch, not master... why we're checking the
"wrong" branch? :)
> Performing the release verification we're checking not only how features
work, but also how they work together.
Yep, I agree that we should do verification for both branches of corse.
> Finally, my
Slava,
>> It would be nice to cut off a new branch from the release and run all the
>> tests with an integrated feature and after that,
>> if you don’t see new failures and the release engineer agrees with the
>> result, then and only then this feature can be merged into the release.
I fully
39 matches
Mail list logo
