[jira] [Created] (IGNITE-13116) CPP: Can not compile using msvc 15

[Igor Sapego (Jira)]

Igor Sapego created IGNITE-13116:


 Summary: CPP: Can not compile using msvc 15
 Key: IGNITE-13116
 URL: https://issues.apache.org/jira/browse/IGNITE-13116
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.8.1
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.9


There are linking errors when trying to build Ignite C++ with msvc 15.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Incorrect example in Pull Request checklist: comma after ticket name in commit message

[Ivan Pavlukhin]

So favorite topic =)

> In fact, it's even OK-ish to use it after the ticket name, since we see such 
> tickets in our code base. It's just not the default and should not be 
> recommended to new users.

Agree here. I would be even more liberal: at least there should be a
consistency among our guidelines.

2020-06-03 16:55 GMT+03:00, Andrey Gura :
> Pavel,
>
> Form my point of view, your example doesn't break the format rule.
> Moreover, the historical aspect also encourages us to follow this
> format in the future (again because it makes easier parsing of
> commits' messages).
>
> On Wed, Jun 3, 2020 at 4:44 PM Pavel Tupitsyn  wrote:
>>
>> Andrey, Ilya,
>>
>> I agree that we should follow a standard.
>> What would you say about .NET tickets/PRs?
>>
>> Since the very beginning all those tickets are called ".NET: Foo Bar",
>> and commit messages are "IGNITE- .NET: Add Foo Bar".
>>
>> Is it ok to continue like this, or do you think we should remove ":" here
>> as well?
>>
>> On Wed, Jun 3, 2020 at 4:38 PM Andrey Gura  wrote:
>>
>> > I've prepared PR [1]
>> >
>> > I already tried to discuss commit message format [2] but stumbled upon
>> > some criticism. I still believe that we have to follow only one
>> > standard. It is unrelated with any annoying. It is just normal
>> > practice which also allows avoid of precedents with references to any
>> > concessions (e.g. on code review).
>> >
>> > Simple and sole format also makes easier commits log analysis (of
>> > course we already must remember that we have many commits with
>> > different message formats).
>> >
>> > [1] https://github.com/apache/ignite/pull/7894
>> > [2]
>> > http://apache-ignite-developers.2346864.n4.nabble.com/Commit-message-format-td46573.html
>> >
>> >
>> > On Wed, Jun 3, 2020 at 4:24 PM Ilya Kasnacheev
>> >  wrote:
>> > >
>> > > Hello!
>> > >
>> > > I have just noticed the following:
>> > >
>> > > The pull request title is treated as the final commit message.
>> > > The following pattern must be used: IGNITE-12407: Add Cluster API
>> > > support
>> > > to Java thin client
>> > >
>> > > However, this format conflicts with our "how to contribute" guide:
>> > > - Rename review to include JIRA key and description (example:
>> > > "IGNITE-42
>> > > Support CacheLoader and CacheWriter")
>> > > - There should be no colon after ticket name. Moreover, this is
>> > reinforced
>> > > by our commit messages: there 2x as much entries without colon after
>> > ticket
>> > > name than ones with colon.
>> > >
>> > > So I propose to change this checklist:
>> > > "The following pattern must be used: IGNITE-12407 Add Cluster API
>> > > support
>> > > to Java thin client"
>> > >
>> > > WDYT?
>> > >
>> > > Regards,
>> > > --
>> > > Ilya Kasnacheev
>> >
>


-- 

Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-13115) Master key name can't be changed if Unicode symbols present

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-13115:


 Summary: Master key name can't be changed if Unicode symbols 
present
 Key: IGNITE-13115
 URL: https://issues.apache.org/jira/browse/IGNITE-13115
 Project: Ignite
  Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


The master key name can't be changed if Unicode symbols present.
The reason is the wrong key name length calculation.

{noformat}
[2020-06-03 
18:43:35,289][ERROR][disco-notifier-worker-#84%grid-1%][IgniteTestResources] 
Critical system error detected. Will be handled accordingly to configured 
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class 
o.a.i.i.processors.cache.persistence.StorageException: Unable to write]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException: 
Unable to write
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:476)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:404)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flushOrWait(FsyncFileWriteHandle.java:344)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fsync(FsyncFileWriteHandle.java:586)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileHandleManagerImpl.flush(FsyncFileHandleManagerImpl.java:167)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:903)
at 
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.writeRaw(MetaStorage.java:438)
at 
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.write(MetaStorage.java:401)
at 
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.writeKeysToMetaStore(GridEncryptionManager.java:822)
at 
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.doChangeMasterKey(GridEncryptionManager.java:956)
at 
org.apache.ignite.internal.managers.encryption.GridEncryptionManager.performMasterKeyChange(GridEncryptionManager.java:1086)
at 
org.apache.ignite.internal.util.distributed.DistributedProcess.lambda$new$2(DistributedProcess.java:148)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:732)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2641)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2679)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.lang.IllegalStateException: Failed to 
write record: WALRecord [size=418, chainSize=418, pos=FileWALPointer [idx=0, 
fileOff=402386, len=418], type=MASTER_KEY_CHANGE_RECORD]
... 18 more
Caused by: java.lang.IllegalStateException: Failed to write record: WALRecord 
[size=418, chainSize=418, pos=FileWALPointer [idx=0, fileOff=402386, len=418], 
type=MASTER_KEY_CHANGE_RECORD]
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.fillBuffer(FsyncFileWriteHandle.java:512)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FsyncFileWriteHandle.flush(FsyncFileWriteHandle.java:464)
... 17 more
Caused by: java.nio.BufferOverflowException
at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
at java.nio.ByteBuffer.put(ByteBuffer.java:859)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writePlainRecord(RecordDataV1Serializer.java:1821)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV2Serializer.writePlainRecord(RecordDataV2Serializer.java:332)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer.writeRecord(RecordDataV1Serializer.java:238)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer$2.writeWithHeaders(RecordV2Serializer.java:189)
at 

RE: [CVE-2020-1963] Apache Ignite access to file system disclosure vulnerability

[Nick Popov]

Are you going to provide CVE-2020-1964 patches and patch instructions for 
previous Ignite versions?

Regards,
-Nick

From: Sriveena Mattaparthi 
Sent: Wednesday, June 3, 2020 9:04 AM
To: u...@ignite.apache.org; dev ; annou...@apache.org; 
Apache Security Team 
Subject: COMMERCIAL:RE: [CVE-2020-1963] Apache Ignite access to file system 
disclosure vulnerability

Thanks, Could you please confirm when the analysis will be updated here for the 
CVE logged.
https://nvd.nist.gov/vuln/detail/CVE-2020-1963

Regards,
Sriveena

From: Юрий mailto:jury.gerzhedow...@gmail.com>>
Sent: 03 June 2020 16:02
To: dev mailto:dev@ignite.apache.org>>; 
u...@ignite.apache.org; 
annou...@apache.org; Apache Security Team 
mailto:secur...@apache.org>>; Sriveena Mattaparthi 
mailto:sriveena.mattapar...@ekaplus.com>>
Subject: [CVE-2020-1963] Apache Ignite access to file system disclosure 
vulnerability

Hi All,

Apache Ignite 2.8.1 has been released. The release contain fix of critical 
vulnerability

CVE-2020-1963: Apache Ignite access to file system through predefined H2 SQL 
functions

Severity: Critical

Vendor:
The Apache Software Foundation

Versions Affected:
All versions of Apache Ignite up to 2.8

Impact
An attacker can use embedded H2 SQL functions to access a filesystem for write 
and read.

Description:
Apache Ignite uses H2 database to build SQL distributed execution engine. H2 
provides SQL functions which could be used by attacker to access to a 
filesystem.

