Re: Ignite-2.0 - Make near readers update async by default

Hm... interesting. My questions are inline. On Mon, Jan 30, 2017 at 3:29 PM, Yakov Zhdanov wrote: > Guys, > > Currently when we do cache updates in FULL_SYNC mode we update near readers > (near cache entries) synchronously. This is quite big drawback in design, I > think. I get each near reader

Re: Tasks Scheduling and Chaining

Why can't we use a cache event, e.g. storing some flag in cache at the end of task 1 to notify that task 2 needs to be started? We cannot create an API for absolutely every possible task event. I can come up with many other possible permutations for task sequencing, e.g. task 2 starts in the middl

Re: Tasks Scheduling and Chaining

I think this definitely should be part of Compute Grid API. We can then implement ScheduledExecutorService based on this API (similar to existing ExecutorService implementation which is based on existing compute API), but it should be a separate task. -Val On Fri, Feb 3, 2017 at 3:42 PM, Denis Ma

Re: Apache Ignite Website Audit Status

Hi Terry, Such a valuable feedback and analysis! Thanks for doing this. At least I can assist Mauricio reviewing and committing the changes. Mauricio, as a contributor, you can grab the site source from here: https://svn.apache.org/repos/asf/ignite/site/trunk — Denis > On Feb 3, 2017, at 2:43

Tasks Scheduling and Chaining

Igniters, Conjure the cases when a task (aka. distributed computation): - has to executed in an hour or - its execution has to be triggered only the other task completes. The first time-based case is partially supported by Ignite’s executor service. However, it has a significant flaw - a task sc

Apache Ignite Website Audit Status

Hi Igniters, We have completed the initial stage of analyzing the Apache Ignite website. Based on the initial review, we identified the following issues: * An http and https version of the site are both resolving. Neither has a canonical tag on them. * Https is the one being s

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Oleg, Thanks, appreciate this. It simplified the review process for me. I’ve left a valuable feedback in the ticket. Please address them. https://issues.apache.org/jira/browse/IGNITE-4212 I’ll keep reviewing as soon as initial issues are fixed

Re: Ensure that builder approach is used for all setters in public API

Folks, I tend to think that the problem is that we try to apply 'builder approach' to *ALL* setters. Let's approach this smarter. This approach is actually applicable only for configuration setters available on public API, i.e. it's only about setters on ***Configuration classes and SPI *implemen

Re: Ensure that builder approach is used for all setters in public API

Sorry, “public modifications” -> “public APIs” — Denis > On Feb 3, 2017, at 10:03 AM, Denis Magda wrote: > > Andrey, > > If the changes affect public modifications don’t forget to update this page: > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide > >

Re: moving to geronimo JCache jar

Alexandr, thanks! I’ve merged your changes to the master branch. — Denis > On Feb 3, 2017, at 12:49 AM, Alexander Fedotov > wrote: > > So, I suppose we should revert JSR107 license fixes in LICENSE_FABRIC and > LICENSE_HADOOP too. > Will update PR shortly. > > On Fri, Feb 3, 2017 at 3:41 AM,

Re: Ensure that builder approach is used for all setters in public API

Andrey, If the changes affect public modifications don’t forget to update this page: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide — Denis > On Feb 3, 2017, at 12:24 AM

Re: IGNITE-3244

If a value can be serialized to BinaryObject then it will be serialized. This piece of the code works perfectly well as far as I understand. I would agree with Vladimir that the binary protocol needs to be revisited or the way we serialize/deserialize arrays. Presently, when an array of any type

Re: IGNITE-3244

There is javax.cache.integration.CacheWriter#write() method which writes key and value, wrapped in CacheEntryImpl. In case of class arrays, values must be in form of BinaryObject or serialized class arrays ? чт, 2 февр. 2017 г. в 19:57, Denis Magda : > Yes, this is exactly the reason why this tic

Re: Do not use H2 parser for DDL

Nope, but we can add this to H2 to make it compatible with Oracle [1] and/or PostgreSQL [2]. [1] https://logicalread.com/oracle-11g-named-parameters-in-sql-function-calls-mc02 [2] https://www.postgresql.org/docs/9.1/static/sql-syntax-calling-funcs.html Sergi 2017-02-03 17:41 GMT+03:00 Vladimir O

[jira] [Created] (IGNITE-4655) Reduce heap usage on exchange.

Alexei Scherbakov created IGNITE-4655: - Summary: Reduce heap usage on exchange. Key: IGNITE-4655 URL: https://issues.apache.org/jira/browse/IGNITE-4655 Project: Ignite Issue Type: Bug

Re: Do not use H2 parser for DDL

Sergi, Does H2 support naming for function parameters? E.g. NEW_CACHE(backups: 1, mode: PARTITIONED) On Fri, Feb 3, 2017 at 4:28 PM, Sergi Vladykin wrote: > Actually we do not support FULLTEXT indexes in SQL right now. Thus I think > we will have to postpone this feature anyways. > > I hope tha

