Re: [RESULT] [VOTE] Apache Ignite 2.5.0 Release (RC1)

> >> > >> > вт, 29 мая 2018 г., 22:14 Pavel Tupitsyn : >> > >> > > NuGet (.NET) packages pushed: >> > > https://www.nuget.org/packages?q=Apache.Ignite >> > > >> > > On Tue, May 29, 2018 at 8:59 PM, Andrey Gura >> w

Re: Ability to check and completely fill transactions on creation

t() < 200) > tx.rollback(); > ... > > So, tx will be rollbacked on creation and any commit attempt will cause > TransactionRollbackException > > Full code listing available at > https://github.com/apache/ignite/pull/4036/files > > Dmitriy, Yakov, > Could you p

Re: IGNITE-8238 - Operation can fails with unexpected RuntimeException when node is stopping

As suggested before, please do not put blank ticket numbers into subjects because no one understands ticket numbers. Please add titles or some other context to the subject. This will improve the level of engagement from the community. I have changed the subject of this thread, let's continue the

Re: Node.js Thin Client @ npmjs

nce the client is built it will be uploaded to the npmjs repository, > > right? So, a JS developer can download the client from there without > > touching the whole Ignite binary release. > > > > However, those who download the whole Ignite binary distribution will >

Re: Node.js Thin Client @ npmjs

On Thu, May 24, 2018 at 12:36 PM, Pavel Petroshenko wrote: > Fair enough. Consistency with the other clients is a good argument. > > Pavel, I would discuss it a bit more. Does it really make sense for a node.js user to download the whole Ignite distribution just to get a

Re: Node.js Thin Client @ npmjs

On Thu, May 24, 2018 at 11:42 AM, Igor Sapego wrote: > Well, all other clients have the same version as Ignite. > Are there any reasons to make a Node.js client some > kind of a special case? > > I may have spoken too soon. Do we plan to include the node.js client into Ignite

Re: IGNITE-8583 - review needed

I continuously ask not to provide naked ticket numbers in the subject. Please also add titles or descriptions. I doubt anyone in the community can tell what this is about just by looking at the number. D. On Thu, May 24, 2018 at 4:09 AM, Dmitry Pavlov wrote: > Hi

Re: Node.js Thin Client @ npmjs

On Thu, May 24, 2018 at 10:03 AM, Pavel Petroshenko wrote: > Igor, > > Are you proposing to update the Thin Client versions on every Ignite > release regardless of the changes made to them? > > I tend to think that an independent versioning scheme for the Thin Clients >

Re: Ability to check and completely fill transactions on creation

ss to Ignite > cluster and there is no other way to setup tx cretion rules. > > Yakov, > > Could you please share your thoughts on that? > > > чт, 24 мая 2018 г. в 8:58, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Wed, May 23, 2018 at 4:08 AM, Anton V

Re: Ability to check and completely fill transactions on creation

On Wed, May 23, 2018 at 4:08 AM, Anton Vinogradov wrote: > Dmitriy, Yakov > > Are there any objections to updated design taking into account the comments > I provided? > Anton, I do not like an additional validator. I think you can accomplish the same with a transaction event.

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

iteConfiguration setBaselineAutoAdjustMaxTimeout(long timeoutInMs); > > Any objections? > > > > On Fri, May 4, 2018 at 10:01 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > I do not like the name "current" on the methods. I think we should just >

Re: Upgrading Ignite to JCache 1.1

Igniters, It will be great if someone in the community would pick this up. The amount of changes are minimal and many of them only have to do with clarifying the documentation. However, removing JSR 107 license confusion in 1.1 would be great for Ignite. D. On Tue, May 22, 2018 at 3:04 PM,

Re: Ability to check and completely fill transactions on creation

Anton, The change looks very questionable. We cannot be adding configuration validators for every piece of Ignite API. What is it you are trying to achieve? D. On Mon, May 21, 2018 at 7:22 AM, Anton Vinogradov wrote: > Yakov, thank's for deep check. > > >> I think that we

Re: Baseline topology documentation clarified: usage scenarios and definition