Mitigation:
Ignite 2.8 or earlier users should upgrade to 2.8.1
In case SQL is not used at all the issue could be mitigated by removing 
ignite-indexing.jar from Ignite classpath
Risk could be partially mitigated by using non privileged user to start Apache 
Ignite.

Credit:
This issue was discovered by Sriveena Mattaparthi of 
ekaplus.com

--
Живи с улыбкой! :D
“Confidentiality Notice: The contents of this email message and any attachments 
are intended solely for the addressee(s) and may contain confidential and/or 
privileged information and may be legally protected from disclosure. If you are 
not the intended recipient of this message or their agent, or if this message 
has been addressed to you in error, please immediately alert the sender by 
reply email and then delete this message and any attachments. If you are not 
the intended recipient, you are hereby notified that any use, dissemination, 
copying, or storage of this message or its attachments is strictly prohibited.”





CAUTION EXTERNAL EMAIL - The email originated outside the organization.  Do not 
click on any links or open attachments unless you recognize the sender and know 
the content is safe.



TDECU and our subsidiaries are committed to maintaining Member confidentiality. 
Please note this message is being sent using a secure connection to ensure all 
information remains private and confidential. The information contained in this 
message is intended only for the recipient. If the reader of this message is 
not the intended recipient, please delete immediately.

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Alexey Zinoviev]

+1 for initial dates, RM candidate, need June to finish and test features

Model export/import for ML and a fewminor fixes

ср, 3 июн. 2020 г., 18:05 Sergey Antonov :

> Cluster read-only mode and new cluster state change API.
>
> ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev :
>
> > Hello!
> >
> > Can you please clarify what is the scope of 2.9 release?
> >
> > I have a feeling that we don't really have any big features in the
> current
> > 2.9 code base. No Calcite, etc.
> >
> > So I'm asking whether it is worth it.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
> >
> > > Hello Igniters,
> > >
> > > AI 2.8.1 is finally released and as we discussed here [1] its time to
> > start
> > > the discussion about 2.9 release.
> > >
> > > I want to propose myself to be the release manager of the 2.9 release.
> > >
> > > What about release time, I agree with Maxim that we should deliver
> > features
> > > as frequently as possible. If some feature doesn't fit into release
> dates
> > > we should better include it into the next release and schedule the next
> > > release earlier then postpone the current release.
> > >
> > > I propose the following dates for 2.9 release:
> > >
> > > Scope Freeze: June 26, 2020
> > > Code Freeze: July 10, 2020
> > > Voting Date: July 31, 2020
> > > Release Date: August 7, 2019
> > >
> > > WDYT?
> > >
> > > [1] :
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> > >
> >
>
>
> --
> BR, Sergey Antonov
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Sergey Antonov]

Cluster read-only mode and new cluster state change API.

ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev :

> Hello!
>
> Can you please clarify what is the scope of 2.9 release?
>
> I have a feeling that we don't really have any big features in the current
> 2.9 code base. No Calcite, etc.
>
> So I'm asking whether it is worth it.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
>
> > Hello Igniters,
> >
> > AI 2.8.1 is finally released and as we discussed here [1] its time to
> start
> > the discussion about 2.9 release.
> >
> > I want to propose myself to be the release manager of the 2.9 release.
> >
> > What about release time, I agree with Maxim that we should deliver
> features
> > as frequently as possible. If some feature doesn't fit into release dates
> > we should better include it into the next release and schedule the next
> > release earlier then postpone the current release.
> >
> > I propose the following dates for 2.9 release:
> >
> > Scope Freeze: June 26, 2020
> > Code Freeze: July 10, 2020
> > Voting Date: July 31, 2020
> > Release Date: August 7, 2019
> >
> > WDYT?
> >
> > [1] :
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> >
>


-- 
BR, Sergey Antonov

Re: [DISCUSSION] Ignite.C++ and CMake

[Nikolay Izhikov]

Hello.

I will do review of this changes.

> 1 июня 2020 г., в 13:21, Ivan Daschinsky  написал(а):
> 
> Igor, could you please check my PR?
> 
> пт, 29 мая 2020 г. в 15:28, Ivan Daschinsky :
> 
>> Thanks you all. Run patch (I've changed some code also) on TC -- all CPP
>> suites are green (GCC, CLang, Win64)
>> 
>> пт, 29 мая 2020 г. в 15:02, Zhenya Stanilovsky >> :
>> 
>>> 
>>> 
>>> Ivan besides documentation [1]
>>> -s no —  no works
>>> -- catch_system_errors =no — works properly well, tests are passed.
>>> 
>>> boost 1.65
>>> 
>>> [1]
>>> https://www.boost.org/doc/libs/1_65_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/catch_system.html
>>> 
 Hello!
 
 I didn't check tests since I don't develop AI C++, merely use it as user.
 That's where we should wait for Igor Sapego to check.
 
 Regards,
 --
 Ilya Kasnacheev
 
 
 пт, 29 мая 2020 г. в 12:20, Ivan Daschinsky < ivanda...@gmail.com >:
 
> Ilya, thanks a lot! What about tests? I found one flag that must be
> supplied to boost.tests.
> This flag should fix JVM crash of C++ suites on Linux.
> 
> Zhenya Stanilovsky and me have checked, that without this flag tests
>>> failed
> with SIGSEGV early (boost catch this signal from jvm, but it is ok for
> jvm).
> Flag is -catch_system_errors=no. I added it to CTest runner. You can
> invoke it manually and using make test ARGS="-V"
> 
> 
> 
> пт, 29 мая 2020 г. в 11:54, Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com >:
> 
>> Hello!
>> 
>> Looks good to me! But we probably also ask Igor to take a look.
>> 
>> Compiled debug and release, without and with odbc, checked running
>>> thick
>> node and ODBC connection on Linux.
>> 
>> Regards,
>> --
>> Ilya Kasnacheev
>> 
>> 
>> чт, 28 мая 2020 г. в 17:31, Ivan Daschinsky < ivanda...@gmail.com >:
>> 
>>> Ok, PR is ready
>>> https://issues.apache.org/jira/browse/IGNITE-13078
>>> 
>>> Build tested on Mac OS X 10.15 and Ubuntu 20.04 with CMake 3.17.2
>>> and
>> 3.6.1
>>> Unfortunately, I was not able to test on Windows, but principally
>>> it
>> should
>>> works, but minor issues are probable.
>>> 
>>> Instruction is attached in PR.
>>> Any use reports are welcomed!
>>> 
>>> вт, 26 мая 2020 г. в 18:51, Ivan Daschinsky < ivanda...@gmail.com
 :
>>> 
 Stephen, looks great! I do mostly the same things in C++ code.
>>> Thank
>> you!
 
 вт, 26 мая 2020 г. в 18:33, Stephen Darlington <
 stephen.darling...@gridgain.com >:
 
> Not sure if it’ll help, but I made some changes to get it
>>> working
> on a
> Mac with the current built system. There may be some code worth
>> taking.
> 
> https://github.com/apache/ignite/pull/4872 <
> https://github.com/apache/ignite/pull/4872 >
> 
> Regards,
> Stephen
> 
>> On 26 May 2020, at 16:02, Ivan Daschinsky <
>>> ivanda...@gmail.com >
>>> wrote:
>> 
>> I appreciate any help, thank you, Ilya.
>> 
>> Currently I have a small PR without ticket (link in first
> post),but
>> I
>> decided not to file a jira issue before discussion.
>> Now I see, that this feature are of great interest to
>>> community.
> So
>> I
> file
>> a ticket, test myself on my home laptop (ubuntu 20.04)
>> and add detailed instructions to DEVNOTES.txt in a few days.
>> 
>> I would be happy if my someone can follow the instruction and
> write
>> possible issues.
>> 
>> I will notify about status update in this thread in next few
>>> days.
>> 
>> Thank you all very much for support!
>> 
>> 
>> вт, 26 мая 2020 г. в 17:50, Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com
>> :
>> 
>>> Hello!
>>> 
>>> I will assist with checking on Linux if you would contribute
>>> a
>> patch.
>>> Please start with a ticket (or even an IEP maybe?)
>>> 
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>> 
>>> 
>>> вт, 26 мая 2020 г. в 16:47, Ivan Daschinsky <
>>> ivanda...@gmail.com
>> :
>>> 
 Guys, I will certainly thoroughly test my fix not only
>>> unices,
> but
>>> on
 windows too.
 And I will describe it very thoroughly.
 
 When I was C++ developer (more than 10 years ago), I have
>>> not
> any
> trouble
 at all with CMake and Visual Studio 2005.
 Everything works and works good. Moreover, you can build
>>> with
>> NMake,
 msbuild and generate solutions for development.
 
 I suppose, for CI purposes, using 

[jira] [Created] (IGNITE-13114) Off-by-one error in GridPortProcessor port number assertion

[Chris Dennis (Jira)]

Chris Dennis created IGNITE-13114:
-

 Summary: Off-by-one error in GridPortProcessor port number 
assertion
 Key: IGNITE-13114
 URL: https://issues.apache.org/jira/browse/IGNITE-13114
 Project: Ignite
  Issue Type: Bug
Reporter: Chris Dennis


GridPortProcessor asserts that the provided port number is `> 0` and `< 65535`. 
This upper bounds check should be `<= 65535`. Since this is a Java language 
assert it's likely to never be tripped in any production system, but could be 
seen when using Ignite in a testing environment that turns on these assertions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSSION] New Ignite settings for IGNITE-12438 and IGNITE-13013

[Denis Magda]

Ivan,

It feels like Val is driving us in the right direction. Is there any reason
for keeping the current logic when servers can open connections to clients?

-
Denis


On Thu, May 21, 2020 at 4:48 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Ivan,
>
> Have you considered eliminating server to client connections altogether?
> Or, at the very least making the "client to server only" mode the default
> one?
>
> All the suggested names are confusing and not intuitive, and I doubt we
> will be able to find a good one. A server initiating a TCP connection with
> a client is confusing in the first place and creates a usability issue. We
> now want to solve it by introducing an additional configuration
> parameter, and therefore additional complexity. I don't think this is the
> right approach.
>
> What are the drawbacks of permanently switching to client-to-server
> connections? Is there any value provided by the server-to-client option?
>
> As for pair connections, I'm not sure I understand why there is a
> limitation. As far as I know, the idea behind this feature is that we
> maintain two connections between two nodes instead of one, so that every
> connection is used for communication in a single direction only. Why does
> it matter which node initiates the connection? Why can't one of the nodes
> (e.g., a client) initiate both connections, and then use them accordingly?
> Correct me if I'm wrong, but I don't see why we can't do this.
>
> -Val
>
> On Thu, May 21, 2020 at 1:58 PM Denis Magda  wrote:
>
> > Ivan,
> >
> > Considering that the setting controls the way a communication SPI
> > connection is open I would add the new parameter to CommunicationSpi
> > interface naming it as follows:
> >
> > >
> > > CommunicationSpi.connectionInitiationMode
> > > {
> > > BIDIRECTIONAL, //both clients and servers initiate a connection
> > > initiation procedure
> > > CLIENTS_TO_SERVERS //servers cannot open a connection to clients,
> > only
> > > clients can do that
> > > }
> >
> >
> > The problem with the environment type approach is that private networks
> of
> > bare-metal environments usually impose restrictions similar to virtual
> > environments powered by Kubernetes. Thus, environmentType.VIRTUALIZED
> > doesn't cover all the cases and I'm struggling to come up with a
> universal
> > alternative.
> >
> > -
> > Denis
> >
> >
> > On Thu, May 21, 2020 at 5:38 AM Ivan Bessonov 
> > wrote:
> >
> > > Hello Igniters,
> > >
> > > I'd like to discuss with you changes related to [1] and [2]. Both
> issues
> > > are mostly the same so
> > > let's discuss the core idea.
> > >
> > > *Motivation.*
> > >
> > > There are certain environments that don't allow Ignite server nodes to
> > open
> > > TCP connections to
> > > thick clients, e.g. K8S, AWS Lambda or Azure Functions. To operate in
> > such
> > > environments, the
> > > server needs a way to request a client to open an "inverse"
> communication
> > > connection to it.
> > >
> > > I've prepared a PR (still in progress) that introduces new mechanism of
> > > opening connection and
> > > related configuration.
> > >
> > > *Main idea*
> > >
> > > This mechanism is called "communication via discovery" or "inverse
> > > connection", it works as
> > > follows:
> > >  - server that needs to connect to "unreachable" thick client sends a
> > > specific Discovery message
> > >(inverse communication request) to that client;
> > >  - client node upon receiving the request opens communication
> connection
> > to
> > > that server;
> > >  - server sees connection opened by client and proceeds with its task
> > (that
> > > required opening
> > >connection to the client).
> > >
> > > Working name for new configuration parameter for this feature is
> > > environmentType, it is an
> > > enum with two values (again, working names): STANDALONE (default) and
> > > VIRTUALIZED.
> > > It is used as a hint to server to speed-up establishing of connections:
> > > when server sees a client
> > > with VIRTUALIZED environmentType it doesn't try to open connection to
> it
> > > and sends inverse
> > > communication request right away.
> > > If environmentType is STANDALONE then server tries to open a connection
> > in
> > > a regular way
> > > (iterating over all client addresses) and sends request only if all
> > > attempts failed.
> > >
> > > There is a concern about naming of the configuration as it catches only
> > one
> > > use-case: when we
> > > deal with some kind of virtualized environment like K8S.
> > > There are other options I've encountered in private discussion:
> > > - connectionMode - ALWAYS_INITIATE / INITIATE_OR_ACCEPT
> > > - networkConnectivity - REACHABLE_ALWAYS / REACHABLE_ONE_WAY
> > > - communicationViaDiscovery - ALWAYS / FALLBACK
> > > - isReachableFromAllNodes (true/false flag)
> > > - initiateConnectionsOnThisNode (true/false flag).
> > >
> > > *Limitations*
> > >
> > > The feature cannot be used along with pairedConnection setting as 

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Ilya,

I've assumed that the next 2.10 release will start in August, so folks
can commit their changes without a rush. Another option, everyone can
ask in the current thread to wait for their changes :-)

