Re: MVCC configuration

Can caches within the same group have different MVCC configuration? On Tue, Sep 19, 2017 at 2:34 AM, Vladimir Ozerov wrote: > What I mean is that it might be not applicable for DML by design. E.g. may > be we will have to fallback to per-memory-policy approach, or to >

Re: Ignite Enhancement Proposal process

Great idea. Either name is fine by me, but we badly need to add these Wiki pages ASAP. Here are some candidates: - Usability - SQL - MVCC - Persistence - Performance D. On Tue, Sep 19, 2017 at 6:00 AM, Vladimir Ozerov wrote: > Both "improvement" and "enhancement" are OK

[jira] [Created] (IGNITE-6446) Stuck on "Loading" screen

Ilya Borisov created IGNITE-6446: Summary: Stuck on "Loading" screen Key: IGNITE-6446 URL: https://issues.apache.org/jira/browse/IGNITE-6446 Project: Ignite Issue Type: Bug

Re: Annoying extra steps for enabling metrics

Let’s simplifying the metrics as a part of this ticket: https://issues.apache.org/jira/browse/IGNITE-5796 Expanded its scope. — Denis > On Sep 9, 2017, at 2:44 PM, Valentin Kulichenko > wrote: > >

JCache time-based metrics

I'd want to make a new attempt to discuss JCache metrics, especially time-based metrics. As discussed earlier ( http://apache-ignite-developers.2346864.n4.nabble.com/Cache-Metrics-tt19699.html ), there are two approaches (and at first glance, the second one is preferable): #1 Node that starts

Re: IGNITE-2894 - Binary object inside of Externalizable still serialized with OptimizedMarshaller

Nikita, It sounds like the test should be changed, no? In case I'm missing something, can you please give more details about the scenario which requires deserialization? Generally, this sounds weird - in cases when we can get advantage of binary format and avoid deserialization, we definitely

Re: Binary compatibility of persistent storage

In my view, there are two different scenarios. First - user just upgrades the version (to get some bug fix, for example), but does not intend to change anything in their project and/or use any new features. In this case it should work transparently and cluster must be able to work with older

[GitHub] ignite pull request #2700: probable fix

GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/2700 probable fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite ignite-5960-1 Alternatively you can review and apply these changes as

[GitHub] ignite pull request #2658: ignite-5960 cont counter null if nobody listens

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

[jira] [Created] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks

Vitaliy Biryukov created IGNITE-6445: Summary: IgniteTxManager.txLocksInfo method misses locks Key: IGNITE-6445 URL: https://issues.apache.org/jira/browse/IGNITE-6445 Project: Ignite

[jira] [Created] (IGNITE-6444) Validate that copyOnRead flag is configured with on-heap cache enabled

Alexey Goncharuk created IGNITE-6444: Summary: Validate that copyOnRead flag is configured with on-heap cache enabled Key: IGNITE-6444 URL: https://issues.apache.org/jira/browse/IGNITE-6444

Re: [RESULT] [VOTE] Apache Ignite 2.2.0 Release (RC2)

NuGet packages pushed: https://www.nuget.org/packages?q=Apache.Ignite On Tue, Sep 19, 2017 at 4:46 PM, Anton Vinogradov wrote: > - Maven artifacts released > - Sources released > - Site updated > - Git tag added > > On Mon, Sep 18, 2017 at 6:19 PM, Anton Vinogradov

[jira] [Created] (IGNITE-6443) Test IgniteSourceConnectorTest has flaky fails

Andrey Gura created IGNITE-6443: --- Summary: Test IgniteSourceConnectorTest has flaky fails Key: IGNITE-6443 URL: https://issues.apache.org/jira/browse/IGNITE-6443 Project: Ignite Issue Type:

[GitHub] ignite pull request #2699: IGNITE-6442

GitHub user BiryukovVA opened a pull request: https://github.com/apache/ignite/pull/2699 IGNITE-6442 You can merge this pull request into a Git repository by running: $ git pull https://github.com/BiryukovVA/ignite IGNITE-6442 Alternatively you can review and apply these

