Re: Ignite 2.0 tasks/roadmap

On Tue, Jan 17, 2017 at 8:35 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Guys, > > Do you think there is any reason to keep optimized marshaller on public API > in Ignite 2.0? It has several disadvantages, the major being non-conformant > with Java serialization guarantees(namely,

Re: Ignite 2.0 tasks/roadmap

Guys, Do you think there is any reason to keep optimized marshaller on public API in Ignite 2.0? It has several disadvantages, the major being non-conformant with Java serialization guarantees(namely, the inability to add/remove fields). On the other hand, Binary marshaller supports all this and

Re: Ignite 2.0 tasks/roadmap

IGNITE-4211 Update Sprint dependency to latest stable version On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda wrote: > Sound reasonable. Please create a ticket and paste it number into this > discussion. > > — > Denis > > >

Re: Ignite 2.0 tasks/roadmap

Sound reasonable. Please create a ticket and paste it number into this discussion. — Denis > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov wrote: > > Hi > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago.

Re: Ignite 2.0 tasks/roadmap

Hi It seems the Spring dependency looks outdated for now. Apache Ignite still uses 4.1.0 released two years ago. Could we include to the list of issues for the release 2.0 to update to latest stable version (4.3.4 at the moment)? On Tue, Nov 1, 2016 at 12:39 PM, Alexey Goncharuk <

Re: Ignite 2.0 tasks/roadmap

Yakov, I've created a ticket for using discovery custom events instead of marshaller cache: https://issues.apache.org/jira/browse/IGNITE-4157 Guys, feel free to comment. Thanks! AG 2016-09-09 20:53 GMT+03:00 Denis Magda : > I’ve created an umbrella ticket for REST >

Re: Ignite 2.0 tasks/roadmap

Denis Generally I'm fine for your approach. I think for 2.0 (or may be for a next 1.x minor version) we can note that currently REST API is deprecated. It will allow us to replace REST by a new implementation once it will be done. On Fri, Sep 9, 2016 at 4:11 PM, Denis Magda

Re: Ignite 2.0 tasks/roadmap

Sergey, I do agree with you that Ignite’s REST API implementation has to be revisited. Your concerns sound reasonable. But personally I wouldn’t rush trying to release it under 2.0 because NodeJS won’t be a part of this release while it can propose additional requirements to the next

Re: Ignite 2.0 tasks/roadmap

Vova, There are more issues than processing (String, String) only: we can't process JSON objects as values, current implementation doesn't follow general RESTfull API requirements. Moreover we're still have no connectors for PHP, Python and other popular languages for web development of LAMP

Re: Ignite 2.0 tasks/roadmap

Denis, Very good catch! Our REST API in ir is current appearance are virtually useless because it only operates on strings. We'd better to design the new one.with blackjack and etc.. On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda wrote: > Basically, we can have two versions

Re: Ignite 2.0 tasks/roadmap

Basically, we can have two versions of the REST API if we want to care about the compatibility and remove the old one (deprecated) at some point of time. Moreover, NodeJS feature [1] can highly influence on the next generation of our REST API implementation. So I wouldn’t introduce the next

Re: Ignite 2.0 tasks/roadmap

I agree with Alexey. The key point is a chance to don't care for compatibility. On Thu, Sep 8, 2016 at 9:56 AM, Alexey Kuznetsov wrote: > Just my opinion. If we move this to 2.1 that will result that we will have > to support 2 versions of REST APIs. > In Ignite 2.0

Re: Ignite 2.0 tasks/roadmap

Just my opinion. If we move this to 2.1 that will result that we will have to support 2 versions of REST APIs. In Ignite 2.0 we could break compatibility and redesign REST API from scratch. On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda wrote: > I would move it to 2.1 or 2.2.

Re: Ignite 2.0 tasks/roadmap

I would move it to 2.1 or 2.2. — Denis > On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan wrote: > > Sergey, I don't think we can fit redesigning of HTTP/REST into our 2.0 > release. The 2.0 already looks pretty packed. Perhaps we should plan it for > the release after,

Re: Ignite 2.0 tasks/roadmap

Hi I suppose we should redesign HTTP REST API. We've a dozen issues around the REST implementation and the provided functionality is very limited and doesn't follow last changes for Ignite. The most suitable ticket is IGNITE-1774 REST API should be implemented using Jersey

Re: Ignite 2.0 tasks/roadmap

There is one more use case where several types per cache can be useful (I know that it's utilized by some of our users). The use case is the following: transactional updates with write-behind and foreign key constraints on the database. In case data within transaction is collocated and all types

Re: Ignite 2.0 tasks/roadmap

Alexey You're right. Of course I meant growth of caches number. I see a few points here: 1. If a grid used by various applications the cache names may overlap (like "accounts") and the application needs to use prefixed names and etc. 2. For clear or destory caches I need to know their names (or

Re: Ignite 2.0 tasks/roadmap

I mean not only SQL features for caches. Single type per cache definitely reduces number of caches for regular user and grouping caches will help to manage caches in grid. On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin wrote: > I'm aware of this issue. My plan was to

Re: Ignite 2.0 tasks/roadmap

I'm aware of this issue. My plan was to allow setting the same schema name to different caches using CacheConfiguration.setSqlSchema(...). This way we will have separate caches but from SQL point of view respective tables will reside in the same schema. No need to introduce new concepts. Sergi

Re: Ignite 2.0 tasks/roadmap

HI Due to approach to disable to store more than one type per cache the cache use becomes similar the table use for databases. So I suppose would be good to introduce a database/schema-similar concept for caches. It may be implemented as a non-default behavior for backward compatibility. On Sat,

Re: Ignite 2.0 tasks/roadmap

Let’s add this [1] issue to the list because it requires significant work on the side of metrics SPI. [1] https://issues.apache.org/jira/browse/IGNITE-3495 — Denis > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov wrote: >

Re: Ignite 2.0 tasks/roadmap

Not yet. The thing is that our recent experience showed that it was not very good idea to go with caches. E.g. when you try to deserialize inside continuous query listener on client side it implicitly calls cache.get() which in turn may cause deadlock under some circumstances. --Yakov 2016-08-02

Re: Ignite 2.0 tasks/roadmap

On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov wrote: > One more point. > > I insist on stop using marshaller and meta caches but switch to spreading > this info via custom discovery events. > Do we have a ticket explaining why this needs to be done? > > --Yakov > >

Re: Ignite 2.0 tasks/roadmap

One more point. I insist on stop using marshaller and meta caches but switch to spreading this info via custom discovery events. --Yakov 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan : > On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov > wrote: > > >

Re: Ignite 2.0 tasks/roadmap

On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov wrote: > Guys, I think we can also split event notification for user listeners and > internal system listeners. I have been seeing a lot of issues caused by > some heavy or blocking operations in user-defined listeners. This

Re: Ignite 2.0 tasks/roadmap

Guys, I think we can also split event notification for user listeners and internal system listeners. I have been seeing a lot of issues caused by some heavy or blocking operations in user-defined listeners. This may block internal component notification (e.g. on discovery event) causing topology

Re: Ignite 2.0 tasks/roadmap

I am allowed to flip-flop on my opinions every now and then :) > On Jul 20, 2016, at 11:06 AM, Pavel Tupitsyn wrote: > > Dmitriy, you have agreed with me in the old thread, and now you don't? > Binarylizable (current) is longer than Binarizable (proposed). > > On Wed,

Re: Ignite 2.0 tasks/roadmap

Dmitriy, you have agreed with me in the old thread, and now you don't? Binarylizable (current) is longer than Binarizable (proposed). On Wed, Jul 20, 2016 at 10:24 AM, Dmitriy Setrakyan wrote: > > > > > On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn

Re: Ignite 2.0 tasks/roadmap

> On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn wrote: > > How about renaming Binarylizable interface? > > http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html Pavel, I would not rename. The name you are suggesting is very hard to

Re: Ignite 2.0 tasks/roadmap

How about renaming Binarylizable interface? http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin wrote: > Alexey K., > > No problem, here it is

Re: Ignite 2.0 tasks/roadmap

Alexey K., No problem, here it is https://issues.apache.org/jira/browse/IGNITE-3488 Sergi On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > I created one more ticket related to SQL: > https://issues.apache.org/jira/browse/IGNITE-3487.

Re: Ignite 2.0 tasks/roadmap

Folks, I created one more ticket related to SQL: https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability issue that pops up on user forum every now and then. Since it's a compatibility breaking changed, it looks like a good candidate for 2.0. -Val On Fri, Jul 15, 2016 at 11:56 AM,

Re: Ignite 2.0 tasks/roadmap

Sergi, that was my idea to drop nulls but I have limited access to internet (I'm on vacation) could you create issue in JIRA? Thanks. Alexey Kuznetsov 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" написал: Huge +1 for dropping support for null in all names, not

Re: Ignite 2.0 tasks/roadmap

Huge +1 for dropping support for null in all names, not only for cache names. Do we have ticket for this one? Sergi On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko wrote: > > 15.07.2016 0:31, Dmitriy Setrakyan пишет: > >> On Fri, Jul 15, 2016 at 12:26 AM,

Re: Ignite 2.0 tasks/roadmap

15.07.2016 0:31, Dmitriy Setrakyan пишет: On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel wrote: Good feature may be Aggregated cache - analog materialized view in DBMS Aggregated cache is great for performance (KPI, analytecal reports). Do you mean a copy of the

Re: Ignite 2.0 tasks/roadmap

On Fri, Jul 15, 2016 at 1:49 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > > > > > > > > I know there is IgniteDataStreamer for writing cache, but how about > > > reading cache as stream for iterate all elements with scan performane > > 1-3M > > > tuple/sec? > > > > > > > We already

Re: Ignite 2.0 tasks/roadmap

> > > > > I know there is IgniteDataStreamer for writing cache, but how about > > reading cache as stream for iterate all elements with scan performane > 1-3M > > tuple/sec? > > > > We already have Scan queries which allow for paginated iteration with > filters. Are you suggesting something beyond

Re: Ignite 2.0 tasks/roadmap

​Great stuff! Guys, please go ahead and file corresponding tickets or reassign the fix version to 2.0 if a ticket exists so that we keep track of the scope. It would also be great if you review the ones I created and see if they make sense.

Re: Ignite 2.0 tasks/roadmap

On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel wrote: > Good feature may be Aggregated cache - analog materialized view in DBMS > Aggregated cache is great for performance (KPI, analytecal reports). > Do you mean a copy of the aggregated data in another cache? What happens

Re: Ignite 2.0 tasks/roadmap

Good feature may be Aggregated cache - analog materialized view in DBMS Aggregated cache is great for performance (KPI, analytecal reports). Recently I learned network traffic between nodes when node restart/startup and do no found any compressing for transferred data. I know there is

Re: Ignite 2.0 tasks/roadmap

Several points from my side: 1) Drop support for null cache names 2) rework Visor data transfer objects to binary format in order to easily extend them if needed.

Re: Ignite 2.0 tasks/roadmap

Yakov, I am not sure we fixed it. Plus sometimes we encode missing value as -1, so it is written as 4 bytes still. Dmitry, to my knowledge Unsafe will be available only when special VM flag is set. It is not a problem for ignite.sh, but may cause usability issues when running in embedded mode.

Re: Ignite 2.0 tasks/roadmap

Vova, why Unsafe removal? To my knowledge, Unsafe still remains in Java 9, no? On Thu, Jul 14, 2016 at 4:09 PM, Vladimir Ozerov wrote: > Several points from my side: > 1) Java 9 support - Unsafe removal, modules, etc.. > 2) Rework our "messages" subsystem - we always

Re: Ignite 2.0 tasks/roadmap

Vova, 2) even long zero is encoded as 1 byte now. Do you think it is a problem? --Yakov 2016-07-14 16:09 GMT+03:00 Vladimir Ozerov : > Several points from my side: > 1) Java 9 support - Unsafe removal, modules, etc.. > 2) Rework our "messages" subsystem - we always

Re: Ignite 2.0 tasks/roadmap

Several points from my side: 1) Java 9 support - Unsafe removal, modules, etc.. 2) Rework our "messages" subsystem - we always read/write all fields, thus transferring lots of zeros without any reason. We should support branching. 3) Review all messages (especially cache, double-especially -

Re: Ignite 2.0 tasks/roadmap

Alex, a lot of excitement for Ignite-2.0 from my side! =) I agree with your points and I will take a close look at them in the nearest future. Here are some suggestions from me. I don't remember if I shared my thoughts on moving to single TCP port per node. So, I filed a new ticket -

Re: Ignite 2.0 tasks/roadmap

So, no excitement about Ignite 2.0? :) I went ahead and created a 2.0 version in Ignite Jira, and included the following tickets so far based on the chance that this ticket will require breaking changes in APIs/Configuration - IGNITE-3469 - Get rid of deprecated APIs and code - IGNTIE-3477 -

Ignite 2.0 tasks/roadmap

Folks, Recently I have seen a couple of emails suggesting tasks/improvements that we cannot do in 1.x releases due to API compatibility reasons, so they are postponed to 2.0. I would like to keep track of these tasks in some way in our Jira to make sure we do not have anything obsolete when it