Re: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Denis Magda]

Andrey,

I would encourage us to roll this release out and consider this change for
the next one. We’re free to make the next release as soon as needed, even a
couple of weeks after.

Do you agree?

Denis

On Tuesday, May 21, 2019, Andrey Gura  wrote:

> Ilya, do you have any estimation for fix Java 12 with SSL issue?
>
> On Tue, May 21, 2019 at 10:26 PM Denis Magda  wrote:
> >
> > Ignite PMC and committers, please cast your vote. It's time to roll the
> release out.
> >
> > --
> > Denis Magda
> >
> >
> > -- Forwarded message -
> > From: Denis A. Magda 
> > Date: Tue, May 21, 2019 at 7:26 AM
> > Subject: Re: [VOTE] Accept Apache Ignite 2.7.5-rc3
> > To: 
> >
> >
> > + 1 (binding)
> >
> > Denis
> >
> > On 2019/05/17 13:49:17, Dmitriy Pavlov  wrote:
> > > Dear Sirs!
> > >
> > > We have uploaded release candidate to
> > > https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
> > >
> > > The following staging can be used for a dependent project for testing:
> > > https://repository.apache.org/content/repositories/
> orgapacheignite-1438/
> > >
> > > This is half-release before 2.8 containing Java 11 support and fixes
> for
> > > Native Persistence storage.
> > >
> > > Tag name is 2.7.5-rc3:
> > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;
> h=refs/tags/2.7.5-rc3
> > >
> > > 2.7.5 changes:
> > > * Added Java 11 support
> > > * Fixed infinite looping during SSL handshake, affecting Java
> 11/Windows
> > > * Fixed storage corruption case after incorrectly rotated page
> > > * Erroneous WAL record after incorrectly rotated page processed
> > > automatically
> > > * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> > > * Launch scripts and some Ignite initialization steps were fixed for
> Java 12
> > > * Fixed indexes corruption on node stop under load
> > > * Fixed case of node crash during node deactivation
> > > * Error message with advice about required JVM parameters printed when
> Java
> > > 9+ is used
> > > * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
> > >
> > > Complete list of closed issues:
> > > https://issues.apache.org/jira/issues/?jql=(project%20%
> 3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(
> Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%
> 20%20%20%20%20%20%20%20%20%20%20
> > >
> > >
> > > DEVNOTES
> > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;
> f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
> > >
> > > RELEASE NOTES
> > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;
> f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f16579
> 40fa12f972;hb=ignite-2.7.5
> > >
> > > The vote is formal, see voting guidelines
> > > https://www.apache.org/foundation/voting.html
> > >
> > > +1 - to accept Apache Ignite 2.7.5-rc3
> > > 0 - don't care either way
> > > -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
> > >
> > > This vote will be open for 6 days till May 23, 14:00 UTC.
> > > https://www.timeanddate.com/countdown/to?year=2019=
> 5=23=14=0=0=utc-1
> > >
> > > Best Regards,
> > > Dmitriy Pavlov
> > >
>


-- 
-
Denis

Re: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Andrey Gura]

Ilya, do you have any estimation for fix Java 12 with SSL issue?

On Tue, May 21, 2019 at 10:26 PM Denis Magda  wrote:
>
> Ignite PMC and committers, please cast your vote. It's time to roll the 
> release out.
>
> --
> Denis Magda
>
>
> -- Forwarded message -
> From: Denis A. Magda 
> Date: Tue, May 21, 2019 at 7:26 AM
> Subject: Re: [VOTE] Accept Apache Ignite 2.7.5-rc3
> To: 
>
>
> + 1 (binding)
>
> Denis
>
> On 2019/05/17 13:49:17, Dmitriy Pavlov  wrote:
> > Dear Sirs!
> >
> > We have uploaded release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
> >
> > The following staging can be used for a dependent project for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1438/
> >
> > This is half-release before 2.8 containing Java 11 support and fixes for
> > Native Persistence storage.
> >
> > Tag name is 2.7.5-rc3:
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.7.5-rc3
> >
> > 2.7.5 changes:
> > * Added Java 11 support
> > * Fixed infinite looping during SSL handshake, affecting Java 11/Windows
> > * Fixed storage corruption case after incorrectly rotated page
> > * Erroneous WAL record after incorrectly rotated page processed
> > automatically
> > * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> > * Launch scripts and some Ignite initialization steps were fixed for Java 12
> > * Fixed indexes corruption on node stop under load
> > * Fixed case of node crash during node deactivation
> > * Error message with advice about required JVM parameters printed when Java
> > 9+ is used
> > * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
> >
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20
> >
> >
> > DEVNOTES
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
> >
> > RELEASE NOTES
> > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f1657940fa12f972;hb=ignite-2.7.5
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.7.5-rc3
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
> >
> > This vote will be open for 6 days till May 23, 14:00 UTC.
> > https://www.timeanddate.com/countdown/to?year=2019=5=23=14=0=0=utc-1
> >
> > Best Regards,
> > Dmitriy Pavlov
> >

Fwd: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Denis Magda]

Ignite PMC and committers, please cast your vote. It's time to roll the
release out.

--
Denis Magda


-- Forwarded message -
From: Denis A. Magda 
Date: Tue, May 21, 2019 at 7:26 AM
Subject: Re: [VOTE] Accept Apache Ignite 2.7.5-rc3
To: 


+ 1 (binding)

Denis

On 2019/05/17 13:49:17, Dmitriy Pavlov  wrote:
> Dear Sirs!
>
> We have uploaded release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
>
> The following staging can be used for a dependent project for testing:
> https://repository.apache.org/content/repositories/orgapacheignite-1438/
>
> This is half-release before 2.8 containing Java 11 support and fixes for
> Native Persistence storage.
>
> Tag name is 2.7.5-rc3:
>
https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.7.5-rc3
>
> 2.7.5 changes:
> * Added Java 11 support
> * Fixed infinite looping during SSL handshake, affecting Java 11/Windows
> * Fixed storage corruption case after incorrectly rotated page
> * Erroneous WAL record after incorrectly rotated page processed
> automatically
> * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> * Launch scripts and some Ignite initialization steps were fixed for Java
12
> * Fixed indexes corruption on node stop under load
> * Fixed case of node crash during node deactivation
> * Error message with advice about required JVM parameters printed when
Java
> 9+ is used
> * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
>
> Complete list of closed issues:
>
https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20
>
>
> DEVNOTES
>
https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
>
> RELEASE NOTES
>
https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f1657940fa12f972;hb=ignite-2.7.5
>
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept Apache Ignite 2.7.5-rc3
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
>
> This vote will be open for 6 days till May 23, 14:00 UTC.
>
https://www.timeanddate.com/countdown/to?year=2019=5=23=14=0=0=utc-1
>
> Best Regards,
> Dmitriy Pavlov
>