[jira] [Created] (IGNITE-6442) Deadlock detection doesn't execute.

Vitaliy Biryukov created IGNITE-6442: Summary: Deadlock detection doesn't execute. Key: IGNITE-6442 URL: https://issues.apache.org/jira/browse/IGNITE-6442 Project: Ignite Issue Type: Bug

[GitHub] ignite pull request #2698: IGNITE-6250 .NET: Thin client: Basic exception ha...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2698 IGNITE-6250 .NET: Thin client: Basic exception handling You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6250

[jira] [Created] (IGNITE-6441) Thin client: configurable message size limit

Pavel Tupitsyn created IGNITE-6441: -- Summary: Thin client: configurable message size limit Key: IGNITE-6441 URL: https://issues.apache.org/jira/browse/IGNITE-6441 Project: Ignite Issue

[jira] [Created] (IGNITE-6440) Flaky failures in DynamicColumnsAbstractConcurrentSelfTest

Vladimir Ozerov created IGNITE-6440: --- Summary: Flaky failures in DynamicColumnsAbstractConcurrentSelfTest Key: IGNITE-6440 URL: https://issues.apache.org/jira/browse/IGNITE-6440 Project: Ignite

[GitHub] ignite pull request #2677: ignite-5960 Sending backupQueue to node.

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

Re: [RESULT] [VOTE] Apache Ignite 2.2.0 Release (RC2)

- Maven artifacts released - Sources released - Site updated - Git tag added On Mon, Sep 18, 2017 at 6:19 PM, Anton Vinogradov wrote: > Igniters, > > Apache Ignite 2.2.0 release (RC2) has been accepted. > > 4 "+1" binding votes received: > > - Vladimir Ozerov > - Alexey

Re: Binary compatibility of persistent storage

>Any major change in data/index page format. E.g. this could happen once transactional SQL is ready. I would suggest we automatically disable this feature for databases created with older versions. --Yakov

[GitHub] ignite pull request #2696: IGNITE-6399 .NET: ClientConnectorConfiguration

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

[GitHub] ignite pull request #2697: ignite-6339 Segmented ring buffer implemented ins...

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/2697 ignite-6339 Segmented ring buffer implemented instead of WAL records chain …chain You can merge this pull request into a Git repository by running: $ git pull

[GitHub] ignite pull request #2689: IGNITE-6099: Fully implemented SQLGetInfo in ODBC...

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

Re: IGNITE-2894 - Binary object inside of Externalizable still serialized with OptimizedMarshaller

I have some problem when we don't deserialize Externalizable. Some messages require deserializing in GridCacheIoManager.message0(). For example, tests like testResponseMessageOnUnmarshallingFailed where readExternal throws an exception. A message containing Externalizable is deserialized and

Re: Binary compatibility of persistent storage

I vote for the 4th variant, because it is the most common approach to the versioning. For example, SemVer says that you can make incompatible API changes only in major versions. 19.09.2017, 14:52, "Vladimir Ozerov" : > Yakov, > > Any major change in data/index page

Re: Ignite Enhancement Proposal process

Both "improvement" and "enhancement" are OK as both are widely used in OSS projects. Ideally, the abbreviation itself should sound cool. Consider "Python Ehnacement Proposals" - PEPS! :-) On Tue, Sep 19, 2017 at 3:10 PM, Andrey Kuznetsov wrote: > Really cool idea! > > It's

Re: Binary compatibility of persistent storage

Yakov, Any major change in data/index page format. E.g. this could happen once transactional SQL is ready. On Tue, Sep 19, 2017 at 2:51 PM, Yakov Zhdanov wrote: > Vladimir, > > Can you please describe the situation when 2 is possible, but 4 is not? > > --Yakov >

Re: Binary compatibility of persistent storage

I have same idea about testing of WAL compatibilty between releases. It will be actual since 2.3 release (as 2.2 was emergency release without impact changes). I look forward to IGNITE-5732 completion and merge. And then I able to start writting first test. I think it is quite unexpected for