Great docs! Any chance we could add some pictures to illustrate the concept better. On Fri, May 18, 2018 at 2:15 AM, Denis Magda wrote: > Igniters, > > With the help of Stanislav Lukyanov and Ivan Rakov, we could make our > baseline topology documentation much better and

Re: supporting different configuration format json,yaml...

gt; > > > > > When I see such configs my eyes are filled with bloody > tears. > > > > > > > > > > > > > > > > > > I think we should really consider YAML as our additional > > > approach > > >

Re: SqlLine script and Java9

uture Java > versions. > > > > > On 15 May 2018, at 01:55, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > Thanks Petr, > > > > How about Java 10? Do we support it for SqlLine as well? > > > > D. > > > > On Mon, May 14

Re: PHP/Python versions for Thin Clients

> I hope it makes sense. > > Thanks, > p. > > [1] http://php.net/supported-versions.php > [2] https://legacy.python.org/dev/peps/pep-0373/ > [3] https://www.jetbrains.com/research/python-developers-survey-2017/ > > > On Sat, May 12, 2018 at 6:21 AM, Dmitriy Setrakyan

Re: tracking SQL queries in 2.5

On Mon, May 14, 2018 at 3:55 PM, Vladimir Ozerov wrote: > Hi Dima, > > This is not that simple unfortunately. We need to build the whole > infrastructure for cache-less SQL queries. This is not very complex, but > require considerable efforts. Let's do that in AI 2.6 scope.

SqlLine script and Java9

Igniters, Any reason SqlLine tool shipped with Ignite does not work with Java 9? This is the error I got. > *The version of JAVA installed in C:\Program Files\Java\jdk-9.0.1 is > incorrect.* > *Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.**You > can also download

Integration with JHipster

Igniters, Jhipster is a very popular Spring Boot + Angular framework. Many caching frameworks integrate with it, including EhCache, Hazelcast, and Infinispan: https://www.jhipster.tech/using-cache/ I think the integration is fairly simple and we should provide our own. Thoughts? D.

tracking SQL queries in 2.5

Igniters, I just noticed this horrible ticket: https://issues.apache.org/jira/browse/IGNITE-6677 Apparently, a couple of releases back the community added support for "CREATE TABLE" command and for some reason nobody checked that query metrics on the created tables do not work. Do we have any

Re: PHP/Python versions for Thin Clients

Pavel, Can you suggest what would be the advantages and disadvantages of supporting different versions? D. On Sat, May 12, 2018 at 7:21 AM, Pavel Petroshenko wrote: > Igniters, > > Are there any strong opinions on which language versions should the Thin > Clients

Re: async operation is not fair async

/application-development/jdbc/ > con1491-3961036.pdf > [2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/ > [3] https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ > [4] https://github.com/pgjdbc/pgjdbc/issues/978 > > On Fri, May 11, 2018 at 9:48 PM, Dmi

Re: async operation is not fair async

On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > I will edit IGNITE-8475, and remove all part that belong to the public api. > Is it acceptable for you? > Everything is acceptable, as long as the public API is safe :)

Re: async operation is not fair async

On Fri, May 11, 2018 at 7:23 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Dmitriy S, > > If it will be in the internal package, and only for internal usage, are you > agree with changes? > Yes, but please be careful not to create deadlocks for ourselves. Can you please close

Re: async operation is not fair async

On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Dmitriy S, > > It is not broke existing code, because for use this ability you must use > decorator "withFairSycn()". > > What about the argument of Vladimir? > Here is Vladimir's quote: *This would

Re: async operation is not fair async

On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Dmitriy S, > > Why method named as "async" but does not work as async? This is misleading. > > getAllAsync() is a special case. Not always you can use getAllAsync() > instead > of multiple getAsync(). >

Re: async operation is not fair async

On Fri, May 11, 2018 at 6:29 PM, Dmitry Pavlov wrote: > IMO you can complete async operations one before another if these > operations are related to independent data. > > It is strange why Ignite users are not confused by current API. So I > support Dmitriy's G.

Re: async operation is not fair async

Guys, I am not sure I like this approach, especially for this code: f1=cache.getAsync(key1); f2=cache.getAsync(key2); You cannot complete f2 before f1. If you do, the code is unusable and it is impossible to predict anything. If you need to get 2 elements asynchronously, use getAllAsync()