Re: PRIORITY Action required: Security review for non-https dependency urls

[Petr Ivanov]

What exactly are we looking for? URLs to dependencies with http?



> On 21 May 2019, at 21:38, Denis Magda  wrote:
> 
> Yeap,
> 
> This looks like a candidate for the change.
> 
> Peter, Anton, is there a quick way to prepare a list of such dependencies 
> where "http" is to be replaced with "https"?
> 
> --
> Denis Magda
> 
> 
> On Tue, May 21, 2019 at 7:17 AM Ilya Kasnacheev  > wrote:
> Hello!
> 
> I think we still have a http dependency on H2:
> 
> 
> 
> false
> 
> 
> true
> always
> ignore
> 
> h2database.com 
> Snapshot repository on h2database.com 
> 
> http://h2database.com/m2-repo 
> 
> default
> 
> 
> WDYT?
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> вт, 21 мая 2019 г. в 17:08, Denis Magda  >:
> 
> > Igniters,
> >
> > Could anybody confirm we don’t have any issues with that?
> >
> > Denis
> >
> > -- Forwarded message --
> > From: *Apache Security Team*  > >
> > Date: Tuesday, May 21, 2019
> > Subject: PRIORITY Action required: Security review for non-https dependency
> > urls
> > To: Apache Security Team mailto:secur...@apache.org>>
> >
> >
> > ASF Security received a report that a number of Apache projects have
> > build dependencies downloaded using insecure urls. The reporter states
> > this could be used in conjunction with a man-in-the-middle attack to
> > compromise project builds.  The reporter claims this a significant
> > issue and will be making an announcement on June 10th and a number of
> > press releases and industry reaction is expected.
> >
> > We have already contacted each of the projects the reporter detected.
> > However we have not run any scanning ourselves to identify any other
> > instances hence this email.
> >
> > We request that you review any build scripts and configurations for
> > insecure urls where appropriate to your projects, fix them asap, and
> > report back if you had to change anything to secur...@apache.org 
> >  by
> > the 31st May 2019.
> >
> > The most common finding was HTTP references to repos like maven.org 
> >  in
> > build files (Gradle, Maven, SBT, or other tools).  Here is an example
> > showing repositories being used with http urls that should be changed
> > to https:
> >
> > https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781b 
> > 
> > a416b8f784/pom.xml#L1017-L1038
> >  >  
> > >
> >
> > Note that searching for http:// might not be enough, look for http\://
> > too due to escaping.
> >
> > Although this issue is public on June 10th, please make fixes to
> > insecure urls immediately.  Also note that some repos will be moving
> > to blocking http transfers in June and later:
> >
> > https://central.sonatype.org/articles/2019/Apr/30/http- 
> > 
> > access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/
> >
> > The reporter claims that a full audit of affected projects is required
> > to ensure builds were not made with tampered dependencies, and that
> > CVE names should be given to each project, however we are not
> > requiring this -- we believe it’s more likely a third party repo could
> > be compromised with a malicious build than a MITM attack.   If you
> > disagree, let us know. Projects like Lucene do checksum whitelists of
> > all their build dependencies, and you may wish to consider that as a
> > protection against threats beyond just MITM.
> >
> > Best Regards,
> > Mark J Cox
> > VP, ASF Security Team
> >
> >
> >
> > --
> > -
> > Denis
> >

Re: PRIORITY Action required: Security review for non-https dependency urls

[Denis Magda]

Yeap,

This looks like a candidate for the change.

Peter, Anton, is there a quick way to prepare a list of such dependencies
where "http" is to be replaced with "https"?

--
Denis Magda


On Tue, May 21, 2019 at 7:17 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> I think we still have a http dependency on H2:
>
> 
> 
> false
> 
> 
> true
> always
> ignore
> 
> h2database.com
> Snapshot repository on h2database.com
> http://h2database.com/m2-repo
> default
> 
>
> WDYT?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 21 мая 2019 г. в 17:08, Denis Magda :
>
> > Igniters,
> >
> > Could anybody confirm we don’t have any issues with that?
> >
> > Denis
> >
> > -- Forwarded message --
> > From: *Apache Security Team* 
> > Date: Tuesday, May 21, 2019
> > Subject: PRIORITY Action required: Security review for non-https
> dependency
> > urls
> > To: Apache Security Team 
> >
> >
> > ASF Security received a report that a number of Apache projects have
> > build dependencies downloaded using insecure urls. The reporter states
> > this could be used in conjunction with a man-in-the-middle attack to
> > compromise project builds.  The reporter claims this a significant
> > issue and will be making an announcement on June 10th and a number of
> > press releases and industry reaction is expected.
> >
> > We have already contacted each of the projects the reporter detected.
> > However we have not run any scanning ourselves to identify any other
> > instances hence this email.
> >
> > We request that you review any build scripts and configurations for
> > insecure urls where appropriate to your projects, fix them asap, and
> > report back if you had to change anything to secur...@apache.org by
> > the 31st May 2019.
> >
> > The most common finding was HTTP references to repos like maven.org in
> > build files (Gradle, Maven, SBT, or other tools).  Here is an example
> > showing repositories being used with http urls that should be changed
> > to https:
> >
> > https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781b
> > a416b8f784/pom.xml#L1017-L1038
> > <
> https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781ba416b8f784/pom.xml#L1017-L1038
> >
> >
> > Note that searching for http:// might not be enough, look for http\://
> > too due to escaping.
> >
> > Although this issue is public on June 10th, please make fixes to
> > insecure urls immediately.  Also note that some repos will be moving
> > to blocking http transfers in June and later:
> >
> > https://central.sonatype.org/articles/2019/Apr/30/http-
> > access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/
> >
> > The reporter claims that a full audit of affected projects is required
> > to ensure builds were not made with tampered dependencies, and that
> > CVE names should be given to each project, however we are not
> > requiring this -- we believe it’s more likely a third party repo could
> > be compromised with a malicious build than a MITM attack.   If you
> > disagree, let us know. Projects like Lucene do checksum whitelists of
> > all their build dependencies, and you may wish to consider that as a
> > protection against threats beyond just MITM.
> >
> > Best Regards,
> > Mark J Cox
> > VP, ASF Security Team
> >
> >
> >
> > --
> > -
> > Denis
> >
>