[jira] [Created] (IGNITE-6439) IgnitePersistentStoreSchemaLoadTest is broken

Dmitriy Govorukhin created IGNITE-6439: -- Summary: IgnitePersistentStoreSchemaLoadTest is broken Key: IGNITE-6439 URL: https://issues.apache.org/jira/browse/IGNITE-6439 Project: Ignite

[GitHub] ignite pull request #2690: IGNITE 6428: IgniteOOME in PDS Indexing test:

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

Re: IGNITE-1025

Anton, Thanks, I'll start it. 2017-09-19 14:54 GMT+03:00 Anton Vinogradov : > Ivan, > > Issue is still actual. > > On Tue, Sep 19, 2017 at 2:10 PM, Иван Федотов wrote: > > > Hi, Igniters! > > I've picked up task

Re: Binary compatibility of persistent storage

I vote for: “4) Maintain compatibility between all versions within major release”. I think this is a trade-off between the complexity of implementing new features and UX. We will be able to get rid of all legacy tools every major release. I’m working on a testing framework, which helps us

Re: Ignite Enhancement Proposal process

Really cool idea! It's not convenient to look for subtle details in devlist discussion thread. But I'd prefer the word "improvement" rather than "enhancement": the stuff being described is not always a sharp-cut functionality. 2017-09-19 14:56 GMT+03:00 ALEKSEY KUZNETSOV

Re: Ignite Enhancement Proposal process

great suggestion вт, 19 сент. 2017 г. в 14:31, Yakov Zhdanov : > Vladimir, I like the suggestion. We should definitely try it. > > --Yakov > -- *Best Regards,* *Kuznetsov Aleksey*

Re: IGNITE-1025

Ivan, Issue is still actual. On Tue, Sep 19, 2017 at 2:10 PM, Иван Федотов wrote: > Hi, Igniters! > I've picked up task https://issues.apache.org/jira/browse/IGNITE-1025 > "Need > to print out warning if IP finder has a lot of addresses on Windows", but > this task was

Re: Exception handling in thin client: should we pass stack traces to the client?

Fully agree. As Alex mentioned web servers support dev and prod modes. We need to do the same and default mode should be dev with warning on startup and ability to change in runtime. --Yakov

Re: Binary compatibility of persistent storage

Vladimir, Can you please describe the situation when 2 is possible, but 4 is not? --Yakov

[jira] [Created] (IGNITE-6438) .NET: Thin client: Advanced exception handling

Pavel Tupitsyn created IGNITE-6438: -- Summary: .NET: Thin client: Advanced exception handling Key: IGNITE-6438 URL: https://issues.apache.org/jira/browse/IGNITE-6438 Project: Ignite Issue

Re: Binary compatibility of persistent storage

Hello, Vladimir. I prefer 2 option. > 2) No compatibility, but provide migration instruments I think we have to provide some tool for converting WAL files from any older format to current. 19.09.2017 14:16, Vladimir Ozerov пишет: igniters, Ignite doesn't have compatibility for binary

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

Val, can you please provide links to threads you meant? I will take a look. --Yakov

Re: Binary compatibility of persistent storage

Vote for case #4. As far as I know, Vyacheslav Daradur already works on framework allows to check compatibility between different version of Ignite. Vyacheslav, Could you provide us more details? On Tue, Sep 19, 2017 at 2:16 PM, Vladimir Ozerov wrote: > igniters, > >

Re: Ignite Enhancement Proposal process

Vladimir, I like the suggestion. We should definitely try it. --Yakov

Re: Static code analysis for Java

