Re: cache query operations

So, when GridCacheTtlManager evicted cache entry due to timeout, how H2 got notified about it ? And as i understand, firstly cacheEntry got evicted, and then H2 data got updated(removed corresponding entry) вт, 18 апр. 2017 г. в 17:56, Denis Magda : > That’s true, SELECT

Re: Apache Ignite 2.0 Release

Vovan, Do I need to commit a 2.0 change to ignite-2.0 first and then merge it back to the master? What’s the process? — Denis > On Apr 18, 2017, at 5:13 AM, Vladimir Ozerov wrote: > > Folks, > > I created branch for AI 2.0: ignite-2.0. Relevant PR #1819. Let's continue

Re: Introduce custom executors for compute grid

Thanks Taras, this will be very handy. I assume its not currently possible to constrain an executor pool to be started only on a specific node? C. > On 18 Apr 2017, at 15:55, Denis Magda wrote: > > Taras, that’s an excellent addition to the project! > > Please don’t

Re: Apache Ignite 2.0 Release

Denis, As usual: merge to release branch at the very least. You can merge ignite-2.0 -> master immediately then if you want, but it is not necessary. ignite-2.0 will be merged to master eventually anyway. On Tue, Apr 18, 2017 at 6:00 PM, Denis Magda wrote: > Vovan, > > Do I

Re: Introduce custom executors for compute grid

Hi, Christos. 1. The custom executor executor is configured for specified node. There is not restriction that guaranties the similar set of executors on the whole cluster. 2. I guess You can use ClusterGroup.forPredicate() and custom node attribute when you want to submit the job only to

Re: Introduce custom executors for compute grid

Agree, very useful. Does the service grid run in its own thread pool? Just wondering if this feature can be useful there as well. D. On Tue, Apr 18, 2017 at 7:55 AM, Denis Magda wrote: > Taras, that’s an excellent addition to the project! > > Please don’t forget to document

Re: Introduce custom executors for compute grid

Taras, If I’m understanding right: Executor is configured local to a node, if same configuration is used to start multiple nodes then they will all have the same executor hence a broadcast task would execute on both all nodes. If one of those nodes didn’t have this executor configured then

[GitHub] ignite pull request #1823: Ignite 4799

GitHub user abeliak opened a pull request: https://github.com/apache/ignite/pull/1823 Ignite 4799 Do not merge You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4799 Alternatively you can review and

Re: Introduce custom executors for compute grid

D, I think this fixed with this ticket: https://issues.apache.org/jira/browse/IGNITE-4802 > On 18 Apr 2017, at 16:30, Dmitriy Setrakyan wrote: > > Agree, very useful. > > Does the service grid run in its own thread

[jira] [Created] (IGNITE-5018) review and improve javadocs in ML module

Oleg Ignatenko created IGNITE-5018: -- Summary: review and improve javadocs in ML module Key: IGNITE-5018 URL: https://issues.apache.org/jira/browse/IGNITE-5018 Project: Ignite Issue Type:

Re: cache query operations

I can’t answer on this question because didn’t develop that part of the system. Could you try to find this out debugging the code? — Denis > On Apr 18, 2017, at 8:00 AM, ALEKSEY KUZNETSOV > wrote: > > So, when GridCacheTtlManager evicted cache entry due to timeout,

Re: cache query operations

That’s true, SELECT queries are executed right away by H2 while DML are eventually converted to key-value operations. — Denis > On Apr 18, 2017, at 1:29 AM, ALEKSEY KUZNETSOV > wrote: > > if executing sql "select" clause then no cache key-value operations would > be

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Nice! Finally Ignite from a "Middleware Solution" becoming an "All In One Backend Solution". Sergi 2017-04-18 5:46 GMT+03:00 Dmitriy Setrakyan : > Great news and I am glad that GridGain was finally able to open source such > an essential feature to Ignite. Given that I

[GitHub] ignite pull request #1785: IGNITE-4954 - Configurable expiration timeout for...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1785 --- 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