Re: Hello

[Denis Magda]

Hello Vladimir and welcome aboard!

Please get to know the process and share your JIRA id once you're ready to
take on a task:
https://ignite.apache.org/community/contribute.html#contribute

-
Denis


On Tue, May 21, 2019 at 8:46 AM Vladimir Malinovskiy <
vmalinovs...@gridgain.com> wrote:

> Hello!
> My name is Vladimir Malinovskiy.
> Please register me as Ignite developer.
>
> --
> Vladimir Malinovskiy
> Software Engineer, Moscow
> +7-753-767-36-24
> https://www.gridgain.com
> Powered by Apache® Ignite™
>

Re: Thin client: transactions support

[Alex Plehanov]

Guys,

I've updated the IEP [1]. Please have a look.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support


вт, 21 мая 2019 г., 14:19 Alex Plehanov :

> Ivan,
>
> Yes, I have plans to do that (at least for java thin client). Something
> like new class "ClientTransactionConfiguration" inside
> "ClientConfiguration".
>
> вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
>
>> Alex,
>>
>> Are you going to introduce settings specifying default values for tx
>> concurrency and isolation in client configuration?
>>
>> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
>> >
>> > Igor,
>> >
>> > Perhaps we don't really need to use server's default values for tx
>> > parameters. It's a minor fix and can be easily implemented if it will be
>> > required in the future.
>> > I will update IEP tomorrow regarding point 1 and point 3.
>> > Thanks for your feedback.
>> >
>> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
>> >
>> > > Ivan,
>> > >
>> > > This may be a good point for a DBMS, but Ignite is much more than
>> just a
>> > > DBMS and Ignite client code is not just an SQL query (which execution
>> > > inherently heavily depends on DBMS). With database user is expecting
>> that
>> > > server have a lot of control on query execution. But with Ignite, in
>> my
>> > > opinion,
>> > > user writes generic code including business logic in native language
>> and
>> > > may
>> > > expect more deterministic behaviour from a client.
>> > >
>> > > Also, thick clients do not use server-side defaults.
>> > >
>> > > Of course, this question is debatable and It's not like I 100% against
>> > > server-side
>> > > defaults here, I just suggest to discuss it in more detail.
>> > >
>> > > Best Regards,
>> > > Igor
>> > >
>> > >
>> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван 
>> wrote:
>> > >
>> > > > Igor, Alex,
>> > > >
>> > > > Regarding point 1. I must say that SQL vendors usually allow to
>> > > > configure default timeouts and a transaction isolation on a server
>> > > > side. E.g. in MySQL you can do a following:
>> > > > set local tx_isolation =  -- per SQL client session
>> > > > (usually physical network connection)
>> > > > set global tx_isolation =  -- global settings, all
>> clients
>> > > > (which does not override it) are affected
>> > > >
>> > > > So, if it is a standard practice why should do it differently? If it
>> > > > is not, we can continue discussion. Do we have some examples
>> following
>> > > > opposite way (client-wide default setting)?
>> > > >
>> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
>> > > > >
>> > > > > 1. In my opinion, having client-specific transaction parameters is
>> > > > expected
>> > > > > for
>> > > > > client when have different arguments depending on server seems
>> > > unexpected
>> > > > > and can lead to hard-to-debug bugs and issues when updating from
>> old to
>> > > > new
>> > > > > server versions. Also it goes against common practice with
>> arguments of
>> > > > thin
>> > > > > client and thus, may be even more unexpected.
>> > > > >
>> > > > > I believe that if we want to add ability to client to adopt some
>> > > server's
>> > > > > defaults
>> > > > > we should implement it as separate feature, and it should not be a
>> > > > default
>> > > > > behaviour for client, user should explicitly state that they want
>> this
>> > > > > behaviour,
>> > > > > so it won't be unexpected for them.
>> > > > >
>> > > > > 3. "Flags" field looks like a good solution to me.
>> > > > >
>> > > > > Best Regards,
>> > > > > Igor
>> > > > >
>> > > > >
>> > > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
>> > > plehanov.a...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi, Igor
>> > > > > >
>> > > > > > 1. I think it's better to have the ability to configure
>> transaction
>> > > > > > parameters (for example configure default timeout for all
>> clients) on
>> > > > > > server-side, then don't have such ability and always use some
>> > > > predefined
>> > > > > > client-side values (which can be different for different client
>> > > > > > implementations). At least default timeout is more server
>> specific
>> > > then
>> > > > > > client specific parameter since it can affect server-side
>> processes
>> > > > (PME
>> > > > > > for example).
>> > > > > >
>> > > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be
>> included to
>> > > > each
>> > > > > > cache operation under a transaction. And it almost will not
>> simplify
>> > > > server
>> > > > > > code. Also, thin clients don't know how to deal with IgniteUuid
>> now,
>> > > > there
>> > > > > > is no such entity in the protocol, there are no described rules
>> on
>> > > how
>> > > > to
>> > > > > > convert it to a string. For monitoring/debugging purposes we
>> should
>> > > > have
>> > > > > > the same presentation of this entity on server and client
>> sides. I
>> > > > think if
>> > > > > > we need to know real tx id on the client side it's better to
>> > > > additionally
>> 

Hello

[Vladimir Malinovskiy]

Hello!
My name is Vladimir Malinovskiy.
Please register me as Ignite developer.

-- 
Vladimir Malinovskiy
Software Engineer, Moscow
+7-753-767-36-24
https://www.gridgain.com
Powered by Apache® Ignite™

[jira] [Created] (IGNITE-11861) GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11861:
--

 Summary: GridEventConsumeSelfTest.testMultithreadedWithNodeRestart 
fails on TC
 Key: IGNITE-11861
 URL: https://issues.apache.org/jira/browse/IGNITE-11861
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4911099288413140059=testDetails]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Denis A . Magda]

+ 1 (binding)