Bas, thanks for joining! Can you please point me to the page listing all types of issue LGTM can find (like this one - https://scan.coverity.com/faq#what-types-of-issues-tool-find)? LGTM really helped to find some bugs like incorrect key type when working with hash map instance, unnecessary

Binary compatibility of persistent storage

igniters, Ignite doesn't have compatibility for binary protocols between different versions, as this would make development harder and slower. On the other hand we maintain API compatibility what helps us move users to new versions faster. As native persistence is implemented, new challenge

IGNITE-1025

Hi, Igniters! I've picked up task https://issues.apache.org/jira/browse/IGNITE-1025 "Need to print out warning if IP finder has a lot of addresses on Windows", but this task was created in June 2015. Is this task still relevant? Thanks in advance. -- Ivan Fedotov. ivanan...@gmail.com

[jira] [Created] (IGNITE-6437) DataStructure can not be obtained on client if it is created on server node.

Mikhail Cherkasov created IGNITE-6437: - Summary: DataStructure can not be obtained on client if it is created on server node. Key: IGNITE-6437 URL: https://issues.apache.org/jira/browse/IGNITE-6437

Re: HOLE query entry in CacheContinuousQueryPartitionRecovery

Nikolay, Could you please check? On Tue, Sep 19, 2017 at 1:50 PM, ALEKSEY KUZNETSOV wrote: > HOLE was introduced in CacheContinuousQueryHandler.PartitionRecovery. > Ticket *IGNITE-426 Implemented failover for Continuous query.* > Then it was refactored in *Continuous

Re: HOLE query entry in CacheContinuousQueryPartitionRecovery

HOLE was introduced in CacheContinuousQueryHandler.PartitionRecovery. Ticket *IGNITE-426 Implemented failover for Continuous query.* Then it was refactored in *Continuous queries fixes.* After refactoring the variable is never compares to true. Probably, its a bug. сб, 16 сент. 2017 г. в 1:52,

[GitHub] ignite pull request #2696: IGNITE-6399 .NET: ClientConnectorConfiguration

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2696 IGNITE-6399 .NET: ClientConnectorConfiguration You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-6399 Alternatively

[jira] [Created] (IGNITE-6436) ransactions slow down

Ksenia Rybakova created IGNITE-6436: --- Summary: ransactions slow down Key: IGNITE-6436 URL: https://issues.apache.org/jira/browse/IGNITE-6436 Project: Ignite Issue Type: Bug

Re: MVCC configuration

Guys, I we should additionally provide ability to manually switch mvcc coordinator via MBean passing order or ID of a new one. We already have all the machinery for this. --Yakov

Ignite Enhancement Proposal process

Igniters, I'd like to discuss an idea of adding "Enhancement Proposal" concept to our process. Many other OSS vendors use it with great success ([1], [2], [3], [4]), so I think we can also benefit from it. **Motivation** Ignite project lacks transparency. We have a lot of thoughts and plans in

Re: MVCC configuration

What I mean is that it might be not applicable for DML by design. E.g. may be we will have to fallback to per-memory-policy approach, or to per-cache-group. As we do not know it at the moment and there is no clear demand from users, I would simply put it aside to avoid in mess in public API in

[jira] [Created] (IGNITE-6435) Web Console: Add release version to footer

Dmitriy Shabalin created IGNITE-6435: Summary: Web Console: Add release version to footer Key: IGNITE-6435 URL: https://issues.apache.org/jira/browse/IGNITE-6435 Project: Ignite Issue

Re: MVCC configuration

If it is not valid for DML then we can easily detect this situation and throw exception, but if I do not use DML why non make it configurable per-cache? On Tue, Sep 19, 2017 at 12:22 PM, Vladimir Ozerov wrote: > I would say that per-cache configuration should be out of

Re: MVCC configuration

I would say that per-cache configuration should be out of scope as well for the first iteration. Because we do not know whether it will be valid for DML. On Tue, Sep 19, 2017 at 12:15 PM, Semyon Boikov wrote: > Folks, thank you for feedback, I want to summarize some

[jira] [Created] (IGNITE-6434) Assertion error in checkpointer during topology change

Eduard Shangareev created IGNITE-6434: - Summary: Assertion error in checkpointer during topology change Key: IGNITE-6434 URL: https://issues.apache.org/jira/browse/IGNITE-6434 Project: Ignite

Re: MVCC configuration

Folks, thank you for feedback, I want to summarize some decisions: 1. Mvcc is disabled by default. We'll add two flags to enable mvcc: per-cache flag - CacheConfiguration.isMvccEnabled, default value for all caches - IgniteConfiguration.isMvccEnabled. 2. For initial implementation mvcc for ATOMIC

[GitHub] ignite pull request #2693: IGNITE-6244 .NET: Thin client: ScanQuery

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

[GitHub] ignite pull request #2648: ignite-4931 tests reworked

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

[GitHub] ignite pull request #2695: Ignite 2.1.5-IGN-8173 remove locDepOwner

GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/2695 Ignite 2.1.5-IGN-8173 remove locDepOwner You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite

[jira] [Created] (IGNITE-6433) We need to cancel eviction instead of waiting it when we should own a partition because we had lost it

Eduard Shangareev created IGNITE-6433: - Summary: We need to cancel eviction instead of waiting it when we should own a partition because we had lost it Key: IGNITE-6433 URL:

[GitHub] ignite pull request #2572: IGNITE-6238 Fix GridClosureProcessorRemoteTest, a...

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

[GitHub] ignite pull request #2694: Ignite 6342 2

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

[GitHub] ignite pull request #2693: IGNITE-6244 .NET: Thin client: ScanQuery

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/2693 IGNITE-6244 .NET: Thin client: ScanQuery You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6244 Alternatively

Re: MVCC configuration

This could be something like "preferredMvccCoordinator". On Tue, Sep 19, 2017 at 10:40 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > > > > I agree that we need coordinator nodes, but I do not understand why can't > > we reuse some cache nodes for it? Why do we need to ask user to

Re: Exception handling in thin client: should we pass stack traces to the client?

Thanks, folks! Excellent catch - we should not decide whether to allow it or not, but rather make it configurable. On Tue, Sep 19, 2017 at 10:43 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > I think the protocol should allow both, and the behavior should be either > configurable

Re: Exception handling in thin client: should we pass stack traces to the client?

Hi Vladimir, All of these arguments are relevant. I suggest to provide full stacktrace at least by server option. This is also common practice on web servers. Sincerely, Dmitriy Pavlov вт, 19 сент. 2017 г. в 10:20, Vladimir Ozerov : > Igniters, > > We had a discussion

Re: Exception handling in thin client: should we pass stack traces to the client?

I think the protocol should allow both, and the behavior should be either configurable or enabled via a system property. Every web server known to me allows exposing this information for debugging purposes. 2017-09-19 10:20 GMT+03:00 Vladimir Ozerov : > Igniters, > > We had

Re: MVCC configuration

> > I agree that we need coordinator nodes, but I do not understand why can't > we reuse some cache nodes for it? Why do we need to ask user to start up > yet another type of node? > Dmitriy, My understanding is that Semyon does not deny a cache node to be used as a coordinator. This property

Exception handling in thin client: should we pass stack traces to the client?

Igniters, We had a discussion about how to propagate error information from cluster nodes to the client. My opinion is that we should pass a kind of vendor code plus optional error message, if vendor code is not very specific. Alternative idea is to pass the whole stack trace as well. I agree

Re: Ignite PDS WAL analysis with human readable records

I've updated issue description. Igniters, who have already faced with necessity to look into WAL content and/or latest records? Sincerely, Dmitriy Pavlov пн, 18 сент. 2017 г. в 23:23, Dmitriy Setrakyan : > Dmitriy, can you please describe your idea in the ticket? > >

[jira] [Created] (IGNITE-6432) SpringCacheManager#getCacheNames() is empty

Valeri Chibaev created IGNITE-6432: -- Summary: SpringCacheManager#getCacheNames() is empty Key: IGNITE-6432 URL: https://issues.apache.org/jira/browse/IGNITE-6432 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-6431) Web Console: "Partition loss policy" field is duplicated

Dmitry Karachentsev created IGNITE-6431: --- Summary: Web Console: "Partition loss policy" field is duplicated Key: IGNITE-6431 URL: https://issues.apache.org/jira/browse/IGNITE-6431 Project: