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

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

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

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

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

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: >

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. > >

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

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

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

[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

[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

[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

[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

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

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