Denis

On 2019/05/17 13:49:17, Dmitriy Pavlov  wrote: 
> Dear Sirs!
> 
> We have uploaded release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
> 
> The following staging can be used for a dependent project for testing:
> https://repository.apache.org/content/repositories/orgapacheignite-1438/
> 
> This is half-release before 2.8 containing Java 11 support and fixes for
> Native Persistence storage.
> 
> Tag name is 2.7.5-rc3:
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.7.5-rc3
> 
> 2.7.5 changes:
> * Added Java 11 support
> * Fixed infinite looping during SSL handshake, affecting Java 11/Windows
> * Fixed storage corruption case after incorrectly rotated page
> * Erroneous WAL record after incorrectly rotated page processed
> automatically
> * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> * Launch scripts and some Ignite initialization steps were fixed for Java 12
> * Fixed indexes corruption on node stop under load
> * Fixed case of node crash during node deactivation
> * Error message with advice about required JVM parameters printed when Java
> 9+ is used
> * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20
> 
> 
> DEVNOTES
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
> 
> RELEASE NOTES
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f1657940fa12f972;hb=ignite-2.7.5
> 
> The vote is formal, see voting guidelines
> https://www.apache.org/foundation/voting.html
> 
> +1 - to accept Apache Ignite 2.7.5-rc3
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
> 
> This vote will be open for 6 days till May 23, 14:00 UTC.
> https://www.timeanddate.com/countdown/to?year=2019=5=23=14=0=0=utc-1
> 
> Best Regards,
> Dmitriy Pavlov
> 

Re: PRIORITY Action required: Security review for non-https dependency urls

[Ilya Kasnacheev]

Hello!

I think we still have a http dependency on H2:



false


true
always
ignore

h2database.com
Snapshot repository on h2database.com
http://h2database.com/m2-repo
default


WDYT?

Regards,
-- 
Ilya Kasnacheev


вт, 21 мая 2019 г. в 17:08, Denis Magda :

> Igniters,
>
> Could anybody confirm we don’t have any issues with that?
>
> Denis
>
> -- Forwarded message --
> From: *Apache Security Team* 
> Date: Tuesday, May 21, 2019
> Subject: PRIORITY Action required: Security review for non-https dependency
> urls
> To: Apache Security Team 
>
>
> ASF Security received a report that a number of Apache projects have
> build dependencies downloaded using insecure urls. The reporter states
> this could be used in conjunction with a man-in-the-middle attack to
> compromise project builds.  The reporter claims this a significant
> issue and will be making an announcement on June 10th and a number of
> press releases and industry reaction is expected.
>
> We have already contacted each of the projects the reporter detected.
> However we have not run any scanning ourselves to identify any other
> instances hence this email.
>
> We request that you review any build scripts and configurations for
> insecure urls where appropriate to your projects, fix them asap, and
> report back if you had to change anything to secur...@apache.org by
> the 31st May 2019.
>
> The most common finding was HTTP references to repos like maven.org in
> build files (Gradle, Maven, SBT, or other tools).  Here is an example
> showing repositories being used with http urls that should be changed
> to https:
>
> https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781b
> a416b8f784/pom.xml#L1017-L1038
> 
>
> Note that searching for http:// might not be enough, look for http\://
> too due to escaping.
>
> Although this issue is public on June 10th, please make fixes to
> insecure urls immediately.  Also note that some repos will be moving
> to blocking http transfers in June and later:
>
> https://central.sonatype.org/articles/2019/Apr/30/http-
> access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/
>
> The reporter claims that a full audit of affected projects is required
> to ensure builds were not made with tampered dependencies, and that
> CVE names should be given to each project, however we are not
> requiring this -- we believe it’s more likely a third party repo could
> be compromised with a malicious build than a MITM attack.   If you
> disagree, let us know. Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM.
>
> Best Regards,
> Mark J Cox
> VP, ASF Security Team
>
>
>
> --
> -
> Denis
>

Fwd: PRIORITY Action required: Security review for non-https dependency urls

[Denis Magda]

Igniters,

Could anybody confirm we don’t have any issues with that?

Denis

-- Forwarded message --
From: *Apache Security Team* 
Date: Tuesday, May 21, 2019
Subject: PRIORITY Action required: Security review for non-https dependency
urls
To: Apache Security Team 


ASF Security received a report that a number of Apache projects have
build dependencies downloaded using insecure urls. The reporter states
this could be used in conjunction with a man-in-the-middle attack to
compromise project builds.  The reporter claims this a significant
issue and will be making an announcement on June 10th and a number of
press releases and industry reaction is expected.

We have already contacted each of the projects the reporter detected.
However we have not run any scanning ourselves to identify any other
instances hence this email.

We request that you review any build scripts and configurations for
insecure urls where appropriate to your projects, fix them asap, and
report back if you had to change anything to secur...@apache.org by
the 31st May 2019.

The most common finding was HTTP references to repos like maven.org in
build files (Gradle, Maven, SBT, or other tools).  Here is an example
showing repositories being used with http urls that should be changed
to https:

https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781b
a416b8f784/pom.xml#L1017-L1038

Note that searching for http:// might not be enough, look for http\://
too due to escaping.

Although this issue is public on June 10th, please make fixes to
insecure urls immediately.  Also note that some repos will be moving
to blocking http transfers in June and later:

https://central.sonatype.org/articles/2019/Apr/30/http-
access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/

The reporter claims that a full audit of affected projects is required
to ensure builds were not made with tampered dependencies, and that
CVE names should be given to each project, however we are not
requiring this -- we believe it’s more likely a third party repo could
be compromised with a malicious build than a MITM attack.   If you
disagree, let us know. Projects like Lucene do checksum whitelists of
all their build dependencies, and you may wish to consider that as a
protection against threats beyond just MITM.

Best Regards,
Mark J Cox
VP, ASF Security Team



-- 
-
Denis

[jira] [Created] (IGNITE-11860) Temporarily peg SSL version to TLSv1.2 to fix Java 11/12

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-11860:


 Summary: Temporarily peg SSL version to TLSv1.2 to fix Java 11/12
 Key: IGNITE-11860
 URL: https://issues.apache.org/jira/browse/IGNITE-11860
 Project: Ignite
  Issue Type: Improvement
  Components: security
