[GitHub] ignite pull request #3036: IGNITE-6916: node joining with enabled pds and em...

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

Re: Ignite Enhancement Proposal #7 (Internal problems detection)

Hi Anton, I don't think that we should shutdown node in case of IgniteOOMException, if one node has no space, then other probably don't have it too, so re -balancing will cause IgniteOOM on all other nodes and will kill the whole cluster. I think for some configurations cluster should survive

Re: Ignite Enhancement Proposal #7 (Internal problems detection)

In the first iteration I would focus only on reporting facilities, to let administrator spot dangerous situation. And in the second phase, when all reporting and metrics are ready, we can think on some automatic actions. On Wed, Nov 22, 2017 at 10:39 AM, Mikhail Cherkasov

[GitHub] ignite pull request #3045: IGN-8915

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

[jira] [Created] (IGNITE-6983) SQL: optimize CREATE INDEX and BPlusTree interaction

Vladimir Ozerov created IGNITE-6983: --- Summary: SQL: optimize CREATE INDEX and BPlusTree interaction Key: IGNITE-6983 URL: https://issues.apache.org/jira/browse/IGNITE-6983 Project: Ignite

Re: Suggestion to improve deadlock detection

On Mon, Nov 20, 2017 at 10:15 PM, Vladimir Ozerov wrote: > It doesn’t need all txes. Instead, other nodes will send info about > suspicious txes to it from time to time. > I see your point, I think it might work.

[jira] [Created] (IGNITE-6971) Ignite Logger type & logging file config indication

Alexey Popov created IGNITE-6971: Summary: Ignite Logger type & logging file config indication Key: IGNITE-6971 URL: https://issues.apache.org/jira/browse/IGNITE-6971 Project: Ignite Issue

[GitHub] ignite pull request #3073: Ignite 2.1.8

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

[jira] [Created] (IGNITE-6970) Error thrown from CacheStore cause cache operation hanging.

Andrew Mashenkov created IGNITE-6970: Summary: Error thrown from CacheStore cause cache operation hanging. Key: IGNITE-6970 URL: https://issues.apache.org/jira/browse/IGNITE-6970 Project: Ignite

[GitHub] ignite pull request #3052: IGNITE-6931

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

Re: Ignite ML dense distributed matrices

Alexey, I dont think that mixing distributed/local is a good idea unlike dense/sparse or blocks/rows/cols. Regards, Yury -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: getAverageGetTime/getAveragePutTime APIs of CacheMetrics always return 0

Hello all. In addition, I found similar closed issue about cache metrics and client mode [1]. The ticket resolution seems strange, because it can be reproduced now. [1] https://issues.apache.org/jira/browse/IGNITE-3605 2017-11-21 2:47 GMT+03:00 Denis Magda : > Ignite dev

Re: IGNITE-6745. Status

Cergey, Some of Ignite users use extended Java7 support, so, it's still alive. Yes, all code should be java7-compatible. On Tue, Nov 21, 2017 at 2:28 AM, Cergey wrote: > My username is cossack5. Please grant me contributor permissions. > As for java 7 version, until

Re: Facility to detect long STW pauses and other system response degradations

Denis, > 1. Totally for a separate native process that will handle the monitoring of an Ignite process. The watchdog process can simply start a JVM tool like jstat and parse its GC logs: https://dzone.com/articles/ how-monitor-java-garbage

[GitHub] ignite pull request #3074: IGNITE-6904 SQL: partition reservations are relea...

GitHub user dolphin1414 opened a pull request: https://github.com/apache/ignite/pull/3074 IGNITE-6904 SQL: partition reservations are released too early in lazy mode In lazy mode partitions reservations are released only after last page has been sent. You can merge this pull

Re: Facility to detect long STW pauses and other system response degradations

Don't forget that the high utilization of CPU can occur for reasons other than GC STW, and GC log parsing will not help us in that case. вт, 21 нояб. 2017 г. в 13:06, Anton Vinogradov [via Apache Ignite Developers] : > Denis, > > > 1. Totally for a separate

[jira] [Created] (IGNITE-6972) BinaryObjectBuilderImpl.build is stuck when server cluster is restarted

