[ANNOUNCE] Apache Ignite 2.1.0 Released

The Apache Ignite Community is pleased to announce the release of Apache Ignite 2.1.0 [1]. https://blogs.apache.org/ignite/entry/apache-ignite-2-1-a This release incorporates a tremendous feature that was donated to the project - Ignite Persistent Store that altogether with the Durable Memory ar

Apache Ignite Site Changed its Face

Igniters, In favor of the 2.1 release we’ve reworked and renewed the front page and some of the existing pages of the site: https://ignite.apache.org The front page reflects the main additions of 2.1, durable memory + persistent store, that opened new opportunities for Ignite. Please welcome ne

Re: [RESULT] [VOTE] Apache Ignite 2.1.0 Release (RC4)

Well, folks, I’m done with the documentation and site update. Mauricio, will update the references soon. So, as far as I see all the main post-release procedures are completed. I’ll send an announcement shortly. *Anton*, just in case, please double check that we hasn’t missed anything signific

Re: Assertions as binary data validation checks in deserialization

May I change this line while working on existing ticket, unless someone else objects? 27 июля 2017 г. 23:37 пользователь "Valentin Kulichenko" < valentin.kuliche...@gmail.com> написал: Makes sense to me. Feel free to create a ticket unless someone else has any objection. However, I think that we

Re: Assertions as binary data validation checks in deserialization

Makes sense to me. Feel free to create a ticket unless someone else has any objection. However, I think that we should revise other code for such places then. Fixing only this one line doesn't change a lot. -Val On Thu, Jul 27, 2017 at 12:55 PM, Andrey Kuznetsov wrote: > Indeed, "let it crash"

Re: Assertions as binary data validation checks in deserialization

Indeed, "let it crash" approach is better than unclear error in some indeterminate place later. Here we depend on data from "inpredictable" source, so assertions are not suitable. 27 июля 2017 г. 22:35 пользователь "Valentin Kulichenko" < valentin.kuliche...@gmail.com> написал: Do you suggest to

Re: Assertions as binary data validation checks in deserialization

Do you suggest to throw an exception instead of assertions? -Val On Thu, Jul 27, 2017 at 11:52 AM, Andrey Kuznetsov wrote: > Valentin, > > I meant the behaviour of this code when corrupted data from the network are > being deserialized. Assertion is no-op in production, and we silently > ignore

Re: [RESULT] [VOTE] Apache Ignite 2.1.0 Release (RC4)

I’m preparing the docs and site for the release. You’ll not recall the front page after it’s out. Mauricio, could you update the “latest” docs to refer to version 2.1.0 For instance this JavaDoc still points to version 2.0.0: https://ignite.apache.org/releases/latest/javadoc/index.html

Re: Assertions as binary data validation checks in deserialization

Valentin, I meant the behaviour of this code when corrupted data from the network are being deserialized. Assertion is no-op in production, and we silently ignore binary format violation. 27 июля 2017 г. 21:09 пользователь "Valentin Kulichenko" < valentin.kuliche...@gmail.com> написал: > Andrey,

Re: Assertions as binary data validation checks in deserialization

Andrey, How will it corrupt the data? Assertions only reads the array, not updates it, right? -Val On Thu, Jul 27, 2017 at 8:54 AM, Andrey Kuznetsov wrote: > Hi Igniters, > > While examining BinaryObjectImpl code I found this curious line in typeId() > method: > > assert arr[off] == GridBina

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

Pavel, This forces user to implement Binarylizable for whole type in case they want to change encoding for one-two fields, right? I really don't like it, why not add default encoding to BinaryTypeConfiguration? -Val On Thu, Jul 27, 2017 at 7:54 AM, Pavel Tupitsyn wrote: > > 1 byte for every fi

Re: [RESULT] [VOTE] Apache Ignite 2.1.0 Release (RC4)

Done. - Maven artifacts released - Sources released - Site updated - Git tag added On Thu, Jul 27, 2017 at 4:24 PM, Anton Vinogradov wrote: > Igniters, > > Apache Ignite 2.1.0 release (RC4) has been accepted. > > 7 "+1" votes received: > > - Valentin Kulichenko (binding) > - Nikolai Tikhonov (b

[GitHub] ignite pull request #2355: IGNITE-5859: Utils.ceilPow2 method fixed.

GitHub user BiryukovVA opened a pull request: https://github.com/apache/ignite/pull/2355 IGNITE-5859: Utils.ceilPow2 method fixed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/BiryukovVA/ignite IGNITE-5859 Alternatively you c

[jira] [Created] (IGNITE-5859) IgniteUtils.ceilPow2 overflow for values greater than 2^30

Vitaliy Biryukov created IGNITE-5859: - Summary: IgniteUtils.ceilPow2 overflow for values greater than 2^30 Key: IGNITE-5859 URL: https://issues.apache.org/jira/browse/IGNITE-5859 Project: Ignite

[jira] [Created] (IGNITE-5860) Client disconnects if server it is connected to goes unresponsive

Evgenii Zhuravlev created IGNITE-5860: - Summary: Client disconnects if server it is connected to goes unresponsive Key: IGNITE-5860 URL: https://issues.apache.org/jira/browse/IGNITE-5860 Project:

[GitHub] ignite pull request #2354: IGNITE-5758: CPP: Added pointer semantics for pri...

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/2354 IGNITE-5758: CPP: Added pointer semantics for primitive types You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-575

[GitHub] ignite pull request #2353: IGNITE-5813: Inconsistent cache store state when ...

GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/2353 IGNITE-5813: Inconsistent cache store state when originating node fails on commit. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain

My first patch into Ignite

Hello, guys. Got my very first patch merged into master. I resolved IGNITE-2190 [1]. I add some warnings about inconsistent Ignite usage: BinaryMarshaller without ignite.withBinary(). Now users can resolve some issues just by carefully reading log. Thanks all the Ignite community and esp

[GitHub] ignite pull request #2256: Ignite 2190

Github user nizhikov closed the pull request at: https://github.com/apache/ignite/pull/2256 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is e

Assertions as binary data validation checks in deserialization

Hi Igniters, While examining BinaryObjectImpl code I found this curious line in typeId() method: assert arr[off] == GridBinaryMarshaller.STRING : arr[off]; Is it OK to check external binary data with assertions? I think it can lead to undefined behaviour on corrupt data from the wire. -- Best

Re: Bug in method

Vitaliy, Let's file an issue and solve it :) Don't forget to add tests. On Thu, Jul 27, 2017 at 5:24 PM, Vitaliy Biryukov < biryukovvitali...@gmail.com> wrote: > Hi, igniters! > > I noticed that the method "IgniteUtils.ceilPow2" can overflow for values > greater than 2^30 and return Integer.MIN_

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

> 1 byte for every field just for this GridBinaryMarshaller.STRING data type remains untouched. We add GridBinaryMarshaller.STRING_ENCODED, which has additional byte for encoding type. This means no overhead for existing code. I think the most common use case is English, which uses 1 byte per char

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

Pavel, what would be the size overhead? Are we adding 1 byte for every field just for this? If you would like to have this info in the binary object directly, can we in this case have some bitmap of field-to-encoding? D. On Thu, Jul 27, 2017 at 9:22 AM, Pavel Tupitsyn wrote: > I'm not sure I ud

Bug in method

Hi, igniters! I noticed that the method "IgniteUtils.ceilPow2" can overflow for values greater than 2^30 and return Integer.MIN_VALUE for them. Maybe this check was skipped for method speed. In this case, we need to add information about this into javaDoc. Current implementation: public static

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

I'm not sure I uderstand how this "per field" configuration is supposed to be implemented. * Marshaller is not tied to a cache. It serializes all kinds of things, like compute job parameters and results. * Raw mode does not involve field names. Also it seems like a complicated and expensive soluti

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

> Igor, it seems like you are advocating the per-cell configuration, not > per-field one. True, some terms mismatch here. > I see your point about C++ and .NET integrations however. Can't we provide > this info at node-join time or table-creation time? This way all nodes will > receive it and you

[jira] [Created] (IGNITE-5858) Ignite Cache 5 Timeout:

Dmitriy Pavlov created IGNITE-5858: -- Summary: Ignite Cache 5 Timeout: Key: IGNITE-5858 URL: https://issues.apache.org/jira/browse/IGNITE-5858 Project: Ignite Issue Type: Bug Affects Ver

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

On Thu, Jul 27, 2017 at 9:04 AM, Igor Sapego wrote: > Just a note from the platforms guy: > > Solution with table-level configuration is going to be significantly > harder to implement for platforms and ODBC then field-level one. > Igor, it seems like you are advocating the per-cell configuratio

[jira] [Created] (IGNITE-5857) Implement cache group destroy

Semen Boikov created IGNITE-5857: Summary: Implement cache group destroy Key: IGNITE-5857 URL: https://issues.apache.org/jira/browse/IGNITE-5857 Project: Ignite Issue Type: Improvement

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

Just a note from the platforms guy: Solution with table-level configuration is going to be significantly harder to implement for platforms and ODBC then field-level one. Also, what about binary objects, which are not stored in cache, but being marshalled? Best Regards, Igor On Wed, Jul 26, 201

Re: сhecksum algorythm

Oleg, Let's check what's used at another popular Apache Projects. On Wed, Jul 26, 2017 at 11:10 PM, Dmitry Pavlov wrote: > Hi Oleg, > > Both MD5 and SHA1 are deprecated and can't be considered as trustfull. > > I think at-least-256 bit member of the SHA-2 family (e. g. sha512) should > be used.

[RESULT] [VOTE] Apache Ignite 2.1.0 Release (RC4)

Igniters, Apache Ignite 2.1.0 release (RC4) has been accepted. 7 "+1" votes received: - Valentin Kulichenko (binding) - Nikolai Tikhonov (binding) - Alexey Kuznetsov (binding) - Yakov Zhdanov (binding) - Konstantin Boudnik (binding) - Andrey Gura (binding) - Denis Magda (binding) Vote thread:

[jira] [Created] (IGNITE-5856) BLAS integration phase 1

Yury Babak created IGNITE-5856: -- Summary: BLAS integration phase 1 Key: IGNITE-5856 URL: https://issues.apache.org/jira/browse/IGNITE-5856 Project: Ignite Issue Type: Sub-task Componen

[GitHub] ignite pull request #2352: IGNITE-5769 Abstract away .NET->Java calls

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2352 IGNITE-5769 Abstract away .NET->Java calls You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-5769 Alternatively you ca

[GitHub] ignite pull request #2351: 8.0.3.ea13

GitHub user agoncharuk opened a pull request: https://github.com/apache/ignite/pull/2351 8.0.3.ea13 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-gg-8.0.3.ea13 Alternatively you can review and app

[jira] [Created] (IGNITE-5855) SQL: BigInteger is supported in SQL queries.

Andrew Mashenkov created IGNITE-5855: Summary: SQL: BigInteger is supported in SQL queries. Key: IGNITE-5855 URL: https://issues.apache.org/jira/browse/IGNITE-5855 Project: Ignite Issue T

[jira] [Created] (IGNITE-5854) Validate baseline topology change history during node joins

Alexey Goncharuk created IGNITE-5854: Summary: Validate baseline topology change history during node joins Key: IGNITE-5854 URL: https://issues.apache.org/jira/browse/IGNITE-5854 Project: Ignite

[jira] [Created] (IGNITE-5853) Provide an interface to mark user attributes used in affinity calculation

Alexey Goncharuk created IGNITE-5853: Summary: Provide an interface to mark user attributes used in affinity calculation Key: IGNITE-5853 URL: https://issues.apache.org/jira/browse/IGNITE-5853 Pro

[jira] [Created] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology

Alexey Goncharuk created IGNITE-5852: Summary: Cache affinity should be calculated wrt baseline topology Key: IGNITE-5852 URL: https://issues.apache.org/jira/browse/IGNITE-5852 Project: Ignite

[jira] [Created] (IGNITE-5851) Automatically activate cluster if baseline topology is reached

Alexey Goncharuk created IGNITE-5851: Summary: Automatically activate cluster if baseline topology is reached Key: IGNITE-5851 URL: https://issues.apache.org/jira/browse/IGNITE-5851 Project: Ignit

[jira] [Created] (IGNITE-5850) Introduce an API for baseline topology for persistence-enabled clusters

Alexey Goncharuk created IGNITE-5850: Summary: Introduce an API for baseline topology for persistence-enabled clusters Key: IGNITE-5850 URL: https://issues.apache.org/jira/browse/IGNITE-5850 Proje

[jira] [Created] (IGNITE-5849) Introduce ignite node persistent meta-store

Alexey Goncharuk created IGNITE-5849: Summary: Introduce ignite node persistent meta-store Key: IGNITE-5849 URL: https://issues.apache.org/jira/browse/IGNITE-5849 Project: Ignite Issue Ty

Re: BinaryObjectBuilder: policy of reusing

On Thu, Jul 27, 2017 at 3:14 AM, Pavel Tupitsyn wrote: > BinaryObjectBuilder reuse should be allowed, performance is an important > point of this mechanism. > Creating a new builder just to modify a single field is wasteful. > > Well-known builders, such as StringBuilder, are reusable. > In this

Re: BinaryObjectBuilder: policy of reusing

BinaryObjectBuilder reuse should be allowed, performance is an important point of this mechanism. Creating a new builder just to modify a single field is wasteful. Well-known builders, such as StringBuilder, are reusable. Pavel On Thu, Jul 27, 2017 at 10:51 AM, Dmitriy Setrakyan wrote: > Serge

Re: BinaryObjectBuilder: policy of reusing

Sergey, why not prohibit any reuse of the builder and throw exception right away? On Wed, Jul 26, 2017 at 6:20 AM, Sergey Chugunov wrote: > Hello folks, > > Recently I filed a ticket [1] with very simple test where correct usage of > BinaryObjectBuilder is vague. > > The issue boils down to the