[GitHub] ignite pull request #1497: Ignite 4541b

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

[GitHub] ignite pull request #1496: IGNITE-3994

GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/1496 IGNITE-3994 Client buffer CacheContinuousQueryEntry on pendingEvts after reconnect to alive cluster You can merge this pull request into a Git repository by running: $ git pull https://git

[GitHub] ignite pull request #1495: Ignite 4395 Implement communication backpressure ...

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/1495 Ignite 4395 Implement communication backpressure per policy - SYSTEM or PUBLIC You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/

[GitHub] ignite pull request #1494: Ignite 4395 Implement communication backpressure ...

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

[GitHub] ignite pull request #1494: Ignite 4395 Implement communication backpressure ...

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/1494 Ignite 4395 Implement communication backpressure per policy - SYSTEM or PUBLIC You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/

Re: IGNITE-3244

This is very important thing because we need same thing in .NET/CPP platforms. I think we should extend the protocol and add type IDs to container's header: Provided that Java do not have normal generics, it will be a no-op for Collection and Map. But it will be used extensively in .NET and CPP. D

Re: Do not use H2 parser for DDL

Actually we do not support FULLTEXT indexes in SQL right now. Thus I think we will have to postpone this feature anyways. I hope that H2 Mode will solve most of the problems here. But another thing is that IMO we should avoid inventing any "too custom" SQL syntax. For example I agree that we have

[GitHub] ignite pull request #1493: IGNITE-4654 GridMarshallerPerformanceTest#testGri...

GitHub user zstan opened a pull request: https://github.com/apache/ignite/pull/1493 IGNITE-4654 GridMarshallerPerformanceTest#testGridMarshaller fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-46

[jira] [Created] (IGNITE-4654) GridMarshallerPerformanceTest fail

Stanilovsky Evgeny created IGNITE-4654: -- Summary: GridMarshallerPerformanceTest fail Key: IGNITE-4654 URL: https://issues.apache.org/jira/browse/IGNITE-4654 Project: Ignite Issue Type: B

[jira] [Created] (IGNITE-4653) Support analytical ROLLUP and CUBE functions

Vladimir Ozerov created IGNITE-4653: --- Summary: Support analytical ROLLUP and CUBE functions Key: IGNITE-4653 URL: https://issues.apache.org/jira/browse/IGNITE-4653 Project: Ignite Issue Typ

[jira] [Created] (IGNITE-4652) Optimization: implement BPlusTree.invoke

Semen Boikov created IGNITE-4652: Summary: Optimization: implement BPlusTree.invoke Key: IGNITE-4652 URL: https://issues.apache.org/jira/browse/IGNITE-4652 Project: Ignite Issue Type: Task

[GitHub] ignite pull request #1492: IGNITE-4619 .NET: TransactionScope example

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1492 IGNITE-4619 .NET: TransactionScope example You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-4619 Alternatively you ca

Re: Unexpected behavior of DiscoveryCustomMessage acks

I think we should have duplicate filtering logic in discovery manager. As far as I remember, we wanted custom events to be consistent with other discovery events and we rely on the fact that node joined and node left event won't be received twice. 2017-02-03 14:40 GMT+03:00 Sergey Chugunov : >

[GitHub] ignite pull request #1491: IGNITE-4492 Add MBean for StripedExecutor

GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/1491 IGNITE-4492 Add MBean for StripedExecutor added MXBean and its interface for communicating with StripedExecutor added tests for StripedExecutor You can merge this pull request into a Git reposito

[jira] [Created] (IGNITE-4651) Support CREATE TABLE and DROP TABLE commands

Vladimir Ozerov created IGNITE-4651: --- Summary: Support CREATE TABLE and DROP TABLE commands Key: IGNITE-4651 URL: https://issues.apache.org/jira/browse/IGNITE-4651 Project: Ignite Issue Typ

Re: Ensure that builder approach is used for all setters in public API

I've found no restriction on return type in MBeans spicification [1]: A *setter* is any public method that takes a single parameter and whose name begins with set. [1] https://docs.oracle.com/javase/tutorial/jmx/mbeans/standard.html On Fri, Feb 3, 2017 at 11:24 AM, Andrey Mashenkov < andrey.ma

Re: Unexpected behavior of DiscoveryCustomMessage acks

Yakov, Thanks for clean explanation, also I found exactly that logic in RingMessageWorker code. But I strongly believe that this behavior should have been documented in *DiscoveryCustomMessage* interface (I think it is the best place for this). Messaging managers like discovery manager must prov

Re: IGNITE-3196 - ready for review

1. On my first question I think up, if we serialize only positive numbers, we can write sign in first byte, because it is positive always. I will try to make this decision 2017-02-03 12:48 GMT+03:00 Pavel Tupitsyn : > Vyacheslav, > > I see the problem now. Yes, negative scale is not supported in

Re: Unexpected behavior of DiscoveryCustomMessage acks

