Re: Future of Ignite transactions

OK, if we must change the current behavior, let's discuss the new design. My comments/questions are below... On Mon, Sep 25, 2017 at 12:09 PM, Vladimir Ozerov wrote: > Folks, > > Sorry for late reply. I had a chat with several Ignite veterans today. We > tried to design

Re: Should we take care of Java 9 in Ignite 2.0 scope?

Yes, have a minimum set at Java 8 (ML contributors would greatly appreciate that...). -- Nikita Ivanov On Tue, Sep 26, 2017 at 6:16 PM, Denis Magda wrote: > You meant Java 7 drop I guess. That's a good question. Hope this happens > soon. > > Denis > > On Tuesday,

Re: Should we take care of Java 9 in Ignite 2.0 scope?

You meant Java 7 drop I guess. That's a good question. Hope this happens soon. Denis On Tuesday, September 26, 2017, Nikita Ivanov wrote: > What about Java 8 to begin with? > > -- > Nikita Ivanov > > > On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda

Re: Should we take care of Java 9 in Ignite 2.0 scope?

What about Java 8 to begin with? -- Nikita Ivanov On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda wrote: > Eventually now it’s time to put all the doubts aside on when Ignite should > support JDK 9. The JDK is production ready and was released not long time > ago. > > Is there

Re: Integration of Spark and Ignite. Prototype.

I will review in the next few days. -Val On Tue, Sep 26, 2017 at 2:23 PM, Denis Magda wrote: > Hello Nikolay, > > This is good news. Finally this capability is coming to Ignite. > > Val, Vladimir, could you do a preliminary review? > > Answering on your questions. > > 1.

Re: Should we take care of Java 9 in Ignite 2.0 scope?

Eventually now it’s time to put all the doubts aside on when Ignite should support JDK 9. The JDK is production ready and was released not long time ago. Is there anyone interested to enable JDK 9 for Ignite? — Denis > On Mar 24, 2017, at 10:22 AM, Denis Magda wrote: > >

Re: An issue of Ignite In-Menory Sql Grid since version 2.0.0

Denis Mek., How do you suggest executing the same query without SQL? Please be specific if you advise discontinuing the SQL for the use case. Alex P., Vladimir, What’s the main reason of WITH RECURSIVE removal? Why it worked before and broken now?

Re: Contributors Permissions for Ignite

Hi, done! Welcome to the Ignite community! Get familiar with Ignite development process described here: https://cwiki.apache.org/confluence/display/IGNITE/Development+Process Instructions on how to contribute can be found here:

Re: Integration of Spark and Ignite. Prototype.

Hello Nikolay, This is good news. Finally this capability is coming to Ignite. Val, Vladimir, could you do a preliminary review? Answering on your questions. 1. Yardstick should be enough for performance measurements. As a Spark user, I will be curious to know what’s the point of this

[GitHub] ignite pull request #2759: exception when trying to check threadId for remot...

GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/2759 exception when trying to check threadId for remote You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite ignite-5714-6 Alternatively you

[jira] [Created] (IGNITE-6507) Commit can be lost in network split scenario

Alexei Scherbakov created IGNITE-6507: - Summary: Commit can be lost in network split scenario Key: IGNITE-6507 URL: https://issues.apache.org/jira/browse/IGNITE-6507 Project: Ignite

[GitHub] ignite pull request #2758: IGNITE-6440 Test fx

GitHub user alexpaschenko opened a pull request: https://github.com/apache/ignite/pull/2758 IGNITE-6440 Test fx You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6440 Alternatively you can review and

[GitHub] ignite pull request #2757: IGNITE-6346 Fix: distributed set does not work in...

GitHub user vk23 opened a pull request: https://github.com/apache/ignite/pull/2757 IGNITE-6346 Fix: distributed set does not work in REPLICATED mode Changes: 1. Fixed bug 2. Added tests You can merge this pull request into a Git repository by running: $ git pull

Re: [DISCUSS] Ignite Update Checker

On Tue, Sep 26, 2017 at 6:20 AM, Vladimir Ozerov wrote: > Folks, > > Can we add version of current node to web request? This way we will better > understand version distribution, what might help us with certain API > update/deprecate decisions > E.g.

Re: Persistence per memory policy configuration

On Tue, Sep 26, 2017 at 7:33 AM, Dmitry Pavlov wrote: > Hi Dmitriy, thank you for reply. Do you agree Memory Policy already became > Ignite's term? We call this configuration now MemoryPolicy(Configuration), > can we call new configuration elments by their existings name?

Re: A quick question on Ignite's B+ tree implementation

+ dev list Hi John, As the one who worked on this documentation, I confirm that it’s correct. In my opinion, the only missing thing is that an index page (node) can comprise key/value if the latter is of primitive type (int, float, char, String of specific length). *Vladimir*, *Sam*, could

[jira] [Created] (IGNITE-6506) Unable to activate cluster node if it was stopped during persistent storage checkpoint

Joel Lang created IGNITE-6506: - Summary: Unable to activate cluster node if it was stopped during persistent storage checkpoint Key: IGNITE-6506 URL: https://issues.apache.org/jira/browse/IGNITE-6506

[jira] [Created] (IGNITE-6505) .NET: Verify output in ExamplesTest

Pavel Tupitsyn created IGNITE-6505: -- Summary: .NET: Verify output in ExamplesTest Key: IGNITE-6505 URL: https://issues.apache.org/jira/browse/IGNITE-6505 Project: Ignite Issue Type:

Default CacheConfiguration instance can't be serialized

Hello, Guys. I found that CacheConfiguration which implements Serializable contains not serializable fields by default. CacheConfiguration -> affMapper -> CacheDefaultBinaryAffinityKeyMapper -> proc -> CacheObjectBinaryProcessorImpl. Is this a bug or I miss something? Simple reproducer: ```

[jira] [Created] (IGNITE-6504) Very quick checkpoint can cause AssertionError on next start from LFS

Ivan Rakov created IGNITE-6504: -- Summary: Very quick checkpoint can cause AssertionError on next start from LFS Key: IGNITE-6504 URL: https://issues.apache.org/jira/browse/IGNITE-6504 Project: Ignite

Re: Warning if no table for BinaryObject

Mikhail, Could you prepare a properly described ticket encompassing the suggested warning? Let’s do the improvement for the upcoming release. — Denis > On Sep 26, 2017, at 7:23 AM, Mikhail Cherkasov > wrote: > > Hi Dmitry, > > The problem is that we don't have

[GitHub] ignite pull request #2756: ignite-gg-pitr-2.1.5 merge to PITR (master)

GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/2756 ignite-gg-pitr-2.1.5 merge to PITR (master) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite PITR

Per-entry overhead - some questions

Hi Igniters, I have been looking in to the per-entry overhead for Ignite cache entries and have a couple of questions. 1. Does each GridCacheMapEntry require a reference to GridCacheContext or could this field be removed/optimized in some way? Is the GridCacheContext instance the same for every

[GitHub] ignite pull request #2755: IGNITE-5730 .NET: Fix ignite.jni.dll temp dir rac...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2755 IGNITE-5730 .NET: Fix ignite.jni.dll temp dir race You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-5730-1

Re: Persistence per memory policy configuration

Hi Dmitriy, thank you for reply. Do you agree Memory Policy already became Ignite's term? We call this configuration now MemoryPolicy(Configuration), can we call new configuration elments by their existings name? We can avoid introduction of second Ignite's term in that case. вт, 26 сент. 2017 г.

[GitHub] ignite pull request #2754: IGNITE-5615 .NET: IgniteConfiguration.LocalEventL...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2754 IGNITE-5615 .NET: IgniteConfiguration.LocalEventListeners You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5615

Re: Warning if no table for BinaryObject

Hi Dmitry, The problem is that we don't have strong typing when defining QueryEntriy and a user can use an arbitrary string id to define a type, but he should use the same string id to obtain binary object builder, however, people sometimes confusing this. So the user can define QueryEntity with

Re: Persistence per memory policy configuration

Vladimir, it is not clear for me, why we need to rename existing configuration classes. Could you explain? And if we can't get consensus now, should we pospond solution? My idea is that user needs this feature more than elegant names in configuration. Moreover once MemoryPolicyConfiguration was

[GitHub] ignite pull request #2753: ignite-5714 updateExplicitVersion for detached en...

GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/2753 ignite-5714 updateExplicitVersion for detached entry You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite ignite-5714-7 Alternatively

Re: Persistence per memory policy configuration

I do not understand why we should delay with renames. Yes, it will cause questions, so we will have to put additional efforts to docs and JavaDocs. But the earlier we do that, the better. On Tue, Sep 26, 2017 at 4:50 PM, Dmitry Pavlov wrote: > Hi Igniters, sorry for late

Re: Persistence per memory policy configuration

Hi Igniters, sorry for late response. I didn't catch idea of renaming. PersistentStoreConfiguration is intuitive, and MemoryPolicyConfiguration is intuitive also. If we rename these classes now, it will bring more questions to user list. Users may be confused by old and new names and by trying to

[GitHub] ignite pull request #2752: IGNITE-6285: Enhance persistent store paths loggi...

GitHub user dspavlov opened a pull request: https://github.com/apache/ignite/pull/2752 IGNITE-6285: Enhance persistent store paths logging on start Experimental commits to run TC tests, do not merge You can merge this pull request into a Git repository by running: $ git pull

Re: [DISCUSS] Ignite Update Checker

Folks, Can we add version of current node to web request? This way we will better understand version distribution, what might help us with certain API update/deprecate decisions E.g. http://ignite.apache.org/latest.cgi=2.2.0 Vladimir. On Fri, Sep 8, 2017 at 7:06 AM, Dmitriy Setrakyan

[GitHub] ignite pull request #2747: Attempt to fix not-null compatibility issue.

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2747 ---

[GitHub] ignite pull request #2751: Adding lock if timeout is negative

GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/2751 Adding lock if timeout is negative You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite ignite-5714-local-lock-not-covered

[GitHub] ignite pull request #2750: IGNITE-6286: fix org.h2.jdbc.JdbcSQLException

GitHub user schernolyas opened a pull request: https://github.com/apache/ignite/pull/2750 IGNITE-6286: fix org.h2.jdbc.JdbcSQLException changes: 1. develop test for check all supported types for parameterized queries 2. add support BigDecimal type as type of

[GitHub] ignite pull request #2749: IGNITE-6186: Removed redundant parameter.

GitHub user andrey-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/2749 IGNITE-6186: Removed redundant parameter. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrey-kuznetsov/ignite ignite-6186

[GitHub] ignite pull request #2737: IGNITE-6286: fix org.h2.jdbc.JdbcSQLException

Github user schernolyas closed the pull request at: https://github.com/apache/ignite/pull/2737 ---

Re: Persistence per memory policy configuration

I do not like DurableMemoryConfiguration, because it's quite confusing - we configure in-memory caches using DurableMemory class, which immediately suggests that everything will be persisted. I am not sure if this is a right wording choice for the documentation either. I would go with

[GitHub] ignite pull request #2748: IGNITE-6015: Rollback on exception in commitIfLoc...

GitHub user andrey-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/2748 IGNITE-6015: Rollback on exception in commitIfLocked. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrey-kuznetsov/ignite

[GitHub] ignite pull request #2747: Attempt to fix not-null compatibility issue.

GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/2747 Attempt to fix not-null compatibility issue. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-gg-12822

Re: Issues if -Djava.net.preferIPv4Stack=true is not set

Why don't we automatically set the preferIPv4Stack to true, unless the user explicitly set it to false? D. On Tue, Sep 26, 2017 at 4:35 AM, Yakov Zhdanov wrote: > Val, I see now. > > For example, this http://apache-ignite-users.70518.x6.nabble.com/How- >

Re: Issues if -Djava.net.preferIPv4Stack=true is not set

Val, I see now. For example, this http://apache-ignite-users.70518.x6.nabble.com/How- to-correctly-shut-down-Ignite-Application-td12548.html could happen due to address passed to org.apache.ignite.internal.util.IgniteUtils#reachable(java.net.InetAddress, int) is NULL. I suspect there may be

[jira] [Created] (IGNITE-6503) Need to test Ignite in IPv6 environment

Yakov Zhdanov created IGNITE-6503: - Summary: Need to test Ignite in IPv6 environment Key: IGNITE-6503 URL: https://issues.apache.org/jira/browse/IGNITE-6503 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-6502) Need to output warning if -Djava.net.preferIPv4Stack=true is not set

Yakov Zhdanov created IGNITE-6502: - Summary: Need to output warning if -Djava.net.preferIPv4Stack=true is not set Key: IGNITE-6502 URL: https://issues.apache.org/jira/browse/IGNITE-6502 Project:

[GitHub] ignite pull request #2746: Ignite 5714 2

GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/2746 Ignite 5714 2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite ignite-5714-2 Alternatively you can review and apply these changes

Re: Future of Ignite transactions

Dmitriy, Agree with Vladimir here. OPTIMISTIC + (READ_COMMITTED | REPEATABLE_READ) modes are completely unusable in real-life use-cases because they do not allow any read-write conflict detection and thus the explicit transaction statement can be omitted at all. The remaining combinations of tx

[GitHub] ignite pull request #2745: Ignite 1.8.12

GitHub user sk0x50 opened a pull request: https://github.com/apache/ignite/pull/2745 Ignite 1.8.12 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-1.8.12 Alternatively you can review and apply

Contributors Permissions for Ignite

Hi I would like to request for Contributors Permissions for Ignite Development. JIRA Username : kotamrajuyashasvi Presently I would like to assign myself to an Issue which I raised and fix it.

[GitHub] ignite pull request #2494: ignite-5714-2

Github user voipp closed the pull request at: https://github.com/apache/ignite/pull/2494 ---

Re: Future of Ignite transactions

On Tue, Sep 26, 2017 at 12:08 AM, Vladimir Ozerov wrote: > Dima, > > My proposal would require two changes: > 1) Public - for sure we will continue support old API > Of course. But my assumption is that you would deprecate the old API, right? If yes, then you will never be

[GitHub] ignite pull request #2741: IGNITE-6494 .NET: Fix CacheConfiguration.WriteSyn...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2741 ---

IGNITE-6286

Hi! I was prepared https://github.com/apache/ignite/pull/2737 PR. The PR fix https://issues.apache.org/jira/browse/IGNITE-6286 . Please, review it Also, the PR is very important for project Hibernate OGM for Ignite. A lot of thank! With best regards, Sergey Chernolyas -- Sent from:

Re: Future of Ignite transactions

Dima, My proposal would require two changes: 1) Public - for sure we will continue support old API 2) Internal TX engine - these changes are inevitable for transactional SQL support. So we have no freedom to choose whether to spend time on internals or not. We will have to do that anyway. On

[jira] [Created] (IGNITE-6501) select distinct exception in simple sqlQuery request.

Stanilovsky Evgeny created IGNITE-6501: -- Summary: select distinct exception in simple sqlQuery request. Key: IGNITE-6501 URL: https://issues.apache.org/jira/browse/IGNITE-6501 Project: Ignite

[jira] [Created] (IGNITE-6500) While using ignite-cassandra-store, POJO field having wrapper type, mapped to Cassandra table are getting initialized to respective default value of primitive type inste

Yashasvi Kotamraju created IGNITE-6500: -- Summary: While using ignite-cassandra-store, POJO field having wrapper type, mapped to Cassandra table are getting initialized to respective default value of primitive type instead of null if column

[jira] [Created] (IGNITE-6499) Compact NULL fields binary representation

Alexandr Kuramshin created IGNITE-6499: -- Summary: Compact NULL fields binary representation Key: IGNITE-6499 URL: https://issues.apache.org/jira/browse/IGNITE-6499 Project: Ignite Issue

Re: Future of Ignite transactions

Vladimir, I do not think we have a luxury of changing Ignite transaction APIs. It is almost the same as changing Ignite put and get APIs. Too much code has already been written to these APIs. The upgrade path will be so onerous that no one will ever take it. As far as the current transaction