[jira] [Created] (IGNITE-5012) Implement ordinary least squares (OLS) linear regression.

Artem Malykh created IGNITE-5012: Summary: Implement ordinary least squares (OLS) linear regression. Key: IGNITE-5012 URL: https://issues.apache.org/jira/browse/IGNITE-5012 Project: Ignite

[jira] [Created] (IGNITE-5013) Allow pass custom types to Cassandra store

Dmitry Karachentsev created IGNITE-5013: --- Summary: Allow pass custom types to Cassandra store Key: IGNITE-5013 URL: https://issues.apache.org/jira/browse/IGNITE-5013 Project: Ignite

Re: Apache Ignite 2.0 Release

CREATE/DROP INDEX feature [1] has been merged to release branch. [1] https://issues.apache.org/jira/browse/IGNITE-4565 On Tue, Apr 18, 2017 at 4:10 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Hi Roman, > > I tried to run tests for RocketMQ streamer, but they failed for me (I've

[jira] [Created] (IGNITE-5014) Do not used partition exchange worker for CREATE/DROP INDEX

Vladimir Ozerov created IGNITE-5014: --- Summary: Do not used partition exchange worker for CREATE/DROP INDEX Key: IGNITE-5014 URL: https://issues.apache.org/jira/browse/IGNITE-5014 Project: Ignite

[GitHub] ignite pull request #1820: fix GridIntList directType

GitHub user kdudkov opened a pull request: https://github.com/apache/ignite/pull/1820 fix GridIntList directType You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite intlist_fix Alternatively you can review

[jira] [Created] (IGNITE-5019) Deadlock in GridCacheVariableTopologySelfTest.testNodeStop

Dmitriy Govorukhin created IGNITE-5019: -- Summary: Deadlock in GridCacheVariableTopologySelfTest.testNodeStop Key: IGNITE-5019 URL: https://issues.apache.org/jira/browse/IGNITE-5019 Project:

[GitHub] ignite pull request #1824: ignite-5019 Deadlock in GridCacheVariableTopology...

GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/1824 ignite-5019 Deadlock in GridCacheVariableTopologySelfTest.testNodeStop You can merge this pull request into a Git repository by running: $ git pull

Re: Adding ML to Ignite, IGNITE-4572

Denis, As far as I can tell renames are now finalized in the way you proposed yesterday. I re-run my checks for build, module unit tests and examples (everything went fine) and updated draft doc for readme.io accordingly. You can find most recent version of the draft doc attached to JIRA

[GitHub] ignite pull request #1818: IGNITE-5000 (Rename Ignite Math module to Ignite ...

GitHub user ybabak opened a pull request: https://github.com/apache/ignite/pull/1818 IGNITE-5000 (Rename Ignite Math module to Ignite ML module): added missed licenses renamed packages fixed wrong ml profile activation You can merge this pull request into a Git

[jira] [Created] (IGNITE-5011) Add validation of input params of disco command

Pavel Konstantinov created IGNITE-5011: -- Summary: Add validation of input params of disco command Key: IGNITE-5011 URL: https://issues.apache.org/jira/browse/IGNITE-5011 Project: Ignite

Re: Apache Ignite 2.0 Release