Re: NodeJS thin client: full API

On Fri, May 11, 2018 at 9:14 AM, Alexey Kosenchuk < alexey.kosenc...@nobitlost.com> wrote: > Not yet. Need a help with that. > I think we definitely need a load test before we merge to master. Can anyone in the community assist Alexey?

Re: NodeJS thin client: full API

This is great! Finally a native NodeJS client for Ignite. Alexey, in addition to the functional tests, were you able to perform any load tests? D. On Fri, May 11, 2018 at 12:07 AM, Alexey Kosenchuk < alexey.kosenc...@nobitlost.com> wrote: > Folks, > > The next version is ready - > in the pull

Re: Using GraalVM instead of standard JVM

Would be nice to have a TC run on Graal, just to have an understanding whether we support it or not. D. On Wed, May 9, 2018 at 4:28 PM, Denis Magda wrote: > The performance might become better just by replacing HotSpot with Graal, > but something suggests me that Ignite has

Re: missing website info

On Tue, May 8, 2018 at 6:23 PM, Denis Magda wrote: > Dmitriy, > > Presently this information is scattered and presented under sections named > differently. Agree with the format proposed by you. > https://issues.apache.org/jira/browse/IGNITE-8455 > > In addition, we should

Re: IGNITE-3999 review

Igniters, let's make sure we add ticket description to the email subject in future, so the community will know what the ticket is about. Not everyone has time to look for the ticket, especially when the link is not even provided in the email. For example, the subject of this thread should have

Re: Postpone Apache Ignite 2.5 release to fix baseline topology

ussed at dev list before > > implementation. > > > > Pros: Persistent users will not be facing with disabled rebalancing in > case > > of node left - (BL)AT will be changed automatically. This also be handled > > by cluster shrink policy for both in-memory and dura

Re: Ticket review checklist

Is this list on the Wiki? On Mon, May 7, 2018 at 7:26 AM, Vladimir Ozerov wrote: > Igniters, > > This is the checklist I have at the moment. Please let me know if you have > any comments on existing items, or want to add or remove anything. It looks > like we may have not

Re: MTCGA 5th mass run-all

Great progress and thanks to everyone contributing! I can hardly wait for the 0-failed-tests day. Hope it is coming some time in future :) On Mon, May 7, 2018 at 3:38 AM, Dmitry Pavlov wrote: > Hi Folks, > > I've started mass run-all last weekend. In short - 361 tests

Re: memory-only mode for Ignite indexes