On Wed, 3 Jun 2020 at 17:29, Ilya Kasnacheev  wrote:
>
> Hello!
>
> I think we should have at least a month before code freeze. People may have
> code planned for commit and we don't want to rush them and commit
> sub-optimal code.
>
> Otherwise, +1.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 3 июн. 2020 г. в 17:24, Maxim Muzafarov :
>
> > +1 to start release and Alexey Plekhanov as a release manager.
> >
> >
> > Alexey, can you clarify why we need a month for scope and code freeze
> > phases? What should we wait for? Maybe I'm missing something, but the
> > scope for the release already exists.
> >
> > So, I'd like to suggest the following dates:
> >
> > Code Freeze: June 10, 2020
> > Voting Date: July 1, 2020
> > Release Date: July 7, 2019
> >
> > On Wed, 3 Jun 2020 at 16:38, Nikolay Izhikov  wrote:
> > >
> > > +1 To start release process for 2.9
> > > +1 For Alexey Plekhanov as a release manager.
> > >
> > > > 3 июня 2020 г., в 16:34, Alex Plehanov 
> > написал(а):
> > > >
> > > > Ilya,
> > > >
> > > > We already have a lot of features implemented in the master branch,
> > but not
> > > > released (perhaps not so big as Calcite, but still useful), some of
> > them
> > > > already mentioned in the previous thread:
> > > > - Sandbox for user-defined code
> > > > - .NET: Native Near Cache
> > > > - TDE - Phase-2. Master key rotation
> > > > - Thin client: compute support
> > > > - Snapshots
> > > > - Tasks/services cancellation commands
> > > > etc.
> > > >
> > > > ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev  > >:
> > > >
> > > >> Hello!
> > > >>
> > > >> Can you please clarify what is the scope of 2.9 release?
> > > >>
> > > >> I have a feeling that we don't really have any big features in the
> > current
> > > >> 2.9 code base. No Calcite, etc.
> > > >>
> > > >> So I'm asking whether it is worth it.
> > > >>
> > > >> Regards,
> > > >> --
> > > >> Ilya Kasnacheev
> > > >>
> > > >>
> > > >> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
> > > >>
> > > >>> Hello Igniters,
> > > >>>
> > > >>> AI 2.8.1 is finally released and as we discussed here [1] its time to
> > > >> start
> > > >>> the discussion about 2.9 release.
> > > >>>
> > > >>> I want to propose myself to be the release manager of the 2.9
> > release.
> > > >>>
> > > >>> What about release time, I agree with Maxim that we should deliver
> > > >> features
> > > >>> as frequently as possible. If some feature doesn't fit into release
> > dates
> > > >>> we should better include it into the next release and schedule the
> > next
> > > >>> release earlier then postpone the current release.
> > > >>>
> > > >>> I propose the following dates for 2.9 release:
> > > >>>
> > > >>> Scope Freeze: June 26, 2020
> > > >>> Code Freeze: July 10, 2020
> > > >>> Voting Date: July 31, 2020
> > > >>> Release Date: August 7, 2019
> > > >>>
> > > >>> WDYT?
> > > >>>
> > > >>> [1] :
> > > >>>
> > > >>>
> > > >>
> > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> > > >>>
> > > >>
> > >
> >

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Ilya Kasnacheev]

Hello!

I think we should have at least a month before code freeze. People may have
code planned for commit and we don't want to rush them and commit
sub-optimal code.

Otherwise, +1.

Regards,
-- 
Ilya Kasnacheev


ср, 3 июн. 2020 г. в 17:24, Maxim Muzafarov :

> +1 to start release and Alexey Plekhanov as a release manager.
>
>
> Alexey, can you clarify why we need a month for scope and code freeze
> phases? What should we wait for? Maybe I'm missing something, but the
> scope for the release already exists.
>
> So, I'd like to suggest the following dates:
>
> Code Freeze: June 10, 2020
> Voting Date: July 1, 2020
> Release Date: July 7, 2019
>
> On Wed, 3 Jun 2020 at 16:38, Nikolay Izhikov  wrote:
> >
> > +1 To start release process for 2.9
> > +1 For Alexey Plekhanov as a release manager.
> >
> > > 3 июня 2020 г., в 16:34, Alex Plehanov 
> написал(а):
> > >
> > > Ilya,
> > >
> > > We already have a lot of features implemented in the master branch,
> but not
> > > released (perhaps not so big as Calcite, but still useful), some of
> them
> > > already mentioned in the previous thread:
> > > - Sandbox for user-defined code
> > > - .NET: Native Near Cache
> > > - TDE - Phase-2. Master key rotation
> > > - Thin client: compute support
> > > - Snapshots
> > > - Tasks/services cancellation commands
> > > etc.
> > >
> > > ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev  >:
> > >
> > >> Hello!
> > >>
> > >> Can you please clarify what is the scope of 2.9 release?
> > >>
> > >> I have a feeling that we don't really have any big features in the
> current
> > >> 2.9 code base. No Calcite, etc.
> > >>
> > >> So I'm asking whether it is worth it.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
> > >>
> > >>> Hello Igniters,
> > >>>
> > >>> AI 2.8.1 is finally released and as we discussed here [1] its time to
> > >> start
> > >>> the discussion about 2.9 release.
> > >>>
> > >>> I want to propose myself to be the release manager of the 2.9
> release.
> > >>>
> > >>> What about release time, I agree with Maxim that we should deliver
> > >> features
> > >>> as frequently as possible. If some feature doesn't fit into release
> dates
> > >>> we should better include it into the next release and schedule the
> next
> > >>> release earlier then postpone the current release.
> > >>>
> > >>> I propose the following dates for 2.9 release:
> > >>>
> > >>> Scope Freeze: June 26, 2020
> > >>> Code Freeze: July 10, 2020
> > >>> Voting Date: July 31, 2020
> > >>> Release Date: August 7, 2019
> > >>>
> > >>> WDYT?
> > >>>
> > >>> [1] :
> > >>>
> > >>>
> > >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> > >>>
> > >>
> >
>

Re: [jira] [Created] (IGNITE-13065) Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null

[Ilya Kasnacheev]

Hello!

Maxim, can you please check this, since you have released 2.8.0.

Regards,
-- 
Ilya Kasnacheev


вт, 26 мая 2020 г. в 17:59, Alex Panchenko :

> I have the same issue. Can anybody help with this?
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

+1 to start release and Alexey Plekhanov as a release manager.


Alexey, can you clarify why we need a month for scope and code freeze
phases? What should we wait for? Maybe I'm missing something, but the
scope for the release already exists.

So, I'd like to suggest the following dates:

Code Freeze: June 10, 2020
Voting Date: July 1, 2020
Release Date: July 7, 2019

On Wed, 3 Jun 2020 at 16:38, Nikolay Izhikov  wrote:
>
> +1 To start release process for 2.9
> +1 For Alexey Plekhanov as a release manager.
>
> > 3 июня 2020 г., в 16:34, Alex Plehanov  написал(а):
> >
> > Ilya,
> >
> > We already have a lot of features implemented in the master branch, but not
> > released (perhaps not so big as Calcite, but still useful), some of them
> > already mentioned in the previous thread:
> > - Sandbox for user-defined code
> > - .NET: Native Near Cache
> > - TDE - Phase-2. Master key rotation
> > - Thin client: compute support
> > - Snapshots
> > - Tasks/services cancellation commands
> > etc.
> >
> > ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev :
> >
> >> Hello!
> >>
> >> Can you please clarify what is the scope of 2.9 release?
> >>
> >> I have a feeling that we don't really have any big features in the current
> >> 2.9 code base. No Calcite, etc.
> >>
> >> So I'm asking whether it is worth it.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
> >>
> >>> Hello Igniters,
> >>>
> >>> AI 2.8.1 is finally released and as we discussed here [1] its time to
> >> start
> >>> the discussion about 2.9 release.
> >>>
> >>> I want to propose myself to be the release manager of the 2.9 release.
> >>>
> >>> What about release time, I agree with Maxim that we should deliver
> >> features
> >>> as frequently as possible. If some feature doesn't fit into release dates
> >>> we should better include it into the next release and schedule the next
> >>> release earlier then postpone the current release.
> >>>
> >>> I propose the following dates for 2.9 release:
> >>>
> >>> Scope Freeze: June 26, 2020
> >>> Code Freeze: July 10, 2020
> >>> Voting Date: July 31, 2020
> >>> Release Date: August 7, 2019
> >>>
> >>> WDYT?
> >>>
> >>> [1] :
> >>>
> >>>
> >> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> >>>
> >>
>

[jira] [Created] (IGNITE-13113) CacheEvent#subjectId for cache events with types EventType#EVTS_CACHE

[Denis Garus (Jira)]

Denis Garus created IGNITE-13113:


 Summary: CacheEvent#subjectId for cache events with types 
EventType#EVTS_CACHE
 Key: IGNITE-13113
 URL: https://issues.apache.org/jira/browse/IGNITE-13113
 Project: Ignite
  Issue Type: Bug
  Components: cache, security
Affects Versions: 2.8.1
Reporter: Denis Garus
Assignee: Denis Garus


For cache events with types:
 EVT_CACHE_ENTRY_CREATED,
 EVT_CACHE_ENTRY_DESTROYED,
 EVT_CACHE_OBJECT_PUT,
 EVT_CACHE_OBJECT_READ,
 EVT_CACHE_OBJECT_REMOVED,
 EVT_CACHE_OBJECT_LOCKED,
 EVT_CACHE_OBJECT_UNLOCKED,
 EVT_CACHE_OBJECT_EXPIRED
field CacheEvent#subjectId should be subject id associated with SecuritySubject 
that trigged the cache event.
Currently, CacheEvent#subjectId for these event types is null or equals subject 
id associated with the node that sends a change request.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

RE: [CVE-2020-1963] Apache Ignite access to file system disclosure vulnerability

[Sriveena Mattaparthi]

Thanks, Could you please confirm when the analysis will be updated here for the 
CVE logged.
https://nvd.nist.gov/vuln/detail/CVE-2020-1963

Regards,
Sriveena

From: Юрий 
Sent: 03 June 2020 16:02
To: dev ; u...@ignite.apache.org; annou...@apache.org; 
Apache Security Team ; Sriveena Mattaparthi 

Subject: [CVE-2020-1963] Apache Ignite access to file system disclosure 
vulnerability

Hi All,

Apache Ignite 2.8.1 has been released. The release contain fix of critical 
vulnerability

CVE-2020-1963: Apache Ignite access to file system through predefined H2 SQL 
functions

Severity: Critical

Vendor:
The Apache Software Foundation

Versions Affected:
All versions of Apache Ignite up to 2.8

Impact
An attacker can use embedded H2 SQL functions to access a filesystem for write 
and read.

Description:
Apache Ignite uses H2 database to build SQL distributed execution engine. H2 
provides SQL functions which could be used by attacker to access to a 
filesystem.

Mitigation:
Ignite 2.8 or earlier users should upgrade to 2.8.1
In case SQL is not used at all the issue could be mitigated by removing 
ignite-indexing.jar from Ignite classpath
Risk could be partially mitigated by using non privileged user to start Apache 
Ignite.

Credit:
This issue was discovered by Sriveena Mattaparthi of 
ekaplus.com

--
Живи с улыбкой! :D
“Confidentiality Notice: The contents of this email message and any attachments 
are intended solely for the addressee(s) and may contain confidential and/or 
privileged information and may be legally protected from disclosure. If you are 
not the intended recipient of this message or their agent, or if this message 
has been addressed to you in error, please immediately alert the sender by 
reply email and then delete this message and any attachments. If you are not 
the intended recipient, you are hereby notified that any use, dissemination, 
copying, or storage of this message or its attachments is strictly prohibited.”

Re: Incorrect example in Pull Request checklist: comma after ticket name in commit message

[Andrey Gura]

Pavel,

Form my point of view, your example doesn't break the format rule.
Moreover, the historical aspect also encourages us to follow this
format in the future (again because it makes easier parsing of
commits' messages).

On Wed, Jun 3, 2020 at 4:44 PM Pavel Tupitsyn  wrote:
>
> Andrey, Ilya,
>
> I agree that we should follow a standard.
> What would you say about .NET tickets/PRs?
>
> Since the very beginning all those tickets are called ".NET: Foo Bar",
> and commit messages are "IGNITE- .NET: Add Foo Bar".
>
> Is it ok to continue like this, or do you think we should remove ":" here
> as well?
>
> On Wed, Jun 3, 2020 at 4:38 PM Andrey Gura  wrote:
>
> > I've prepared PR [1]
> >
> > I already tried to discuss commit message format [2] but stumbled upon
> > some criticism. I still believe that we have to follow only one
> > standard. It is unrelated with any annoying. It is just normal
> > practice which also allows avoid of precedents with references to any
> > concessions (e.g. on code review).
> >
> > Simple and sole format also makes easier commits log analysis (of
> > course we already must remember that we have many commits with
> > different message formats).
> >
> > [1] https://github.com/apache/ignite/pull/7894
> > [2]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Commit-message-format-td46573.html
> >
> >
> > On Wed, Jun 3, 2020 at 4:24 PM Ilya Kasnacheev
> >  wrote:
> > >
> > > Hello!
> > >
> > > I have just noticed the following:
> > >
> > > The pull request title is treated as the final commit message.
> > > The following pattern must be used: IGNITE-12407: Add Cluster API support
> > > to Java thin client
> > >
> > > However, this format conflicts with our "how to contribute" guide:
> > > - Rename review to include JIRA key and description (example: "IGNITE-42
> > > Support CacheLoader and CacheWriter")
> > > - There should be no colon after ticket name. Moreover, this is
> > reinforced
> > > by our commit messages: there 2x as much entries without colon after
> > ticket
> > > name than ones with colon.
> > >
> > > So I propose to change this checklist:
> > > "The following pattern must be used: IGNITE-12407 Add Cluster API support
> > > to Java thin client"
> > >
> > > WDYT?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> >

Re: Incorrect example in Pull Request checklist: comma after ticket name in commit message

[Ilya Kasnacheev]

Hello!

I think that it's OK to use colon anywhere in a commit message, other than
directly after the ticket name.
In fact, it's even OK-ish to use it after the ticket name, since we see
such tickets in our code base. It's just not the default and should not be
recommended to new users.

Regards,
-- 
Ilya Kasnacheev


ср, 3 июн. 2020 г. в 16:44, Pavel Tupitsyn :

> Andrey, Ilya,
>
> I agree that we should follow a standard.
> What would you say about .NET tickets/PRs?
>
> Since the very beginning all those tickets are called ".NET: Foo Bar",
> and commit messages are "IGNITE- .NET: Add Foo Bar".
>
> Is it ok to continue like this, or do you think we should remove ":" here
> as well?
>
> On Wed, Jun 3, 2020 at 4:38 PM Andrey Gura  wrote:
>
> > I've prepared PR [1]
> >
> > I already tried to discuss commit message format [2] but stumbled upon
> > some criticism. I still believe that we have to follow only one
> > standard. It is unrelated with any annoying. It is just normal
> > practice which also allows avoid of precedents with references to any
> > concessions (e.g. on code review).
> >
> > Simple and sole format also makes easier commits log analysis (of
> > course we already must remember that we have many commits with
> > different message formats).
> >
> > [1] https://github.com/apache/ignite/pull/7894
> > [2]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Commit-message-format-td46573.html
> >
> >
> > On Wed, Jun 3, 2020 at 4:24 PM Ilya Kasnacheev
> >  wrote:
> > >
> > > Hello!
> > >
> > > I have just noticed the following:
> > >
> > > The pull request title is treated as the final commit message.
> > > The following pattern must be used: IGNITE-12407: Add Cluster API
> support
> > > to Java thin client
> > >
> > > However, this format conflicts with our "how to contribute" guide:
> > > - Rename review to include JIRA key and description (example:
> "IGNITE-42
> > > Support CacheLoader and CacheWriter")
> > > - There should be no colon after ticket name. Moreover, this is
> > reinforced
> > > by our commit messages: there 2x as much entries without colon after
> > ticket
> > > name than ones with colon.
> > >
> > > So I propose to change this checklist:
> > > "The following pattern must be used: IGNITE-12407 Add Cluster API
> support
> > > to Java thin client"
> > >
> > > WDYT?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> >
>

[jira] [Created] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED

[Denis Garus (Jira)]

Denis Garus created IGNITE-13112:


 Summary: CacheEvent#subjectId is always null for cache events with 
types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
 Key: IGNITE-13112
 URL: https://issues.apache.org/jira/browse/IGNITE-13112
 Project: Ignite
  Issue Type: Bug
  Components: cache, security
Reporter: Denis Garus


CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have 
fieldCacheEvent#subjectId always null. 
CacheEvent#subjectId should be subject id associated with SecuritySubject that 
trigged the cache event.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Incorrect example in Pull Request checklist: comma after ticket name in commit message

[Pavel Tupitsyn]

Andrey, Ilya,

I agree that we should follow a standard.
What would you say about .NET tickets/PRs?

Since the very beginning all those tickets are called ".NET: Foo Bar",
and commit messages are "IGNITE- .NET: Add Foo Bar".

Is it ok to continue like this, or do you think we should remove ":" here
as well?

On Wed, Jun 3, 2020 at 4:38 PM Andrey Gura  wrote:

> I've prepared PR [1]
>
> I already tried to discuss commit message format [2] but stumbled upon
> some criticism. I still believe that we have to follow only one
> standard. It is unrelated with any annoying. It is just normal
> practice which also allows avoid of precedents with references to any
> concessions (e.g. on code review).
>
> Simple and sole format also makes easier commits log analysis (of
> course we already must remember that we have many commits with
> different message formats).
>
> [1] https://github.com/apache/ignite/pull/7894
> [2]
> http://apache-ignite-developers.2346864.n4.nabble.com/Commit-message-format-td46573.html
>
>
> On Wed, Jun 3, 2020 at 4:24 PM Ilya Kasnacheev
>  wrote:
> >
> > Hello!
> >
> > I have just noticed the following:
> >
> > The pull request title is treated as the final commit message.
> > The following pattern must be used: IGNITE-12407: Add Cluster API support
> > to Java thin client
> >
> > However, this format conflicts with our "how to contribute" guide:
> > - Rename review to include JIRA key and description (example: "IGNITE-42
> > Support CacheLoader and CacheWriter")
> > - There should be no colon after ticket name. Moreover, this is
> reinforced
> > by our commit messages: there 2x as much entries without colon after
> ticket
> > name than ones with colon.
> >
> > So I propose to change this checklist:
> > "The following pattern must be used: IGNITE-12407 Add Cluster API support
> > to Java thin client"
> >
> > WDYT?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
>

Re: Incorrect example in Pull Request checklist: comma after ticket name in commit message

[Andrey Gura]

I've prepared PR [1]

I already tried to discuss commit message format [2] but stumbled upon
some criticism. I still believe that we have to follow only one
standard. It is unrelated with any annoying. It is just normal
practice which also allows avoid of precedents with references to any
concessions (e.g. on code review).

Simple and sole format also makes easier commits log analysis (of
course we already must remember that we have many commits with
different message formats).

[1] https://github.com/apache/ignite/pull/7894
[2] 
http://apache-ignite-developers.2346864.n4.nabble.com/Commit-message-format-td46573.html


On Wed, Jun 3, 2020 at 4:24 PM Ilya Kasnacheev
 wrote:
>
> Hello!
>
> I have just noticed the following:
>
> The pull request title is treated as the final commit message.
> The following pattern must be used: IGNITE-12407: Add Cluster API support
> to Java thin client
>
> However, this format conflicts with our "how to contribute" guide:
> - Rename review to include JIRA key and description (example: "IGNITE-42
> Support CacheLoader and CacheWriter")
> - There should be no colon after ticket name. Moreover, this is reinforced
> by our commit messages: there 2x as much entries without colon after ticket
> name than ones with colon.
>
> So I propose to change this checklist:
> "The following pattern must be used: IGNITE-12407 Add Cluster API support
> to Java thin client"
>
> WDYT?
>
> Regards,
> --
> Ilya Kasnacheev

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

+1 To start release process for 2.9
+1 For Alexey Plekhanov as a release manager.

> 3 июня 2020 г., в 16:34, Alex Plehanov  написал(а):
> 
> Ilya,
> 
> We already have a lot of features implemented in the master branch, but not
> released (perhaps not so big as Calcite, but still useful), some of them
> already mentioned in the previous thread:
> - Sandbox for user-defined code
> - .NET: Native Near Cache
> - TDE - Phase-2. Master key rotation
> - Thin client: compute support
> - Snapshots
> - Tasks/services cancellation commands
> etc.
> 
> ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev :
> 
>> Hello!
>> 
>> Can you please clarify what is the scope of 2.9 release?
>> 
>> I have a feeling that we don't really have any big features in the current
>> 2.9 code base. No Calcite, etc.
>> 
>> So I'm asking whether it is worth it.
>> 
>> Regards,
>> --
>> Ilya Kasnacheev
>> 
>> 
>> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
>> 
>>> Hello Igniters,
>>> 
>>> AI 2.8.1 is finally released and as we discussed here [1] its time to
>> start
>>> the discussion about 2.9 release.
>>> 
>>> I want to propose myself to be the release manager of the 2.9 release.
>>> 
>>> What about release time, I agree with Maxim that we should deliver
>> features
>>> as frequently as possible. If some feature doesn't fit into release dates
>>> we should better include it into the next release and schedule the next
>>> release earlier then postpone the current release.
>>> 
>>> I propose the following dates for 2.9 release:
>>> 
>>> Scope Freeze: June 26, 2020
>>> Code Freeze: July 10, 2020
>>> Voting Date: July 31, 2020
>>> Release Date: August 7, 2019
>>> 
>>> WDYT?
>>> 
>>> [1] :
>>> 
>>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
>>> 
>> 

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Alex Plehanov]

Ilya,

We already have a lot of features implemented in the master branch, but not
released (perhaps not so big as Calcite, but still useful), some of them
already mentioned in the previous thread:
 - Sandbox for user-defined code
 - .NET: Native Near Cache
 - TDE - Phase-2. Master key rotation
 - Thin client: compute support
 - Snapshots
 - Tasks/services cancellation commands
etc.

ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev :

> Hello!
>
> Can you please clarify what is the scope of 2.9 release?
>
> I have a feeling that we don't really have any big features in the current
> 2.9 code base. No Calcite, etc.
>
> So I'm asking whether it is worth it.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
>
> > Hello Igniters,
> >
> > AI 2.8.1 is finally released and as we discussed here [1] its time to
> start
> > the discussion about 2.9 release.
> >
> > I want to propose myself to be the release manager of the 2.9 release.
> >
> > What about release time, I agree with Maxim that we should deliver
> features
> > as frequently as possible. If some feature doesn't fit into release dates
> > we should better include it into the next release and schedule the next
> > release earlier then postpone the current release.
> >
> > I propose the following dates for 2.9 release:
> >
> > Scope Freeze: June 26, 2020
> > Code Freeze: July 10, 2020
> > Voting Date: July 31, 2020
> > Release Date: August 7, 2019
> >
> > WDYT?
> >
> > [1] :
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> >
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Anton Vinogradov]

Cellular switch

On Wed, Jun 3, 2020 at 4:10 PM Nikolay Izhikov  wrote:

> Snapshots.
>
> > 3 июня 2020 г., в 16:10, Ilya Kasnacheev 
> написал(а):
> >
> > Hello!
> >
> > Can you please clarify what is the scope of 2.9 release?
> >
> > I have a feeling that we don't really have any big features in the
> current
> > 2.9 code base. No Calcite, etc.
> >
> > So I'm asking whether it is worth it.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
> >
> >> Hello Igniters,
> >>
> >> AI 2.8.1 is finally released and as we discussed here [1] its time to
> start
> >> the discussion about 2.9 release.
> >>
> >> I want to propose myself to be the release manager of the 2.9 release.
> >>
> >> What about release time, I agree with Maxim that we should deliver
> features
> >> as frequently as possible. If some feature doesn't fit into release
> dates
> >> we should better include it into the next release and schedule the next
> >> release earlier then postpone the current release.
> >>
> >> I propose the following dates for 2.9 release:
> >>
> >> Scope Freeze: June 26, 2020
> >> Code Freeze: July 10, 2020
> >> Voting Date: July 31, 2020
> >> Release Date: August 7, 2019
> >>
> >> WDYT?
> >>
> >> [1] :
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> >>
>
>

Incorrect example in Pull Request checklist: comma after ticket name in commit message

[Ilya Kasnacheev]

Hello!

I have just noticed the following:

The pull request title is treated as the final commit message.
The following pattern must be used: IGNITE-12407: Add Cluster API support
to Java thin client

However, this format conflicts with our "how to contribute" guide:
- Rename review to include JIRA key and description (example: "IGNITE-42
Support CacheLoader and CacheWriter")
- There should be no colon after ticket name. Moreover, this is reinforced
by our commit messages: there 2x as much entries without colon after ticket
name than ones with colon.

So I propose to change this checklist:
"The following pattern must be used: IGNITE-12407 Add Cluster API support
to Java thin client"

WDYT?

Regards,
-- 
Ilya Kasnacheev

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Ilya Kasnacheev]

Hello!

Can you please clarify what is the scope of 2.9 release?

I have a feeling that we don't really have any big features in the current
2.9 code base. No Calcite, etc.

So I'm asking whether it is worth it.

Regards,
-- 
Ilya Kasnacheev


ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :

> Hello Igniters,
>
> AI 2.8.1 is finally released and as we discussed here [1] its time to start
> the discussion about 2.9 release.
>
> I want to propose myself to be the release manager of the 2.9 release.
>
> What about release time, I agree with Maxim that we should deliver features
> as frequently as possible. If some feature doesn't fit into release dates
> we should better include it into the next release and schedule the next
> release earlier then postpone the current release.
>
> I propose the following dates for 2.9 release:
>
> Scope Freeze: June 26, 2020
> Code Freeze: July 10, 2020
> Voting Date: July 31, 2020
> Release Date: August 7, 2019
>
> WDYT?
>
> [1] :
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

Snapshots.

> 3 июня 2020 г., в 16:10, Ilya Kasnacheev  
> написал(а):
> 
> Hello!
> 
> Can you please clarify what is the scope of 2.9 release?
> 
> I have a feeling that we don't really have any big features in the current
> 2.9 code base. No Calcite, etc.
> 
> So I'm asking whether it is worth it.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :
> 
>> Hello Igniters,
>> 
>> AI 2.8.1 is finally released and as we discussed here [1] its time to start
>> the discussion about 2.9 release.
>> 
>> I want to propose myself to be the release manager of the 2.9 release.
>> 
>> What about release time, I agree with Maxim that we should deliver features
>> as frequently as possible. If some feature doesn't fit into release dates
>> we should better include it into the next release and schedule the next
>> release earlier then postpone the current release.
>> 
>> I propose the following dates for 2.9 release:
>> 
>> Scope Freeze: June 26, 2020
>> Code Freeze: July 10, 2020
>> Voting Date: July 31, 2020
>> Release Date: August 7, 2019
>> 
>> WDYT?
>> 
>> [1] :
>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
>> 

[MTCGA]: new failures in builds [5360312] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master GridVersionSelfTest.testVersions 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2028128591644736718=%3Cdefault%3E=testDetails
 Changes may lead to failure were done by 
 - maxim  
https://ci.ignite.apache.org/viewModification.html?modId=902628

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 15:46:30 03-06-2020 

[jira] [Created] (IGNITE-13111) Simplify backward checking of node connection.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13111:
-

 Summary: Simplify backward checking of node connection.
 Key: IGNITE-13111
 URL: https://issues.apache.org/jira/browse/IGNITE-13111
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


We should fix several drawbacks in the backward checking of failed node. They 
prolong node failure detection upto: 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. 

See:
* ‘_NodeFailureResearch.patch_'. It creates test 'FailureDetectionResearch' 
which emulates long answears on a failed node and measures failure detection 
delays.
* '_FailureDetectionResearch.txt_' - results of the test.
* '_FailureDetectionResearch_fixed.txt_' - results of the test after this fix.
* '_WostCaseStepByStep.txt_' - description how the worst case happens.


*Suggestion:*

1) We can simplify backward connection checking as we implement IGNITE-13012. 
Once we get robust, predictable connection ping, we don't need to check 
previous node because we can see whether it sent ping to current node within 
failure detection timeout. If not, previous node can be considered lost.

Instead of:
{code:java}
// Node cannot connect to it's next (for local node it's previous).
// Need to check connectivity to it.
long rcvdTime = lastRingMsgReceivedTime;
long now = U.currentTimeMillis();

// We got message from previous in less than double 
connection check interval.
boolean ok = rcvdTime + effectiveExchangeTimeout() >= 
now;
TcpDiscoveryNode previous = null;

if (ok) {
// Check case when previous node suddenly died. 
This will speed up
// node failing.

  Checking connection to previous node
 }
{code}

2) Then, seems we can remove:
{code:java}
ServerImpl.SocketReader.isConnectionRefused(SocketAddress addr);
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Dmitriy Pavlov]

++1 for Alexey as a release manager, that's good we are keeping a rotation
of RMs so every committer/PMC knows how to release the code.

0 for dates, actually, it is up to contributors to propose alternatives.
All in all, it is up to the discussion's course.

Sincerely,
Dmitriy Pavlov

ср, 3 июн. 2020 г. в 14:45, Alex Plehanov :

> Hello Igniters,
>
> AI 2.8.1 is finally released and as we discussed here [1] its time to start
> the discussion about 2.9 release.
>
> I want to propose myself to be the release manager of the 2.9 release.
>
> What about release time, I agree with Maxim that we should deliver features
> as frequently as possible. If some feature doesn't fit into release dates
> we should better include it into the next release and schedule the next
> release earlier then postpone the current release.
>
> I propose the following dates for 2.9 release:
>
> Scope Freeze: June 26, 2020
> Code Freeze: July 10, 2020
> Voting Date: July 31, 2020
> Release Date: August 7, 2019
>
> WDYT?
>
> [1] :
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
>

Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Alex Plehanov]

Hello Igniters,

AI 2.8.1 is finally released and as we discussed here [1] its time to start
the discussion about 2.9 release.

I want to propose myself to be the release manager of the 2.9 release.

What about release time, I agree with Maxim that we should deliver features
as frequently as possible. If some feature doesn't fit into release dates
we should better include it into the next release and schedule the next
release earlier then postpone the current release.

I propose the following dates for 2.9 release:

Scope Freeze: June 26, 2020
Code Freeze: July 10, 2020
Voting Date: July 31, 2020
Release Date: August 7, 2019

WDYT?

[1] :
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575

Re: [DISCUSS] Make AtomicConfiguration more flexible

[Ilya Kasnacheev]

Hello!

I think it makes sense.

I think we should not over-engineer it now. Let's just allow to specify
your own CacheConfiguration and take all the risks.

Regards,
-- 
Ilya Kasnacheev


вт, 2 июн. 2020 г. в 17:37, Vladimir Pligin :

> Hi Igniters!
>
> It seems that AtomicConfiguration
> (
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/AtomicConfiguration.html
> )
> is not flexible enough to cover some reasonable use-cases. It's possible to
> configure only cache mode, group name, affinity and backups of the
> underlying cache. It would be great to have the ability to inject
> full-fledged CacheConfiguration there. For example there's no
> straightforward way to configure a node filter, this scenario can be useful
> as sometimes it's required to avoid atomic sequence residence on a subset
> of
> nodes.
>
> What do you think about it, are there any pitfalls?
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[CVE-2020-1963] Apache Ignite access to file system disclosure vulnerability

[Юрий]

Hi All,

Apache Ignite 2.8.1 has been released. The release contain fix of critical
vulnerability

CVE-2020-1963: Apache Ignite access to file system through predefined H2
SQL functions

Severity: Critical

Vendor:
The Apache Software Foundation

Versions Affected:
All versions of Apache Ignite up to 2.8

Impact
An attacker can use embedded H2 SQL functions to access a filesystem for
write and read.

Description:
Apache Ignite uses H2 database to build SQL distributed execution engine.
H2 provides SQL functions which could be used by attacker to access to a
filesystem.

Mitigation:
Ignite 2.8 or earlier users should upgrade to 2.8.1
In case SQL is not used at all the issue could be mitigated by removing
ignite-indexing.jar from Ignite classpath
Risk could be partially mitigated by using non privileged user to start
Apache Ignite.

Credit:
This issue was discovered by Sriveena Mattaparthi of ekaplus.com

-- 
Живи с улыбкой! :D

Re: Prevent insertion of cache entry if the binary field type and the type of the query entity do not match.

[Sergey Kalashnikov]

Guys,

I've taken the liberty of creating the ticket
(https://issues.apache.org/jira/browse/IGNITE-13110) for the proposed
changes.
I did some prototyping as well. You may find the draft code/test
changes in PR https://github.com/apache/ignite/pull/7893
Would appreciate if you can look at it and provide feedback.

Thanks a lot.
--
Sergei K.

чт, 28 мая 2020 г. в 13:45, Ivan Daschinsky :
>
> I think this feature quite easy to implement. Before put in cache tree, we
> can iterate over query descriptor fields and check whether
> this field presents in binary object and if typeId is the same.
> But I think there can l be a quite noticeable performance penalty when this
> feature is enabled.
> It should be thoroughly benchmarked.
>
>
>
> чт, 28 мая 2020 г. в 10:22, Alex Plehanov :
>
> > Pavel, Ilya,
> >
> > I think we should implement such a check on insert. It can be optional (for
> > example enabled by property in SqlConfiguration). The sooner we found the
> > problem - the better.
> >
> > вт, 26 мая 2020 г. в 17:56, Ilya Kasnacheev :
> >
> > > Hello!
> > >
> > > I'm not aware about any mechanism like this one built in Apache Ignite.
> > >
> > > I advise you to wrap Ignite's APIs into ones of your own and avoid using
> > > raw Ignite API. This way you will make sure to do these checks on your
> > own.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 25 мая 2020 г. в 15:22, Pavel Pereslegin :
> > >
> > > > Hello Igniters.
> > > >
> > > > If type of binary field does not match query entity field type we
> > > > still able to insert such entry into cache, but can't query it.
> > > > In the following example we have query entity with the UUID field
> > > > "name", but we insert String field "name" using binary object.
> > > >
> > > > IgniteCache cache = grid(0).createCache(
> > > > new CacheConfiguration<>("testCache").setQueryEntities(
> > > > Collections.singletonList(
> > > > new QueryEntity()
> > > > .setKeyFieldName("id")
> > > > .setValueType("Person")
> > > > .setFields(new LinkedHashMap<>(
> > > > F.asMap("id", "java.lang.Integer",
> > > > "name", "java.util.UUID"));
> > > >
> > > > BinaryObject obj = grid(0).binary().builder("Person")
> > > > .setField("id", 1)
> > > > .setField("name", UUID.randomUUID().toString())
> > > > .build();
> > > >
> > > > cache.put(1, obj);
> > > > assertEquals(obj, cache.withKeepBinary().get(1));
> > > >
> > > > String sql = "select id, name from Person where id=1";
> > > >
> > > > grid(0).context().query()
> > > > .querySqlFields(new
> > > > SqlFieldsQuery(sql).setSchema("testCache"), true)
> > > > .getAll(); // java.lang.ClassCastException:
> > > > java.lang.String cannot be cast to java.util.UUID
> > > >
> > > > The object was successfully inserted, but the "name"-field cannot be
> > > > read using sql.
> > > >
> > > > Should it be better to prevent insertion of cache entry if the binary
> > > > field type and the type of the query entity field do not match?
> > > >
> > >
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy

[jira] [Created] (IGNITE-13110) An option to validate field types against SQL schema on key-value insert

[Sergey Kalashnikov (Jira)]

Sergey Kalashnikov created IGNITE-13110:
---

 Summary: An option to validate field types against SQL schema on 
key-value insert
 Key: IGNITE-13110
 URL: https://issues.apache.org/jira/browse/IGNITE-13110
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Kalashnikov
Assignee: Sergey Kalashnikov


Let's add a configurable option to prevent insertion of key-value pairs that 
aren't compatible with SQL schema.

An option can be added on {{SqlConfiguration}} level or even per 
{{QueryEntity}}.

The checks can be performed within the existing 
{{GridQueryTypeDescriptor#validateKeyAndValue}} facility that seems to be well 
suited for this task.

This addition will prevent the problems when values successfully added to the 
cache later produce errors when queried with SQL.

See discussion : 
http://apache-ignite-developers.2346864.n4.nabble.com/Prevent-insertion-of-cache-entry-if-the-binary-field-type-and-the-type-of-the-query-entity-do-not-ma-td47678.html







--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13109) Skip metastorage entries that can not be unmarshalled

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-13109:


 Summary: Skip metastorage entries that can not be unmarshalled
 Key: IGNITE-13109
 URL: https://issues.apache.org/jira/browse/IGNITE-13109
 Project: Ignite
  Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita


Need to skip metastorage entries that can not be unmarshalled (created by the 
old cluster). It leads that nodes can't join to the first started node:

{noformat}
[SEVERE][main][PersistenceBasicCompatibilityTest1] Got exception while starting 
(will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2035)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1314)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2063)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1116)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:636)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:562)
at org.apache.ignite.Ignition.start(Ignition.java:328)
at 
org.apache.ignite.testframework.junits.multijvm.IgniteNodeRunner.main(IgniteNodeRunner.java:74)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, 
marsh=JdkMarshaller 
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@77b14724], 
reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=5, 
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null, 
skipAddrsRandomization=false]
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:302)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:948)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:2030)
... 8 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: Unable to unmarshal 
key=ignite.testOldClusterTag
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2009)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1116)
at org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:427)
at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2111)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:299)
... 10 more
{noformat}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13108) Decrease number of clients for IgniteCache150ClientsTest

[Maxim Muzafarov (Jira)]

Maxim Muzafarov created IGNITE-13108:


 Summary: Decrease number of clients for IgniteCache150ClientsTest
 Key: IGNITE-13108
 URL: https://issues.apache.org/jira/browse/IGNITE-13108
 Project: Ignite
  Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


The number of clients for the {{IgniteCache150ClientsTest}} due to not 
sufficient TeamCity resources available on agents.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)