Affects Versions: 2.7
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
 Fix For: 2.7.5






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSSION] Channel communication between nodes

[Maxim Muzafarov]

Alexey,

Thank you for your feedback. I'll take a bit of time to re-think an
API and its usage according to your suggestions and back to you soon
with the detailed response.

But in general, I'd like to focus your attention on the following idea
of this PR, which does not fully correspond to the title of this topic
(perhaps I have to change the topic title, but I can't do it anymore).
This change is not about providing the raw socket channel to the
Supplier for transferring binary data through it, but creating an
internal service for sending\receiving files between nodes which can
be reused by other Apache Ignite components. I think it's better to
move this file transfer machinery outside the supply-demand
communication protocol and make it an independent abstraction
(service) for sending\receiving any Ignites internal files.
>From the IEP-28 perspective, the hierarchy of such objects can be:
Channel > GridIoManager > Send file Service > Preloader (backup
partition and send it to remote the Demander node).

Please, correct me if I'm missing something or have some
misunderstanding of Ignite internals.

On Mon, 20 May 2019 at 11:56, Alexey Goncharuk
 wrote:
>
> Maxim,
>
> I left response in the ticket.
>
> пт, 17 мая 2019 г. в 12:04, Maxim Muzafarov :
>
> > Igniters,
> >
> >
> > I've implemented the file transfer machinery between grid nodes over
> > Communication SPI covered by JIRA [1] and as the first part of IEP-28
> > [3]. Please, consider my PR [2] to be reviewed and included in the
> > Apache Ignite project source code.
> >
> > These changes will allow developer (and the user in future) uploading
> > arbitrary files from one cluster node to another. It is a mandatory
> > feature for the new rebalance by partition files procedure (you can
> > find all the details of it on IEP-28 [3]) but also can be used, for
> > example, as a new way of resource deployment (e.g. on
> > UriDeploymentSPI).
> >
> > The starting point of PR reviewing and examples of using the file
> > transfer can be --
> > IgniteFileTransmitProcessorSelfTest#testFileHandlerBase. Any feedback
> > is really appreciated. Please, don't be silent.
> >
> >
> > PR [2] contains two major changes (components):
> >
> > 1) Adding channel support for the Communication SPI, which allows from now:
> > - establishing channel connections to the remote node to an arbitrary
> > topic (GridTopic) with predefined channel processing policy;
> > - listening to incoming channel creation events and registering
> > connection handlers on the particular node;
> > - an arbitrary set of channel attributes configured on connection
> > handshake (exchanging the channel attributes );
> > The main API changes in the communication component can be found here [5].
> >
> > 2) Creating a new FileTransmitProcessor, which provide an API for
> > sending and receiving files. It supports:
> > - using different approaches of incoming data handling – buffered and
> > direct (zero-copy approach of FileChannel#transferTo);
> > - transferring data by chunks of predefined size with saving
> > intermediate results;
> > - re-establishing connection if an error occurs and continue file
> > upload\download;
> > - limiting connection bandwidth (upload and download) at runtime;
> > The write\read file handlers API can be found here [6].
> >
> > As we discussed before, I've kept all these as the part of the
> > internal API, so I'm expecting the merge will be quite safe.
> >
> > Summary,
> >
> > JIRA: [1]
> > PR: [2]
> > Upsource: [4]
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-10619
> > [2] https://github.com/apache/ignite/pull/5619
> > [3]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-28%3A+Cluster+peer-2-peer+balancing#IEP-28:Clusterpeer-2-peerbalancing-Filetransferbetweennodes
> > [4] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-1035
> > [5]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-28%3A+Cluster+peer-2-peer+balancing#IEP-28:Clusterpeer-2-peerbalancing-API
> > [6]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-28%3A+Cluster+peer-2-peer+balancing#IEP-28:Clusterpeer-2-peerbalancing-API.1
> >
> >
> > On Tue, 2 Apr 2019 at 15:37, Nikolay Izhikov  wrote:
> > >
> > > Hello, Maxim.
> > >
> > > Thanks for the update.
> > >
> > > Please, let me know when PR will be ready.
> > > I will do the review.
> > >
> > > В Вт, 02/04/2019 в 14:52 +0300, Maxim Muzafarov пишет:
> > > > Ivan,
> > > >
> > > > I tend to agree with you. Let's keep changes as an internal Apache
> > Ignite API.
> > > >
> > > > Igniters,
> > > >
> > > > I need your support by reviewing the issue [1] with my changes of
> > > > CommunicationSpi about establishing direct socket connections between
> > > > cluster nodes. I've prepared the draft PR [2] with such changes. I'll
> > > > add more JUnit tests to this PR and I'll provide all the
> > > > implementation details.
> > > > Can anyone help me with the review?
> > > >
> > > > The issue [1] is related to my work over 

[jira] [Created] (IGNITE-11859) CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works

[Sergey Antonov (JIRA)]

Sergey Antonov created IGNITE-11859:
---

 Summary: 
CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
 Key: IGNITE-11859
 URL: https://issues.apache.org/jira/browse/IGNITE-11859
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Antonov
 Fix For: 2.8


{{parseArgs(Arrays.asList(WAL.text(), WAL_PRINT));}} and 
{{parseArgs(Arrays.asList(WAL.text(), WAL_DELETE));}} should throw 
IllegalArgumentException, but it isn't.

h2. How to reproduce:
Replace test to:

{code:java}
/**
 * Test that experimental command (i.e. WAL command) is disabled by default.
 */
@Test
public void testExperimentalCommandIsDisabled() {
System.clearProperty(IGNITE_ENABLE_EXPERIMENTAL_COMMAND);

GridTestUtils.assertThrows(null, 
()->parseArgs(Arrays.asList(WAL.text(), WAL_PRINT)), 
IllegalArgumentException.class, null);

GridTestUtils.assertThrows(null, 
()->parseArgs(Arrays.asList(WAL.text(), WAL_DELETE)), 
IllegalArgumentException.class, null);
}
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Thin client: transactions support

[Alex Plehanov]

Ivan,

Yes, I have plans to do that (at least for java thin client). Something
like new class "ClientTransactionConfiguration" inside
"ClientConfiguration".

вт, 21 мая 2019 г. в 13:37, Павлухин Иван :

> Alex,
>
> Are you going to introduce settings specifying default values for tx
> concurrency and isolation in client configuration?
>
> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
> >
> > Igor,
> >
> > Perhaps we don't really need to use server's default values for tx
> > parameters. It's a minor fix and can be easily implemented if it will be
> > required in the future.
> > I will update IEP tomorrow regarding point 1 and point 3.
> > Thanks for your feedback.
> >
> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> >
> > > Ivan,
> > >
> > > This may be a good point for a DBMS, but Ignite is much more than just
> a
> > > DBMS and Ignite client code is not just an SQL query (which execution
> > > inherently heavily depends on DBMS). With database user is expecting
> that
> > > server have a lot of control on query execution. But with Ignite, in my
> > > opinion,
> > > user writes generic code including business logic in native language
> and
> > > may
> > > expect more deterministic behaviour from a client.
> > >
> > > Also, thick clients do not use server-side defaults.
> > >
> > > Of course, this question is debatable and It's not like I 100% against
> > > server-side
> > > defaults here, I just suggest to discuss it in more detail.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван 
> wrote:
> > >
> > > > Igor, Alex,
> > > >
> > > > Regarding point 1. I must say that SQL vendors usually allow to
> > > > configure default timeouts and a transaction isolation on a server
> > > > side. E.g. in MySQL you can do a following:
> > > > set local tx_isolation =  -- per SQL client session
> > > > (usually physical network connection)
> > > > set global tx_isolation =  -- global settings, all clients
> > > > (which does not override it) are affected
> > > >
> > > > So, if it is a standard practice why should do it differently? If it
> > > > is not, we can continue discussion. Do we have some examples
> following
> > > > opposite way (client-wide default setting)?
> > > >
> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> > > > >
> > > > > 1. In my opinion, having client-specific transaction parameters is
> > > > expected
> > > > > for
> > > > > client when have different arguments depending on server seems
> > > unexpected
> > > > > and can lead to hard-to-debug bugs and issues when updating from
> old to
> > > > new
> > > > > server versions. Also it goes against common practice with
> arguments of
> > > > thin
> > > > > client and thus, may be even more unexpected.
> > > > >
> > > > > I believe that if we want to add ability to client to adopt some
> > > server's
> > > > > defaults
> > > > > we should implement it as separate feature, and it should not be a
> > > > default
> > > > > behaviour for client, user should explicitly state that they want
> this
> > > > > behaviour,
> > > > > so it won't be unexpected for them.
> > > > >
> > > > > 3. "Flags" field looks like a good solution to me.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
> > > plehanov.a...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi, Igor
> > > > > >
> > > > > > 1. I think it's better to have the ability to configure
> transaction
> > > > > > parameters (for example configure default timeout for all
> clients) on
> > > > > > server-side, then don't have such ability and always use some
> > > > predefined
> > > > > > client-side values (which can be different for different client
> > > > > > implementations). At least default timeout is more server
> specific
> > > then
> > > > > > client specific parameter since it can affect server-side
> processes
> > > > (PME
> > > > > > for example).
> > > > > >
> > > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be
> included to
> > > > each
> > > > > > cache operation under a transaction. And it almost will not
> simplify
> > > > server
> > > > > > code. Also, thin clients don't know how to deal with IgniteUuid
> now,
> > > > there
> > > > > > is no such entity in the protocol, there are no described rules
> on
> > > how
> > > > to
> > > > > > convert it to a string. For monitoring/debugging purposes we
> should
> > > > have
> > > > > > the same presentation of this entity on server and client sides.
> I
> > > > think if
> > > > > > we need to know real tx id on the client side it's better to
> > > > additionally
> > > > > > include this value to OP_TX_START response (we also can
> serialize it
> > > > as a
> > > > > > string to avoid introducing new entity on client side) or create
> a
> > > new
> > > > > > operation to explicitly request tx id (for example OP_TX_INFO).
> > > > > >
> > > > > > 3. Make sense, we can reuse deprecated "flags" field 

Re: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Ilya Kasnacheev]