On Mon, May 7, 2018 at 2:09 AM, Vladimir Ozerov wrote: > Hi Dima, > > Update with indexes would definitely be slower than update without them. > The question is how much slower. For now the slowdown comes mostly from > excessive data page reads ([1] and [2] in my previous

Re: memory-only mode for Ignite indexes

ld render a significant performance boost. > > [1] > https://issues.apache.org/jira/browse/IGNITE-8385 > [2] > https://issues.apache.org/jira/browse/IGNITE-8384 > [3] > https://cwiki.apache.org/confluence/display/IGNITE/IEP- > 20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressi

missing website info

I have been going through the Ignite website today, and I have noticed that nowhere on the website we mention various modes on how Ignite native persistence can be used: - no disk, data is in memory-only (potentially over a 3rd-party database) - disk is a copy of the memory (only for recovery

memory-only mode for Ignite indexes

Igniters, One of the main complaints I hear from users is that whenever the persistence is turned on, index creation can really slow down the performance, because of massive amounts of writes to disk. The reason Ignite is writing indexes to disk is to support fast restarts - nothing needs to be

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

I do not like the name "current" on the methods. I think we should just remove it, e.g. currentAffinityTopology() -> affinityTopology() D. On Fri, May 4, 2018 at 6:17 AM, Eduard Shangareev < eduard.shangar...@gmail.com> wrote: > Igniters, > > With Vladimir's help, we analyzed another solution's

Re: Greetings

Hi Monil, Welcome to the Ignite community! Please use dev@ alias going forward instead of dev-owner@. Ignite comes with lots of examples. You can also find documentation and screencasts on the Ignite website. If you run into any questions, please send them here. D. On Tue, May 1, 2018 at 7:44

Re: cache store usability

On Wed, May 2, 2018 at 4:15 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Vyacheslav, > > There is already a warning for this: > https://github.com/apache/ignite/blob/master/modules/ > core/src/main/java/org/apache/ignite/internal/processors/cache/store/ >

cache store usability

Igniters, This is another usability issue that can be addressed quickly. Apparently, setWriteBehindEnabled(true) is not enough to enable CacheStore, the setWriteThrough(true) also needs to be enabled. https://stackoverflow.com/questions/50118842/write-behind-and-write-through Why not make it

Re: Contributing

Hi Mihkel, I just added you to the Ignite contributors list in Jira. You should be able to assign the ticket to yourself now. D. On Mon, Apr 30, 2018 at 6:42 AM, Mihkel Jõhvik wrote: > Hi > > I'd like to be added to the Apache Ignite contributors list to work on >

Re: Postpone Apache Ignite 2.5 release to fix baseline topology

Can someone explain what is the before and after effect for this change from the usability standpoint. If we are changing BLT for the in-memory mode, which is the default, then we must think through all the usability consequences ahead of time. Otherwise, the perception will be that the product

Re: Apache Ignite 2.5 release

On Fri, Apr 27, 2018 at 6:38 AM, Ivan Rakov wrote: > Folks, > > I have a fix for a critical issue related to WAL compaction: > https://issues.apache.org/jira/browse/IGNITE-8393 > In short, if part of WAL archive is broken, attempt to compress it may > result in spamming

Re: IEP-19: Optimize SQL indexes

On Thu, Apr 26, 2018 at 9:09 PM, Vladimir Ozerov wrote: > It is impossible to estimate what is more critical because it would require > prototypes for every idea to estimate the impact. Instead, we should start > working on the simplest things, such as IGINTE-8386 [1] or

Re: cache size() calculation for MVCC

On Wed, Apr 25, 2018 at 5:45 PM, Vladimir Ozerov wrote: > Yakov, > > Thread-per-partition is hardly applicable for general SQL use case as user > operates on arbitrary data sets. But in general we may track size deltas > for partitions on transaction level. If transaction

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

Ed, how difficult is this fix? Are you suggesting it for 2.5? On Thu, Apr 26, 2018 at 3:10 AM, Eduard Shangareev < eduard.shangar...@gmail.com> wrote: > Igniters, > I have described the issue with current approach in "New definition for > affinity node (issues with baseline)" topic[1]. > > Now

Re: IEP-19: Optimize SQL indexes

Thanks, Vladimir! Looking at this IEP, it is not clear which tickets are more critical than others. Also, the complexity of each ticket is unknown. Is there a way to provide this information? D. On Wed, Apr 25, 2018 at 10:21 PM, Vladimir Ozerov wrote: > Igniters, > > I

Re: cache size() calculation for MVCC

Vova, what about maintaining the size as you go? This way you don't have to count multiple versions, no? D. On Wed, Apr 25, 2018, 5:07 PM Vladimir Ozerov wrote: > This is interesting question. Full-scan size may be tremendously slow > operation on large data sets. On the

Re: New definition for affinity node (issues with baseline)

On Wed, Apr 25, 2018 at 4:13 AM, Vladimir Ozerov wrote: > Right, as far as I understand we are not arguing on whether BLT is needed > or not. The main questions are how to properly deliver this feature to > users and how to deal with co-location issues between persistent

Re: Service grid redesign

On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov wrote: > Dmitriy, > > After the proposed changes are made the utility cache won't be needed at > all. > I was rather talking about prioritization. In my view, first and foremost we must fix deployment before anything else.

Re: Apache Ignite 2.4+ Go language client

Any chance we can add key-value support as well? On Tue, Apr 24, 2018, 2:48 PM Pavel Tupitsyn wrote: > Hi Aleksandr, > > This is awesome, thank you! > > However, let's make it clear that this client supports SQL only, > and none of the other Thin Client protocol features.

Re: Writing a helper for KafkaStreamer

Who can pick up https://issues.apache.org/jira/browse/IGNITE-5416 review? > > Sincerely, > Dmitriy Pavlov > > вт, 6 июн. 2017 г. в 10:56, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Thanks, Mike! Sounds great. > > > > On Tue, Jun 6, 2017 at 12:26 AM, Michael Griggs &

Re: Replace Cron4J with Quartz for ignite-schedule module.

Dmitriy, who is a good candidate within the community to review this ticket? On Mon, Apr 23, 2018 at 6:10 AM, Dmitry Pavlov wrote: > Hi Igniters, > > it seems ticket https://issues.apache.org/jira/browse/IGNITE-5565 is still > in PA state. What are our next steps? > > Who

Re: write-through when using SQL updates

On Sun, Apr 22, 2018 at 10:16 PM, Denis Magda wrote: > If a table is created with CREATE TABLE command then: > >- Ignite creates two custom binary types (one for the key and one for >the value) the columns will be wrapped into. A primary key defines what >goes into

Re: write-through when using SQL updates

firm my understanding is correct. > > -- > Denis > > > On Sun, Apr 22, 2018 at 7:54 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Igniters, > > > > Do we support write-through to a 3rd party database when performing SQL > > inserts and updates? If yes, how does the mapping between SQL and > > CacheStore key-value API happen? > > > > D. > > >

write-through when using SQL updates

Igniters, Do we support write-through to a 3rd party database when performing SQL inserts and updates? If yes, how does the mapping between SQL and CacheStore key-value API happen? D.

Re: Service grid redesign

lts. > > -- > Denis > > On Sat, Apr 21, 2018 at 3:04 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > I am not sure why we are discussing a potential removal of the "init" > > method. I think it is useful, as the service may have to do some &g

Re: Topology-wide notification on critical errors

On Fri, Apr 20, 2018 at 4:50 AM, Anton Vinogradov wrote: > P.s. Andrey Kuznetsov, corrected me that we have no warranty that failed > node able to notify cluster. > > But, > > try{ >sendDiscoveryMessageWithFail(...); > } catch(){ >// No-op; > } > > is better than

Re: Service grid redesign

> > >> > > > > > > > > > > > > >> > > -Val > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Mon, Apr 9, 2018 at 2:48 PM, Denis Magda < > >

Re: Apache Ignite RPM packaging (Stage II)

RPM packages. > > >>>>>>>>>>> > > >>>>>>>>>>> Critical things like ignite-spring and ignite-indexing should > > >>>> be > > >>>>>> in > > >>>>>

Re: Topology-wide notification on critical errors

On Thu, Apr 19, 2018 at 8:19 AM, Yakov Zhdanov wrote: > Guys, > > We have activity to implement a set of mechanisms to handle critical issues > on nodes (IEP-14 - [1]). > > I have an idea to spread message about critical issues to nodes through > entire topology and put it

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

On Tue, Apr 17, 2018 at 4:38 PM, Denis Magda wrote: > Dmitriy, > > We don't want to disable the baseline topology for the scenario discussed > here. The goal is to make it more flexible by triggering the rebalancing in > some circumstances. > > As for the SAFE or AGGRESSIVE

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

On Tue, Apr 17, 2018 at 10:47 AM, Denis Magda wrote: > Thanks, Pavel! > > Alexey, Ivan, could you check that there are no any pitfalls in the example > and it can be used as a template for our users? > https://issues.apache.org/jira/secure/attachment/ >

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

On Thu, Apr 12, 2018 at 9:45 AM, Ivan Rakov wrote: > Dmitriy, > > fsync() is really slow operation - it's the main reason why FSYNC mode is > way slower than LOG_ONLY. > Fix includes extra fsyncs in necessary parts of code and nothing more. > Every part is important - at

Re: Apache Ignite RPM packaging (Stage II)

;dma...@apache.org>: > > >>>>> > > >>>>>>> > > >>>>>>>> > > >>>>>>>> How big would be a final core module? > > >>>>>>> Around 30M. Can be shrinked to ~15

Re: Ignite documentation is broken

This is what I see (attached) On Wed, Apr 11, 2018 at 1:52 AM, Alexey Kuznetsov <akuznet...@apache.org> wrote: > I have no problems. > > Try other browser / or force refresh of page. > > On Wed, Apr 11, 2018 at 3:49 PM, Dmitriy Setrakyan <dsetrak...@apache.org&

Ignite documentation is broken

Igniters, The readme documentation seems broken. Is it only for me, or others experience the same thing? https://apacheignite.readme.io/docs Did anyone change anything in the docs settings? D.

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

On Tue, Apr 10, 2018 at 11:57 PM, Ilya Suntsov wrote: > Dmitriy, > > I've measured performance on the current master and haven't found any > problems with in-memory mode. > Got it. I would still say that the performance drop is too big with persistence turned on. It seems

Re: Warning message

On Tue, Apr 10, 2018 at 2:22 PM, Alew wrote: > Hi! > > I use local cache and get a lot of warnings when execute ScanQueries. > > [13:26:25 WRN] Ignoring query projection because it's > executed over LOCAL cache (only local node will be queried): > GridCacheQueryAdapter

Re: Atomic caches

On Tue, Apr 10, 2018 at 2:03 PM, akurbanov wrote: > Dmitry, > > Sorry for confusing topic. I I'm pretty sure that configuration for atomic > caches is validated, will double-check this. I was referring only atomic > data structures cache. > Got it. We should definitely add

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

oze...@gridgain.com> wrote: > 16% looks perfectly ok to me provided that we compare correct > implementation with incorrect one. > > вт, 10 апр. 2018 г. в 18:24, Dmitriy Setrakyan <d...@gridgain.com>: > > > Ilya, can we find out why pure in-memory scenario also had a performance

Re: Reconsider default WAL mode: we need something between LOG_ONLY and FSYNC

;>>>>>>>>>> : > > > >>>>>>>>>> +1 for accepting drop in LOG_ONLY. 7% is not that much and > > > >>>>>>>>>>>> not a > > > >>>>>>>>>>>>>>

Re: Remove cache groups in AI 3.0

Vladimir, sounds like a huge refactoring. Other than "cache groups are confusing", are we solving any other big issues with the new proposed approach? (every time we try to refactor rebalancing, I get goose bumps) D. On Tue, Apr 10, 2018 at 1:32 AM, Vladimir Ozerov wrote:

Re: REST API and new authentication API

On Tue, Apr 10, 2018 at 12:28 AM, Alexey Kuznetsov wrote: > Dmitriy, > > Yes, because we have a command "Add new user" and this command can be > executed only with credentials of some "admin" user. > > It means, that in one command you need to specify name of new user and

Re: REST API and new authentication API

Alexey, are you suggesting that we have "newUser" as command parameter, while "user" is also a valid command parameter?  ⁣D.​ On Apr 10, 2018, 12:00 AM, at 12:00 AM, Alexey Kuznetsov wrote: >I looked into code and I think that we could do the following: > >1) Use user

Re: Atomic caches

On Mon, Apr 9, 2018 at 6:29 AM, Ilya Lantukh wrote: > Anton, > > Please do not use term "atomic cache" for system caches that hold internal > data for atomic data structures. This is very confusing. > > You are right, currently there is no logic that will validate cache >

Re: IGNITE-6827 - Review needed.

On Mon, Apr 9, 2018 at 5:42 AM, Alexey Goncharuk wrote: > Guys, > > After the review in Upsource the configuration parameter was renamed > to txTimeoutOnPartMapSync, and it makes sense to me because PME is an > implementation detail and it may change in future,

Re: Atomic caches

I would say absolutely YES - we need to have configuration validation. Igniters, why was the validation skipped in atomic caches? D. On Fri, Apr 6, 2018 at 1:43 PM, akurbanov wrote: > Hello Igniters, > > I want to address a question on AtomicConfiguration validation. I've

Re: Service grid redesign

On Fri, Apr 6, 2018 at 9:13 AM, Dmitry Pavlov wrote: > Hi Igniters, > > I like automatic redeploy which can be disabled by config if user wants to > control this process. What do you think? > I do not think we should have anything automatic when it comes to deployment,

Re: IEP-18: Transparent Data Encryption

Here is a correct link to IEP: https://cwiki.apache.org/confluence/display/IGNITE/IEP-18%3A+Transparent+Data+Encryption On Thu, Apr 5, 2018 at 12:01 PM, Nikolay Izhikov wrote: > Hello, Igniters. > > Based on previous discussion [1] we've created "IEP-18: Transparent Data >

Re: Breaking change in JDBC connection string format

Vladimir, my older email got kind of lost. Can you please clarify, will we be able to support both, older and newer formats, to avoid a breaking compatibility change between releases? D. On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov wrote: > I think colon is not very

Re: Memory usage per cache

On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk wrote: > Denis, > > I think this particular metric should be deprecated. The most we can do > about it is to return the actual allocated size when a cache is the only > cache in a group and return -1 if there are

Re: Service grid redesign

Here is the correct link: https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid I have looked at the tickets there, and I believe that we should not support peer-deployment for services. It is very hard and I do not think we should even try. I am proposing

Re: Make TC issues seems to be hung up

Igniters, Dmitriy Pavlov is working very hard on making sure that we do not have failing tests in Ignite. Let's help him in this effort. I would like to encourage the committers responsible for the failing tests to either fix them or remove them. Please respond here. D. On Tue, Apr 3, 2018 at

Re: Timeline for support of compute functions by thin clients

On Tue, Apr 3, 2018 at 5:48 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Dmitry, > > I just think that it's natural to have this functionality and that it would > drastically increase flexibility of thin client. Multiple requests from > users (one of them in this thread) seem

Re: Breaking change in JDBC connection string format

Vladimir, why can't we support both, the "&" and whatever other character we choose? This way it will not be a breaking change. D. On Tue, Apr 3, 2018 at 1:30 AM, Vladimir Ozerov wrote: > Igniters, > > Thanks to Alex Kuznetsov, we revealed serious usability issue in our

Re: Timeline for support of compute functions by thin clients

Val, my preference would be not to have compute functionality on thin clients, as it would introduce extra security risk. Any particular reason why you are asking for this feature? ⁣D.​ On Apr 2, 2018, 8:47 PM, at 8:47 PM, Valentin Kulichenko wrote: >Folks, >

Re: IGNITE-6827 - Review needed.

name should be PartitionMapExchangePreparationTimeout or PartitionMapExchangeTxTimeout. Am I missing something? D. On Mon, Apr 2, 2018 at 2:48 AM, Alexey Goncharuk <alexey.goncha...@gmail.com > wrote: > Guys, especially Vladimir Ozerov, Yakov Zhanov, Dmitriy Setrakyan, > > Whil

Re: Memory usage per cache

not the keys > themselves. Looks like the method name is confusing, should we rename it to > getLockedKeysNumber? > > --AG > > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Dmitriy, > > > > For transactions, are these s

Re: Memory usage per cache

Dmitriy, For transactions, are these separate metrics for each transaction or aggregates for all of them? If these are aggregates, then methods like "getLockedKeys" may produce a very large collection, which on top of everything else, will be very difficult to create. D. On Fri, Mar 30, 2018 at

Re: Memory usage per cache

On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Denis, > > Currently there is an easy way to add per-cache-group metrics for data and > index pages. There is an internal counter, but it is not published as an > MBean metric, we will do this as a part of

Ignite download page

Igniters, I think the Ignite Download page is getting too crowded. https://ignite.apache.org/download.cgi I would like to propose moving most of the previous versions to a separate page. For example, we can list 3 latest versions on the download page and older versions on another page. What do

Re: Apache Ignite RPM packaging (Stage II)

ix bugs in both RPM and DEB packages > simultaneously. > > > > > On 28 Mar 2018, at 03:17, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > Petr, > > > > I am confused. Do we already have Debian packages? > > > > D. >

Re: Apache Ignite RPM packaging (Stage II)

;> On 15 Mar 2018, at 10:35, Petr Ivanov <mr.wei...@gmail.com> wrote: > >>>>> > >>>>> Considering that DEV package for now is almost platform independent > >>> (its > >>>> a java application more or less), that package will work a

Re: MTCGA: Hot failures

Dmitriy, I think it would make sense to create a ticket for every single one of these, or at least try to group them in to several tickets. What do you think? D. On Tue, Mar 27, 2018 at 5:17 AM, Dmitry Pavlov wrote: > Hi Igniters, > > I’ve filtered report of master

<    1   2   3   4   5   6   7   8   9   10   >