Jason Man created IGNITE-6972: - Summary: BinaryObjectBuilderImpl.build is stuck when server cluster is restarted Key: IGNITE-6972 URL: https://issues.apache.org/jira/browse/IGNITE-6972 Project: Ignite

Right MXBean for new metrics

Hello, Igniters! I would like to discuss the implementation of ticket IGNITE-6871. In our Ignite instance there are more than 1000 caches and about 10 cache groups. To minimize the probability of data loss we need to alert when a critical level of redundancy in cluster is reached. So, we

[jira] [Created] (IGNITE-6973) Node restarts with enabled persistence lead to affinity assignment mismatch on different nodes.

Alexei Scherbakov created IGNITE-6973: - Summary: Node restarts with enabled persistence lead to affinity assignment mismatch on different nodes. Key: IGNITE-6973 URL:

[jira] [Created] (IGNITE-6974) .NET: consoleWrite error during application shutdown

Alexey Popov created IGNITE-6974: Summary: .NET: consoleWrite error during application shutdown Key: IGNITE-6974 URL: https://issues.apache.org/jira/browse/IGNITE-6974 Project: Ignite Issue

[jira] [Created] (IGNITE-6975) .NET: Create cross-platform examples on .NET Core

Pavel Tupitsyn created IGNITE-6975: -- Summary: .NET: Create cross-platform examples on .NET Core Key: IGNITE-6975 URL: https://issues.apache.org/jira/browse/IGNITE-6975 Project: Ignite Issue

Re: SQL warning for partitioned caches with setLocal

Thanks dsetrakyan, I would like to add a few more things over here which should be applicable to partitioned caches. This context variable which is set through affinityCall or affinityRun should be available through either a helper class or cache configuration. There could be other advantages as

Re: Facility to detect long STW pauses and other system response degradations

My 2 cents. Don’t do it. JVM provides sufficient means of detecting a struggling process out of the box. SRE/Operations teams usually know how to monitor JVMs and can handle killing of such processes themselves. The feature adds no value, just complexity (and more configuration parameters (!)

Re: Data eviction/expiration from Ignite persistence

Hi Denis, Second fix we need to do is B+ tree separation in per-partition basis: https://issues.apache.org/jira/browse/IGNITE-5874 Should we take into account compatibilty issues with previous Ignite persistent store versions, because current TTL tree is persisted, and will change its format?

Re: Facility to detect long STW pauses and other system response degradations

Andrey, > JVM provides sufficient means of detecting a struggling process out of the box. Could you point to some articles describing how to detect STW exceeding some duration using only JVM API? On Tue, Nov 21, 2017 at 7:17 PM, Andrey Kornev wrote: > My 2 cents.

[jira] [Created] (IGNITE-6980) Automatic cancelling of hanging Ignite operations

Denis Magda created IGNITE-6980: --- Summary: Automatic cancelling of hanging Ignite operations Key: IGNITE-6980 URL: https://issues.apache.org/jira/browse/IGNITE-6980 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-6981) System thread pool continuously creates and destroys threads while idle

Joel Lang created IGNITE-6981: - Summary: System thread pool continuously creates and destroys threads while idle Key: IGNITE-6981 URL: https://issues.apache.org/jira/browse/IGNITE-6981 Project: Ignite

[jira] [Created] (IGNITE-6979) Race in GridClientPartitionTopology may cause NPE and partition map exchange hang.

Alexei Scherbakov created IGNITE-6979: - Summary: Race in GridClientPartitionTopology may cause NPE and partition map exchange hang. Key: IGNITE-6979 URL: https://issues.apache.org/jira/browse/IGNITE-6979

Re: Ignite Enhancement Proposal #7 (Internal problems detection)

A lack of suggestions and thoughts encourages me to create a ticket: https://issues.apache.org/jira/browse/IGNITE-6980 — Denis > On Nov 20, 2017, at 2:53 PM, Denis Magda wrote: > > If an Ignite operation hangs by some

Re: Losing data during restarting cluster with persistence enabled

Hello. As far as I know data is always passed to the cache store on the same node it is being written in case of TRANSACTIONAL cache, to make cache store transaction-aware, unless write-behind mode is enabled (making the cache store effectively not participating in the actual txs that wrote

[jira] [Created] (IGNITE-6977) Wrong initial BitSet size in GridPartitionStateMap

Alexander Belyak created IGNITE-6977: Summary: Wrong initial BitSet size in GridPartitionStateMap Key: IGNITE-6977 URL: https://issues.apache.org/jira/browse/IGNITE-6977 Project: Ignite

Re: Losing data during restarting cluster with persistence enabled

Valentin, >> Why don't you use Ignite persistence [1]? I have a use case for one of the projects that need the RAM on disk replication only. All PDS features aren't needed. During the first assessment, persist to RocksDB works faster. >> CacheStore design assumes that the underlying storage is

[GitHub] ignite pull request #3076: IGNITE-6171: + LongJVMPauseDetector, + longJVMPau...

GitHub user x-kreator opened a pull request: https://github.com/apache/ignite/pull/3076 IGNITE-6171: + LongJVMPauseDetector, + longJVMPausesCount and longJVM… …PausesTotalDuration properties of IgniteMXBean. You can merge this pull request into a Git repository by running:

[GitHub] ignite pull request #3075: no BaselineTopology for in-memory-only grid

GitHub user sergey-chugunov-1985 opened a pull request: https://github.com/apache/ignite/pull/3075 no BaselineTopology for in-memory-only grid You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite

[GitHub] ignite pull request #3077: IGNITE-2766 Ensure that cache is available after ...

GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/3077 IGNITE-2766 Ensure that cache is available after client ID changes. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite

[jira] [Created] (IGNITE-6978) Failed to move temp file to a regular WAL segment file

Oleg Ostanin created IGNITE-6978: Summary: Failed to move temp file to a regular WAL segment file Key: IGNITE-6978 URL: https://issues.apache.org/jira/browse/IGNITE-6978 Project: Ignite

[jira] [Created] (IGNITE-6976) Visor CMD: Add ability to put/get/remove data to caches via command line Visor.

Alexey Kuznetsov created IGNITE-6976: Summary: Visor CMD: Add ability to put/get/remove data to caches via command line Visor. Key: IGNITE-6976 URL: https://issues.apache.org/jira/browse/IGNITE-6976

Re: Data eviction/expiration from Ignite persistence

We might break the compatibility for the next major release or even create a tool that will migrate persistence files from an old to new formats. — Denis > On Nov 21, 2017, at 8:34 AM, Dmitry Pavlov wrote: > > Hi Denis, > > Second fix we need to do is B+ tree

[jira] [Created] (IGNITE-6982) .NET: Migrate to latest NUnit

Pavel Tupitsyn created IGNITE-6982: -- Summary: .NET: Migrate to latest NUnit Key: IGNITE-6982 URL: https://issues.apache.org/jira/browse/IGNITE-6982 Project: Ignite Issue Type: Improvement

Re: Facility to detect long STW pauses and other system response degradations

Anton, The question is why user may need so precise measurement? I share Andrey’s opinion - cannot understand the value. вт, 21 нояб. 2017 г. в 19:33, Anton Vinogradov : > Andrey, > > > JVM provides sufficient means of detecting a struggling process out of > the box.

Re: SQL warning for partitioned caches with setLocal

Hi Vladmir, Agree - they shouldnt be coupled togethor but what if we can set something in affinity api which can be read in sql api. Please correct me if I am wrong but in the affinityCall/Run we have to provide all the cache names and rebalancing will skip if there is already an operation in

Re: SQL warning for partitioned caches with setLocal

Hi Luqman, I do not think SQL and compute should be coupled in the product. Instead, we should fix local query execution and pin partitions in the same way it is done for affinityCall/Run and distributed SQL. On Tue, Nov 21, 2017 at 6:25 PM, luqmanahmad wrote: > Thanks

Re: Losing data during restarting cluster with persistence enabled

Vyacheslav, If you want the persistence storage to be *distributed*, then using Ignite persistence would be the easiest thing to do anyway, even if you don't need all its features. CacheStore indeed can be updated from different nodes with different nodes, but the problem is in coordination. If

Re: Right MXBean for new metrics

Hi Alex, I think the proper approach would be to have a separate MBean for cache groups. It should show average metrics across all the caches in the group and some additional metrics as well. Agree? Also, I am not sure I understand what is "partition redundancy level" and what that metric would