Hello!

Downloaded source, source compiles.

Downloaded binary, C++ compiles and runs with JDK 8 & 12, node starts on
JDK 8 & 12. However, nodes on JDK 12 with SSL on fail to form a cluster.

-1 from me, I think that SSL & Java 12 should work out of box. I will file
a ticket and fix our launch scripts (as well as .Net and C++ launcher).

Regards,
-- 
Ilya Kasnacheev


вт, 21 мая 2019 г. в 11:42, Dmitriy Pavlov :

> Igniters,
>
>  I encourage everyone to vote, not only PMC. Having an advisory vote does
> not mean this vote does not matter. More Ignite developers check this
> release more possible issues we can find. Steps to be performed to verify
> the release can be found here
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
>
> PMCs,
>
>  This vote could be closed as unsuccessful after 2 days. I intentionally
> set timeline longer due to weekends, but it does not seem to me it helps.
> Please pay attention to this release.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 17 мая 2019 г. в 17:36, Anton Vinogradov :
>
> > Dmitriy,
> >
> > Could you please check release using special TC tasks [1] "Compare w/
> > Previous Release" and "Check RC"
> > Also, I see you used some new task [2] to assembly the release.
> > What's the difference with original task [3]?
> > Please make sure correct task used and remove obsolete one. Don't forget
> to
> > fix task's naming.
> >
> > [1]
> >
> >
> https://ci.ignite.apache.org/project.html?projectId=Releases_ApacheIgniteMain=projectOverview_Releases_ApacheIgniteMain=ignite-2.7.5
> > [2]
> >
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild_Releases_ApacheIgniteMain=ignite-2.7.5=buildTypeStatusDiv
> > [3]
> >
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote_Releases_ApacheIgniteMain=ignite-2.7.5=buildTypeStatusDiv
> >
> >
> > On Fri, May 17, 2019 at 4:49 PM Dmitriy Pavlov 
> wrote:
> >
> > > Dear Sirs!
> > >
> > > We have uploaded release candidate to
> > > https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
> > >
> > > The following staging can be used for a dependent project for testing:
> > >
> https://repository.apache.org/content/repositories/orgapacheignite-1438/
> > >
> > > This is half-release before 2.8 containing Java 11 support and fixes
> for
> > > Native Persistence storage.
> > >
> > > Tag name is 2.7.5-rc3:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.7.5-rc3
> > >
> > > 2.7.5 changes:
> > > * Added Java 11 support
> > > * Fixed infinite looping during SSL handshake, affecting Java
> 11/Windows
> > > * Fixed storage corruption case after incorrectly rotated page
> > > * Erroneous WAL record after incorrectly rotated page processed
> > > automatically
> > > * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> > > * Launch scripts and some Ignite initialization steps were fixed for
> Java
> > > 12
> > > * Fixed indexes corruption on node stop under load
> > > * Fixed case of node crash during node deactivation
> > > * Error message with advice about required JVM parameters printed when
> > Java
> > > 9+ is used
> > > * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
> > >
> > > Complete list of closed issues:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20
> > >
> > >
> > > DEVNOTES
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
> > >
> > > RELEASE NOTES
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f1657940fa12f972;hb=ignite-2.7.5
> > >
> > > The vote is formal, see voting guidelines
> > > https://www.apache.org/foundation/voting.html
> > >
> > > +1 - to accept Apache Ignite 2.7.5-rc3
> > > 0 - don't care either way
> > > -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
> > >
> > > This vote will be open for 6 days till May 23, 14:00 UTC.
> > >
> > >
> >
> https://www.timeanddate.com/countdown/to?year=2019=5=23=14=0=0=utc-1
> > >
> > > Best Regards,
> > > Dmitriy Pavlov
> > >
> >
>