Hi Roman, I tried to run tests for RocketMQ streamer, but they failed for me (I've added a comment in the ticket). Can you please take a look? 2017-04-18 15:13 GMT+03:00 Vladimir Ozerov : > Folks, > > I created branch for AI 2.0: ignite-2.0. Relevant PR #1819. Let's

Re: Performance vs correctness: I vote fore the second

Sergi, most probably, performance will not be vert much affected since we can batch delayed responses and this for primary_sync only. However, I agree with your point about overcomplicated code, but I did not state that it would be trivial. So, what is the solution here? Switch replicated cache

Re: Performance vs correctness: I vote fore the second

I agree with Yakov. Let's not swing like a pendulum from one side to the other. Why not switch to FULL_SYNC only for REPLICATED caches? D. On Tue, Apr 18, 2017 at 5:48 AM, Yakov Zhdanov wrote: > Sergi, most probably, performance will not be vert much affected since we >

Re: Introduce custom executors for compute grid

Christos, I think you are right in general, however, is the executor service is not found, there should not be an exception, we should default to the public pool. D. On Tue, Apr 18, 2017 at 8:53 AM, Christos Erotocritou wrote: > Taras, > > If I’m understanding right: >

Re: IGNITE-4799 MetricsUpdate after each job

Denis, thanks! That makes sense to me. Sasha, please go ahead and change code to interpret this parameter as exact frequency in milliseconds. -- Yakov Zhdanov

Re: Performance vs correctness: I vote fore the second

Vladimir, What is wrong with a query in PRIMARY_SYNC mode? Why won't it work? D. On Tue, Apr 18, 2017 at 12:25 AM, Vladimir Ozerov wrote: > Folks, > > I received a number of complaints from users that our default setting favor > performance at the cost of correctness and

Re: Performance vs correctness: I vote fore the second

Val, I'm not sure I understand what optimization you are talking about and what exactly did you decide to switch off, can you explain please? Sergi 2017-04-18 10:42 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > This sounds more like an issue with query execution, rather

Re: Performance vs correctness: I vote fore the second

Val, PRIMARY_SYNC doesn't work correctly with the most common case of SQL query execution over REPLICATED cache. Also it has weird consequences for continuous queries when coupled with another performance-over-correctness property "readFromBackup=true": user may receive CQ notification with new

Re: Performance vs correctness: I vote fore the second

Sergi, I'm talking about this discussion: http://apache-ignite-developers.2346864.n4.nabble.com/SQL-on-PARTITIONED-vs-REPLICATED-cache-td16478.html -Val On Tue, Apr 18, 2017 at 9:46 AM, Vladimir Ozerov wrote: > Val, > > PRIMARY_SYNC doesn't work correctly with the most

[GitHub] ignite pull request #1810: MemoryConfiguration javadoc updated

Github user sergey-chugunov-1985 closed the pull request at: https://github.com/apache/ignite/pull/1810 --- 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

Re: Performance vs correctness: I vote fore the second

Val, That discussion has nothing to do with this PRIMARY_SYNC problem. Sergi 2017-04-18 10:51 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Sergi, > > I'm talking about this discussion: > http://apache-ignite-developers.2346864.n4.nabble. >

Introduce custom executors for compute grid

Igniters, Custom executor (user's thread pool) is added fro compute grid with following semantics: 1. Configuration: IgniteConfiguration cfg; ... cfg.setExecutorConfiguration( new ExecutorConfiguration().setName("executor0").setSize(2), new

Re: question: How data are stored in IgniteCache?

Denis, thanks a lot for your explanations. 2017-04-17 21:20 GMT+03:00 Denis Magda : > It depends on a storage. If it’s a relational database and > isStoreKeepBinary is false then an object will be deserialized upon the > store invocation and the storage will insert or update a

Performance vs correctness: I vote fore the second

Folks, I received a number of complaints from users that our default setting favor performance at the cost of correctness and subtle behavior. Yesterday I faced one such situation on my own. I started REPLICATED cache on several nodes, put some data, executed simple SQL and got wrong result. No

Re: Performance vs correctness: I vote fore the second

With replicated cache we can execute a query against backup partitions that were not updated yet because of PRIMARY_SYNC. Thus we do not see an update. Sergi 2017-04-18 10:30 GMT+03:00 Dmitriy Setrakyan : > Vladimir, > > What is wrong with a query in PRIMARY_SYNC mode?

Re: Performance vs correctness: I vote fore the second

This sounds more like an issue with query execution, rather than wrong PRIMARY_SYNC behavior. We already had a discussion about this optimization in replicated cache and decided to switch it off by default. -Val On Tue, Apr 18, 2017 at 9:35 AM, Sergi Vladykin wrote: >

[GitHub] ignite pull request #1732: IGNITE-4856 .NET: StopAll on AppDomain unload

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1732 --- 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

Re: cache query operations

thanx! ) пн, 17 апр. 2017 г. в 21:48, Denis Magda : > Did you have a chance to take a look this documentation that explains how > DML statements are turned into cache operations? > https://apacheignite.readme.io/docs/dml#dml-operations < >

Re: IGNITE-4052 ready for review

Hi Nikolay! The comments was added. Vadim 2017-04-17 15:32 GMT+03:00 Nikolai Tikhonov : > Vadim, > > Thank you for your contribution. I'll look at changes. Can you please post > the list improvements to jira ticket? > > On Mon, Apr 17, 2017 at 3:23 PM, Вадим Опольский

Re: Performance vs correctness: I vote fore the second

Can you please elaborate then? What is the logic there? -Val On Tue, Apr 18, 2017 at 9:55 AM, Sergi Vladykin wrote: > Val, > > That discussion has nothing to do with this PRIMARY_SYNC problem. > > Sergi > > 2017-04-18 10:51 GMT+03:00 Valentin Kulichenko < >

Re: Performance vs correctness: I vote fore the second

Val, There we were not able to run queries against partitioned tables using replicated cache API (I already fixed that in master). Here we are talking about query result inconsistency in case of PRIMARY_SYNC because of async backup update. Sergi 2017-04-18 11:04 GMT+03:00 Valentin Kulichenko <

[GitHub] ignite pull request #1787: IGNITE-2398 .NET: Change default mapper behavior

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1787 --- 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

[GitHub] ignite pull request #1774: IGNITE-4946

Github user gvvinblade closed the pull request at: https://github.com/apache/ignite/pull/1774 --- 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

[jira] [Created] (IGNITE-5009) Backport IGNITE-4932 optimization in 2.x release

Semen Boikov created IGNITE-5009: Summary: Backport IGNITE-4932 optimization in 2.x release Key: IGNITE-5009 URL: https://issues.apache.org/jira/browse/IGNITE-5009 Project: Ignite Issue

Re: cache query operations

if executing sql "select" clause then no cache key-value operations would be called. Debbuging cache.query(...) leads to org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#executeSqlQuery which doesnt call cache key-value ops вт, 18 апр. 2017 г. в 10:49, ALEKSEY KUZNETSOV

Re: Page Memory behavior with default memory policy

I think Ignite can behave like JVM: we can have -Xms -Xmx settings with defaults depending on available memory. Thanks On Tue, Apr 18, 2017 at 4:56 AM, Dmitriy Setrakyan wrote: > Denis, > > If what you are suggesting is true, then we can always allocate about 80% > of

Re: Page Memory behavior with default memory policy

The reason we cannot add another memory region to page memory is performance. Currently, the translation of a page ID to a virtual address is basically a no-op. If we add dynamic memory expansion, we need to maintain some sort of page ID mapping, which adds significant (in my view, about 10%)

[jira] [Created] (IGNITE-5016) SQL: Support LEFT JOIN from replicated table to a partitioned.

Sergi Vladykin created IGNITE-5016: -- Summary: SQL: Support LEFT JOIN from replicated table to a partitioned. Key: IGNITE-5016 URL: https://issues.apache.org/jira/browse/IGNITE-5016 Project: Ignite

[GitHub] ignite pull request #1818: IGNITE-5000 (Rename Ignite Math module to Ignite ...

Github user ybabak closed the pull request at: https://github.com/apache/ignite/pull/1818 --- 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

[GitHub] ignite pull request #1821: 8.0.4.ea1 tests run

GitHub user glukos opened a pull request: https://github.com/apache/ignite/pull/1821 8.0.4.ea1 tests run Pull request for running ignite tests on 8.0.4.ea1. Please, don't merge. You can merge this pull request into a Git repository by running: $ git pull

[GitHub] ignite pull request #1819: Ignite 2.0

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

Re: Apache Ignite 2.0 Release

Folks, I created branch for AI 2.0: ignite-2.0. Relevant PR #1819. Let's continue 2.0 finalization in this branch. On Wed, Apr 12, 2017 at 7:58 AM, Dmitriy Setrakyan wrote: > Awesome! Great addition to the project. > > On Tue, Apr 11, 2017 at 8:27 PM, Denis Magda

[jira] [Created] (IGNITE-5015) In TcpCommunicationSpi use IgniteConfiguration.clientFailureDetectionTimeout

Alexander Belyak created IGNITE-5015: Summary: In TcpCommunicationSpi use IgniteConfiguration.clientFailureDetectionTimeout Key: IGNITE-5015 URL: https://issues.apache.org/jira/browse/IGNITE-5015

[jira] [Created] (IGNITE-5017) HTML formatted releases notes

Sergey Kozlov created IGNITE-5017: - Summary: HTML formatted releases notes Key: IGNITE-5017 URL: https://issues.apache.org/jira/browse/IGNITE-5017 Project: Ignite Issue Type: Bug

When cache topology can be null?

One case is when node is down. Is there other cases?

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

Nikita, For Externalizable option 1 is the correct one. Externalizable objects should not be treated as binary objects. For read/writeObject, you indeed have to extend ObjectOutputStream. writeObject() is final because you should extend writeObjectOverride() instead. Take a look at

[GitHub] ignite pull request #1822: IGNITE-5008 message of IgniteOutOfMemoryException...

GitHub user sergey-chugunov-1985 opened a pull request: https://github.com/apache/ignite/pull/1822 IGNITE-5008 message of IgniteOutOfMemoryException was detailed You can merge this pull request into a Git repository by running: $ git pull

Re: Introduce custom executors for compute grid

Taras, that’s an excellent addition to the project! Please don’t forget to document it: https://issues.apache.org/jira/browse/IGNITE-4969 — Denis > On Apr 18, 2017, at 1:23 AM, Taras Ledkov wrote: > > Igniters, > >

Re: Stable binary key representation

At all, guys, BinaryIdentityResolvers were discontinued but the ticket [1] that had triggered the discussion has not been fixed yet. It must be fixed in 2.0 otherwise Hibernate integration can be considered broken in 2.0 because the initial workaround was based on the resolvers. Andrey M.,

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Igniters, I would encourage everyone interested to share his/her opinion on this donation and if there are no objections I will kick off an official vote in a couple of ways. — Denis > On Apr 18, 2017, at 4:11 AM, Nikita Ivanov wrote: > > Combining this with upcoming

[GitHub] ignite pull request #1825: lazy qry

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

Re: Introduce custom executors for compute grid

On Tue, Apr 18, 2017 at 1:49 PM, Vladimir Ozerov wrote: > Yes, task will be routed to public pool with a warning to the log. > Let's make sure we throttle these warnings for every computation so we do not flood the logs. > > On Tue, Apr 18, 2017 at 9:21 PM, Dmitriy

[GitHub] ignite pull request #1814: IGNITE-4939 Receive event before cache initialize...

Github user ezhuravl closed the pull request at: https://github.com/apache/ignite/pull/1814 --- 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

[GitHub] ignite pull request #1814: IGNITE-4939 Receive event before cache initialize...

GitHub user ezhuravl opened a pull request: https://github.com/apache/ignite/pull/1814 IGNITE-4939 Receive event before cache initialized fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4939

[GitHub] ignite pull request #1814: IGNITE-4939 Receive event before cache initialize...

GitHub user ezhuravl reopened a pull request: https://github.com/apache/ignite/pull/1814 IGNITE-4939 Receive event before cache initialized fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4939

Re: Performance vs correctness: I vote fore the second

Dima, If change behavior of REPLICATED caches this way, instead of nice scalability out of the box, users will have slow distributed joins by default. All we need to do is to set strict FULL_SYNC as default. On Tue, Apr 18, 2017 at 12:26 PM, Dmitriy Setrakyan wrote: > On

Re: Performance vs correctness: I vote fore the second

It only means that we will parse the query always and check if it contains only replicated tables or not. If it does, then we execute the query on a single node across all the partitions. Sergi 2017-04-18 12:26 GMT+03:00 Dmitriy Setrakyan : > On Tue, Apr 18, 2017 at 2:21

[GitHub] ignite pull request #1816: IGNITE-4990 Remove deprecated properties from Fil...

GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/1816 IGNITE-4990 Remove deprecated properties from FileSystemConfiguration You can merge this pull request into a Git repository by running: $ git pull

[jira] [Created] (IGNITE-5010) Add dynamic index create-drop tests for geo-spacial indexes

Vladimir Ozerov created IGNITE-5010: --- Summary: Add dynamic index create-drop tests for geo-spacial indexes Key: IGNITE-5010 URL: https://issues.apache.org/jira/browse/IGNITE-5010 Project: Ignite

Re: Performance vs correctness: I vote fore the second

On Tue, Apr 18, 2017 at 2:21 AM, Sergi Vladykin wrote: > We never read from backups on partitioned cache, but for replicated we do > that to be able to execute the whole query on single node locally.\ > But I thought that we agreed to change that behavior and have

Re: Performance vs correctness: I vote fore the second

Yakov, The idea of tracking current operations and wait if needed looks overcomplicated and most probably will result in performance drop. I think there is no way to have this guarantee with PRIMARY_SYNC in general case. Sergi 2017-04-18 13:25 GMT+03:00 Yakov Zhdanov : >

[GitHub] ignite pull request #1811: Ignite 5000

Github user ybabak closed the pull request at: https://github.com/apache/ignite/pull/1811 --- 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

Re: Page Memory behavior with default memory policy

Thanks, Alexey, got it. What happens if a user starts multiple nodes on the same box? Will it work the way Denis suggested? On Tue, Apr 18, 2017 at 1:47 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > The reason we cannot add another memory region to page memory is > performance.

[GitHub] ignite pull request #1077: Ignite 3920

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1077 --- 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

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

This is fantastic news guys!! Finally a real solution that can cater for BIG AND FAST data! -- View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/GridGain-Donates-Persistent-Distributed-Store-To-ASF-Apache-Ignite-tp16788p16836.html Sent from the Apache Ignite

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Combining this with upcoming new SQL features should give Google Spanner a run for its money... -- Nikita Ivanov On Tue, Apr 18, 2017 at 3:39 AM, christos wrote: > This is fantastic news guys!! Finally a real solution that can cater for > BIG > AND FAST data! > > > > --

Re: Page Memory behavior with default memory policy

On Tue, Apr 18, 2017 at 2:09 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > I don't see why not, this is the way our tests are currently running. > Anyways, we can think about efficient dynamic memory expansion in 2.1, this > may be feasible if we free up some space in PageId to

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

Yeah. I've already run the test with two caches. Definately, the bug hidden in cache.query() method. cache.query() calls IgniteH2Indexing#queryLocalSql(), which calls executeSqlQueryWithTimer, and then it sinks into JdbcPreparedStatement.executeQuery(). There is no key-value operations subsequent

[GitHub] ignite pull request #1812: testAllocatedMemory fix

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1812 --- 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

[GitHub] ignite pull request #1817: Ignite 4473 1

GitHub user issecorvus opened a pull request: https://github.com/apache/ignite/pull/1817 Ignite 4473 1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/ignite ignite-4473-1 Alternatively you can review and apply these

Re: Performance vs correctness: I vote fore the second

Sergi, I am confused. If we don't read from backups, then why do we care about sync or async backup updates? On Tue, Apr 18, 2017 at 1:11 AM, Sergi Vladykin wrote: > Val, > > There we were not able to run queries against partitioned tables using > replicated cache API

Re: Performance vs correctness: I vote fore the second

We never read from backups on partitioned cache, but for replicated we do that to be able to execute the whole query on single node locally. Sergi 2017-04-18 12:07 GMT+03:00 Dmitriy Setrakyan : > Sergi, I am confused. If we don't read from backups, then why do we care >

Re: Performance vs correctness: I vote fore the second

Guys, what if we look at this from another point - we can switch to read from primary only if there is any primary_sync operation that is not acked by backups yet. Or we can wait until all operations of the kind are acked and then proceed with query. This seems to work when we have query after

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

I see two ways to support the Externalizable in the BM: 1. Add a new type constant to the GridBinaryMarshaller class etc and read/writeExternal in the BinaryClassDescriptor. 2. Make read/writeExternal through the BINARY type without updating metadata. I don't know how to make a support

Re: Page Memory behavior with default memory policy

I don't see why not, this is the way our tests are currently running. Anyways, we can think about efficient dynamic memory expansion in 2.1, this may be feasible if we free up some space in PageId to encode segment number. There is a ticket for this:

[GitHub] ignite pull request #1815: IGNITE-4188

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

[GitHub] ignite pull request #1107: Ignite 3920 1

Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/1107 --- 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

Tickets for work

Hello. Could you give me any ticket ? Preferably not time-consuming. -- Best wishes, Amelchev Nikita

[jira] [Created] (IGNITE-5021) visorcmd: log command - incorrect chronology in file

Pavel Konstantinov created IGNITE-5021: -- Summary: visorcmd: log command - incorrect chronology in file Key: IGNITE-5021 URL: https://issues.apache.org/jira/browse/IGNITE-5021 Project: Ignite

Re: Webinar: Apache Ignite as a backbone for microservices-based architectures

Thanks, Denis. I will surely join the conference. Take Care, Rishi > On Apr 18, 2017, at 7:38 PM, Denis Magda wrote: > > Igniters, > > Just a final reminder for those who might be interested. The slides are > ready, the demo is running..so waiting for all of you tomorrow

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Great news indeed! Thanks for sharing! Before we jump on the voting and all that, can we have a chance to learn more about this new feature and its integration points with the rest of the platform? A few questions come to mind immediately: 1. This is an "optional disk layer", so it could be

Re: Webinar: Apache Ignite as a backbone for microservices-based architectures

Igniters, Just a final reminder for those who might be interested. The slides are ready, the demo is running..so waiting for all of you tomorrow April 19, 11:00 AM PST on the line ;) http://bit.ly/2nEmyv1 Plus, look at our “news” section for upcoming conferences where the community is going

Re: Stable binary key representation

Denis, I'll rework PR according new solution. Alex G, Sergi, what approach is used for keys comparison in ignite 2.0 ? On Tue, Apr 18, 2017 at 11:11 PM, Denis Magda wrote: > At all, guys, BinaryIdentityResolvers were discontinued but the ticket [1] > that had triggered the

Re: Introduce custom executors for compute grid

Yes, task will be routed to public pool with a warning to the log. On Tue, Apr 18, 2017 at 9:21 PM, Dmitriy Setrakyan wrote: > Christos, > > I think you are right in general, however, is the executor service is not > found, there should not be an exception, we should

No direct way to download Ignite Web Agent

Engineers, I realized that from the Web Console there is no direct way to download Ignite Web Agent. The only way to download it is by going to either Model, Monitoring, or Queries page (It's odd that to download the web agent, you have to go to model -> import from db-> and then download when

[jira] [Created] (IGNITE-5020) Client node failed with NPE

, order=4, intOrder=0, lastExchangeTime=1492575133264, loc=true, ver=2.0.0#20170418-sha1:6a1d263d, isClient=true]] [11:12:59,580][INFO][sys-#29%tester%][GridCacheProcessor] Stopped cache: igfs-data [11:12:59,586][INFO][sys-#34%tester%][GridCacheProcessor] Stopped cache: offheap-sorted-100 [11:12

  1   2   >