Can anyone point a place in javadoc that states that there is exactly once guarantee? Imagine you have nodes A, B and C. A sends custom message to B and gets ack back, B sends to C and dies. A connects to C and resends the message. Result - C has got the message twice. Currently handling logic is

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

But I suppose we should file a new ticket for that task On Fri, Feb 3, 2017 at 12:35 PM, Sergey Kozlov wrote: > Yes we can do it as new project but the task should be redesigned at least > by security reasons (removing the credentials). > > On Fri, Feb 3, 2017 at 12:29 PM, Anton Vinogradov < > a

Re: IGNITE-3196 - ready for review

Vyacheslav, I see the problem now. Yes, negative scale is not supported in .NET. I don't think we should do the multiplication. As you described, this will break equality on Java side. SQL queries might be broken, etc. I think we should throw an exception in .NET when encountering negative decima

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Yes we can do it as new project but the task should be redesigned at least by security reasons (removing the credentials). On Fri, Feb 3, 2017 at 12:29 PM, Anton Vinogradov wrote: > BTW, it will be a good point to relocate Ignite assembly to > ci.ignite.apache.org :) > > On Fri, Feb 3, 2017 at 1

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

BTW, it will be a good point to relocate Ignite assembly to ci.ignite.apache.org :) On Fri, Feb 3, 2017 at 12:26 PM, Sergey Kozlov wrote: > Hi > > Not sure that we've a release task on ci.ignite.apache.org > > On Fri, Feb 3, 2017 at 12:20 PM, Anton Vinogradov < > avinogra...@gridgain.com> > wrot

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Hi Not sure that we've a release task on ci.ignite.apache.org On Fri, Feb 3, 2017 at 12:20 PM, Anton Vinogradov wrote: > Oleg, you can point to TC build artifacts next time. > > On Fri, Feb 3, 2017 at 11:49 AM, Oleg Ostanin > wrote: > > > Hi! > > > > Denis, I've uploaded Ignite release binarie

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Oleg, you can point to TC build artifacts next time. On Fri, Feb 3, 2017 at 11:49 AM, Oleg Ostanin wrote: > Hi! > > Denis, I've uploaded Ignite release binaries with my changes here: > > https://drive.google.com/file/d/0B9teTzJ9iIvHYTdUMlRsYTdRckk/ > view?usp=sharing > > On Thu, Feb 2, 2017 at 8

Re: IGNITE-3244

it is org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl#marshalToBinary() method which creates Object array and put binaries into it, which eliminates array's primary class info. So i suggest to make return it array of correct type. For example , marshalToBinary( Te

[jira] [Created] (IGNITE-4650) Scan and SPI queries must go through dedicated query pool

Vladimir Ozerov created IGNITE-4650: --- Summary: Scan and SPI queries must go through dedicated query pool Key: IGNITE-4650 URL: https://issues.apache.org/jira/browse/IGNITE-4650 Project: Ignite

[GitHub] ignite pull request #1459: Ignite 4537 Update Notifier must not transfer sys...

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

Re: IGNITE-3196 - ready for review

Hello. I looked and understood the code of methods ReadDecimal and WriteDecimal on .NET platform. 1. At the moment remaking of this methods for my Java-decimal-fix is very difficult, it needs to write new methods for serialization/deserialization of negative decimals. I can make it, but there is

[GitHub] ignite pull request #1489: IGNITE-4252 Fixed exception with local cache quer...

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

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Hi! Denis, I've uploaded Ignite release binaries with my changes here: https://drive.google.com/file/d/0B9teTzJ9iIvHYTdUMlRsYTdRckk/view?usp=sharing On Thu, Feb 2, 2017 at 8:02 PM, Denis Magda wrote: > Oleg, thanks, > > Could you share Ignite release binaries with your patch applied? You > sho

Re: moving to geronimo JCache jar

So, I suppose we should revert JSR107 license fixes in LICENSE_FABRIC and LICENSE_HADOOP too. Will update PR shortly. On Fri, Feb 3, 2017 at 3:41 AM, Denis Magda wrote: > Got more clarifications from the folks that driving the license upgrade. > We need to wait until the process fully finishes:

[GitHub] ignite pull request #1486: IGNITE-4196 Added means to specify port for H2 de...

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

Re: Ensure that builder approach is used for all setters in public API

Vladimir, Ok. I'll go ahead with changing SPI interfaces and run TC test. I think, it would be better to have this branch merged to master as 2 separate commits at least. And may be we should make changes of SPI interfaces in separate Jira ticket? On Fri, Feb 3, 2017 at 11:08 AM, Vladimir Ozerov

Re: Ensure that builder approach is used for all setters in public API

Andrey, This is very important change from usability standpoint. But my main concern is changes to SPI *interfaces*. If we do so users who implemented custom SPIs will have broken compatibility. On the other hand, I doubt there will be too much affected users, and we break compilation in AI 2.0 an