Re: Thin client: transactions support

[Павлухин Иван]

Alex,

Are you going to introduce settings specifying default values for tx
concurrency and isolation in client configuration?

пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
>
> Igor,
>
> Perhaps we don't really need to use server's default values for tx
> parameters. It's a minor fix and can be easily implemented if it will be
> required in the future.
> I will update IEP tomorrow regarding point 1 and point 3.
> Thanks for your feedback.
>
> пн, 20 мая 2019 г. в 15:24, Igor Sapego :
>
> > Ivan,
> >
> > This may be a good point for a DBMS, but Ignite is much more than just a
> > DBMS and Ignite client code is not just an SQL query (which execution
> > inherently heavily depends on DBMS). With database user is expecting that
> > server have a lot of control on query execution. But with Ignite, in my
> > opinion,
> > user writes generic code including business logic in native language and
> > may
> > expect more deterministic behaviour from a client.
> >
> > Also, thick clients do not use server-side defaults.
> >
> > Of course, this question is debatable and It's not like I 100% against
> > server-side
> > defaults here, I just suggest to discuss it in more detail.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван  wrote:
> >
> > > Igor, Alex,
> > >
> > > Regarding point 1. I must say that SQL vendors usually allow to
> > > configure default timeouts and a transaction isolation on a server
> > > side. E.g. in MySQL you can do a following:
> > > set local tx_isolation =  -- per SQL client session
> > > (usually physical network connection)
> > > set global tx_isolation =  -- global settings, all clients
> > > (which does not override it) are affected
> > >
> > > So, if it is a standard practice why should do it differently? If it
> > > is not, we can continue discussion. Do we have some examples following
> > > opposite way (client-wide default setting)?
> > >
> > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> > > >
> > > > 1. In my opinion, having client-specific transaction parameters is
> > > expected
> > > > for
> > > > client when have different arguments depending on server seems
> > unexpected
> > > > and can lead to hard-to-debug bugs and issues when updating from old to
> > > new
> > > > server versions. Also it goes against common practice with arguments of
> > > thin
> > > > client and thus, may be even more unexpected.
> > > >
> > > > I believe that if we want to add ability to client to adopt some
> > server's
> > > > defaults
> > > > we should implement it as separate feature, and it should not be a
> > > default
> > > > behaviour for client, user should explicitly state that they want this
> > > > behaviour,
> > > > so it won't be unexpected for them.
> > > >
> > > > 3. "Flags" field looks like a good solution to me.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
> > plehanov.a...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi, Igor
> > > > >
> > > > > 1. I think it's better to have the ability to configure transaction
> > > > > parameters (for example configure default timeout for all clients) on
> > > > > server-side, then don't have such ability and always use some
> > > predefined
> > > > > client-side values (which can be different for different client
> > > > > implementations). At least default timeout is more server specific
> > then
> > > > > client specific parameter since it can affect server-side processes
> > > (PME
> > > > > for example).
> > > > >
> > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be included to
> > > each
> > > > > cache operation under a transaction. And it almost will not simplify
> > > server
> > > > > code. Also, thin clients don't know how to deal with IgniteUuid now,
> > > there
> > > > > is no such entity in the protocol, there are no described rules on
> > how
> > > to
> > > > > convert it to a string. For monitoring/debugging purposes we should
> > > have
> > > > > the same presentation of this entity on server and client sides. I
> > > think if
> > > > > we need to know real tx id on the client side it's better to
> > > additionally
> > > > > include this value to OP_TX_START response (we also can serialize it
> > > as a
> > > > > string to avoid introducing new entity on client side) or create a
> > new
> > > > > operation to explicitly request tx id (for example OP_TX_INFO).
> > > > >
> > > > > 3. Make sense, we can reuse deprecated "flags" field (undeprecate
> > it),
> > > > > which is included now to each cache operation.
> > > > >
> > > > >
> > > > > пт, 17 мая 2019 г. в 18:49, Igor Sapego :
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I had a look at IEP and have several comments:
> > > > > >
> > > > > > 1. Why would one want to use to use server's default values for
> > > > > Concurrency
> > > > > > or Isolation?
> > > > > > I believe, client should have its own defaults which should be
> > > explicitly
> > > > > > 

[jira] [Created] (IGNITE-11858) IgniteClientRejoinTest.testClientsReconnectAfterStart is flaky

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11858:
--

 Summary: IgniteClientRejoinTest.testClientsReconnectAfterStart is 
flaky
 Key: IGNITE-11858
 URL: https://issues.apache.org/jira/browse/IGNITE-11858
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=594525236246121383=testDetails_IgniteTests24Java8=%3Cdefault%3E]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11857) Investigate performance drop after IGNITE-10078

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-11857:
--

 Summary: Investigate performance drop after IGNITE-10078
 Key: IGNITE-11857
 URL: https://issues.apache.org/jira/browse/IGNITE-11857
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexei Scherbakov


After IGNITE-1078 yardstick tests show performance drop up to 8% in some 
scenarios:

* tx-optim-repRead-put-get

* tx-optimistic-put

* tx-putAll

Partially this is due new update counter implementation, but not only. 
Investigation is required.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Dmitriy Pavlov]

Igniters,

 I encourage everyone to vote, not only PMC. Having an advisory vote does
not mean this vote does not matter. More Ignite developers check this
release more possible issues we can find. Steps to be performed to verify
the release can be found here
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process

PMCs,

 This vote could be closed as unsuccessful after 2 days. I intentionally
set timeline longer due to weekends, but it does not seem to me it helps.
Please pay attention to this release.

Sincerely,
Dmitriy Pavlov

пт, 17 мая 2019 г. в 17:36, Anton Vinogradov :

> Dmitriy,
>
> Could you please check release using special TC tasks [1] "Compare w/
> Previous Release" and "Check RC"
> Also, I see you used some new task [2] to assembly the release.
> What's the difference with original task [3]?
> Please make sure correct task used and remove obsolete one. Don't forget to
> fix task's naming.
>
> [1]
>
> https://ci.ignite.apache.org/project.html?projectId=Releases_ApacheIgniteMain=projectOverview_Releases_ApacheIgniteMain=ignite-2.7.5
> [2]
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild_Releases_ApacheIgniteMain=ignite-2.7.5=buildTypeStatusDiv
> [3]
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote_Releases_ApacheIgniteMain=ignite-2.7.5=buildTypeStatusDiv
>
>
> On Fri, May 17, 2019 at 4:49 PM Dmitriy Pavlov  wrote:
>
> > Dear Sirs!
> >
> > We have uploaded release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
> >
> > The following staging can be used for a dependent project for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1438/
> >
> > This is half-release before 2.8 containing Java 11 support and fixes for
> > Native Persistence storage.
> >
> > Tag name is 2.7.5-rc3:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.7.5-rc3
> >
> > 2.7.5 changes:
> > * Added Java 11 support
> > * Fixed infinite looping during SSL handshake, affecting Java 11/Windows
> > * Fixed storage corruption case after incorrectly rotated page
> > * Erroneous WAL record after incorrectly rotated page processed
> > automatically
> > * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> > * Launch scripts and some Ignite initialization steps were fixed for Java
> > 12
> > * Fixed indexes corruption on node stop under load
> > * Fixed case of node crash during node deactivation
> > * Error message with advice about required JVM parameters printed when
> Java
> > 9+ is used
> > * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
> >
> > Complete list of closed issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20
> >
> >
> > DEVNOTES
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
> >
> > RELEASE NOTES
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f1657940fa12f972;hb=ignite-2.7.5
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.7.5-rc3
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
> >
> > This vote will be open for 6 days till May 23, 14:00 UTC.
> >
> >
> https://www.timeanddate.com/countdown/to?year=2019=5=23=14=0=0=utc-1
> >
> > Best Regards,
> > Dmitriy Pavlov
> >
>

Re: [VOTE] Accept Apache Ignite 2.7.5-rc3

[Dmitriy Pavlov]

Hi Anton,

thank you for pointing that out. This step is mentioned in the release
manager instructions, but I've missed it. But as this release in minor, I
guess we may skip it for now and do in the background.

Hi Peter I., as far I understand from private discussion with Anton, the
new release build chain may be not compatible with this verification step.
Could you please assist with aligning two builds to be compatible? To
update release manager instructions I need to understand which build number
to be used in release verification step.

Sincerely
Dmitriy Pavlov

пт, 17 мая 2019 г. в 17:36, Anton Vinogradov :

> Dmitriy,
>
> Could you please check release using special TC tasks [1] "Compare w/
> Previous Release" and "Check RC"
> Also, I see you used some new task [2] to assembly the release.
> What's the difference with original task [3]?
> Please make sure correct task used and remove obsolete one. Don't forget to
> fix task's naming.
>
> [1]
>
> https://ci.ignite.apache.org/project.html?projectId=Releases_ApacheIgniteMain=projectOverview_Releases_ApacheIgniteMain=ignite-2.7.5
> [2]
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_ApacheIgniteMain_ReleaseBuild_Releases_ApacheIgniteMain=ignite-2.7.5=buildTypeStatusDiv
> [3]
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote_Releases_ApacheIgniteMain=ignite-2.7.5=buildTypeStatusDiv
>
>
> On Fri, May 17, 2019 at 4:49 PM Dmitriy Pavlov  wrote:
>
> > Dear Sirs!
> >
> > We have uploaded release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
> >
> > The following staging can be used for a dependent project for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1438/
> >
> > This is half-release before 2.8 containing Java 11 support and fixes for
> > Native Persistence storage.
> >
> > Tag name is 2.7.5-rc3:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.7.5-rc3
> >
> > 2.7.5 changes:
> > * Added Java 11 support
> > * Fixed infinite looping during SSL handshake, affecting Java 11/Windows
> > * Fixed storage corruption case after incorrectly rotated page
> > * Erroneous WAL record after incorrectly rotated page processed
> > automatically
> > * Addressed ignite.sh failure on Mac OS and Linux, affecting Java 11
> > * Launch scripts and some Ignite initialization steps were fixed for Java
> > 12
> > * Fixed indexes corruption on node stop under load
> > * Fixed case of node crash during node deactivation
> > * Error message with advice about required JVM parameters printed when
> Java
> > 9+ is used
> > * Introduced SYSTEM_CRITICAL_OPERATION_TIMEOUT failure type
> >
> > Complete list of closed issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20'Ignite'%20AND%20fixVersion%20in%20('2.7.5')%20AND%20status%20IN%20(Resolved%2C%20Closed))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20
> >
> >
> > DEVNOTES
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=DEVNOTES.txt;h=307189059ae70834ead4c127cc18295ce4d0735a;hb=ignite-2.7.5
> >
> > RELEASE NOTES
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;h=0a7d2d395b3c9ca1a69ce3f8f1657940fa12f972;hb=ignite-2.7.5
> >
> > The vote is formal, see voting guidelines
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.7.5-rc3
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.7.5-rc3 (explain why)
> >
> > This vote will be open for 6 days till May 23, 14:00 UTC.
> >
> >
> https://www.timeanddate.com/countdown/to?year=2019=5=23=14=0=0=utc-1
> >
> > Best Regards,
> > Dmitriy Pavlov
> >
>