You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Alexey Goncharuk <al...@gmail.com> on 2016/06/24 23:42:25 UTC

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 comes to the
next major version release.

My question for now is how should we track such tasks? Should it be a
label, a parent task with subtasks, something else?

I would go with a label + release version.

--AG

Re: Ignite 2.0 tasks/roadmap

Posted by Yakov Zhdanov <yz...@apache.org>.
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 <vo...@gridgain.com>:

> 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 - atomic) in
> terms of performance. Most probably we will refactor/split some of them.
>
> 14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <yz...@apache.org>
> написал:
>
> > 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 -
> > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> > another one let's merge them.
> >
> > I would also think over removing communication SPI and discovery SPI and
> > introducing communication and discovery processors instead. In some
> places
> > Ignite pretty much relies on internal implementation details of these
> SPIs
> > which makes implementation of any other SPI pretty complex task. Btw, did
> > anyone did that? Removing SPIs will allow us to cleanup the code and use
> > common abstractions and logic.
> >
> > I will give some more ideas going forward.
> >
> > Thanks!
> >
> > --Yakov
> >
> > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
> >
> > > 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 - Rework offheap storage
> > >  - IGNITE-3478 - Transactional SQL
> > >  - IGNITE-1605 - Provide stronger data loss check
> > >  - IGNITE-3306 - Extend IgniteCluster interface with the methods to
> send
> > > and receive custom discovery events
> > >
> > > I believe that there are many more changes that we wanted to make but
> > > delayed because they would break binary compatibility, so if you have
> > > something in mind - it's time to create a ticket or assign it to 2.0 if
> > it
> > > exists. It's good to know the scope of work.
> > >
> > > Also, it would be great if you review/comment the above-mentioned
> > tickets.
> > >
> > > Thanks,
> > > AG
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Goncharuk <al...@gmail.com>.
​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

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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

Posted by Vladimir Ozerov <vo...@gridgain.com>.
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. Moreover, some methods will be removed from
Unsafe, e.g. monitorEnter(). So I doubt we even compilable with Java 9 now.

14 июля 2016 г. 16:27 пользователь "Dmitriy Setrakyan" <
dsetrakyan@apache.org> написал:

> 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 <vo...@gridgain.com>
> wrote:
>
> > 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 - atomic) in
> > terms of performance. Most probably we will refactor/split some of them.
> >
> > 14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <yz...@apache.org>
> > написал:
> >
> > > 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 -
> > > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> > > another one let's merge them.
> > >
> > > I would also think over removing communication SPI and discovery SPI
> and
> > > introducing communication and discovery processors instead. In some
> > places
> > > Ignite pretty much relies on internal implementation details of these
> > SPIs
> > > which makes implementation of any other SPI pretty complex task. Btw,
> did
> > > anyone did that? Removing SPIs will allow us to cleanup the code and
> use
> > > common abstractions and logic.
> > >
> > > I will give some more ideas going forward.
> > >
> > > Thanks!
> > >
> > > --Yakov
> > >
> > > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <alexey.goncharuk@gmail.com
> >:
> > >
> > > > 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 - Rework offheap storage
> > > >  - IGNITE-3478 - Transactional SQL
> > > >  - IGNITE-1605 - Provide stronger data loss check
> > > >  - IGNITE-3306 - Extend IgniteCluster interface with the methods to
> > send
> > > > and receive custom discovery events
> > > >
> > > > I believe that there are many more changes that we wanted to make but
> > > > delayed because they would break binary compatibility, so if you have
> > > > something in mind - it's time to create a ticket or assign it to 2.0
> if
> > > it
> > > > exists. It's good to know the scope of work.
> > > >
> > > > Also, it would be great if you review/comment the above-mentioned
> > > tickets.
> > > >
> > > > Thanks,
> > > > AG
> > > >
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <vo...@gridgain.com>
wrote:

> 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 - atomic) in
> terms of performance. Most probably we will refactor/split some of them.
>
> 14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <yz...@apache.org>
> написал:
>
> > 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 -
> > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> > another one let's merge them.
> >
> > I would also think over removing communication SPI and discovery SPI and
> > introducing communication and discovery processors instead. In some
> places
> > Ignite pretty much relies on internal implementation details of these
> SPIs
> > which makes implementation of any other SPI pretty complex task. Btw, did
> > anyone did that? Removing SPIs will allow us to cleanup the code and use
> > common abstractions and logic.
> >
> > I will give some more ideas going forward.
> >
> > Thanks!
> >
> > --Yakov
> >
> > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
> >
> > > 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 - Rework offheap storage
> > >  - IGNITE-3478 - Transactional SQL
> > >  - IGNITE-1605 - Provide stronger data loss check
> > >  - IGNITE-3306 - Extend IgniteCluster interface with the methods to
> send
> > > and receive custom discovery events
> > >
> > > I believe that there are many more changes that we wanted to make but
> > > delayed because they would break binary compatibility, so if you have
> > > something in mind - it's time to create a ticket or assign it to 2.0 if
> > it
> > > exists. It's good to know the scope of work.
> > >
> > > Also, it would be great if you review/comment the above-mentioned
> > tickets.
> > >
> > > Thanks,
> > > AG
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 - atomic) in
terms of performance. Most probably we will refactor/split some of them.

14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <yz...@apache.org>
написал:

> 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 -
> https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> another one let's merge them.
>
> I would also think over removing communication SPI and discovery SPI and
> introducing communication and discovery processors instead. In some places
> Ignite pretty much relies on internal implementation details of these SPIs
> which makes implementation of any other SPI pretty complex task. Btw, did
> anyone did that? Removing SPIs will allow us to cleanup the code and use
> common abstractions and logic.
>
> I will give some more ideas going forward.
>
> Thanks!
>
> --Yakov
>
> 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
>
> > 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 - Rework offheap storage
> >  - IGNITE-3478 - Transactional SQL
> >  - IGNITE-1605 - Provide stronger data loss check
> >  - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
> > and receive custom discovery events
> >
> > I believe that there are many more changes that we wanted to make but
> > delayed because they would break binary compatibility, so if you have
> > something in mind - it's time to create a ticket or assign it to 2.0 if
> it
> > exists. It's good to know the scope of work.
> >
> > Also, it would be great if you review/comment the above-mentioned
> tickets.
> >
> > Thanks,
> > AG
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Yakov Zhdanov <yz...@apache.org>.
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 -
https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
another one let's merge them.

I would also think over removing communication SPI and discovery SPI and
introducing communication and discovery processors instead. In some places
Ignite pretty much relies on internal implementation details of these SPIs
which makes implementation of any other SPI pretty complex task. Btw, did
anyone did that? Removing SPIs will allow us to cleanup the code and use
common abstractions and logic.

I will give some more ideas going forward.

Thanks!

--Yakov

2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:

> 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 - Rework offheap storage
>  - IGNITE-3478 - Transactional SQL
>  - IGNITE-1605 - Provide stronger data loss check
>  - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
> and receive custom discovery events
>
> I believe that there are many more changes that we wanted to make but
> delayed because they would break binary compatibility, so if you have
> something in mind - it's time to create a ticket or assign it to 2.0 if it
> exists. It's good to know the scope of work.
>
> Also, it would be great if you review/comment the above-mentioned tickets.
>
> Thanks,
> AG
>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Jul 15, 2016 at 1:49 AM, Alexey Goncharuk <
alexey.goncharuk@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 have Scan queries which allow for paginated iteration with
> > filters. Are you suggesting something beyond this?
>
>
> I like the idea of DataStreamer approach for scanning a cache. I think it
> would be nice to have a way to iterate over cache partitions in parallel,
> similar to forEachPartition() method in Spark RDD.
>
> Benefits compared to current Scan query:
>  * Parallel execution for different partitions
>  * Bringing computation to data, not data to client.
>
> Of course, this can already be implemented by a user with local scan query
> + compute task, but having an utility method on an API will cut a lot of
> boilerplate code for users.
>

Got it now. Sounds very useful. I think we should definitely create a
ticket for it and see if anyone in the community will pick it up. Sounds
like it won’t be too difficult to implement.

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Goncharuk <al...@gmail.com>.
>
> >
> > 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 this?


I like the idea of DataStreamer approach for scanning a cache. I think it
would be nice to have a way to iterate over cache partitions in parallel,
similar to forEachPartition() method in Spark RDD.

Benefits compared to current Scan query:
 * Parallel execution for different partitions
 * Bringing computation to data, not data to client.

Of course, this can already be implemented by a user with local scan query
+ compute task, but having an utility method on an API will cut a lot of
boilerplate code for users.

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@gridgain.com>.
I am allowed to flip-flop on my opinions every now and then :)


> On Jul 20, 2016, at 11:06 AM, Pavel Tupitsyn <pt...@gridgain.com> 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, Jul 20, 2016 at 10:24 AM, Dmitriy Setrakyan <dsetrakyan@gridgain.com
>> wrote:
> 
>> 
>> 
>> 
>>> On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn <pt...@gridgain.com>
>> 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
>> pronounce.
>> 
>>> 
>>> On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <
>> sergi.vladykin@gmail.com>
>>> wrote:
>>> 
>>>> 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.kulichenko@gmail.com> wrote:
>>>> 
>>>>> 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, Alexey Kuznetsov <
>>>>> akuznetsov@gridgain.com>
>>>>> wrote:
>>>>> 
>>>>>> 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" <
>>>>>> sergi.vladykin@gmail.com>
>>>>>> написал:
>>>>>> 
>>>>>> 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 <
>> andrey4vel@gmail.com
>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>>>>>>> 
>>>>>>>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>
>>>>>> 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
>>>>>>>> when the data in the original caches is updated?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> Yes, aggregated data can be store in another cache,
>>>>>>> embedded aggregating cache can be updated sync/async. Aggregating
>>>> from
>>>>>> the
>>>>>>> box has better performance then creating custom event listeners.
>>>>>>> 
>>>>>>> If cache entry updated/deleted aggregate listener can get 2 values
>>>> old
>>>>>> and
>>>>>>> new.
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>

Re: Ignite 2.0 tasks/roadmap

Posted by Pavel Tupitsyn <pt...@gridgain.com>.
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 <dsetrakyan@gridgain.com
> wrote:

>
>
>
> > On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn <pt...@gridgain.com>
> 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
> pronounce.
>
> >
> > On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <
> sergi.vladykin@gmail.com>
> > wrote:
> >
> >> 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.kulichenko@gmail.com> wrote:
> >>
> >>> 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, Alexey Kuznetsov <
> >>> akuznetsov@gridgain.com>
> >>> wrote:
> >>>
> >>>> 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" <
> >>>> sergi.vladykin@gmail.com>
> >>>> написал:
> >>>>
> >>>> 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 <
> andrey4vel@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> >>>>>
> >>>>>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>
> >>>> 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
> >>>>>> when the data in the original caches is updated?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Yes, aggregated data can be store in another cache,
> >>>>> embedded aggregating cache can be updated sync/async. Aggregating
> >> from
> >>>> the
> >>>>> box has better performance then creating custom event listeners.
> >>>>>
> >>>>> If cache entry updated/deleted aggregate listener can get 2 values
> >> old
> >>>> and
> >>>>> new.
> >>>>>
> >>>>
> >>>
> >>
>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@gridgain.com>.


> On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn <pt...@gridgain.com> 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 pronounce.

> 
> On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <se...@gmail.com>
> wrote:
> 
>> 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.kulichenko@gmail.com> wrote:
>> 
>>> 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, Alexey Kuznetsov <
>>> akuznetsov@gridgain.com>
>>> wrote:
>>> 
>>>> 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" <
>>>> sergi.vladykin@gmail.com>
>>>> написал:
>>>> 
>>>> 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 <andrey4vel@gmail.com
>>> 
>>>> wrote:
>>>> 
>>>>> 
>>>>> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>>>>> 
>>>>>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>
>>>> 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
>>>>>> when the data in the original caches is updated?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> Yes, aggregated data can be store in another cache,
>>>>> embedded aggregating cache can be updated sync/async. Aggregating
>> from
>>>> the
>>>>> box has better performance then creating custom event listeners.
>>>>> 
>>>>> If cache entry updated/deleted aggregate listener can get 2 values
>> old
>>>> and
>>>>> new.
>>>>> 
>>>> 
>>> 
>>

Re: Ignite 2.0 tasks/roadmap

Posted by Pavel Tupitsyn <pt...@gridgain.com>.
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 <se...@gmail.com>
wrote:

> 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.kulichenko@gmail.com> wrote:
>
> > 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, Alexey Kuznetsov <
> > akuznetsov@gridgain.com>
> > wrote:
> >
> > > 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" <
> > > sergi.vladykin@gmail.com>
> > > написал:
> > >
> > > 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 <andrey4vel@gmail.com
> >
> > > wrote:
> > >
> > > >
> > > > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> > > >
> > > >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>
> > > 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
> > > >> when the data in the original caches is updated?
> > > >>
> > > >>
> > > >>
> > > > Yes, aggregated data can be store in another cache,
> > > > embedded aggregating cache can be updated sync/async. Aggregating
> from
> > > the
> > > > box has better performance then creating custom event listeners.
> > > >
> > > > If cache entry updated/deleted aggregate listener can get 2 values
> old
> > > and
> > > > new.
> > > >
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergi Vladykin <se...@gmail.com>.
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.kulichenko@gmail.com> wrote:

> 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, Alexey Kuznetsov <
> akuznetsov@gridgain.com>
> wrote:
>
> > 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" <
> > sergi.vladykin@gmail.com>
> > написал:
> >
> > 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 <an...@gmail.com>
> > wrote:
> >
> > >
> > > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> > >
> > >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>
> > 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
> > >> when the data in the original caches is updated?
> > >>
> > >>
> > >>
> > > Yes, aggregated data can be store in another cache,
> > > embedded aggregating cache can be updated sync/async. Aggregating from
> > the
> > > box has better performance then creating custom event listeners.
> > >
> > > If cache entry updated/deleted aggregate listener can get 2 values old
> > and
> > > new.
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Valentin Kulichenko <va...@gmail.com>.
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, Alexey Kuznetsov <ak...@gridgain.com>
wrote:

> 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" <
> sergi.vladykin@gmail.com>
> написал:
>
> 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 <an...@gmail.com>
> wrote:
>
> >
> > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> >
> >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>
> 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
> >> when the data in the original caches is updated?
> >>
> >>
> >>
> > Yes, aggregated data can be store in another cache,
> > embedded aggregating cache can be updated sync/async. Aggregating from
> the
> > box has better performance then creating custom event listeners.
> >
> > If cache entry updated/deleted aggregate listener can get 2 values old
> and
> > new.
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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" <se...@gmail.com>
написал:

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 <an...@gmail.com>
wrote:

>
> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>
>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>  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
>> when the data in the original caches is updated?
>>
>>
>>
> Yes, aggregated data can be store in another cache,
> embedded aggregating cache can be updated sync/async. Aggregating from the
> box has better performance then creating custom event listeners.
>
> If cache entry updated/deleted aggregate listener can get 2 values old and
> new.
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergi Vladykin <se...@gmail.com>.
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 <an...@gmail.com>
wrote:

>
> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>
>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>  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
>> when the data in the original caches is updated?
>>
>>
>>
> Yes, aggregated data can be store in another cache,
> embedded aggregating cache can be updated sync/async. Aggregating from the
> box has better performance then creating custom event listeners.
>
> If cache entry updated/deleted aggregate listener can get 2 values old and
> new.
>

Re: Ignite 2.0 tasks/roadmap

Posted by Andrey Velichko <an...@gmail.com>.
15.07.2016 0:31, Dmitriy Setrakyan \u043f\u0438\u0448\u0435\u0442:
> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<an...@gmail.com>  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
> when the data in the original caches is updated?
>
>

Yes, aggregated data can be store in another cache,
embedded aggregating cache can be updated sync/async. Aggregating from 
the box has better performance then creating custom event listeners.

If cache entry updated/deleted aggregate listener can get 2 values old 
and new.

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel <an...@gmail.com> 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
when the data in the original caches is updated?


>
> Recently I learned network traffic between nodes when node restart/startup
> and do no found any compressing for transferred data.
>

Agree, we should allow users compress the data. I am not an expert on
Ignite messaging, but would be nice if some of the committers could comment
on this.


>
> 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 this?


>
>
> 14.07.2016 4:43, Alexey Goncharuk пишет:
>
> 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 - Rework offheap storage
>>   - IGNITE-3478 - Transactional SQL
>>   - IGNITE-1605 - Provide stronger data loss check
>>   - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
>> and receive custom discovery events
>>
>> I believe that there are many more changes that we wanted to make but
>> delayed because they would break binary compatibility, so if you have
>> something in mind - it's time to create a ticket or assign it to 2.0 if it
>> exists. It's good to know the scope of work.
>>
>> Also, it would be great if you review/comment the above-mentioned tickets.
>>
>> Thanks,
>> AG
>>
>>
>

Re: Ignite 2.0 tasks/roadmap

Posted by AndreyVel <an...@gmail.com>.
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 IgniteDataStreamer for writing cache, but how about 
reading cache as stream for iterate all elements with scan performane 
1-3M tuple/sec?


14.07.2016 4:43, Alexey Goncharuk \u043f\u0438\u0448\u0435\u0442:
> 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 - Rework offheap storage
>   - IGNITE-3478 - Transactional SQL
>   - IGNITE-1605 - Provide stronger data loss check
>   - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
> and receive custom discovery events
>
> I believe that there are many more changes that we wanted to make but
> delayed because they would break binary compatibility, so if you have
> something in mind - it's time to create a ticket or assign it to 2.0 if it
> exists. It's good to know the scope of work.
>
> Also, it would be great if you review/comment the above-mentioned tickets.
>
> Thanks,
> AG
>

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Goncharuk <al...@gmail.com>.
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 - Rework offheap storage
 - IGNITE-3478 - Transactional SQL
 - IGNITE-1605 - Provide stronger data loss check
 - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
and receive custom discovery events

I believe that there are many more changes that we wanted to make but
delayed because they would break binary compatibility, so if you have
something in mind - it's time to create a ticket or assign it to 2.0 if it
exists. It's good to know the scope of work.

Also, it would be great if you review/comment the above-mentioned tickets.

Thanks,
AG

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Jan 17, 2017 at 8:35 AM, Alexey Goncharuk <
alexey.goncharuk@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, the inability to add/remove
> fields). On the other hand, Binary marshaller supports all this and much
> more, and as fast as optimized.
>
> Given that Binary marshaller rolls back to optimized in case of
> Externalizable or presence of writeReplace/readResolve, I think it makes
> sense just to move it to the private package.
>
> Another positive effect - this will almost halve the number of test suites
> we need to run on TC.
>
> Thoughts?
>

No objections from me. Although, we should still make sure that we run all
the Externalizable test suites with Binary Marshaller.


>
> 2016-11-10 18:34 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
>
> > IGNITE-4211 Update Sprint dependency to latest stable version
> > <https://issues.apache.org/jira/browse/IGNITE-4211>
> >
> > On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dm...@gridgain.com>
> wrote:
> >
> > > Sound reasonable. Please create a ticket and paste it number into this
> > > discussion.
> > >
> > > —
> > > Denis
> > >
> > > > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@gridgain.com>
> > wrote:
> > > >
> > > > 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 <
> > > > alexey.goncharuk@gmail.com> wrote:
> > > >
> > > >> 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 <dm...@gridgain.com>:
> > > >>
> > > >>> I’ve created an umbrella ticket for REST
> > > >>> https://issues.apache.org/jira/browse/IGNITE-3879 <
> > > >>> https://issues.apache.org/jira/browse/IGNITE-3879>
> > > >>>
> > > >>> And I wouldn’t deprecate anything until the next version gets
> > released
> > > ;)
> > > >>>
> > > >>> —
> > > >>> Denis
> > > >>>
> > > >>>> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com>
> > > >> wrote:
> > > >>>>
> > > >>>> 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 <dm...@gridgain.com>
> > > >> wrote:
> > > >>>>
> > > >>>>> 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
> > > >>> generation
> > > >>>>> of REST API implementation.
> > > >>>>>
> > > >>>>> Does it make sense to you?
> > > >>>>>
> > > >>>>> —
> > > >>>>> Denis
> > > >>>>>
> > > >>>>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skozlov@gridgain.com
> >
> > > >>> wrote:
> > > >>>>>>
> > > >>>>>> 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 market and REST API is a
> > > single
> > > >>> way
> > > >>>>>> get access to Apache Ignite.
> > > >>>>>>
> > > >>>>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <
> > > >> vozerov@gridgain.com
> > > >>>>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> 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 <
> dmagda@gridgain.com
> > >
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> 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
> > > >>>>>>>> version of REST API implementation before NodeJS component is
> > > done.
> > > >>>>>>>>
> > > >>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> > > >>>>>>>>
> > > >>>>>>>> —
> > > >>>>>>>> Denis
> > > >>>>>>>>
> > > >>>>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <
> > skozlov@gridgain.com>
> > > >>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> 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 <
> > > >>>>>>>> akuznetsov@gridgain.com>
> > > >>>>>>>>> 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 we could break compatibility and redesign REST
> > API
> > > >>> from
> > > >>>>>>>>>> scratch.
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <
> > > dmagda@gridgain.com
> > > >>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> I would move it to 2.1 or 2.2.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> —
> > > >>>>>>>>>>> Denis
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> > > >>>>>>> dsetrakyan@apache.org>
> > > >>>>>>>>>>> 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, like 2.1?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> > > >>>>> skozlov@gridgain.com
> > > >>>>>>>>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but
> > > >>> probably
> > > >>>>>>> we
> > > >>>>>>>>>>> need
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>> have a root ticket for that.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> > > >>>>>>>>>>> dsetrakyan@apache.org>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Denis, thanks for taking a role of a release manger for
> > 2.0.
> > > >> It
> > > >>>>> is
> > > >>>>>>>>>>>>>> definitely an important release for us and good
> > supervision
> > > >> is
> > > >>>>>>> going
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>> very helpful.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I have looked at the tickets and the list seems nice. I
> > > would
> > > >>>>> also
> > > >>>>>>>>>> add
> > > >>>>>>>>>>> a
> > > >>>>>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo
> > as
> > > >>> well,
> > > >>>>>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be
> able
> > > to
> > > >>> do
> > > >>>>>>> it
> > > >>>>>>>>>>> prior
> > > >>>>>>>>>>>>>> to 2.0.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> D.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <
> > > >>> dmagda@gridgain.com
> > > >>>>>>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Community,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Let me take a role of the release manager for Apache
> > Ignite
> > > >>> 2.0
> > > >>>>>>> and
> > > >>>>>>>>>>>>>>> coordinate the process.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should
> be
> > > >>>>> released
> > > >>>>>>>> by
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>> end of the year. This sounds like a good practice to
> > make a
> > > >>>>> major
> > > >>>>>>>>>>>>> release
> > > >>>>>>>>>>>>>>> once a year. I would suggest us following the same
> rule.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Actual we have more than 3 month for development and
> I’ve
> > > >>>>> prepare
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>> wiki
> > > >>>>>>>>>>>>>>> page that contains tickets that are required to be
> > released
> > > >> in
> > > >>>>>>> 2.0
> > > >>>>>>>>>> and
> > > >>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>> are optional
> > > >>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> > > >>>>>>>>>> Apache+Ignite+2.0
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Proposed release date is December 23rd, 2016.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> The tickets that are required for the release basically
> > > >> break
> > > >>>>> the
> > > >>>>>>>>>>>>>>> compatibility and we postpone fixing them in minor
> > release
> > > >> or
> > > >>>>>>> they
> > > >>>>>>>>>>>>> bring
> > > >>>>>>>>>>>>>>> significant improvements into the product. Please
> review
> > > the
> > > >>>>>>> page,
> > > >>>>>>>>>>>>>> provide
> > > >>>>>>>>>>>>>>> your comments and assign the tickets on yourself if
> > you’re
> > > >>> ready
> > > >>>>>>> to
> > > >>>>>>>>>>>>> work
> > > >>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>> them.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> —
> > > >>>>>>>>>>>>>>> Denis
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > > >>>>>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 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 are in the same cache, it works, because
> > > >> there
> > > >>> is
> > > >>>>>>>>>> only
> > > >>>>>>>>>>>>>> one
> > > >>>>>>>>>>>>>>>> write-behind queue. Once we split different types into
> > > >>>>> different
> > > >>>>>>>>>>>>>> caches,
> > > >>>>>>>>>>>>>>>> there is no guarantee that objects will be written in
> > the
> > > >>>>> proper
> > > >>>>>>>>>>>>> order
> > > >>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>> that the constraints will not be violated.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> However, I think this is not a very clean way to
> achieve
> > > >> the
> > > >>>>>>>>>> result.
> > > >>>>>>>>>>>>>>>> Probably we should just provide better support for
> this
> > > use
> > > >>>>> case
> > > >>>>>>>> in
> > > >>>>>>>>>>>>>> 2.0.
> > > >>>>>>>>>>>>>>>> Basically, we somehow need to allow to share a single
> > > >>>>>>> write-behind
> > > >>>>>>>>>>>>>> queue
> > > >>>>>>>>>>>>>>>> between different caches.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Any thoughts?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> -Val
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > > >>>>>>>>>>>>>>> dsetrakyan@apache.org>
> > > >>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> > > >>>>>>>>>>>>> skozlov@gridgain.com>
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>> iterate
> > > >>>>>>>>>>>>>>>>> over
> > > >>>>>>>>>>>>>>>>>> caches but I'm not sure that it is supported by
> API).
> > > For
> > > >>>>>>>>>>>>>> destroy/clear
> > > >>>>>>>>>>>>>>>>>> caches belonging to same group we will do it by
> single
> > > >>>>>>> operation
> > > >>>>>>>>>>>>>>> without
> > > >>>>>>>>>>>>>>>>>> knowledge of cache names.
> > > >>>>>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will
> be
> > > >>>>>>> inherited
> > > >>>>>>>>>>>>> by a
> > > >>>>>>>>>>>>>>>>> cache
> > > >>>>>>>>>>>>>>>>>> created in that group (like eviction policy or cache
> > > >> mode).
> > > >>>>>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema
> if
> > it
> > > >>>>>>>>>> applicable
> > > >>>>>>>>>>>>>> for
> > > >>>>>>>>>>>>>>>>>> regular caches as well.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple
> > > caches,
> > > >>> as
> > > >>>>>>>>>>>>> proposed
> > > >>>>>>>>>>>>>>> by
> > > >>>>>>>>>>>>>>>>> Sergi, solves a different problem of having too many
> > SQL
> > > >>>>>>> schemas
> > > >>>>>>>>>> due
> > > >>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>> too
> > > >>>>>>>>>>>>>>>>> many different caches. I think Sergi proposed a good
> > > >>> solution
> > > >>>>>>> for
> > > >>>>>>>>>>>>> it.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > > >>>>>>>>>>>>>>>>> akuznetsov@gridgain.com
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of
> > > >> "reduce"?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> How grouping will help?
> > > >>>>>>>>>>>>>>>>>>> To do some operation, for example, clear on group
> of
> > > >>> cashes
> > > >>>>>>> at
> > > >>>>>>>>>>>>> once?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > > >>>>>>>>>>>>>>>>> skozlov@gridgain.com>
> > > >>>>>>>>>>>>>>>>>>> написал:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> 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 <
> > > >>>>>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> > > >>>>>>>>>> skozlov@gridgain.com
> > > >>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy
> Setrakyan
> > <
> > > >>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey
> Kuznetsov
> > <
> > > >>>>>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> > > >>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in
> > > >> Ignite
> > > >>>>>>> 2.0?
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Why?
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module
> > > >> support
> > > >>> as
> > > >>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>> **Spark**
> > > >>>>>>>>>>>>>>>>>>>>> 2
> > > >>>>>>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to
> > support.
> > > >> Do
> > > >>>>> we
> > > >>>>>>>>>> know
> > > >>>>>>>>>>>>>>>>>> what
> > > >>>>>>>>>>>>>>>>>>>>> kind
> > > >>>>>>>>>>>>>>>>>>>>>> of
> > > >>>>>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is
> > > >> still
> > > >>>>>>> using
> > > >>>>>>>>>>>>>>>>> 2.10?
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > > >>>>>>>>>>>>>>>>>>> dmagda@gridgain.com>
> > > >>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>> <
> > > >>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/
> > > jira/browse/IGNITE-3495
> > > >>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> —
> > > >>>>>>>>>>>>>>>>>>>>>>>>> Denis
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > > >>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan
> <
> > > >>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > > >>>>>>>>>>>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov
> > Zhdanov <
> > > >>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy
> > Setrakyan <
> > > >>>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > > >>>>>>>>>>>>>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
> > > >> Zhdanov
> > > >>> <
> > > >>>>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>> may
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> block
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
> > > >>>>> discovery
> > > >>>>>>>>>>>>>>>>>> event)
> > > >>>>>>>>>>>>>>>>>>>>>> causing
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being
> > > added.
> > > >>>>>>> Would
> > > >>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>>>> nice
> > > >>>>>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>>>>>> assign
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and
> document
> > > >> all
> > > >>>>> the
> > > >>>>>>>>>>>>>>>>>>>> discussed
> > > >>>>>>>>>>>>>>>>>>>>>>>> features
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey
> > Goncharuk <
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> comes
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we
> > track
> > > >>> such
> > > >>>>>>>>>>>>>>>>> tasks?
> > > >>>>>>>>>>>>>>>>>>>>> Should
> > > >>>>>>>>>>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> be a
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks,
> > > >> something
> > > >>>>>>> else?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release
> > version.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> > > >>>>>>>>>>>>>>>>>>>>>>>> GridGain Systems
> > > >>>>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>>>> Sergey Kozlov
> > > >>>>>>>>>>>>>>>>>>>>>> GridGain Systems
> > > >>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>>> Sergey Kozlov
> > > >>>>>>>>>>>>>>>>>>>> GridGain Systems
> > > >>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>> Sergey Kozlov
> > > >>>>>>>>>>>>>>>>>> GridGain Systems
> > > >>>>>>>>>>>>>>>>>> www.gridgain.com
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> --
> > > >>>>>>>>>>>>> Sergey Kozlov
> > > >>>>>>>>>>>>> GridGain Systems
> > > >>>>>>>>>>>>> www.gridgain.com
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> Alexey Kuznetsov
> > > >>>>>>>>>> GridGain Systems
> > > >>>>>>>>>> www.gridgain.com
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Sergey Kozlov
> > > >>>>>>>>> GridGain Systems
> > > >>>>>>>>> www.gridgain.com
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Sergey Kozlov
> > > >>>>>> GridGain Systems
> > > >>>>>> www.gridgain.com
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Sergey Kozlov
> > > >>>> GridGain Systems
> > > >>>> www.gridgain.com
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Sergey Kozlov
> > > > GridGain Systems
> > > > www.gridgain.com
> > >
> > >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Goncharuk <al...@gmail.com>.
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 much
more, and as fast as optimized.

Given that Binary marshaller rolls back to optimized in case of
Externalizable or presence of writeReplace/readResolve, I think it makes
sense just to move it to the private package.

Another positive effect - this will almost halve the number of test suites
we need to run on TC.

Thoughts?

2016-11-10 18:34 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:

> IGNITE-4211 Update Sprint dependency to latest stable version
> <https://issues.apache.org/jira/browse/IGNITE-4211>
>
> On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dm...@gridgain.com> wrote:
>
> > Sound reasonable. Please create a ticket and paste it number into this
> > discussion.
> >
> > —
> > Denis
> >
> > > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@gridgain.com>
> wrote:
> > >
> > > 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 <
> > > alexey.goncharuk@gmail.com> wrote:
> > >
> > >> 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 <dm...@gridgain.com>:
> > >>
> > >>> I’ve created an umbrella ticket for REST
> > >>> https://issues.apache.org/jira/browse/IGNITE-3879 <
> > >>> https://issues.apache.org/jira/browse/IGNITE-3879>
> > >>>
> > >>> And I wouldn’t deprecate anything until the next version gets
> released
> > ;)
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> > >>>> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com>
> > >> wrote:
> > >>>>
> > >>>> 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 <dm...@gridgain.com>
> > >> wrote:
> > >>>>
> > >>>>> 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
> > >>> generation
> > >>>>> of REST API implementation.
> > >>>>>
> > >>>>> Does it make sense to you?
> > >>>>>
> > >>>>> —
> > >>>>> Denis
> > >>>>>
> > >>>>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>> 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 market and REST API is a
> > single
> > >>> way
> > >>>>>> get access to Apache Ignite.
> > >>>>>>
> > >>>>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <
> > >> vozerov@gridgain.com
> > >>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> 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 <dmagda@gridgain.com
> >
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> 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
> > >>>>>>>> version of REST API implementation before NodeJS component is
> > done.
> > >>>>>>>>
> > >>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> > >>>>>>>>
> > >>>>>>>> —
> > >>>>>>>> Denis
> > >>>>>>>>
> > >>>>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <
> skozlov@gridgain.com>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> 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 <
> > >>>>>>>> akuznetsov@gridgain.com>
> > >>>>>>>>> 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 we could break compatibility and redesign REST
> API
> > >>> from
> > >>>>>>>>>> scratch.
> > >>>>>>>>>>
> > >>>>>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <
> > dmagda@gridgain.com
> > >>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> I would move it to 2.1 or 2.2.
> > >>>>>>>>>>>
> > >>>>>>>>>>> —
> > >>>>>>>>>>> Denis
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> > >>>>>>> dsetrakyan@apache.org>
> > >>>>>>>>>>> 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, like 2.1?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> > >>>>> skozlov@gridgain.com
> > >>>>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> 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
> > >>>>>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but
> > >>> probably
> > >>>>>>> we
> > >>>>>>>>>>> need
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>> have a root ticket for that.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> > >>>>>>>>>>> dsetrakyan@apache.org>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Denis, thanks for taking a role of a release manger for
> 2.0.
> > >> It
> > >>>>> is
> > >>>>>>>>>>>>>> definitely an important release for us and good
> supervision
> > >> is
> > >>>>>>> going
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> be
> > >>>>>>>>>>>>>> very helpful.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I have looked at the tickets and the list seems nice. I
> > would
> > >>>>> also
> > >>>>>>>>>> add
> > >>>>>>>>>>> a
> > >>>>>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo
> as
> > >>> well,
> > >>>>>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able
> > to
> > >>> do
> > >>>>>>> it
> > >>>>>>>>>>> prior
> > >>>>>>>>>>>>>> to 2.0.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> D.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <
> > >>> dmagda@gridgain.com
> > >>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Community,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Let me take a role of the release manager for Apache
> Ignite
> > >>> 2.0
> > >>>>>>> and
> > >>>>>>>>>>>>>>> coordinate the process.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
> > >>>>> released
> > >>>>>>>> by
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>> end of the year. This sounds like a good practice to
> make a
> > >>>>> major
> > >>>>>>>>>>>>> release
> > >>>>>>>>>>>>>>> once a year. I would suggest us following the same rule.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Actual we have more than 3 month for development and I’ve
> > >>>>> prepare
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>> wiki
> > >>>>>>>>>>>>>>> page that contains tickets that are required to be
> released
> > >> in
> > >>>>>>> 2.0
> > >>>>>>>>>> and
> > >>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>> are optional
> > >>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> > >>>>>>>>>> Apache+Ignite+2.0
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Proposed release date is December 23rd, 2016.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> The tickets that are required for the release basically
> > >> break
> > >>>>> the
> > >>>>>>>>>>>>>>> compatibility and we postpone fixing them in minor
> release
> > >> or
> > >>>>>>> they
> > >>>>>>>>>>>>> bring
> > >>>>>>>>>>>>>>> significant improvements into the product. Please review
> > the
> > >>>>>>> page,
> > >>>>>>>>>>>>>> provide
> > >>>>>>>>>>>>>>> your comments and assign the tickets on yourself if
> you’re
> > >>> ready
> > >>>>>>> to
> > >>>>>>>>>>>>> work
> > >>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>> them.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> —
> > >>>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > >>>>>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 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 are in the same cache, it works, because
> > >> there
> > >>> is
> > >>>>>>>>>> only
> > >>>>>>>>>>>>>> one
> > >>>>>>>>>>>>>>>> write-behind queue. Once we split different types into
> > >>>>> different
> > >>>>>>>>>>>>>> caches,
> > >>>>>>>>>>>>>>>> there is no guarantee that objects will be written in
> the
> > >>>>> proper
> > >>>>>>>>>>>>> order
> > >>>>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> that the constraints will not be violated.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> However, I think this is not a very clean way to achieve
> > >> the
> > >>>>>>>>>> result.
> > >>>>>>>>>>>>>>>> Probably we should just provide better support for this
> > use
> > >>>>> case
> > >>>>>>>> in
> > >>>>>>>>>>>>>> 2.0.
> > >>>>>>>>>>>>>>>> Basically, we somehow need to allow to share a single
> > >>>>>>> write-behind
> > >>>>>>>>>>>>>> queue
> > >>>>>>>>>>>>>>>> between different caches.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Any thoughts?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> -Val
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > >>>>>>>>>>>>>>> dsetrakyan@apache.org>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> > >>>>>>>>>>>>> skozlov@gridgain.com>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>> iterate
> > >>>>>>>>>>>>>>>>> over
> > >>>>>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API).
> > For
> > >>>>>>>>>>>>>> destroy/clear
> > >>>>>>>>>>>>>>>>>> caches belonging to same group we will do it by single
> > >>>>>>> operation
> > >>>>>>>>>>>>>>> without
> > >>>>>>>>>>>>>>>>>> knowledge of cache names.
> > >>>>>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
> > >>>>>>> inherited
> > >>>>>>>>>>>>> by a
> > >>>>>>>>>>>>>>>>> cache
> > >>>>>>>>>>>>>>>>>> created in that group (like eviction policy or cache
> > >> mode).
> > >>>>>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if
> it
> > >>>>>>>>>> applicable
> > >>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>> regular caches as well.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple
> > caches,
> > >>> as
> > >>>>>>>>>>>>> proposed
> > >>>>>>>>>>>>>>> by
> > >>>>>>>>>>>>>>>>> Sergi, solves a different problem of having too many
> SQL
> > >>>>>>> schemas
> > >>>>>>>>>> due
> > >>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>> too
> > >>>>>>>>>>>>>>>>> many different caches. I think Sergi proposed a good
> > >>> solution
> > >>>>>>> for
> > >>>>>>>>>>>>> it.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > >>>>>>>>>>>>>>>>> akuznetsov@gridgain.com
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of
> > >> "reduce"?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> How grouping will help?
> > >>>>>>>>>>>>>>>>>>> To do some operation, for example, clear on group of
> > >>> cashes
> > >>>>>>> at
> > >>>>>>>>>>>>> once?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > >>>>>>>>>>>>>>>>> skozlov@gridgain.com>
> > >>>>>>>>>>>>>>>>>>> написал:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 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 <
> > >>>>>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> > >>>>>>>>>> skozlov@gridgain.com
> > >>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan
> <
> > >>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov
> <
> > >>>>>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> > >>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in
> > >> Ignite
> > >>>>>>> 2.0?
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Why?
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module
> > >> support
> > >>> as
> > >>>>>>> of
> > >>>>>>>>>>>>>>>>>>>> **Spark**
> > >>>>>>>>>>>>>>>>>>>>> 2
> > >>>>>>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to
> support.
> > >> Do
> > >>>>> we
> > >>>>>>>>>> know
> > >>>>>>>>>>>>>>>>>> what
> > >>>>>>>>>>>>>>>>>>>>> kind
> > >>>>>>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is
> > >> still
> > >>>>>>> using
> > >>>>>>>>>>>>>>>>> 2.10?
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > >>>>>>>>>>>>>>>>>>> dmagda@gridgain.com>
> > >>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/
> > jira/browse/IGNITE-3495
> > >>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> —
> > >>>>>>>>>>>>>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > >>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov
> Zhdanov <
> > >>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy
> Setrakyan <
> > >>>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
> > >> Zhdanov
> > >>> <
> > >>>>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>> may
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> block
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
> > >>>>> discovery
> > >>>>>>>>>>>>>>>>>> event)
> > >>>>>>>>>>>>>>>>>>>>>> causing
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being
> > added.
> > >>>>>>> Would
> > >>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>> nice
> > >>>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>>> assign
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document
> > >> all
> > >>>>> the
> > >>>>>>>>>>>>>>>>>>>> discussed
> > >>>>>>>>>>>>>>>>>>>>>>>> features
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey
> Goncharuk <
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> comes
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we
> track
> > >>> such
> > >>>>>>>>>>>>>>>>> tasks?
> > >>>>>>>>>>>>>>>>>>>>> Should
> > >>>>>>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> be a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks,
> > >> something
> > >>>>>>> else?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release
> version.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> > >>>>>>>>>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Alexey Kuznetsov
> > >>>>>>>>>> GridGain Systems
> > >>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Sergey Kozlov
> > >>>>>>>>> GridGain Systems
> > >>>>>>>>> www.gridgain.com
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Sergey Kozlov
> > >>>>>> GridGain Systems
> > >>>>>> www.gridgain.com
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Sergey Kozlov
> > >>>> GridGain Systems
> > >>>> www.gridgain.com
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
IGNITE-4211 Update Sprint dependency to latest stable version
<https://issues.apache.org/jira/browse/IGNITE-4211>

On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dm...@gridgain.com> wrote:

> Sound reasonable. Please create a ticket and paste it number into this
> discussion.
>
> —
> Denis
>
> > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> >
> > 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 <
> > alexey.goncharuk@gmail.com> wrote:
> >
> >> 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 <dm...@gridgain.com>:
> >>
> >>> I’ve created an umbrella ticket for REST
> >>> https://issues.apache.org/jira/browse/IGNITE-3879 <
> >>> https://issues.apache.org/jira/browse/IGNITE-3879>
> >>>
> >>> And I wouldn’t deprecate anything until the next version gets released
> ;)
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com>
> >> wrote:
> >>>>
> >>>> 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 <dm...@gridgain.com>
> >> wrote:
> >>>>
> >>>>> 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
> >>> generation
> >>>>> of REST API implementation.
> >>>>>
> >>>>> Does it make sense to you?
> >>>>>
> >>>>> —
> >>>>> Denis
> >>>>>
> >>>>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com>
> >>> wrote:
> >>>>>>
> >>>>>> 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 market and REST API is a
> single
> >>> way
> >>>>>> get access to Apache Ignite.
> >>>>>>
> >>>>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <
> >> vozerov@gridgain.com
> >>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> 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 <dm...@gridgain.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>> version of REST API implementation before NodeJS component is
> done.
> >>>>>>>>
> >>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> >>>>>>>>
> >>>>>>>> —
> >>>>>>>> Denis
> >>>>>>>>
> >>>>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> 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 <
> >>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>> 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 we could break compatibility and redesign REST API
> >>> from
> >>>>>>>>>> scratch.
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <
> dmagda@gridgain.com
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I would move it to 2.1 or 2.2.
> >>>>>>>>>>>
> >>>>>>>>>>> —
> >>>>>>>>>>> Denis
> >>>>>>>>>>>
> >>>>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> >>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>> 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, like 2.1?
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> >>>>> skozlov@gridgain.com
> >>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but
> >>> probably
> >>>>>>> we
> >>>>>>>>>>> need
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>> have a root ticket for that.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> >>>>>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0.
> >> It
> >>>>> is
> >>>>>>>>>>>>>> definitely an important release for us and good supervision
> >> is
> >>>>>>> going
> >>>>>>>>>> to
> >>>>>>>>>>>>> be
> >>>>>>>>>>>>>> very helpful.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have looked at the tickets and the list seems nice. I
> would
> >>>>> also
> >>>>>>>>>> add
> >>>>>>>>>>> a
> >>>>>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as
> >>> well,
> >>>>>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able
> to
> >>> do
> >>>>>>> it
> >>>>>>>>>>> prior
> >>>>>>>>>>>>>> to 2.0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> D.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <
> >>> dmagda@gridgain.com
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Community,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite
> >>> 2.0
> >>>>>>> and
> >>>>>>>>>>>>>>> coordinate the process.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
> >>>>> released
> >>>>>>>> by
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> end of the year. This sounds like a good practice to make a
> >>>>> major
> >>>>>>>>>>>>> release
> >>>>>>>>>>>>>>> once a year. I would suggest us following the same rule.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Actual we have more than 3 month for development and I’ve
> >>>>> prepare
> >>>>>>>>>> the
> >>>>>>>>>>>>>> wiki
> >>>>>>>>>>>>>>> page that contains tickets that are required to be released
> >> in
> >>>>>>> 2.0
> >>>>>>>>>> and
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>> are optional
> >>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> >>>>>>>>>> Apache+Ignite+2.0
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Proposed release date is December 23rd, 2016.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The tickets that are required for the release basically
> >> break
> >>>>> the
> >>>>>>>>>>>>>>> compatibility and we postpone fixing them in minor release
> >> or
> >>>>>>> they
> >>>>>>>>>>>>> bring
> >>>>>>>>>>>>>>> significant improvements into the product. Please review
> the
> >>>>>>> page,
> >>>>>>>>>>>>>> provide
> >>>>>>>>>>>>>>> your comments and assign the tickets on yourself if you’re
> >>> ready
> >>>>>>> to
> >>>>>>>>>>>>> work
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>> them.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> >>>>>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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 are in the same cache, it works, because
> >> there
> >>> is
> >>>>>>>>>> only
> >>>>>>>>>>>>>> one
> >>>>>>>>>>>>>>>> write-behind queue. Once we split different types into
> >>>>> different
> >>>>>>>>>>>>>> caches,
> >>>>>>>>>>>>>>>> there is no guarantee that objects will be written in the
> >>>>> proper
> >>>>>>>>>>>>> order
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> that the constraints will not be violated.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> However, I think this is not a very clean way to achieve
> >> the
> >>>>>>>>>> result.
> >>>>>>>>>>>>>>>> Probably we should just provide better support for this
> use
> >>>>> case
> >>>>>>>> in
> >>>>>>>>>>>>>> 2.0.
> >>>>>>>>>>>>>>>> Basically, we somehow need to allow to share a single
> >>>>>>> write-behind
> >>>>>>>>>>>>>> queue
> >>>>>>>>>>>>>>>> between different caches.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any thoughts?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Val
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> >>>>>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>> iterate
> >>>>>>>>>>>>>>>>> over
> >>>>>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API).
> For
> >>>>>>>>>>>>>> destroy/clear
> >>>>>>>>>>>>>>>>>> caches belonging to same group we will do it by single
> >>>>>>> operation
> >>>>>>>>>>>>>>> without
> >>>>>>>>>>>>>>>>>> knowledge of cache names.
> >>>>>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
> >>>>>>> inherited
> >>>>>>>>>>>>> by a
> >>>>>>>>>>>>>>>>> cache
> >>>>>>>>>>>>>>>>>> created in that group (like eviction policy or cache
> >> mode).
> >>>>>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
> >>>>>>>>>> applicable
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>> regular caches as well.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple
> caches,
> >>> as
> >>>>>>>>>>>>> proposed
> >>>>>>>>>>>>>>> by
> >>>>>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
> >>>>>>> schemas
> >>>>>>>>>> due
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> too
> >>>>>>>>>>>>>>>>> many different caches. I think Sergi proposed a good
> >>> solution
> >>>>>>> for
> >>>>>>>>>>>>> it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> >>>>>>>>>>>>>>>>> akuznetsov@gridgain.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of
> >> "reduce"?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> How grouping will help?
> >>>>>>>>>>>>>>>>>>> To do some operation, for example, clear on group of
> >>> cashes
> >>>>>>> at
> >>>>>>>>>>>>> once?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> >>>>>>>>>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>>>>>>> написал:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> >>>>>>>>>> skozlov@gridgain.com
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in
> >> Ignite
> >>>>>>> 2.0?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Why?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module
> >> support
> >>> as
> >>>>>>> of
> >>>>>>>>>>>>>>>>>>>> **Spark**
> >>>>>>>>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support.
> >> Do
> >>>>> we
> >>>>>>>>>> know
> >>>>>>>>>>>>>>>>>> what
> >>>>>>>>>>>>>>>>>>>>> kind
> >>>>>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is
> >> still
> >>>>>>> using
> >>>>>>>>>>>>>>>>> 2.10?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>>>>>>>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/
> jira/browse/IGNITE-3495
> >>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
> >> Zhdanov
> >>> <
> >>>>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> block
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
> >>>>> discovery
> >>>>>>>>>>>>>>>>>> event)
> >>>>>>>>>>>>>>>>>>>>>> causing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being
> added.
> >>>>>>> Would
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>> nice
> >>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>> assign
> >>>>>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document
> >> all
> >>>>> the
> >>>>>>>>>>>>>>>>>>>> discussed
> >>>>>>>>>>>>>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>>> comes
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track
> >>> such
> >>>>>>>>>>>>>>>>> tasks?
> >>>>>>>>>>>>>>>>>>>>> Should
> >>>>>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks,
> >> something
> >>>>>>> else?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>> GridGain Systems
> >>>>>>>>>> www.gridgain.com
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Sergey Kozlov
> >>>>>>>>> GridGain Systems
> >>>>>>>>> www.gridgain.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Sergey Kozlov
> >>>>>> GridGain Systems
> >>>>>> www.gridgain.com
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sergey Kozlov
> >>>> GridGain Systems
> >>>> www.gridgain.com
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
>
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
Sound reasonable. Please create a ticket and paste it number into this discussion.

—
Denis

> On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> 
> 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 <
> alexey.goncharuk@gmail.com> wrote:
> 
>> 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 <dm...@gridgain.com>:
>> 
>>> I’ve created an umbrella ticket for REST
>>> https://issues.apache.org/jira/browse/IGNITE-3879 <
>>> https://issues.apache.org/jira/browse/IGNITE-3879>
>>> 
>>> And I wouldn’t deprecate anything until the next version gets released ;)
>>> 
>>> —
>>> Denis
>>> 
>>>> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com>
>> wrote:
>>>> 
>>>> 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 <dm...@gridgain.com>
>> wrote:
>>>> 
>>>>> 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
>>> generation
>>>>> of REST API implementation.
>>>>> 
>>>>> Does it make sense to you?
>>>>> 
>>>>> —
>>>>> Denis
>>>>> 
>>>>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com>
>>> wrote:
>>>>>> 
>>>>>> 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 market and REST API is a single
>>> way
>>>>>> get access to Apache Ignite.
>>>>>> 
>>>>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <
>> vozerov@gridgain.com
>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> 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 <dm...@gridgain.com>
>>>>> wrote:
>>>>>>> 
>>>>>>>> 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
>>>>>>>> version of REST API implementation before NodeJS component is done.
>>>>>>>> 
>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
>>>>>>>> 
>>>>>>>> —
>>>>>>>> Denis
>>>>>>>> 
>>>>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 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 <
>>>>>>>> akuznetsov@gridgain.com>
>>>>>>>>> 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 we could break compatibility and redesign REST API
>>> from
>>>>>>>>>> scratch.
>>>>>>>>>> 
>>>>>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dmagda@gridgain.com
>>> 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I would move it to 2.1 or 2.2.
>>>>>>>>>>> 
>>>>>>>>>>> —
>>>>>>>>>>> Denis
>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
>>>>>>> dsetrakyan@apache.org>
>>>>>>>>>>> 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, like 2.1?
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
>>>>> skozlov@gridgain.com
>>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but
>>> probably
>>>>>>> we
>>>>>>>>>>> need
>>>>>>>>>>>>> to
>>>>>>>>>>>>> have a root ticket for that.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
>>>>>>>>>>> dsetrakyan@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0.
>> It
>>>>> is
>>>>>>>>>>>>>> definitely an important release for us and good supervision
>> is
>>>>>>> going
>>>>>>>>>> to
>>>>>>>>>>>>> be
>>>>>>>>>>>>>> very helpful.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I have looked at the tickets and the list seems nice. I would
>>>>> also
>>>>>>>>>> add
>>>>>>>>>>> a
>>>>>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as
>>> well,
>>>>>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to
>>> do
>>>>>>> it
>>>>>>>>>>> prior
>>>>>>>>>>>>>> to 2.0.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> D.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <
>>> dmagda@gridgain.com
>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Community,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite
>>> 2.0
>>>>>>> and
>>>>>>>>>>>>>>> coordinate the process.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
>>>>> released
>>>>>>>> by
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> end of the year. This sounds like a good practice to make a
>>>>> major
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> once a year. I would suggest us following the same rule.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Actual we have more than 3 month for development and I’ve
>>>>> prepare
>>>>>>>>>> the
>>>>>>>>>>>>>> wiki
>>>>>>>>>>>>>>> page that contains tickets that are required to be released
>> in
>>>>>>> 2.0
>>>>>>>>>> and
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> are optional
>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
>>>>>>>>>> Apache+Ignite+2.0
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Proposed release date is December 23rd, 2016.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The tickets that are required for the release basically
>> break
>>>>> the
>>>>>>>>>>>>>>> compatibility and we postpone fixing them in minor release
>> or
>>>>>>> they
>>>>>>>>>>>>> bring
>>>>>>>>>>>>>>> significant improvements into the product. Please review the
>>>>>>> page,
>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>> your comments and assign the tickets on yourself if you’re
>>> ready
>>>>>>> to
>>>>>>>>>>>>> work
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
>>>>>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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 are in the same cache, it works, because
>> there
>>> is
>>>>>>>>>> only
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>> write-behind queue. Once we split different types into
>>>>> different
>>>>>>>>>>>>>> caches,
>>>>>>>>>>>>>>>> there is no guarantee that objects will be written in the
>>>>> proper
>>>>>>>>>>>>> order
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> that the constraints will not be violated.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> However, I think this is not a very clean way to achieve
>> the
>>>>>>>>>> result.
>>>>>>>>>>>>>>>> Probably we should just provide better support for this use
>>>>> case
>>>>>>>> in
>>>>>>>>>>>>>> 2.0.
>>>>>>>>>>>>>>>> Basically, we somehow need to allow to share a single
>>>>>>> write-behind
>>>>>>>>>>>>>> queue
>>>>>>>>>>>>>>>> between different caches.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Any thoughts?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Val
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
>>>>>>>>>>>>>>> dsetrakyan@apache.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
>>>>>>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> iterate
>>>>>>>>>>>>>>>>> over
>>>>>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For
>>>>>>>>>>>>>> destroy/clear
>>>>>>>>>>>>>>>>>> caches belonging to same group we will do it by single
>>>>>>> operation
>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>>>> knowledge of cache names.
>>>>>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
>>>>>>> inherited
>>>>>>>>>>>>> by a
>>>>>>>>>>>>>>>>> cache
>>>>>>>>>>>>>>>>>> created in that group (like eviction policy or cache
>> mode).
>>>>>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
>>>>>>>>>> applicable
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> regular caches as well.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches,
>>> as
>>>>>>>>>>>>> proposed
>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
>>>>>>> schemas
>>>>>>>>>> due
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>> many different caches. I think Sergi proposed a good
>>> solution
>>>>>>> for
>>>>>>>>>>>>> it.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of
>> "reduce"?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> How grouping will help?
>>>>>>>>>>>>>>>>>>> To do some operation, for example, clear on group of
>>> cashes
>>>>>>> at
>>>>>>>>>>>>> once?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
>>>>>>>>>>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>>>>>>>>>> написал:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
>>>>>>>>>> skozlov@gridgain.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
>>>>>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in
>> Ignite
>>>>>>> 2.0?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module
>> support
>>> as
>>>>>>> of
>>>>>>>>>>>>>>>>>>>> **Spark**
>>>>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support.
>> Do
>>>>> we
>>>>>>>>>> know
>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>>>> kind
>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is
>> still
>>>>>>> using
>>>>>>>>>>>>>>>>> 2.10?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
>>>>>>>>>>>>>>>>>>> dmagda@gridgain.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495
>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
>> Zhdanov
>>> <
>>>>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
>>>>> discovery
>>>>>>>>>>>>>>>>>> event)
>>>>>>>>>>>>>>>>>>>>>> causing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> topology
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
>>>>>>> Would
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> nice
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> assign
>>>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document
>> all
>>>>> the
>>>>>>>>>>>>>>>>>>>> discussed
>>>>>>>>>>>>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>>>>>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>> comes
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track
>>> such
>>>>>>>>>>>>>>>>> tasks?
>>>>>>>>>>>>>>>>>>>>> Should
>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks,
>> something
>>>>>>> else?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
>>>>>>>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Alexey Kuznetsov
>>>>>>>>>> GridGain Systems
>>>>>>>>>> www.gridgain.com
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Sergey Kozlov
>>>>>>>>> GridGain Systems
>>>>>>>>> www.gridgain.com
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sergey Kozlov
>>>>>> GridGain Systems
>>>>>> www.gridgain.com
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Sergey Kozlov
>>>> GridGain Systems
>>>> www.gridgain.com
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <
alexey.goncharuk@gmail.com> wrote:

> 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 <dm...@gridgain.com>:
>
> > I’ve created an umbrella ticket for REST
> > https://issues.apache.org/jira/browse/IGNITE-3879 <
> > https://issues.apache.org/jira/browse/IGNITE-3879>
> >
> > And I wouldn’t deprecate anything until the next version gets released ;)
> >
> > —
> > Denis
> >
> > > On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com>
> wrote:
> > >
> > > 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 <dm...@gridgain.com>
> wrote:
> > >
> > >> 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
> > generation
> > >> of REST API implementation.
> > >>
> > >> Does it make sense to you?
> > >>
> > >> —
> > >> Denis
> > >>
> > >>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com>
> > wrote:
> > >>>
> > >>> 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 market and REST API is a single
> > way
> > >>> get access to Apache Ignite.
> > >>>
> > >>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <
> vozerov@gridgain.com
> > >
> > >>> wrote:
> > >>>
> > >>>> 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 <dm...@gridgain.com>
> > >> wrote:
> > >>>>
> > >>>>> 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
> > >>>>> version of REST API implementation before NodeJS component is done.
> > >>>>>
> > >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> > >>>>>
> > >>>>> —
> > >>>>> Denis
> > >>>>>
> > >>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
> > >>>> wrote:
> > >>>>>>
> > >>>>>> 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 <
> > >>>>> akuznetsov@gridgain.com>
> > >>>>>> 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 we could break compatibility and redesign REST API
> > from
> > >>>>>>> scratch.
> > >>>>>>>
> > >>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dmagda@gridgain.com
> >
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> I would move it to 2.1 or 2.2.
> > >>>>>>>>
> > >>>>>>>> —
> > >>>>>>>> Denis
> > >>>>>>>>
> > >>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> > >>>> dsetrakyan@apache.org>
> > >>>>>>>> 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, like 2.1?
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> > >> skozlov@gridgain.com
> > >>>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but
> > probably
> > >>>> we
> > >>>>>>>> need
> > >>>>>>>>>> to
> > >>>>>>>>>> have a root ticket for that.
> > >>>>>>>>>>
> > >>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> > >>>>>>>> dsetrakyan@apache.org>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0.
> It
> > >> is
> > >>>>>>>>>>> definitely an important release for us and good supervision
> is
> > >>>> going
> > >>>>>>> to
> > >>>>>>>>>> be
> > >>>>>>>>>>> very helpful.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I have looked at the tickets and the list seems nice. I would
> > >> also
> > >>>>>>> add
> > >>>>>>>> a
> > >>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as
> > well,
> > >>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to
> > do
> > >>>> it
> > >>>>>>>> prior
> > >>>>>>>>>>> to 2.0.
> > >>>>>>>>>>>
> > >>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> > >>>>>>>>>>>
> > >>>>>>>>>>> D.
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <
> > dmagda@gridgain.com
> > >>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Community,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite
> > 2.0
> > >>>> and
> > >>>>>>>>>>>> coordinate the process.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
> > >> released
> > >>>>> by
> > >>>>>>>>>> the
> > >>>>>>>>>>>> end of the year. This sounds like a good practice to make a
> > >> major
> > >>>>>>>>>> release
> > >>>>>>>>>>>> once a year. I would suggest us following the same rule.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Actual we have more than 3 month for development and I’ve
> > >> prepare
> > >>>>>>> the
> > >>>>>>>>>>> wiki
> > >>>>>>>>>>>> page that contains tickets that are required to be released
> in
> > >>>> 2.0
> > >>>>>>> and
> > >>>>>>>>>>> that
> > >>>>>>>>>>>> are optional
> > >>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> > >>>>>>> Apache+Ignite+2.0
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Proposed release date is December 23rd, 2016.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> The tickets that are required for the release basically
> break
> > >> the
> > >>>>>>>>>>>> compatibility and we postpone fixing them in minor release
> or
> > >>>> they
> > >>>>>>>>>> bring
> > >>>>>>>>>>>> significant improvements into the product. Please review the
> > >>>> page,
> > >>>>>>>>>>> provide
> > >>>>>>>>>>>> your comments and assign the tickets on yourself if you’re
> > ready
> > >>>> to
> > >>>>>>>>>> work
> > >>>>>>>>>>> on
> > >>>>>>>>>>>> them.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> —
> > >>>>>>>>>>>> Denis
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > >>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 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 are in the same cache, it works, because
> there
> > is
> > >>>>>>> only
> > >>>>>>>>>>> one
> > >>>>>>>>>>>>> write-behind queue. Once we split different types into
> > >> different
> > >>>>>>>>>>> caches,
> > >>>>>>>>>>>>> there is no guarantee that objects will be written in the
> > >> proper
> > >>>>>>>>>> order
> > >>>>>>>>>>>> and
> > >>>>>>>>>>>>> that the constraints will not be violated.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> However, I think this is not a very clean way to achieve
> the
> > >>>>>>> result.
> > >>>>>>>>>>>>> Probably we should just provide better support for this use
> > >> case
> > >>>>> in
> > >>>>>>>>>>> 2.0.
> > >>>>>>>>>>>>> Basically, we somehow need to allow to share a single
> > >>>> write-behind
> > >>>>>>>>>>> queue
> > >>>>>>>>>>>>> between different caches.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Any thoughts?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -Val
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > >>>>>>>>>>>> dsetrakyan@apache.org>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> > >>>>>>>>>> skozlov@gridgain.com>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 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
> > >>>>>>>>>> iterate
> > >>>>>>>>>>>>>> over
> > >>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For
> > >>>>>>>>>>> destroy/clear
> > >>>>>>>>>>>>>>> caches belonging to same group we will do it by single
> > >>>> operation
> > >>>>>>>>>>>> without
> > >>>>>>>>>>>>>>> knowledge of cache names.
> > >>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
> > >>>> inherited
> > >>>>>>>>>> by a
> > >>>>>>>>>>>>>> cache
> > >>>>>>>>>>>>>>> created in that group (like eviction policy or cache
> mode).
> > >>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
> > >>>>>>> applicable
> > >>>>>>>>>>> for
> > >>>>>>>>>>>>>>> regular caches as well.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches,
> > as
> > >>>>>>>>>> proposed
> > >>>>>>>>>>>> by
> > >>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
> > >>>> schemas
> > >>>>>>> due
> > >>>>>>>>>>> to
> > >>>>>>>>>>>> too
> > >>>>>>>>>>>>>> many different caches. I think Sergi proposed a good
> > solution
> > >>>> for
> > >>>>>>>>>> it.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > >>>>>>>>>>>>>> akuznetsov@gridgain.com
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of
> "reduce"?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> How grouping will help?
> > >>>>>>>>>>>>>>>> To do some operation, for example, clear on group of
> > cashes
> > >>>> at
> > >>>>>>>>>> once?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > >>>>>>>>>>>>>> skozlov@gridgain.com>
> > >>>>>>>>>>>>>>>> написал:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 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 <
> > >>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> > >>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> > >>>>>>> skozlov@gridgain.com
> > >>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > >>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > >>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in
> Ignite
> > >>>> 2.0?
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Why?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module
> support
> > as
> > >>>> of
> > >>>>>>>>>>>>>>>>> **Spark**
> > >>>>>>>>>>>>>>>>>> 2
> > >>>>>>>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support.
> Do
> > >> we
> > >>>>>>> know
> > >>>>>>>>>>>>>>> what
> > >>>>>>>>>>>>>>>>>> kind
> > >>>>>>>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is
> still
> > >>>> using
> > >>>>>>>>>>>>>> 2.10?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > >>>>>>>>>>>>>>>> dmagda@gridgain.com>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 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
> > >>>> <
> > >>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495
> >
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> —
> > >>>>>>>>>>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > >>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > >>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
> Zhdanov
> > <
> > >>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>> may
> > >>>>>>>>>>>>>>>>>>>>>>>>>> block
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
> > >> discovery
> > >>>>>>>>>>>>>>> event)
> > >>>>>>>>>>>>>>>>>>> causing
> > >>>>>>>>>>>>>>>>>>>>>>>>>> topology
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
> > >>>> Would
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>> nice
> > >>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>> assign
> > >>>>>>>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document
> all
> > >> the
> > >>>>>>>>>>>>>>>>> discussed
> > >>>>>>>>>>>>>>>>>>>>> features
> > >>>>>>>>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > >>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> > >>>>>>>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>>>>> comes
> > >>>>>>>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track
> > such
> > >>>>>>>>>>>>>> tasks?
> > >>>>>>>>>>>>>>>>>> Should
> > >>>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>>>>>> be a
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks,
> something
> > >>>> else?
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> > >>>>>>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>> GridGain Systems
> > >>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Alexey Kuznetsov
> > >>>>>>> GridGain Systems
> > >>>>>>> www.gridgain.com
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Sergey Kozlov
> > >>>>>> GridGain Systems
> > >>>>>> www.gridgain.com
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Sergey Kozlov
> > >>> GridGain Systems
> > >>> www.gridgain.com
> > >>
> > >>
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> >
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Goncharuk <al...@gmail.com>.
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 <dm...@gridgain.com>:

> I’ve created an umbrella ticket for REST
> https://issues.apache.org/jira/browse/IGNITE-3879 <
> https://issues.apache.org/jira/browse/IGNITE-3879>
>
> And I wouldn’t deprecate anything until the next version gets released ;)
>
> —
> Denis
>
> > On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> >
> > 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 <dm...@gridgain.com> wrote:
> >
> >> 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
> generation
> >> of REST API implementation.
> >>
> >> Does it make sense to you?
> >>
> >> —
> >> Denis
> >>
> >>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com>
> wrote:
> >>>
> >>> 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 market and REST API is a single
> way
> >>> get access to Apache Ignite.
> >>>
> >>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <vozerov@gridgain.com
> >
> >>> wrote:
> >>>
> >>>> 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 <dm...@gridgain.com>
> >> wrote:
> >>>>
> >>>>> 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
> >>>>> version of REST API implementation before NodeJS component is done.
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> >>>>>
> >>>>> —
> >>>>> Denis
> >>>>>
> >>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
> >>>> wrote:
> >>>>>>
> >>>>>> 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 <
> >>>>> akuznetsov@gridgain.com>
> >>>>>> 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 we could break compatibility and redesign REST API
> from
> >>>>>>> scratch.
> >>>>>>>
> >>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> I would move it to 2.1 or 2.2.
> >>>>>>>>
> >>>>>>>> —
> >>>>>>>> Denis
> >>>>>>>>
> >>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> >>>> dsetrakyan@apache.org>
> >>>>>>>> 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, like 2.1?
> >>>>>>>>>
> >>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> >> skozlov@gridgain.com
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but
> probably
> >>>> we
> >>>>>>>> need
> >>>>>>>>>> to
> >>>>>>>>>> have a root ticket for that.
> >>>>>>>>>>
> >>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> >>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It
> >> is
> >>>>>>>>>>> definitely an important release for us and good supervision is
> >>>> going
> >>>>>>> to
> >>>>>>>>>> be
> >>>>>>>>>>> very helpful.
> >>>>>>>>>>>
> >>>>>>>>>>> I have looked at the tickets and the list seems nice. I would
> >> also
> >>>>>>> add
> >>>>>>>> a
> >>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as
> well,
> >>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to
> do
> >>>> it
> >>>>>>>> prior
> >>>>>>>>>>> to 2.0.
> >>>>>>>>>>>
> >>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >>>>>>>>>>>
> >>>>>>>>>>> D.
> >>>>>>>>>>>
> >>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <
> dmagda@gridgain.com
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Community,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite
> 2.0
> >>>> and
> >>>>>>>>>>>> coordinate the process.
> >>>>>>>>>>>>
> >>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
> >> released
> >>>>> by
> >>>>>>>>>> the
> >>>>>>>>>>>> end of the year. This sounds like a good practice to make a
> >> major
> >>>>>>>>>> release
> >>>>>>>>>>>> once a year. I would suggest us following the same rule.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Actual we have more than 3 month for development and I’ve
> >> prepare
> >>>>>>> the
> >>>>>>>>>>> wiki
> >>>>>>>>>>>> page that contains tickets that are required to be released in
> >>>> 2.0
> >>>>>>> and
> >>>>>>>>>>> that
> >>>>>>>>>>>> are optional
> >>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> >>>>>>> Apache+Ignite+2.0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Proposed release date is December 23rd, 2016.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The tickets that are required for the release basically break
> >> the
> >>>>>>>>>>>> compatibility and we postpone fixing them in minor release or
> >>>> they
> >>>>>>>>>> bring
> >>>>>>>>>>>> significant improvements into the product. Please review the
> >>>> page,
> >>>>>>>>>>> provide
> >>>>>>>>>>>> your comments and assign the tickets on yourself if you’re
> ready
> >>>> to
> >>>>>>>>>> work
> >>>>>>>>>>> on
> >>>>>>>>>>>> them.
> >>>>>>>>>>>>
> >>>>>>>>>>>> —
> >>>>>>>>>>>> Denis
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> >>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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 are in the same cache, it works, because there
> is
> >>>>>>> only
> >>>>>>>>>>> one
> >>>>>>>>>>>>> write-behind queue. Once we split different types into
> >> different
> >>>>>>>>>>> caches,
> >>>>>>>>>>>>> there is no guarantee that objects will be written in the
> >> proper
> >>>>>>>>>> order
> >>>>>>>>>>>> and
> >>>>>>>>>>>>> that the constraints will not be violated.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> However, I think this is not a very clean way to achieve the
> >>>>>>> result.
> >>>>>>>>>>>>> Probably we should just provide better support for this use
> >> case
> >>>>> in
> >>>>>>>>>>> 2.0.
> >>>>>>>>>>>>> Basically, we somehow need to allow to share a single
> >>>> write-behind
> >>>>>>>>>>> queue
> >>>>>>>>>>>>> between different caches.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Any thoughts?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Val
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> >>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>> iterate
> >>>>>>>>>>>>>> over
> >>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For
> >>>>>>>>>>> destroy/clear
> >>>>>>>>>>>>>>> caches belonging to same group we will do it by single
> >>>> operation
> >>>>>>>>>>>> without
> >>>>>>>>>>>>>>> knowledge of cache names.
> >>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
> >>>> inherited
> >>>>>>>>>> by a
> >>>>>>>>>>>>>> cache
> >>>>>>>>>>>>>>> created in that group (like eviction policy or cache mode).
> >>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
> >>>>>>> applicable
> >>>>>>>>>>> for
> >>>>>>>>>>>>>>> regular caches as well.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches,
> as
> >>>>>>>>>> proposed
> >>>>>>>>>>>> by
> >>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
> >>>> schemas
> >>>>>>> due
> >>>>>>>>>>> to
> >>>>>>>>>>>> too
> >>>>>>>>>>>>>> many different caches. I think Sergi proposed a good
> solution
> >>>> for
> >>>>>>>>>> it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> >>>>>>>>>>>>>> akuznetsov@gridgain.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> How grouping will help?
> >>>>>>>>>>>>>>>> To do some operation, for example, clear on group of
> cashes
> >>>> at
> >>>>>>>>>> once?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> >>>>>>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>>>> написал:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> >>>>>>> skozlov@gridgain.com
> >>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite
> >>>> 2.0?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Why?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support
> as
> >>>> of
> >>>>>>>>>>>>>>>>> **Spark**
> >>>>>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do
> >> we
> >>>>>>> know
> >>>>>>>>>>>>>>> what
> >>>>>>>>>>>>>>>>>> kind
> >>>>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still
> >>>> using
> >>>>>>>>>>>>>> 2.10?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>>>>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 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
> >>>> <
> >>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov
> <
> >>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>>>>>>>>>> block
> >>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
> >> discovery
> >>>>>>>>>>>>>>> event)
> >>>>>>>>>>>>>>>>>>> causing
> >>>>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
> >>>> Would
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> nice
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> assign
> >>>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all
> >> the
> >>>>>>>>>>>>>>>>> discussed
> >>>>>>>>>>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>> comes
> >>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track
> such
> >>>>>>>>>>>>>> tasks?
> >>>>>>>>>>>>>>>>>> Should
> >>>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something
> >>>> else?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Sergey Kozlov
> >>>>>>>>>> GridGain Systems
> >>>>>>>>>> www.gridgain.com
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Alexey Kuznetsov
> >>>>>>> GridGain Systems
> >>>>>>> www.gridgain.com
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Sergey Kozlov
> >>>>>> GridGain Systems
> >>>>>> www.gridgain.com
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sergey Kozlov
> >>> GridGain Systems
> >>> www.gridgain.com
> >>
> >>
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
>
>

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
I’ve created an umbrella ticket for REST
https://issues.apache.org/jira/browse/IGNITE-3879 <https://issues.apache.org/jira/browse/IGNITE-3879>

And I wouldn’t deprecate anything until the next version gets released ;)

—
Denis

> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> 
> 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 <dm...@gridgain.com> wrote:
> 
>> 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 generation
>> of REST API implementation.
>> 
>> Does it make sense to you?
>> 
>> —
>> Denis
>> 
>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
>>> 
>>> 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 market and REST API is a single way
>>> get access to Apache Ignite.
>>> 
>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <vo...@gridgain.com>
>>> wrote:
>>> 
>>>> 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 <dm...@gridgain.com>
>> wrote:
>>>> 
>>>>> 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
>>>>> version of REST API implementation before NodeJS component is done.
>>>>> 
>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
>>>>> 
>>>>> —
>>>>> Denis
>>>>> 
>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
>>>> wrote:
>>>>>> 
>>>>>> 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 <
>>>>> akuznetsov@gridgain.com>
>>>>>> 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 we could break compatibility and redesign REST API from
>>>>>>> scratch.
>>>>>>> 
>>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com>
>>>>> wrote:
>>>>>>> 
>>>>>>>> I would move it to 2.1 or 2.2.
>>>>>>>> 
>>>>>>>> —
>>>>>>>> Denis
>>>>>>>> 
>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
>>>> dsetrakyan@apache.org>
>>>>>>>> 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, like 2.1?
>>>>>>>>> 
>>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
>> skozlov@gridgain.com
>>>>> 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably
>>>> we
>>>>>>>> need
>>>>>>>>>> to
>>>>>>>>>> have a root ticket for that.
>>>>>>>>>> 
>>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
>>>>>>>> dsetrakyan@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It
>> is
>>>>>>>>>>> definitely an important release for us and good supervision is
>>>> going
>>>>>>> to
>>>>>>>>>> be
>>>>>>>>>>> very helpful.
>>>>>>>>>>> 
>>>>>>>>>>> I have looked at the tickets and the list seems nice. I would
>> also
>>>>>>> add
>>>>>>>> a
>>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as well,
>>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do
>>>> it
>>>>>>>> prior
>>>>>>>>>>> to 2.0.
>>>>>>>>>>> 
>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
>>>>>>>>>>> 
>>>>>>>>>>> D.
>>>>>>>>>>> 
>>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dmagda@gridgain.com
>>> 
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Community,
>>>>>>>>>>>> 
>>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite 2.0
>>>> and
>>>>>>>>>>>> coordinate the process.
>>>>>>>>>>>> 
>>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
>> released
>>>>> by
>>>>>>>>>> the
>>>>>>>>>>>> end of the year. This sounds like a good practice to make a
>> major
>>>>>>>>>> release
>>>>>>>>>>>> once a year. I would suggest us following the same rule.
>>>>>>>>>>>> 
>>>>>>>>>>>> Actual we have more than 3 month for development and I’ve
>> prepare
>>>>>>> the
>>>>>>>>>>> wiki
>>>>>>>>>>>> page that contains tickets that are required to be released in
>>>> 2.0
>>>>>>> and
>>>>>>>>>>> that
>>>>>>>>>>>> are optional
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
>>>>>>> Apache+Ignite+2.0
>>>>>>>>>>>> 
>>>>>>>>>>>> Proposed release date is December 23rd, 2016.
>>>>>>>>>>>> 
>>>>>>>>>>>> The tickets that are required for the release basically break
>> the
>>>>>>>>>>>> compatibility and we postpone fixing them in minor release or
>>>> they
>>>>>>>>>> bring
>>>>>>>>>>>> significant improvements into the product. Please review the
>>>> page,
>>>>>>>>>>> provide
>>>>>>>>>>>> your comments and assign the tickets on yourself if you’re ready
>>>> to
>>>>>>>>>> work
>>>>>>>>>>> on
>>>>>>>>>>>> them.
>>>>>>>>>>>> 
>>>>>>>>>>>> —
>>>>>>>>>>>> Denis
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
>>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 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 are in the same cache, it works, because there is
>>>>>>> only
>>>>>>>>>>> one
>>>>>>>>>>>>> write-behind queue. Once we split different types into
>> different
>>>>>>>>>>> caches,
>>>>>>>>>>>>> there is no guarantee that objects will be written in the
>> proper
>>>>>>>>>> order
>>>>>>>>>>>> and
>>>>>>>>>>>>> that the constraints will not be violated.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> However, I think this is not a very clean way to achieve the
>>>>>>> result.
>>>>>>>>>>>>> Probably we should just provide better support for this use
>> case
>>>>> in
>>>>>>>>>>> 2.0.
>>>>>>>>>>>>> Basically, we somehow need to allow to share a single
>>>> write-behind
>>>>>>>>>>> queue
>>>>>>>>>>>>> between different caches.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Any thoughts?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Val
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
>>>>>>>>>>>> dsetrakyan@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
>>>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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
>>>>>>>>>> iterate
>>>>>>>>>>>>>> over
>>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For
>>>>>>>>>>> destroy/clear
>>>>>>>>>>>>>>> caches belonging to same group we will do it by single
>>>> operation
>>>>>>>>>>>> without
>>>>>>>>>>>>>>> knowledge of cache names.
>>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
>>>> inherited
>>>>>>>>>> by a
>>>>>>>>>>>>>> cache
>>>>>>>>>>>>>>> created in that group (like eviction policy or cache mode).
>>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
>>>>>>> applicable
>>>>>>>>>>> for
>>>>>>>>>>>>>>> regular caches as well.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
>>>>>>>>>> proposed
>>>>>>>>>>>> by
>>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
>>>> schemas
>>>>>>> due
>>>>>>>>>>> to
>>>>>>>>>>>> too
>>>>>>>>>>>>>> many different caches. I think Sergi proposed a good solution
>>>> for
>>>>>>>>>> it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
>>>>>>>>>>>>>> akuznetsov@gridgain.com
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> How grouping will help?
>>>>>>>>>>>>>>>> To do some operation, for example, clear on group of cashes
>>>> at
>>>>>>>>>> once?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
>>>>>>>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>>>>>>> написал:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
>>>>>>> skozlov@gridgain.com
>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
>>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite
>>>> 2.0?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as
>>>> of
>>>>>>>>>>>>>>>>> **Spark**
>>>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do
>> we
>>>>>>> know
>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>> kind
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still
>>>> using
>>>>>>>>>>>>>> 2.10?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
>>>>>>>>>>>>>>>> dmagda@gridgain.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 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
>>>> <
>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
>> discovery
>>>>>>>>>>>>>>> event)
>>>>>>>>>>>>>>>>>>> causing
>>>>>>>>>>>>>>>>>>>>>>>>>> topology
>>>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
>>>> Would
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> nice
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> assign
>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all
>> the
>>>>>>>>>>>>>>>>> discussed
>>>>>>>>>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> comes
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
>>>>>>>>>>>>>> tasks?
>>>>>>>>>>>>>>>>>> Should
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something
>>>> else?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
>>>>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Sergey Kozlov
>>>>>>>>>> GridGain Systems
>>>>>>>>>> www.gridgain.com
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Alexey Kuznetsov
>>>>>>> GridGain Systems
>>>>>>> www.gridgain.com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sergey Kozlov
>>>>>> GridGain Systems
>>>>>> www.gridgain.com
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sergey Kozlov
>>> GridGain Systems
>>> www.gridgain.com
>> 
>> 
> 
> 
> -- 
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <dm...@gridgain.com> wrote:

> 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 generation
> of REST API implementation.
>
> Does it make sense to you?
>
> —
> Denis
>
> > On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> >
> > 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 market and REST API is a single way
> > get access to Apache Ignite.
> >
> > On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> >
> >> 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 <dm...@gridgain.com>
> wrote:
> >>
> >>> 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
> >>> version of REST API implementation before NodeJS component is done.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
> >> wrote:
> >>>>
> >>>> 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 <
> >>> akuznetsov@gridgain.com>
> >>>> 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 we could break compatibility and redesign REST API from
> >>>>> scratch.
> >>>>>
> >>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com>
> >>> wrote:
> >>>>>
> >>>>>> I would move it to 2.1 or 2.2.
> >>>>>>
> >>>>>> —
> >>>>>> Denis
> >>>>>>
> >>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> >> dsetrakyan@apache.org>
> >>>>>> 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, like 2.1?
> >>>>>>>
> >>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> skozlov@gridgain.com
> >>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably
> >> we
> >>>>>> need
> >>>>>>>> to
> >>>>>>>> have a root ticket for that.
> >>>>>>>>
> >>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> >>>>>> dsetrakyan@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It
> is
> >>>>>>>>> definitely an important release for us and good supervision is
> >> going
> >>>>> to
> >>>>>>>> be
> >>>>>>>>> very helpful.
> >>>>>>>>>
> >>>>>>>>> I have looked at the tickets and the list seems nice. I would
> also
> >>>>> add
> >>>>>> a
> >>>>>>>>> ticket about migration of the JTA dependency to Geronimo as well,
> >>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do
> >> it
> >>>>>> prior
> >>>>>>>>> to 2.0.
> >>>>>>>>>
> >>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >>>>>>>>>
> >>>>>>>>> D.
> >>>>>>>>>
> >>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dmagda@gridgain.com
> >
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Community,
> >>>>>>>>>>
> >>>>>>>>>> Let me take a role of the release manager for Apache Ignite 2.0
> >> and
> >>>>>>>>>> coordinate the process.
> >>>>>>>>>>
> >>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be
> released
> >>> by
> >>>>>>>> the
> >>>>>>>>>> end of the year. This sounds like a good practice to make a
> major
> >>>>>>>> release
> >>>>>>>>>> once a year. I would suggest us following the same rule.
> >>>>>>>>>>
> >>>>>>>>>> Actual we have more than 3 month for development and I’ve
> prepare
> >>>>> the
> >>>>>>>>> wiki
> >>>>>>>>>> page that contains tickets that are required to be released in
> >> 2.0
> >>>>> and
> >>>>>>>>> that
> >>>>>>>>>> are optional
> >>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> >>>>> Apache+Ignite+2.0
> >>>>>>>>>>
> >>>>>>>>>> Proposed release date is December 23rd, 2016.
> >>>>>>>>>>
> >>>>>>>>>> The tickets that are required for the release basically break
> the
> >>>>>>>>>> compatibility and we postpone fixing them in minor release or
> >> they
> >>>>>>>> bring
> >>>>>>>>>> significant improvements into the product. Please review the
> >> page,
> >>>>>>>>> provide
> >>>>>>>>>> your comments and assign the tickets on yourself if you’re ready
> >> to
> >>>>>>>> work
> >>>>>>>>> on
> >>>>>>>>>> them.
> >>>>>>>>>>
> >>>>>>>>>> —
> >>>>>>>>>> Denis
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> >>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> 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 are in the same cache, it works, because there is
> >>>>> only
> >>>>>>>>> one
> >>>>>>>>>>> write-behind queue. Once we split different types into
> different
> >>>>>>>>> caches,
> >>>>>>>>>>> there is no guarantee that objects will be written in the
> proper
> >>>>>>>> order
> >>>>>>>>>> and
> >>>>>>>>>>> that the constraints will not be violated.
> >>>>>>>>>>>
> >>>>>>>>>>> However, I think this is not a very clean way to achieve the
> >>>>> result.
> >>>>>>>>>>> Probably we should just provide better support for this use
> case
> >>> in
> >>>>>>>>> 2.0.
> >>>>>>>>>>> Basically, we somehow need to allow to share a single
> >> write-behind
> >>>>>>>>> queue
> >>>>>>>>>>> between different caches.
> >>>>>>>>>>>
> >>>>>>>>>>> Any thoughts?
> >>>>>>>>>>>
> >>>>>>>>>>> -Val
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> >>>>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> >>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>> iterate
> >>>>>>>>>>>> over
> >>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For
> >>>>>>>>> destroy/clear
> >>>>>>>>>>>>> caches belonging to same group we will do it by single
> >> operation
> >>>>>>>>>> without
> >>>>>>>>>>>>> knowledge of cache names.
> >>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
> >> inherited
> >>>>>>>> by a
> >>>>>>>>>>>> cache
> >>>>>>>>>>>>> created in that group (like eviction policy or cache mode).
> >>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
> >>>>> applicable
> >>>>>>>>> for
> >>>>>>>>>>>>> regular caches as well.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
> >>>>>>>> proposed
> >>>>>>>>>> by
> >>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
> >> schemas
> >>>>> due
> >>>>>>>>> to
> >>>>>>>>>> too
> >>>>>>>>>>>> many different caches. I think Sergi proposed a good solution
> >> for
> >>>>>>>> it.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> >>>>>>>>>>>> akuznetsov@gridgain.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> How grouping will help?
> >>>>>>>>>>>>>> To do some operation, for example, clear on group of cashes
> >> at
> >>>>>>>> once?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> >>>>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>> написал:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> >>>>> skozlov@gridgain.com
> >>>>>>>>> :
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite
> >> 2.0?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Why?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as
> >> of
> >>>>>>>>>>>>>>> **Spark**
> >>>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>> on **scala 2.11**.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do
> we
> >>>>> know
> >>>>>>>>>>>>> what
> >>>>>>>>>>>>>>>> kind
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still
> >> using
> >>>>>>>>>>>> 2.10?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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
> >> <
> >>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>>>>>>>> block
> >>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on
> discovery
> >>>>>>>>>>>>> event)
> >>>>>>>>>>>>>>>>> causing
> >>>>>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>>>>> hangings.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
> >> Would
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>> nice
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> assign
> >>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all
> the
> >>>>>>>>>>>>>>> discussed
> >>>>>>>>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>> comes
> >>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
> >>>>>>>>>>>> tasks?
> >>>>>>>>>>>>>>>> Should
> >>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something
> >> else?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> --AG
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Sergey Kozlov
> >>>>>>>> GridGain Systems
> >>>>>>>> www.gridgain.com
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Alexey Kuznetsov
> >>>>> GridGain Systems
> >>>>> www.gridgain.com
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sergey Kozlov
> >>>> GridGain Systems
> >>>> www.gridgain.com
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
>
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
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 generation of REST API implementation.

Does it make sense to you?

—
Denis
 
> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> 
> 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 market and REST API is a single way
> get access to Apache Ignite.
> 
> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
> 
>> 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 <dm...@gridgain.com> wrote:
>> 
>>> 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
>>> version of REST API implementation before NodeJS component is done.
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
>>> 
>>> —
>>> Denis
>>> 
>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
>> wrote:
>>>> 
>>>> 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 <
>>> akuznetsov@gridgain.com>
>>>> 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 we could break compatibility and redesign REST API from
>>>>> scratch.
>>>>> 
>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com>
>>> wrote:
>>>>> 
>>>>>> I would move it to 2.1 or 2.2.
>>>>>> 
>>>>>> —
>>>>>> Denis
>>>>>> 
>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
>> dsetrakyan@apache.org>
>>>>>> 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, like 2.1?
>>>>>>> 
>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <skozlov@gridgain.com
>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> 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
>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably
>> we
>>>>>> need
>>>>>>>> to
>>>>>>>> have a root ticket for that.
>>>>>>>> 
>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
>>>>>> dsetrakyan@apache.org>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It is
>>>>>>>>> definitely an important release for us and good supervision is
>> going
>>>>> to
>>>>>>>> be
>>>>>>>>> very helpful.
>>>>>>>>> 
>>>>>>>>> I have looked at the tickets and the list seems nice. I would also
>>>>> add
>>>>>> a
>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as well,
>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do
>> it
>>>>>> prior
>>>>>>>>> to 2.0.
>>>>>>>>> 
>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
>>>>>>>>> 
>>>>>>>>> D.
>>>>>>>>> 
>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Community,
>>>>>>>>>> 
>>>>>>>>>> Let me take a role of the release manager for Apache Ignite 2.0
>> and
>>>>>>>>>> coordinate the process.
>>>>>>>>>> 
>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be released
>>> by
>>>>>>>> the
>>>>>>>>>> end of the year. This sounds like a good practice to make a major
>>>>>>>> release
>>>>>>>>>> once a year. I would suggest us following the same rule.
>>>>>>>>>> 
>>>>>>>>>> Actual we have more than 3 month for development and I’ve prepare
>>>>> the
>>>>>>>>> wiki
>>>>>>>>>> page that contains tickets that are required to be released in
>> 2.0
>>>>> and
>>>>>>>>> that
>>>>>>>>>> are optional
>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
>>>>> Apache+Ignite+2.0
>>>>>>>>>> 
>>>>>>>>>> Proposed release date is December 23rd, 2016.
>>>>>>>>>> 
>>>>>>>>>> The tickets that are required for the release basically break the
>>>>>>>>>> compatibility and we postpone fixing them in minor release or
>> they
>>>>>>>> bring
>>>>>>>>>> significant improvements into the product. Please review the
>> page,
>>>>>>>>> provide
>>>>>>>>>> your comments and assign the tickets on yourself if you’re ready
>> to
>>>>>>>> work
>>>>>>>>> on
>>>>>>>>>> them.
>>>>>>>>>> 
>>>>>>>>>> —
>>>>>>>>>> Denis
>>>>>>>>>> 
>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 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 are in the same cache, it works, because there is
>>>>> only
>>>>>>>>> one
>>>>>>>>>>> write-behind queue. Once we split different types into different
>>>>>>>>> caches,
>>>>>>>>>>> there is no guarantee that objects will be written in the proper
>>>>>>>> order
>>>>>>>>>> and
>>>>>>>>>>> that the constraints will not be violated.
>>>>>>>>>>> 
>>>>>>>>>>> However, I think this is not a very clean way to achieve the
>>>>> result.
>>>>>>>>>>> Probably we should just provide better support for this use case
>>> in
>>>>>>>>> 2.0.
>>>>>>>>>>> Basically, we somehow need to allow to share a single
>> write-behind
>>>>>>>>> queue
>>>>>>>>>>> between different caches.
>>>>>>>>>>> 
>>>>>>>>>>> Any thoughts?
>>>>>>>>>>> 
>>>>>>>>>>> -Val
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
>>>>>>>>>> dsetrakyan@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 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
>>>>>>>> iterate
>>>>>>>>>>>> over
>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For
>>>>>>>>> destroy/clear
>>>>>>>>>>>>> caches belonging to same group we will do it by single
>> operation
>>>>>>>>>> without
>>>>>>>>>>>>> knowledge of cache names.
>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be
>> inherited
>>>>>>>> by a
>>>>>>>>>>>> cache
>>>>>>>>>>>>> created in that group (like eviction policy or cache mode).
>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
>>>>> applicable
>>>>>>>>> for
>>>>>>>>>>>>> regular caches as well.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
>>>>>>>> proposed
>>>>>>>>>> by
>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL
>> schemas
>>>>> due
>>>>>>>>> to
>>>>>>>>>> too
>>>>>>>>>>>> many different caches. I think Sergi proposed a good solution
>> for
>>>>>>>> it.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
>>>>>>>>>>>> akuznetsov@gridgain.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> How grouping will help?
>>>>>>>>>>>>>> To do some operation, for example, clear on group of cashes
>> at
>>>>>>>> once?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
>>>>>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>>>>> написал:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> sergi.vladykin@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
>>>>> skozlov@gridgain.com
>>>>>>>>> :
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite
>> 2.0?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as
>> of
>>>>>>>>>>>>>>> **Spark**
>>>>>>>>>>>>>>>> 2
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> on **scala 2.11**.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do we
>>>>> know
>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>> kind
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still
>> using
>>>>>>>>>>>> 2.10?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
>>>>>>>>>>>>>> dmagda@gridgain.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 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
>> <
>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
>>>>>>>>>>>>> event)
>>>>>>>>>>>>>>>>> causing
>>>>>>>>>>>>>>>>>>>>>>>> topology
>>>>>>>>>>>>>>>>>>>>>>>>> hangings.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
>> Would
>>>>>>>>>>>> be
>>>>>>>>>>>>>> nice
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> assign
>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
>>>>>>>>>>>>>>> discussed
>>>>>>>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>> comes
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> next major version release.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
>>>>>>>>>>>> tasks?
>>>>>>>>>>>>>>>> Should
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something
>> else?
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> --AG
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
>>>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Sergey Kozlov
>>>>>>>> GridGain Systems
>>>>>>>> www.gridgain.com
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Alexey Kuznetsov
>>>>> GridGain Systems
>>>>> www.gridgain.com
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Sergey Kozlov
>>>> GridGain Systems
>>>> www.gridgain.com
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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 market and REST API is a single way
get access to Apache Ignite.

On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:

> 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 <dm...@gridgain.com> wrote:
>
> > 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
> > version of REST API implementation before NodeJS component is done.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-961
> >
> > —
> > Denis
> >
> > > On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com>
> wrote:
> > >
> > > 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 <
> > akuznetsov@gridgain.com>
> > > 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 we could break compatibility and redesign REST API from
> > >> scratch.
> > >>
> > >> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com>
> > wrote:
> > >>
> > >>> I would move it to 2.1 or 2.2.
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> > >>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > >>> 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, like 2.1?
> > >>>>
> > >>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <skozlov@gridgain.com
> >
> > >>> wrote:
> > >>>>
> > >>>>> 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
> > >>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably
> we
> > >>> need
> > >>>>> to
> > >>>>> have a root ticket for that.
> > >>>>>
> > >>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> > >>> dsetrakyan@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Denis, thanks for taking a role of a release manger for 2.0. It is
> > >>>>>> definitely an important release for us and good supervision is
> going
> > >> to
> > >>>>> be
> > >>>>>> very helpful.
> > >>>>>>
> > >>>>>> I have looked at the tickets and the list seems nice. I would also
> > >> add
> > >>> a
> > >>>>>> ticket about migration of the JTA dependency to Geronimo as well,
> > >>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do
> it
> > >>> prior
> > >>>>>> to 2.0.
> > >>>>>>
> > >>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> > >>>>>>
> > >>>>>> D.
> > >>>>>>
> > >>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> Community,
> > >>>>>>>
> > >>>>>>> Let me take a role of the release manager for Apache Ignite 2.0
> and
> > >>>>>>> coordinate the process.
> > >>>>>>>
> > >>>>>>> So, my personal view is that Apache Ignite 2.0 should be released
> > by
> > >>>>> the
> > >>>>>>> end of the year. This sounds like a good practice to make a major
> > >>>>> release
> > >>>>>>> once a year. I would suggest us following the same rule.
> > >>>>>>>
> > >>>>>>> Actual we have more than 3 month for development and I’ve prepare
> > >> the
> > >>>>>> wiki
> > >>>>>>> page that contains tickets that are required to be released in
> 2.0
> > >> and
> > >>>>>> that
> > >>>>>>> are optional
> > >>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> > >> Apache+Ignite+2.0
> > >>>>>>>
> > >>>>>>> Proposed release date is December 23rd, 2016.
> > >>>>>>>
> > >>>>>>> The tickets that are required for the release basically break the
> > >>>>>>> compatibility and we postpone fixing them in minor release or
> they
> > >>>>> bring
> > >>>>>>> significant improvements into the product. Please review the
> page,
> > >>>>>> provide
> > >>>>>>> your comments and assign the tickets on yourself if you’re ready
> to
> > >>>>> work
> > >>>>>> on
> > >>>>>>> them.
> > >>>>>>>
> > >>>>>>> —
> > >>>>>>> Denis
> > >>>>>>>
> > >>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > >>>>>>> valentin.kulichenko@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> 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 are in the same cache, it works, because there is
> > >> only
> > >>>>>> one
> > >>>>>>>> write-behind queue. Once we split different types into different
> > >>>>>> caches,
> > >>>>>>>> there is no guarantee that objects will be written in the proper
> > >>>>> order
> > >>>>>>> and
> > >>>>>>>> that the constraints will not be violated.
> > >>>>>>>>
> > >>>>>>>> However, I think this is not a very clean way to achieve the
> > >> result.
> > >>>>>>>> Probably we should just provide better support for this use case
> > in
> > >>>>>> 2.0.
> > >>>>>>>> Basically, we somehow need to allow to share a single
> write-behind
> > >>>>>> queue
> > >>>>>>>> between different caches.
> > >>>>>>>>
> > >>>>>>>> Any thoughts?
> > >>>>>>>>
> > >>>>>>>> -Val
> > >>>>>>>>
> > >>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > >>>>>>> dsetrakyan@apache.org>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> > >>>>> skozlov@gridgain.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>> iterate
> > >>>>>>>>> over
> > >>>>>>>>>> caches but I'm not sure that it is supported by API). For
> > >>>>>> destroy/clear
> > >>>>>>>>>> caches belonging to same group we will do it by single
> operation
> > >>>>>>> without
> > >>>>>>>>>> knowledge of cache names.
> > >>>>>>>>>> 3. Cache group can have cache attributes which will be
> inherited
> > >>>>> by a
> > >>>>>>>>> cache
> > >>>>>>>>>> created in that group (like eviction policy or cache mode).
> > >>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
> > >> applicable
> > >>>>>> for
> > >>>>>>>>>> regular caches as well.
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
> > >>>>> proposed
> > >>>>>>> by
> > >>>>>>>>> Sergi, solves a different problem of having too many SQL
> schemas
> > >> due
> > >>>>>> to
> > >>>>>>> too
> > >>>>>>>>> many different caches. I think Sergi proposed a good solution
> for
> > >>>>> it.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > >>>>>>>>> akuznetsov@gridgain.com
> > >>>>>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
> > >>>>>>>>>>>
> > >>>>>>>>>>> How grouping will help?
> > >>>>>>>>>>> To do some operation, for example, clear on group of cashes
> at
> > >>>>> once?
> > >>>>>>>>>>>
> > >>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > >>>>>>>>> skozlov@gridgain.com>
> > >>>>>>>>>>> написал:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> 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 <
> > >>>>>>>>>>> sergi.vladykin@gmail.com>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> > >> skozlov@gridgain.com
> > >>>>>> :
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > >>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > >>>>>>>>>>>>>> akuznetsov@gridgain.com>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite
> 2.0?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Why?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as
> of
> > >>>>>>>>>>>> **Spark**
> > >>>>>>>>>>>>> 2
> > >>>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>> on **scala 2.11**.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do we
> > >> know
> > >>>>>>>>>> what
> > >>>>>>>>>>>>> kind
> > >>>>>>>>>>>>>> of
> > >>>>>>>>>>>>>>> impact will it have on the community? Anyone is still
> using
> > >>>>>>>>> 2.10?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > >>>>>>>>>>> dmagda@gridgain.com>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 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
> <
> > >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> —
> > >>>>>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > >>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > >>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > >>>>>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>> may
> > >>>>>>>>>>>>>>>>>>>>> block
> > >>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> > >>>>>>>>>> event)
> > >>>>>>>>>>>>>> causing
> > >>>>>>>>>>>>>>>>>>>>> topology
> > >>>>>>>>>>>>>>>>>>>>>> hangings.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added.
> Would
> > >>>>>>>>> be
> > >>>>>>>>>>> nice
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>> assign
> > >>>>>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> > >>>>>>>>>>>> discussed
> > >>>>>>>>>>>>>>>> features
> > >>>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>>> the Wiki.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> --Yakov
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > >>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> > >>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>>> comes
> > >>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>> next major version release.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
> > >>>>>>>>> tasks?
> > >>>>>>>>>>>>> Should
> > >>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>> be a
> > >>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something
> else?
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> --AG
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>> Alexey Kuznetsov
> > >>>>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>> GridGain Systems
> > >>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Sergey Kozlov
> > >>>>> GridGain Systems
> > >>>>> www.gridgain.com
> > >>>>>
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Alexey Kuznetsov
> > >> GridGain Systems
> > >> www.gridgain.com
> > >>
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> >
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <dm...@gridgain.com> wrote:

> 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
> version of REST API implementation before NodeJS component is done.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-961
>
> —
> Denis
>
> > On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> >
> > 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 <
> akuznetsov@gridgain.com>
> > 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 we could break compatibility and redesign REST API from
> >> scratch.
> >>
> >> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com>
> wrote:
> >>
> >>> I would move it to 2.1 or 2.2.
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@apache.org>
> >>> 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, like 2.1?
> >>>>
> >>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <sk...@gridgain.com>
> >>> wrote:
> >>>>
> >>>>> 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
> >>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we
> >>> need
> >>>>> to
> >>>>> have a root ticket for that.
> >>>>>
> >>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> >>> dsetrakyan@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> Denis, thanks for taking a role of a release manger for 2.0. It is
> >>>>>> definitely an important release for us and good supervision is going
> >> to
> >>>>> be
> >>>>>> very helpful.
> >>>>>>
> >>>>>> I have looked at the tickets and the list seems nice. I would also
> >> add
> >>> a
> >>>>>> ticket about migration of the JTA dependency to Geronimo as well,
> >>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do it
> >>> prior
> >>>>>> to 2.0.
> >>>>>>
> >>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >>>>>>
> >>>>>> D.
> >>>>>>
> >>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com>
> >>> wrote:
> >>>>>>
> >>>>>>> Community,
> >>>>>>>
> >>>>>>> Let me take a role of the release manager for Apache Ignite 2.0 and
> >>>>>>> coordinate the process.
> >>>>>>>
> >>>>>>> So, my personal view is that Apache Ignite 2.0 should be released
> by
> >>>>> the
> >>>>>>> end of the year. This sounds like a good practice to make a major
> >>>>> release
> >>>>>>> once a year. I would suggest us following the same rule.
> >>>>>>>
> >>>>>>> Actual we have more than 3 month for development and I’ve prepare
> >> the
> >>>>>> wiki
> >>>>>>> page that contains tickets that are required to be released in 2.0
> >> and
> >>>>>> that
> >>>>>>> are optional
> >>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> >> Apache+Ignite+2.0
> >>>>>>>
> >>>>>>> Proposed release date is December 23rd, 2016.
> >>>>>>>
> >>>>>>> The tickets that are required for the release basically break the
> >>>>>>> compatibility and we postpone fixing them in minor release or they
> >>>>> bring
> >>>>>>> significant improvements into the product. Please review the page,
> >>>>>> provide
> >>>>>>> your comments and assign the tickets on yourself if you’re ready to
> >>>>> work
> >>>>>> on
> >>>>>>> them.
> >>>>>>>
> >>>>>>> —
> >>>>>>> Denis
> >>>>>>>
> >>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> >>>>>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> 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 are in the same cache, it works, because there is
> >> only
> >>>>>> one
> >>>>>>>> write-behind queue. Once we split different types into different
> >>>>>> caches,
> >>>>>>>> there is no guarantee that objects will be written in the proper
> >>>>> order
> >>>>>>> and
> >>>>>>>> that the constraints will not be violated.
> >>>>>>>>
> >>>>>>>> However, I think this is not a very clean way to achieve the
> >> result.
> >>>>>>>> Probably we should just provide better support for this use case
> in
> >>>>>> 2.0.
> >>>>>>>> Basically, we somehow need to allow to share a single write-behind
> >>>>>> queue
> >>>>>>>> between different caches.
> >>>>>>>>
> >>>>>>>> Any thoughts?
> >>>>>>>>
> >>>>>>>> -Val
> >>>>>>>>
> >>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> >>>>>>> dsetrakyan@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> >>>>> skozlov@gridgain.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> 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
> >>>>> iterate
> >>>>>>>>> over
> >>>>>>>>>> caches but I'm not sure that it is supported by API). For
> >>>>>> destroy/clear
> >>>>>>>>>> caches belonging to same group we will do it by single operation
> >>>>>>> without
> >>>>>>>>>> knowledge of cache names.
> >>>>>>>>>> 3. Cache group can have cache attributes which will be inherited
> >>>>> by a
> >>>>>>>>> cache
> >>>>>>>>>> created in that group (like eviction policy or cache mode).
> >>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
> >> applicable
> >>>>>> for
> >>>>>>>>>> regular caches as well.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
> >>>>> proposed
> >>>>>>> by
> >>>>>>>>> Sergi, solves a different problem of having too many SQL schemas
> >> due
> >>>>>> to
> >>>>>>> too
> >>>>>>>>> many different caches. I think Sergi proposed a good solution for
> >>>>> it.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> >>>>>>>>> akuznetsov@gridgain.com
> >>>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
> >>>>>>>>>>>
> >>>>>>>>>>> How grouping will help?
> >>>>>>>>>>> To do some operation, for example, clear on group of cashes at
> >>>>> once?
> >>>>>>>>>>>
> >>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> >>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>> написал:
> >>>>>>>>>>>
> >>>>>>>>>>>> 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 <
> >>>>>>>>>>> sergi.vladykin@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> >> skozlov@gridgain.com
> >>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Why?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
> >>>>>>>>>>>> **Spark**
> >>>>>>>>>>>>> 2
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> on **scala 2.11**.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do we
> >> know
> >>>>>>>>>> what
> >>>>>>>>>>>>> kind
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>> impact will it have on the community? Anyone is still using
> >>>>>>>>> 2.10?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>>>>> block
> >>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> >>>>>>>>>> event)
> >>>>>>>>>>>>>> causing
> >>>>>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>>>>> hangings.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
> >>>>>>>>> be
> >>>>>>>>>>> nice
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> assign
> >>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> >>>>>>>>>>>> discussed
> >>>>>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>> comes
> >>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> next major version release.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
> >>>>>>>>> tasks?
> >>>>>>>>>>>>> Should
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> --AG
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Sergey Kozlov
> >>>>>>>>>> GridGain Systems
> >>>>>>>>>> www.gridgain.com
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Sergey Kozlov
> >>>>> GridGain Systems
> >>>>> www.gridgain.com
> >>>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Alexey Kuznetsov
> >> GridGain Systems
> >> www.gridgain.com
> >>
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
>
>

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
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 version of REST API implementation before NodeJS component is done.

[1] https://issues.apache.org/jira/browse/IGNITE-961

—
Denis

> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> 
> 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 <ak...@gridgain.com>
> 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 we could break compatibility and redesign REST API from
>> scratch.
>> 
>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com> wrote:
>> 
>>> I would move it to 2.1 or 2.2.
>>> 
>>> —
>>> Denis
>>> 
>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@apache.org>
>>> 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, like 2.1?
>>>> 
>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <sk...@gridgain.com>
>>> wrote:
>>>> 
>>>>> 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
>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we
>>> need
>>>>> to
>>>>> have a root ticket for that.
>>>>> 
>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
>>> dsetrakyan@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It is
>>>>>> definitely an important release for us and good supervision is going
>> to
>>>>> be
>>>>>> very helpful.
>>>>>> 
>>>>>> I have looked at the tickets and the list seems nice. I would also
>> add
>>> a
>>>>>> ticket about migration of the JTA dependency to Geronimo as well,
>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do it
>>> prior
>>>>>> to 2.0.
>>>>>> 
>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
>>>>>> 
>>>>>> D.
>>>>>> 
>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com>
>>> wrote:
>>>>>> 
>>>>>>> Community,
>>>>>>> 
>>>>>>> Let me take a role of the release manager for Apache Ignite 2.0 and
>>>>>>> coordinate the process.
>>>>>>> 
>>>>>>> So, my personal view is that Apache Ignite 2.0 should be released by
>>>>> the
>>>>>>> end of the year. This sounds like a good practice to make a major
>>>>> release
>>>>>>> once a year. I would suggest us following the same rule.
>>>>>>> 
>>>>>>> Actual we have more than 3 month for development and I’ve prepare
>> the
>>>>>> wiki
>>>>>>> page that contains tickets that are required to be released in 2.0
>> and
>>>>>> that
>>>>>>> are optional
>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
>> Apache+Ignite+2.0
>>>>>>> 
>>>>>>> Proposed release date is December 23rd, 2016.
>>>>>>> 
>>>>>>> The tickets that are required for the release basically break the
>>>>>>> compatibility and we postpone fixing them in minor release or they
>>>>> bring
>>>>>>> significant improvements into the product. Please review the page,
>>>>>> provide
>>>>>>> your comments and assign the tickets on yourself if you’re ready to
>>>>> work
>>>>>> on
>>>>>>> them.
>>>>>>> 
>>>>>>> —
>>>>>>> Denis
>>>>>>> 
>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
>>>>>>> valentin.kulichenko@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> 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 are in the same cache, it works, because there is
>> only
>>>>>> one
>>>>>>>> write-behind queue. Once we split different types into different
>>>>>> caches,
>>>>>>>> there is no guarantee that objects will be written in the proper
>>>>> order
>>>>>>> and
>>>>>>>> that the constraints will not be violated.
>>>>>>>> 
>>>>>>>> However, I think this is not a very clean way to achieve the
>> result.
>>>>>>>> Probably we should just provide better support for this use case in
>>>>>> 2.0.
>>>>>>>> Basically, we somehow need to allow to share a single write-behind
>>>>>> queue
>>>>>>>> between different caches.
>>>>>>>> 
>>>>>>>> Any thoughts?
>>>>>>>> 
>>>>>>>> -Val
>>>>>>>> 
>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
>>>>>>> dsetrakyan@apache.org>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
>>>>> skozlov@gridgain.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 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
>>>>> iterate
>>>>>>>>> over
>>>>>>>>>> caches but I'm not sure that it is supported by API). For
>>>>>> destroy/clear
>>>>>>>>>> caches belonging to same group we will do it by single operation
>>>>>>> without
>>>>>>>>>> knowledge of cache names.
>>>>>>>>>> 3. Cache group can have cache attributes which will be inherited
>>>>> by a
>>>>>>>>> cache
>>>>>>>>>> created in that group (like eviction policy or cache mode).
>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it
>> applicable
>>>>>> for
>>>>>>>>>> regular caches as well.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
>>>>> proposed
>>>>>>> by
>>>>>>>>> Sergi, solves a different problem of having too many SQL schemas
>> due
>>>>>> to
>>>>>>> too
>>>>>>>>> many different caches. I think Sergi proposed a good solution for
>>>>> it.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
>>>>>>>>> akuznetsov@gridgain.com
>>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
>>>>>>>>>>> 
>>>>>>>>>>> How grouping will help?
>>>>>>>>>>> To do some operation, for example, clear on group of cashes at
>>>>> once?
>>>>>>>>>>> 
>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
>>>>>>>>> skozlov@gridgain.com>
>>>>>>>>>>> написал:
>>>>>>>>>>> 
>>>>>>>>>>>> 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 <
>>>>>>>>>>> sergi.vladykin@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
>> skozlov@gridgain.com
>>>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
>>>>>>>>>>>>>> akuznetsov@gridgain.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
>>>>>>>>>>>> **Spark**
>>>>>>>>>>>>> 2
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> on **scala 2.11**.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do we
>> know
>>>>>>>>>> what
>>>>>>>>>>>>> kind
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still using
>>>>>>>>> 2.10?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
>>>>>>>>>>> dmagda@gridgain.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> —
>>>>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
>>>>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
>>>>>>>>>> event)
>>>>>>>>>>>>>> causing
>>>>>>>>>>>>>>>>>>>>> topology
>>>>>>>>>>>>>>>>>>>>>> hangings.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
>>>>>>>>> be
>>>>>>>>>>> nice
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> assign
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
>>>>>>>>>>>> discussed
>>>>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> --Yakov
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>>>>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
>>>>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> comes
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> next major version release.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
>>>>>>>>> tasks?
>>>>>>>>>>>>> Should
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> --AG
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Alexey Kuznetsov
>>>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Sergey Kozlov
>>>>>>>>>> GridGain Systems
>>>>>>>>>> www.gridgain.com
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sergey Kozlov
>>>>> GridGain Systems
>>>>> www.gridgain.com
>>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Alexey Kuznetsov
>> GridGain Systems
>> www.gridgain.com
>> 
> 
> 
> 
> -- 
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <ak...@gridgain.com>
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 we could break compatibility and redesign REST API from
> scratch.
>
> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dm...@gridgain.com> wrote:
>
> > I would move it to 2.1 or 2.2.
> >
> > —
> > Denis
> >
> > > On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@apache.org>
> > 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, like 2.1?
> > >
> > > On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <sk...@gridgain.com>
> > wrote:
> > >
> > >> 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
> > >> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we
> > need
> > >> to
> > >> have a root ticket for that.
> > >>
> > >> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > >> wrote:
> > >>
> > >>> Denis, thanks for taking a role of a release manger for 2.0. It is
> > >>> definitely an important release for us and good supervision is going
> to
> > >> be
> > >>> very helpful.
> > >>>
> > >>> I have looked at the tickets and the list seems nice. I would also
> add
> > a
> > >>> ticket about migration of the JTA dependency to Geronimo as well,
> > >>> IGNITE-3793 [1], however I am not sure if we might be able to do it
> > prior
> > >>> to 2.0.
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> > >>>
> > >>> D.
> > >>>
> > >>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com>
> > wrote:
> > >>>
> > >>>> Community,
> > >>>>
> > >>>> Let me take a role of the release manager for Apache Ignite 2.0 and
> > >>>> coordinate the process.
> > >>>>
> > >>>> So, my personal view is that Apache Ignite 2.0 should be released by
> > >> the
> > >>>> end of the year. This sounds like a good practice to make a major
> > >> release
> > >>>> once a year. I would suggest us following the same rule.
> > >>>>
> > >>>> Actual we have more than 3 month for development and I’ve prepare
> the
> > >>> wiki
> > >>>> page that contains tickets that are required to be released in 2.0
> and
> > >>> that
> > >>>> are optional
> > >>>> https://cwiki.apache.org/confluence/display/IGNITE/
> Apache+Ignite+2.0
> > >>>>
> > >>>> Proposed release date is December 23rd, 2016.
> > >>>>
> > >>>> The tickets that are required for the release basically break the
> > >>>> compatibility and we postpone fixing them in minor release or they
> > >> bring
> > >>>> significant improvements into the product. Please review the page,
> > >>> provide
> > >>>> your comments and assign the tickets on yourself if you’re ready to
> > >> work
> > >>> on
> > >>>> them.
> > >>>>
> > >>>> —
> > >>>> Denis
> > >>>>
> > >>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > >>>> valentin.kulichenko@gmail.com> wrote:
> > >>>>>
> > >>>>> 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 are in the same cache, it works, because there is
> only
> > >>> one
> > >>>>> write-behind queue. Once we split different types into different
> > >>> caches,
> > >>>>> there is no guarantee that objects will be written in the proper
> > >> order
> > >>>> and
> > >>>>> that the constraints will not be violated.
> > >>>>>
> > >>>>> However, I think this is not a very clean way to achieve the
> result.
> > >>>>> Probably we should just provide better support for this use case in
> > >>> 2.0.
> > >>>>> Basically, we somehow need to allow to share a single write-behind
> > >>> queue
> > >>>>> between different caches.
> > >>>>>
> > >>>>> Any thoughts?
> > >>>>>
> > >>>>> -Val
> > >>>>>
> > >>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > >>>> dsetrakyan@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> > >> skozlov@gridgain.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> 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
> > >> iterate
> > >>>>>> over
> > >>>>>>> caches but I'm not sure that it is supported by API). For
> > >>> destroy/clear
> > >>>>>>> caches belonging to same group we will do it by single operation
> > >>>> without
> > >>>>>>> knowledge of cache names.
> > >>>>>>> 3. Cache group can have cache attributes which will be inherited
> > >> by a
> > >>>>>> cache
> > >>>>>>> created in that group (like eviction policy or cache mode).
> > >>>>>>> 4. No reason to add specific feature like SqlShema if it
> applicable
> > >>> for
> > >>>>>>> regular caches as well.
> > >>>>>>>
> > >>>>>>
> > >>>>>> Sergey K, setting the same SQL schema for multiple caches, as
> > >> proposed
> > >>>> by
> > >>>>>> Sergi, solves a different problem of having too many SQL schemas
> due
> > >>> to
> > >>>> too
> > >>>>>> many different caches. I think Sergi proposed a good solution for
> > >> it.
> > >>>>>>
> > >>>>>>
> > >>>>>>>
> > >>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > >>>>>> akuznetsov@gridgain.com
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
> > >>>>>>>>
> > >>>>>>>> How grouping will help?
> > >>>>>>>> To do some operation, for example, clear on group of cashes at
> > >> once?
> > >>>>>>>>
> > >>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > >>>>>> skozlov@gridgain.com>
> > >>>>>>>> написал:
> > >>>>>>>>
> > >>>>>>>>> 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 <
> > >>>>>>>> sergi.vladykin@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> 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
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <
> skozlov@gridgain.com
> > >>> :
> > >>>>>>>>>>
> > >>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > >>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > >>>>>>>>>>> akuznetsov@gridgain.com>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> I remember couple more thing for 2.0
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Why?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
> > >>>>>>>>> **Spark**
> > >>>>>>>>>> 2
> > >>>>>>>>>>> is
> > >>>>>>>>>>>>> on **scala 2.11**.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I would drop it only if it is difficult to support. Do we
> know
> > >>>>>>> what
> > >>>>>>>>>> kind
> > >>>>>>>>>>> of
> > >>>>>>>>>>>> impact will it have on the community? Anyone is still using
> > >>>>>> 2.10?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > >>>>>>>> dmagda@gridgain.com>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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 <
> > >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> —
> > >>>>>>>>>>>>>> Denis
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > >>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > >>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > >>>>>>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>> may
> > >>>>>>>>>>>>>>>>>> block
> > >>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> > >>>>>>> event)
> > >>>>>>>>>>> causing
> > >>>>>>>>>>>>>>>>>> topology
> > >>>>>>>>>>>>>>>>>>> hangings.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
> > >>>>>> be
> > >>>>>>>> nice
> > >>>>>>>>>> to
> > >>>>>>>>>>>>> assign
> > >>>>>>>>>>>>>>>> a
> > >>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> > >>>>>>>>> discussed
> > >>>>>>>>>>>>> features
> > >>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>> the Wiki.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> --Yakov
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > >>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> > >>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>> comes
> > >>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>> next major version release.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
> > >>>>>> tasks?
> > >>>>>>>>>> Should
> > >>>>>>>>>>> it
> > >>>>>>>>>>>>>>>> be a
> > >>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> --AG
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>>> Alexey Kuznetsov
> > >>>>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> Sergey Kozlov
> > >>>>>>>>>>> GridGain Systems
> > >>>>>>>>>>> www.gridgain.com
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Sergey Kozlov
> > >>>>>>>>> GridGain Systems
> > >>>>>>>>> www.gridgain.com
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Sergey Kozlov
> > >>>>>>> GridGain Systems
> > >>>>>>> www.gridgain.com
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Sergey Kozlov
> > >> GridGain Systems
> > >> www.gridgain.com
> > >>
> >
> >
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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 <dm...@gridgain.com> wrote:

> I would move it to 2.1 or 2.2.
>
> —
> Denis
>
> > On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@apache.org>
> 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, like 2.1?
> >
> > On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <sk...@gridgain.com>
> wrote:
> >
> >> 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
> >> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we
> need
> >> to
> >> have a root ticket for that.
> >>
> >> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> >> wrote:
> >>
> >>> Denis, thanks for taking a role of a release manger for 2.0. It is
> >>> definitely an important release for us and good supervision is going to
> >> be
> >>> very helpful.
> >>>
> >>> I have looked at the tickets and the list seems nice. I would also add
> a
> >>> ticket about migration of the JTA dependency to Geronimo as well,
> >>> IGNITE-3793 [1], however I am not sure if we might be able to do it
> prior
> >>> to 2.0.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >>>
> >>> D.
> >>>
> >>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com>
> wrote:
> >>>
> >>>> Community,
> >>>>
> >>>> Let me take a role of the release manager for Apache Ignite 2.0 and
> >>>> coordinate the process.
> >>>>
> >>>> So, my personal view is that Apache Ignite 2.0 should be released by
> >> the
> >>>> end of the year. This sounds like a good practice to make a major
> >> release
> >>>> once a year. I would suggest us following the same rule.
> >>>>
> >>>> Actual we have more than 3 month for development and I’ve prepare the
> >>> wiki
> >>>> page that contains tickets that are required to be released in 2.0 and
> >>> that
> >>>> are optional
> >>>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
> >>>>
> >>>> Proposed release date is December 23rd, 2016.
> >>>>
> >>>> The tickets that are required for the release basically break the
> >>>> compatibility and we postpone fixing them in minor release or they
> >> bring
> >>>> significant improvements into the product. Please review the page,
> >>> provide
> >>>> your comments and assign the tickets on yourself if you’re ready to
> >> work
> >>> on
> >>>> them.
> >>>>
> >>>> —
> >>>> Denis
> >>>>
> >>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> >>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>
> >>>>> 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 are in the same cache, it works, because there is only
> >>> one
> >>>>> write-behind queue. Once we split different types into different
> >>> caches,
> >>>>> there is no guarantee that objects will be written in the proper
> >> order
> >>>> and
> >>>>> that the constraints will not be violated.
> >>>>>
> >>>>> However, I think this is not a very clean way to achieve the result.
> >>>>> Probably we should just provide better support for this use case in
> >>> 2.0.
> >>>>> Basically, we somehow need to allow to share a single write-behind
> >>> queue
> >>>>> between different caches.
> >>>>>
> >>>>> Any thoughts?
> >>>>>
> >>>>> -Val
> >>>>>
> >>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> >>>> dsetrakyan@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> >> skozlov@gridgain.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> 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
> >> iterate
> >>>>>> over
> >>>>>>> caches but I'm not sure that it is supported by API). For
> >>> destroy/clear
> >>>>>>> caches belonging to same group we will do it by single operation
> >>>> without
> >>>>>>> knowledge of cache names.
> >>>>>>> 3. Cache group can have cache attributes which will be inherited
> >> by a
> >>>>>> cache
> >>>>>>> created in that group (like eviction policy or cache mode).
> >>>>>>> 4. No reason to add specific feature like SqlShema if it applicable
> >>> for
> >>>>>>> regular caches as well.
> >>>>>>>
> >>>>>>
> >>>>>> Sergey K, setting the same SQL schema for multiple caches, as
> >> proposed
> >>>> by
> >>>>>> Sergi, solves a different problem of having too many SQL schemas due
> >>> to
> >>>> too
> >>>>>> many different caches. I think Sergi proposed a good solution for
> >> it.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> >>>>>> akuznetsov@gridgain.com
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
> >>>>>>>>
> >>>>>>>> How grouping will help?
> >>>>>>>> To do some operation, for example, clear on group of cashes at
> >> once?
> >>>>>>>>
> >>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> >>>>>> skozlov@gridgain.com>
> >>>>>>>> написал:
> >>>>>>>>
> >>>>>>>>> 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 <
> >>>>>>>> sergi.vladykin@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com
> >>> :
> >>>>>>>>>>
> >>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> >>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
> >>>>>>>>> **Spark**
> >>>>>>>>>> 2
> >>>>>>>>>>> is
> >>>>>>>>>>>>> on **scala 2.11**.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would drop it only if it is difficult to support. Do we know
> >>>>>>> what
> >>>>>>>>>> kind
> >>>>>>>>>>> of
> >>>>>>>>>>>> impact will it have on the community? Anyone is still using
> >>>>>> 2.10?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> —
> >>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>> :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> >>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>> block
> >>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> >>>>>>> event)
> >>>>>>>>>>> causing
> >>>>>>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>>>>>> hangings.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
> >>>>>> be
> >>>>>>>> nice
> >>>>>>>>>> to
> >>>>>>>>>>>>> assign
> >>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> >>>>>>>>> discussed
> >>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>> comes
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>> next major version release.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
> >>>>>> tasks?
> >>>>>>>>>> Should
> >>>>>>>>>>> it
> >>>>>>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> --AG
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>> GridGain Systems
> >>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Sergey Kozlov
> >>>>>>>>> GridGain Systems
> >>>>>>>>> www.gridgain.com
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Sergey Kozlov
> >>>>>>> GridGain Systems
> >>>>>>> www.gridgain.com
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Sergey Kozlov
> >> GridGain Systems
> >> www.gridgain.com
> >>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
I would move it to 2.1 or 2.2.

—
Denis

> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@apache.org> 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, like 2.1?
> 
> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <sk...@gridgain.com> wrote:
> 
>> 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
>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we need
>> to
>> have a root ticket for that.
>> 
>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <ds...@apache.org>
>> wrote:
>> 
>>> Denis, thanks for taking a role of a release manger for 2.0. It is
>>> definitely an important release for us and good supervision is going to
>> be
>>> very helpful.
>>> 
>>> I have looked at the tickets and the list seems nice. I would also add a
>>> ticket about migration of the JTA dependency to Geronimo as well,
>>> IGNITE-3793 [1], however I am not sure if we might be able to do it prior
>>> to 2.0.
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
>>> 
>>> D.
>>> 
>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com> wrote:
>>> 
>>>> Community,
>>>> 
>>>> Let me take a role of the release manager for Apache Ignite 2.0 and
>>>> coordinate the process.
>>>> 
>>>> So, my personal view is that Apache Ignite 2.0 should be released by
>> the
>>>> end of the year. This sounds like a good practice to make a major
>> release
>>>> once a year. I would suggest us following the same rule.
>>>> 
>>>> Actual we have more than 3 month for development and I’ve prepare the
>>> wiki
>>>> page that contains tickets that are required to be released in 2.0 and
>>> that
>>>> are optional
>>>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
>>>> 
>>>> Proposed release date is December 23rd, 2016.
>>>> 
>>>> The tickets that are required for the release basically break the
>>>> compatibility and we postpone fixing them in minor release or they
>> bring
>>>> significant improvements into the product. Please review the page,
>>> provide
>>>> your comments and assign the tickets on yourself if you’re ready to
>> work
>>> on
>>>> them.
>>>> 
>>>> —
>>>> Denis
>>>> 
>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
>>>> valentin.kulichenko@gmail.com> wrote:
>>>>> 
>>>>> 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 are in the same cache, it works, because there is only
>>> one
>>>>> write-behind queue. Once we split different types into different
>>> caches,
>>>>> there is no guarantee that objects will be written in the proper
>> order
>>>> and
>>>>> that the constraints will not be violated.
>>>>> 
>>>>> However, I think this is not a very clean way to achieve the result.
>>>>> Probably we should just provide better support for this use case in
>>> 2.0.
>>>>> Basically, we somehow need to allow to share a single write-behind
>>> queue
>>>>> between different caches.
>>>>> 
>>>>> Any thoughts?
>>>>> 
>>>>> -Val
>>>>> 
>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
>>>> dsetrakyan@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
>> skozlov@gridgain.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> 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
>> iterate
>>>>>> over
>>>>>>> caches but I'm not sure that it is supported by API). For
>>> destroy/clear
>>>>>>> caches belonging to same group we will do it by single operation
>>>> without
>>>>>>> knowledge of cache names.
>>>>>>> 3. Cache group can have cache attributes which will be inherited
>> by a
>>>>>> cache
>>>>>>> created in that group (like eviction policy or cache mode).
>>>>>>> 4. No reason to add specific feature like SqlShema if it applicable
>>> for
>>>>>>> regular caches as well.
>>>>>>> 
>>>>>> 
>>>>>> Sergey K, setting the same SQL schema for multiple caches, as
>> proposed
>>>> by
>>>>>> Sergi, solves a different problem of having too many SQL schemas due
>>> to
>>>> too
>>>>>> many different caches. I think Sergi proposed a good solution for
>> it.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
>>>>>> akuznetsov@gridgain.com
>>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"?
>>>>>>>> 
>>>>>>>> How grouping will help?
>>>>>>>> To do some operation, for example, clear on group of cashes at
>> once?
>>>>>>>> 
>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
>>>>>> skozlov@gridgain.com>
>>>>>>>> написал:
>>>>>>>> 
>>>>>>>>> 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 <
>>>>>>>> sergi.vladykin@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com
>>> :
>>>>>>>>>> 
>>>>>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
>>>>>>>>>>> akuznetsov@gridgain.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I remember couple more thing for 2.0
>>>>>>>>>>>>> 
>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Why?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
>>>>>>>>> **Spark**
>>>>>>>>>> 2
>>>>>>>>>>> is
>>>>>>>>>>>>> on **scala 2.11**.
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I would drop it only if it is difficult to support. Do we know
>>>>>>> what
>>>>>>>>>> kind
>>>>>>>>>>> of
>>>>>>>>>>>> impact will it have on the community? Anyone is still using
>>>>>> 2.10?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
>>>>>>>> dmagda@gridgain.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> —
>>>>>>>>>>>>>> Denis
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>> :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
>>>>>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
>>>>>>> event)
>>>>>>>>>>> causing
>>>>>>>>>>>>>>>>>> topology
>>>>>>>>>>>>>>>>>>> hangings.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
>>>>>> be
>>>>>>>> nice
>>>>>>>>>> to
>>>>>>>>>>>>> assign
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
>>>>>>>>> discussed
>>>>>>>>>>>>> features
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --Yakov
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>>>>>>>>>>>>>>>> alexey.goncharuk@gmail.com
>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> comes
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> next major version release.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such
>>>>>> tasks?
>>>>>>>>>> Should
>>>>>>>>>>> it
>>>>>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I would go with a label + release version.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> --AG
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Alexey Kuznetsov
>>>>>>>>>>>>> GridGain Systems
>>>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Sergey Kozlov
>>>>>>>>>>> GridGain Systems
>>>>>>>>>>> www.gridgain.com
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Sergey Kozlov
>>>>>>>>> GridGain Systems
>>>>>>>>> www.gridgain.com
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Sergey Kozlov
>>>>>>> GridGain Systems
>>>>>>> www.gridgain.com
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Sergey Kozlov
>> GridGain Systems
>> www.gridgain.com
>>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
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, like 2.1?

On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <sk...@gridgain.com> wrote:

> 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
> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we need
> to
> have a root ticket for that.
>
> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > Denis, thanks for taking a role of a release manger for 2.0. It is
> > definitely an important release for us and good supervision is going to
> be
> > very helpful.
> >
> > I have looked at the tickets and the list seems nice. I would also add a
> > ticket about migration of the JTA dependency to Geronimo as well,
> > IGNITE-3793 [1], however I am not sure if we might be able to do it prior
> > to 2.0.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >
> > D.
> >
> > On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com> wrote:
> >
> > > Community,
> > >
> > > Let me take a role of the release manager for Apache Ignite 2.0 and
> > > coordinate the process.
> > >
> > > So, my personal view is that Apache Ignite 2.0 should be released by
> the
> > > end of the year. This sounds like a good practice to make a major
> release
> > > once a year. I would suggest us following the same rule.
> > >
> > > Actual we have more than 3 month for development and I’ve prepare the
> > wiki
> > > page that contains tickets that are required to be released in 2.0 and
> > that
> > > are optional
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
> > >
> > > Proposed release date is December 23rd, 2016.
> > >
> > > The tickets that are required for the release basically break the
> > > compatibility and we postpone fixing them in minor release or they
> bring
> > > significant improvements into the product. Please review the page,
> > provide
> > > your comments and assign the tickets on yourself if you’re ready to
> work
> > on
> > > them.
> > >
> > > —
> > > Denis
> > >
> > > > On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > > >
> > > > 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 are in the same cache, it works, because there is only
> > one
> > > > write-behind queue. Once we split different types into different
> > caches,
> > > > there is no guarantee that objects will be written in the proper
> order
> > > and
> > > > that the constraints will not be violated.
> > > >
> > > > However, I think this is not a very clean way to achieve the result.
> > > > Probably we should just provide better support for this use case in
> > 2.0.
> > > > Basically, we somehow need to allow to share a single write-behind
> > queue
> > > > between different caches.
> > > >
> > > > Any thoughts?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > > wrote:
> > > >
> > > >> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> skozlov@gridgain.com>
> > > >> wrote:
> > > >>
> > > >>> 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
> iterate
> > > >> over
> > > >>> caches but I'm not sure that it is supported by API). For
> > destroy/clear
> > > >>> caches belonging to same group we will do it by single operation
> > > without
> > > >>> knowledge of cache names.
> > > >>> 3. Cache group can have cache attributes which will be inherited
> by a
> > > >> cache
> > > >>> created in that group (like eviction policy or cache mode).
> > > >>> 4. No reason to add specific feature like SqlShema if it applicable
> > for
> > > >>> regular caches as well.
> > > >>>
> > > >>
> > > >> Sergey K, setting the same SQL schema for multiple caches, as
> proposed
> > > by
> > > >> Sergi, solves a different problem of having too many SQL schemas due
> > to
> > > too
> > > >> many different caches. I think Sergi proposed a good solution for
> it.
> > > >>
> > > >>
> > > >>>
> > > >>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > > >> akuznetsov@gridgain.com
> > > >>>>
> > > >>> wrote:
> > > >>>
> > > >>>> Sergey, I belive you mean "increase" instead of "reduce"?
> > > >>>>
> > > >>>> How grouping will help?
> > > >>>> To do some operation, for example, clear on group of cashes at
> once?
> > > >>>>
> > > >>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > > >> skozlov@gridgain.com>
> > > >>>> написал:
> > > >>>>
> > > >>>>> 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 <
> > > >>>> sergi.vladykin@gmail.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> 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
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com
> >:
> > > >>>>>>
> > > >>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > > >>>>> dsetrakyan@apache.org
> > > >>>>>>>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > >>>>>>> akuznetsov@gridgain.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> I remember couple more thing for 2.0
> > > >>>>>>>>>
> > > >>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Why?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
> > > >>>>> **Spark**
> > > >>>>>> 2
> > > >>>>>>> is
> > > >>>>>>>>> on **scala 2.11**.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> I would drop it only if it is difficult to support. Do we know
> > > >>> what
> > > >>>>>> kind
> > > >>>>>>> of
> > > >>>>>>>> impact will it have on the community? Anyone is still using
> > > >> 2.10?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > > >>>> dmagda@gridgain.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> 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 <
> > > >>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> > > >>>>>>>>>>
> > > >>>>>>>>>> —
> > > >>>>>>>>>> Denis
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > > >>>>> yzhdanov@apache.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > > >>>>>> dsetrakyan@apache.org
> > > >>>>>>>> :
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > > >>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>> 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
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > > >>>>>>>> dsetrakyan@apache.org
> > > >>>>>>>>>> :
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > >>>>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>>>>>> 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
> > > >>>>>>>>> may
> > > >>>>>>>>>>>>>> block
> > > >>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> > > >>> event)
> > > >>>>>>> causing
> > > >>>>>>>>>>>>>> topology
> > > >>>>>>>>>>>>>>> hangings.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
> > > >> be
> > > >>>> nice
> > > >>>>>> to
> > > >>>>>>>>> assign
> > > >>>>>>>>>>>> a
> > > >>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> > > >>>>> discussed
> > > >>>>>>>>> features
> > > >>>>>>>>>>>> on
> > > >>>>>>>>>>>>>> the Wiki.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> --Yakov
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > >>>>>>>>>>>> alexey.goncharuk@gmail.com
> > > >>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>> comes
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> next major version release.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> My question for now is how should we track such
> > > >> tasks?
> > > >>>>>> Should
> > > >>>>>>> it
> > > >>>>>>>>>>>> be a
> > > >>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I would go with a label + release version.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --AG
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Alexey Kuznetsov
> > > >>>>>>>>> GridGain Systems
> > > >>>>>>>>> www.gridgain.com
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Sergey Kozlov
> > > >>>>>>> GridGain Systems
> > > >>>>>>> www.gridgain.com
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Sergey Kozlov
> > > >>>>> GridGain Systems
> > > >>>>> www.gridgain.com
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Sergey Kozlov
> > > >>> GridGain Systems
> > > >>> www.gridgain.com
> > > >>>
> > > >>
> > >
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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
<https://issues.apache.org/jira/browse/IGNITE-1774> but probably we need to
have a root ticket for that.

On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> Denis, thanks for taking a role of a release manger for 2.0. It is
> definitely an important release for us and good supervision is going to be
> very helpful.
>
> I have looked at the tickets and the list seems nice. I would also add a
> ticket about migration of the JTA dependency to Geronimo as well,
> IGNITE-3793 [1], however I am not sure if we might be able to do it prior
> to 2.0.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3793
>
> D.
>
> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com> wrote:
>
> > Community,
> >
> > Let me take a role of the release manager for Apache Ignite 2.0 and
> > coordinate the process.
> >
> > So, my personal view is that Apache Ignite 2.0 should be released by the
> > end of the year. This sounds like a good practice to make a major release
> > once a year. I would suggest us following the same rule.
> >
> > Actual we have more than 3 month for development and I’ve prepare the
> wiki
> > page that contains tickets that are required to be released in 2.0 and
> that
> > are optional
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
> >
> > Proposed release date is December 23rd, 2016.
> >
> > The tickets that are required for the release basically break the
> > compatibility and we postpone fixing them in minor release or they bring
> > significant improvements into the product. Please review the page,
> provide
> > your comments and assign the tickets on yourself if you’re ready to work
> on
> > them.
> >
> > —
> > Denis
> >
> > > On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> > >
> > > 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 are in the same cache, it works, because there is only
> one
> > > write-behind queue. Once we split different types into different
> caches,
> > > there is no guarantee that objects will be written in the proper order
> > and
> > > that the constraints will not be violated.
> > >
> > > However, I think this is not a very clean way to achieve the result.
> > > Probably we should just provide better support for this use case in
> 2.0.
> > > Basically, we somehow need to allow to share a single write-behind
> queue
> > > between different caches.
> > >
> > > Any thoughts?
> > >
> > > -Val
> > >
> > > On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > >> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <sk...@gridgain.com>
> > >> wrote:
> > >>
> > >>> 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 iterate
> > >> over
> > >>> caches but I'm not sure that it is supported by API). For
> destroy/clear
> > >>> caches belonging to same group we will do it by single operation
> > without
> > >>> knowledge of cache names.
> > >>> 3. Cache group can have cache attributes which will be inherited by a
> > >> cache
> > >>> created in that group (like eviction policy or cache mode).
> > >>> 4. No reason to add specific feature like SqlShema if it applicable
> for
> > >>> regular caches as well.
> > >>>
> > >>
> > >> Sergey K, setting the same SQL schema for multiple caches, as proposed
> > by
> > >> Sergi, solves a different problem of having too many SQL schemas due
> to
> > too
> > >> many different caches. I think Sergi proposed a good solution for it.
> > >>
> > >>
> > >>>
> > >>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > >> akuznetsov@gridgain.com
> > >>>>
> > >>> wrote:
> > >>>
> > >>>> Sergey, I belive you mean "increase" instead of "reduce"?
> > >>>>
> > >>>> How grouping will help?
> > >>>> To do some operation, for example, clear on group of cashes at once?
> > >>>>
> > >>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > >> skozlov@gridgain.com>
> > >>>> написал:
> > >>>>
> > >>>>> 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 <
> > >>>> sergi.vladykin@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> 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
> > >>>>>>
> > >>>>>>
> > >>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> > >>>>>>
> > >>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > >>>>> dsetrakyan@apache.org
> > >>>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > >>>>>>> akuznetsov@gridgain.com>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> I remember couple more thing for 2.0
> > >>>>>>>>>
> > >>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Why?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
> > >>>>> **Spark**
> > >>>>>> 2
> > >>>>>>> is
> > >>>>>>>>> on **scala 2.11**.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> I would drop it only if it is difficult to support. Do we know
> > >>> what
> > >>>>>> kind
> > >>>>>>> of
> > >>>>>>>> impact will it have on the community? Anyone is still using
> > >> 2.10?
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > >>>> dmagda@gridgain.com>
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> 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 <
> > >>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> > >>>>>>>>>>
> > >>>>>>>>>> —
> > >>>>>>>>>> Denis
> > >>>>>>>>>>
> > >>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > >>>>> yzhdanov@apache.org>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>> dsetrakyan@apache.org
> > >>>>>>>> :
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > >>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>> 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
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > >>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>> :
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > >>>>>>>>> yzhdanov@apache.org>
> > >>>>>>>>>>>>>> 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
> > >>>>>>>>> may
> > >>>>>>>>>>>>>> block
> > >>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> > >>> event)
> > >>>>>>> causing
> > >>>>>>>>>>>>>> topology
> > >>>>>>>>>>>>>>> hangings.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
> > >> be
> > >>>> nice
> > >>>>>> to
> > >>>>>>>>> assign
> > >>>>>>>>>>>> a
> > >>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> > >>>>> discussed
> > >>>>>>>>> features
> > >>>>>>>>>>>> on
> > >>>>>>>>>>>>>> the Wiki.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> --Yakov
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > >>>>>>>>>>>> alexey.goncharuk@gmail.com
> > >>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>> comes
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> next major version release.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> My question for now is how should we track such
> > >> tasks?
> > >>>>>> Should
> > >>>>>>> it
> > >>>>>>>>>>>> be a
> > >>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I would go with a label + release version.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --AG
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Alexey Kuznetsov
> > >>>>>>>>> GridGain Systems
> > >>>>>>>>> www.gridgain.com
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Sergey Kozlov
> > >>>>>>> GridGain Systems
> > >>>>>>> www.gridgain.com
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Sergey Kozlov
> > >>>>> GridGain Systems
> > >>>>> www.gridgain.com
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Sergey Kozlov
> > >>> GridGain Systems
> > >>> www.gridgain.com
> > >>>
> > >>
> >
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
Denis, thanks for taking a role of a release manger for 2.0. It is
definitely an important release for us and good supervision is going to be
very helpful.

I have looked at the tickets and the list seems nice. I would also add a
ticket about migration of the JTA dependency to Geronimo as well,
IGNITE-3793 [1], however I am not sure if we might be able to do it prior
to 2.0.

[1] https://issues.apache.org/jira/browse/IGNITE-3793

D.

On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dm...@gridgain.com> wrote:

> Community,
>
> Let me take a role of the release manager for Apache Ignite 2.0 and
> coordinate the process.
>
> So, my personal view is that Apache Ignite 2.0 should be released by the
> end of the year. This sounds like a good practice to make a major release
> once a year. I would suggest us following the same rule.
>
> Actual we have more than 3 month for development and I’ve prepare the wiki
> page that contains tickets that are required to be released in 2.0 and that
> are optional
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
>
> Proposed release date is December 23rd, 2016.
>
> The tickets that are required for the release basically break the
> compatibility and we postpone fixing them in minor release or they bring
> significant improvements into the product. Please review the page, provide
> your comments and assign the tickets on yourself if you’re ready to work on
> them.
>
> —
> Denis
>
> > On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
> >
> > 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 are in the same cache, it works, because there is only one
> > write-behind queue. Once we split different types into different caches,
> > there is no guarantee that objects will be written in the proper order
> and
> > that the constraints will not be violated.
> >
> > However, I think this is not a very clean way to achieve the result.
> > Probably we should just provide better support for this use case in 2.0.
> > Basically, we somehow need to allow to share a single write-behind queue
> > between different caches.
> >
> > Any thoughts?
> >
> > -Val
> >
> > On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> >> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <sk...@gridgain.com>
> >> wrote:
> >>
> >>> 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 iterate
> >> over
> >>> caches but I'm not sure that it is supported by API). For destroy/clear
> >>> caches belonging to same group we will do it by single operation
> without
> >>> knowledge of cache names.
> >>> 3. Cache group can have cache attributes which will be inherited by a
> >> cache
> >>> created in that group (like eviction policy or cache mode).
> >>> 4. No reason to add specific feature like SqlShema if it applicable for
> >>> regular caches as well.
> >>>
> >>
> >> Sergey K, setting the same SQL schema for multiple caches, as proposed
> by
> >> Sergi, solves a different problem of having too many SQL schemas due to
> too
> >> many different caches. I think Sergi proposed a good solution for it.
> >>
> >>
> >>>
> >>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> >> akuznetsov@gridgain.com
> >>>>
> >>> wrote:
> >>>
> >>>> Sergey, I belive you mean "increase" instead of "reduce"?
> >>>>
> >>>> How grouping will help?
> >>>> To do some operation, for example, clear on group of cashes at once?
> >>>>
> >>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> >> skozlov@gridgain.com>
> >>>> написал:
> >>>>
> >>>>> 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 <
> >>>> sergi.vladykin@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> >>>>>>
> >>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> >>>>> dsetrakyan@apache.org
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>> akuznetsov@gridgain.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>
> >>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Why?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
> >>>>> **Spark**
> >>>>>> 2
> >>>>>>> is
> >>>>>>>>> on **scala 2.11**.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I would drop it only if it is difficult to support. Do we know
> >>> what
> >>>>>> kind
> >>>>>>> of
> >>>>>>>> impact will it have on the community? Anyone is still using
> >> 2.10?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>> dmagda@gridgain.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> 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 <
> >>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> >>>>>>>>>>
> >>>>>>>>>> —
> >>>>>>>>>> Denis
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>> yzhdanov@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>> dsetrakyan@apache.org
> >>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>> yzhdanov@apache.org>
> >>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>> :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> >>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>> 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
> >>>>>>>>> may
> >>>>>>>>>>>>>> block
> >>>>>>>>>>>>>>> internal component notification (e.g. on discovery
> >>> event)
> >>>>>>> causing
> >>>>>>>>>>>>>> topology
> >>>>>>>>>>>>>>> hangings.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
> >> be
> >>>> nice
> >>>>>> to
> >>>>>>>>> assign
> >>>>>>>>>>>> a
> >>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
> >>>>> discussed
> >>>>>>>>> features
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>> alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>> comes
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> next major version release.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> My question for now is how should we track such
> >> tasks?
> >>>>>> Should
> >>>>>>> it
> >>>>>>>>>>>> be a
> >>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would go with a label + release version.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --AG
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Alexey Kuznetsov
> >>>>>>>>> GridGain Systems
> >>>>>>>>> www.gridgain.com
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Sergey Kozlov
> >>>>>>> GridGain Systems
> >>>>>>> www.gridgain.com
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Sergey Kozlov
> >>>>> GridGain Systems
> >>>>> www.gridgain.com
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sergey Kozlov
> >>> GridGain Systems
> >>> www.gridgain.com
> >>>
> >>
>
>

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
Community,

Let me take a role of the release manager for Apache Ignite 2.0 and coordinate the process.

So, my personal view is that Apache Ignite 2.0 should be released by the end of the year. This sounds like a good practice to make a major release once a year. I would suggest us following the same rule.

Actual we have more than 3 month for development and I’ve prepare the wiki page that contains tickets that are required to be released in 2.0 and that are optional
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0

Proposed release date is December 23rd, 2016.

The tickets that are required for the release basically break the compatibility and we postpone fixing them in minor release or they bring significant improvements into the product. Please review the page, provide your comments and assign the tickets on yourself if you’re ready to work on them.

—
Denis

> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <va...@gmail.com> wrote:
> 
> 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 are in the same cache, it works, because there is only one
> write-behind queue. Once we split different types into different caches,
> there is no guarantee that objects will be written in the proper order and
> that the constraints will not be violated.
> 
> However, I think this is not a very clean way to achieve the result.
> Probably we should just provide better support for this use case in 2.0.
> Basically, we somehow need to allow to share a single write-behind queue
> between different caches.
> 
> Any thoughts?
> 
> -Val
> 
> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
> 
>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <sk...@gridgain.com>
>> wrote:
>> 
>>> 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 iterate
>> over
>>> caches but I'm not sure that it is supported by API). For destroy/clear
>>> caches belonging to same group we will do it by single operation without
>>> knowledge of cache names.
>>> 3. Cache group can have cache attributes which will be inherited by a
>> cache
>>> created in that group (like eviction policy or cache mode).
>>> 4. No reason to add specific feature like SqlShema if it applicable for
>>> regular caches as well.
>>> 
>> 
>> Sergey K, setting the same SQL schema for multiple caches, as proposed by
>> Sergi, solves a different problem of having too many SQL schemas due to too
>> many different caches. I think Sergi proposed a good solution for it.
>> 
>> 
>>> 
>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
>> akuznetsov@gridgain.com
>>>> 
>>> wrote:
>>> 
>>>> Sergey, I belive you mean "increase" instead of "reduce"?
>>>> 
>>>> How grouping will help?
>>>> To do some operation, for example, clear on group of cashes at once?
>>>> 
>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
>> skozlov@gridgain.com>
>>>> написал:
>>>> 
>>>>> 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 <
>>>> sergi.vladykin@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
>>>>>> 
>>>>>>> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
>>>>> dsetrakyan@apache.org
>>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
>>>>>>> akuznetsov@gridgain.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I remember couple more thing for 2.0
>>>>>>>>> 
>>>>>>>>> How about to drop **ignite-scalar** module in Ignite 2.0?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Why?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> And may be drop **ignite-spark-2.10** module support as of
>>>>> **Spark**
>>>>>> 2
>>>>>>> is
>>>>>>>>> on **scala 2.11**.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I would drop it only if it is difficult to support. Do we know
>>> what
>>>>>> kind
>>>>>>> of
>>>>>>>> impact will it have on the community? Anyone is still using
>> 2.10?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
>>>> dmagda@gridgain.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 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 <
>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
>>>>>>>>>> 
>>>>>>>>>> —
>>>>>>>>>> Denis
>>>>>>>>>> 
>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
>>>>> yzhdanov@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 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 2:41 GMT+03:00 Dmitriy Setrakyan <
>>>>>> dsetrakyan@apache.org
>>>>>>>> :
>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
>>>>>>> yzhdanov@apache.org>
>>>>>>>>>> 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
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
>>>>>>>> dsetrakyan@apache.org
>>>>>>>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
>>>>>>>>> yzhdanov@apache.org>
>>>>>>>>>>>>>> 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
>>>>>>>>> may
>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>> internal component notification (e.g. on discovery
>>> event)
>>>>>>> causing
>>>>>>>>>>>>>> topology
>>>>>>>>>>>>>>> hangings.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Sure. There are a lot of features being added. Would
>> be
>>>> nice
>>>>>> to
>>>>>>>>> assign
>>>>>>>>>>>> a
>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the
>>>>> discussed
>>>>>>>>> features
>>>>>>>>>>>> on
>>>>>>>>>>>>>> the Wiki.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --Yakov
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>>>>>>>>>>>> alexey.goncharuk@gmail.com
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>> comes
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> next major version release.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> My question for now is how should we track such
>> tasks?
>>>>>> Should
>>>>>>> it
>>>>>>>>>>>> be a
>>>>>>>>>>>>>>>> label, a parent task with subtasks, something else?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I would go with a label + release version.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --AG
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Alexey Kuznetsov
>>>>>>>>> GridGain Systems
>>>>>>>>> www.gridgain.com
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Sergey Kozlov
>>>>>>> GridGain Systems
>>>>>>> www.gridgain.com
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sergey Kozlov
>>>>> GridGain Systems
>>>>> www.gridgain.com
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sergey Kozlov
>>> GridGain Systems
>>> www.gridgain.com
>>> 
>>

Re: Ignite 2.0 tasks/roadmap

Posted by Valentin Kulichenko <va...@gmail.com>.
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 are in the same cache, it works, because there is only one
write-behind queue. Once we split different types into different caches,
there is no guarantee that objects will be written in the proper order and
that the constraints will not be violated.

However, I think this is not a very clean way to achieve the result.
Probably we should just provide better support for this use case in 2.0.
Basically, we somehow need to allow to share a single write-behind queue
between different caches.

Any thoughts?

-Val

On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <sk...@gridgain.com>
> wrote:
>
> > 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 iterate
> over
> > caches but I'm not sure that it is supported by API). For destroy/clear
> > caches belonging to same group we will do it by single operation without
> > knowledge of cache names.
> > 3. Cache group can have cache attributes which will be inherited by a
> cache
> > created in that group (like eviction policy or cache mode).
> > 4. No reason to add specific feature like SqlShema if it applicable for
> > regular caches as well.
> >
>
> Sergey K, setting the same SQL schema for multiple caches, as proposed by
> Sergi, solves a different problem of having too many SQL schemas due to too
> many different caches. I think Sergi proposed a good solution for it.
>
>
> >
> > On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> akuznetsov@gridgain.com
> > >
> > wrote:
> >
> > > Sergey, I belive you mean "increase" instead of "reduce"?
> > >
> > > How grouping will help?
> > > To do some operation, for example, clear on group of cashes at once?
> > >
> > > 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> skozlov@gridgain.com>
> > > написал:
> > >
> > > > 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 <
> > > sergi.vladykin@gmail.com>
> > > > wrote:
> > > >
> > > > > 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
> > > > >
> > > > >
> > > > > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> > > > >
> > > > > > 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > > > > akuznetsov@gridgain.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I remember couple more thing for 2.0
> > > > > > > >
> > > > > > > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > > > > > > >
> > > > > > >
> > > > > > > Why?
> > > > > > >
> > > > > > >
> > > > > > > > And may be drop **ignite-spark-2.10** module support as of
> > > > **Spark**
> > > > > 2
> > > > > > is
> > > > > > > > on **scala 2.11**.
> > > > > > > >
> > > > > > >
> > > > > > > I would drop it only if it is difficult to support. Do we know
> > what
> > > > > kind
> > > > > > of
> > > > > > > impact will it have on the community? Anyone is still using
> 2.10?
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > > dmagda@gridgain.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > > > > > >
> > > > > > > > > —
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > > > yzhdanov@apache.org>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > > > > dsetrakyan@apache.org
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > > > > > yzhdanov@apache.org>
> > > > > > > > > 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
> > > > > > > > > >>>
> > > > > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > > > > > > dsetrakyan@apache.org
> > > > > > > > >:
> > > > > > > > > >>>
> > > > > > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > > > > > > yzhdanov@apache.org>
> > > > > > > > > >>>> 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
> > > > > > > > may
> > > > > > > > > >>>> block
> > > > > > > > > >>>>> internal component notification (e.g. on discovery
> > event)
> > > > > > causing
> > > > > > > > > >>>> topology
> > > > > > > > > >>>>> hangings.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> Sure. There are a lot of features being added. Would
> be
> > > nice
> > > > > to
> > > > > > > > assign
> > > > > > > > > >> a
> > > > > > > > > >>>> release manager for Ignite 2.0 and document all the
> > > > discussed
> > > > > > > > features
> > > > > > > > > >> on
> > > > > > > > > >>>> the Wiki.
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> --Yakov
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > > > > > > > >> alexey.goncharuk@gmail.com
> > > > > > > > > >>>> :
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>> 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
> > > > > > > > > >> comes
> > > > > > > > > >>> to
> > > > > > > > > >>>>> the
> > > > > > > > > >>>>>> next major version release.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> My question for now is how should we track such
> tasks?
> > > > > Should
> > > > > > it
> > > > > > > > > >> be a
> > > > > > > > > >>>>>> label, a parent task with subtasks, something else?
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> I would go with a label + release version.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> --AG
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alexey Kuznetsov
> > > > > > > > GridGain Systems
> > > > > > > > www.gridgain.com
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sergey Kozlov
> > > > > > GridGain Systems
> > > > > > www.gridgain.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sergey Kozlov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <sk...@gridgain.com> wrote:

> 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 iterate over
> caches but I'm not sure that it is supported by API). For destroy/clear
> caches belonging to same group we will do it by single operation without
> knowledge of cache names.
> 3. Cache group can have cache attributes which will be inherited by a cache
> created in that group (like eviction policy or cache mode).
> 4. No reason to add specific feature like SqlShema if it applicable for
> regular caches as well.
>

Sergey K, setting the same SQL schema for multiple caches, as proposed by
Sergi, solves a different problem of having too many SQL schemas due to too
many different caches. I think Sergi proposed a good solution for it.


>
> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <akuznetsov@gridgain.com
> >
> wrote:
>
> > Sergey, I belive you mean "increase" instead of "reduce"?
> >
> > How grouping will help?
> > To do some operation, for example, clear on group of cashes at once?
> >
> > 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <sk...@gridgain.com>
> > написал:
> >
> > > 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 <
> > sergi.vladykin@gmail.com>
> > > wrote:
> > >
> > > > 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
> > > >
> > > >
> > > > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> > > >
> > > > > 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > > > akuznetsov@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I remember couple more thing for 2.0
> > > > > > >
> > > > > > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > > > > > >
> > > > > >
> > > > > > Why?
> > > > > >
> > > > > >
> > > > > > > And may be drop **ignite-spark-2.10** module support as of
> > > **Spark**
> > > > 2
> > > > > is
> > > > > > > on **scala 2.11**.
> > > > > > >
> > > > > >
> > > > > > I would drop it only if it is difficult to support. Do we know
> what
> > > > kind
> > > > > of
> > > > > > impact will it have on the community? Anyone is still using 2.10?
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > dmagda@gridgain.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > 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 <
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > > > > >
> > > > > > > > —
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > > yzhdanov@apache.org>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >:
> > > > > > > > >
> > > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > > > > yzhdanov@apache.org>
> > > > > > > > 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
> > > > > > > > >>>
> > > > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > > > > > dsetrakyan@apache.org
> > > > > > > >:
> > > > > > > > >>>
> > > > > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > > > > > yzhdanov@apache.org>
> > > > > > > > >>>> 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
> > > > > > > may
> > > > > > > > >>>> block
> > > > > > > > >>>>> internal component notification (e.g. on discovery
> event)
> > > > > causing
> > > > > > > > >>>> topology
> > > > > > > > >>>>> hangings.
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>> Sure. There are a lot of features being added. Would be
> > nice
> > > > to
> > > > > > > assign
> > > > > > > > >> a
> > > > > > > > >>>> release manager for Ignite 2.0 and document all the
> > > discussed
> > > > > > > features
> > > > > > > > >> on
> > > > > > > > >>>> the Wiki.
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> --Yakov
> > > > > > > > >>>>>
> > > > > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > > > > > > >> alexey.goncharuk@gmail.com
> > > > > > > > >>>> :
> > > > > > > > >>>>>
> > > > > > > > >>>>>> 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
> > > > > > > > >> comes
> > > > > > > > >>> to
> > > > > > > > >>>>> the
> > > > > > > > >>>>>> next major version release.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> My question for now is how should we track such tasks?
> > > > Should
> > > > > it
> > > > > > > > >> be a
> > > > > > > > >>>>>> label, a parent task with subtasks, something else?
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I would go with a label + release version.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> --AG
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alexey Kuznetsov
> > > > > > > GridGain Systems
> > > > > > > www.gridgain.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sergey Kozlov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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 iterate over
caches but I'm not sure that it is supported by API). For destroy/clear
caches belonging to same group we will do it by single operation without
knowledge of cache names.
3. Cache group can have cache attributes which will be inherited by a cache
created in that group (like eviction policy or cache mode).
4. No reason to add specific feature like SqlShema if it applicable for
regular caches as well.


On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <ak...@gridgain.com>
wrote:

> Sergey, I belive you mean "increase" instead of "reduce"?
>
> How grouping will help?
> To do some operation, for example, clear on group of cashes at once?
>
> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <sk...@gridgain.com>
> написал:
>
> > 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 <
> sergi.vladykin@gmail.com>
> > wrote:
> >
> > > 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
> > >
> > >
> > > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> > >
> > > > 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > > akuznetsov@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > I remember couple more thing for 2.0
> > > > > >
> > > > > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > > > > >
> > > > >
> > > > > Why?
> > > > >
> > > > >
> > > > > > And may be drop **ignite-spark-2.10** module support as of
> > **Spark**
> > > 2
> > > > is
> > > > > > on **scala 2.11**.
> > > > > >
> > > > >
> > > > > I would drop it only if it is difficult to support. Do we know what
> > > kind
> > > > of
> > > > > impact will it have on the community? Anyone is still using 2.10?
> > > > >
> > > > >
> > > > > >
> > > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> dmagda@gridgain.com>
> > > > > wrote:
> > > > > >
> > > > > > > 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 <
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > > > >
> > > > > > > —
> > > > > > > Denis
> > > > > > >
> > > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > yzhdanov@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > > dsetrakyan@apache.org
> > > > >:
> > > > > > > >
> > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > > > yzhdanov@apache.org>
> > > > > > > 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
> > > > > > > >>>
> > > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > > > > dsetrakyan@apache.org
> > > > > > >:
> > > > > > > >>>
> > > > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > > > > yzhdanov@apache.org>
> > > > > > > >>>> 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
> > > > > > may
> > > > > > > >>>> block
> > > > > > > >>>>> internal component notification (e.g. on discovery event)
> > > > causing
> > > > > > > >>>> topology
> > > > > > > >>>>> hangings.
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>> Sure. There are a lot of features being added. Would be
> nice
> > > to
> > > > > > assign
> > > > > > > >> a
> > > > > > > >>>> release manager for Ignite 2.0 and document all the
> > discussed
> > > > > > features
> > > > > > > >> on
> > > > > > > >>>> the Wiki.
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>>
> > > > > > > >>>>> --Yakov
> > > > > > > >>>>>
> > > > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > > > > > >> alexey.goncharuk@gmail.com
> > > > > > > >>>> :
> > > > > > > >>>>>
> > > > > > > >>>>>> 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
> > > > > > > >> comes
> > > > > > > >>> to
> > > > > > > >>>>> the
> > > > > > > >>>>>> next major version release.
> > > > > > > >>>>>>
> > > > > > > >>>>>> My question for now is how should we track such tasks?
> > > Should
> > > > it
> > > > > > > >> be a
> > > > > > > >>>>>> label, a parent task with subtasks, something else?
> > > > > > > >>>>>>
> > > > > > > >>>>>> I would go with a label + release version.
> > > > > > > >>>>>>
> > > > > > > >>>>>> --AG
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alexey Kuznetsov
> > > > > > GridGain Systems
> > > > > > www.gridgain.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sergey Kozlov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
Sergey, I belive you mean "increase" instead of "reduce"?

How grouping will help?
To do some operation, for example, clear on group of cashes at once?

11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <sk...@gridgain.com>
написал:

> 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 <se...@gmail.com>
> wrote:
>
> > 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
> >
> >
> > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> >
> > > 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >
> > > wrote:
> > >
> > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > akuznetsov@gridgain.com>
> > > > wrote:
> > > >
> > > > > I remember couple more thing for 2.0
> > > > >
> > > > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > > > >
> > > >
> > > > Why?
> > > >
> > > >
> > > > > And may be drop **ignite-spark-2.10** module support as of
> **Spark**
> > 2
> > > is
> > > > > on **scala 2.11**.
> > > > >
> > > >
> > > > I would drop it only if it is difficult to support. Do we know what
> > kind
> > > of
> > > > impact will it have on the community? Anyone is still using 2.10?
> > > >
> > > >
> > > > >
> > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <dm...@gridgain.com>
> > > > wrote:
> > > > >
> > > > > > 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 <
> > > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > > >
> > > > > > —
> > > > > > Denis
> > > > > >
> > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> yzhdanov@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >:
> > > > > > >
> > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > > yzhdanov@apache.org>
> > > > > > 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
> > > > > > >>>
> > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >:
> > > > > > >>>
> > > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > > > yzhdanov@apache.org>
> > > > > > >>>> 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
> > > > > may
> > > > > > >>>> block
> > > > > > >>>>> internal component notification (e.g. on discovery event)
> > > causing
> > > > > > >>>> topology
> > > > > > >>>>> hangings.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> Sure. There are a lot of features being added. Would be nice
> > to
> > > > > assign
> > > > > > >> a
> > > > > > >>>> release manager for Ignite 2.0 and document all the
> discussed
> > > > > features
> > > > > > >> on
> > > > > > >>>> the Wiki.
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>>
> > > > > > >>>>> --Yakov
> > > > > > >>>>>
> > > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > > > > >> alexey.goncharuk@gmail.com
> > > > > > >>>> :
> > > > > > >>>>>
> > > > > > >>>>>> 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
> > > > > > >> comes
> > > > > > >>> to
> > > > > > >>>>> the
> > > > > > >>>>>> next major version release.
> > > > > > >>>>>>
> > > > > > >>>>>> My question for now is how should we track such tasks?
> > Should
> > > it
> > > > > > >> be a
> > > > > > >>>>>> label, a parent task with subtasks, something else?
> > > > > > >>>>>>
> > > > > > >>>>>> I would go with a label + release version.
> > > > > > >>>>>>
> > > > > > >>>>>> --AG
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <se...@gmail.com>
wrote:

> 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
>
>
> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
>
> > 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> > wrote:
> >
> > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com>
> > > wrote:
> > >
> > > > I remember couple more thing for 2.0
> > > >
> > > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > > >
> > >
> > > Why?
> > >
> > >
> > > > And may be drop **ignite-spark-2.10** module support as of **Spark**
> 2
> > is
> > > > on **scala 2.11**.
> > > >
> > >
> > > I would drop it only if it is difficult to support. Do we know what
> kind
> > of
> > > impact will it have on the community? Anyone is still using 2.10?
> > >
> > >
> > > >
> > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <dm...@gridgain.com>
> > > wrote:
> > > >
> > > > > 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 <
> > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > >
> > > > > —
> > > > > Denis
> > > > >
> > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <yz...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >:
> > > > > >
> > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> > yzhdanov@apache.org>
> > > > > 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
> > > > > >>>
> > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > > dsetrakyan@apache.org
> > > > >:
> > > > > >>>
> > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > > yzhdanov@apache.org>
> > > > > >>>> 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
> > > > may
> > > > > >>>> block
> > > > > >>>>> internal component notification (e.g. on discovery event)
> > causing
> > > > > >>>> topology
> > > > > >>>>> hangings.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> Sure. There are a lot of features being added. Would be nice
> to
> > > > assign
> > > > > >> a
> > > > > >>>> release manager for Ignite 2.0 and document all the discussed
> > > > features
> > > > > >> on
> > > > > >>>> the Wiki.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>>
> > > > > >>>>> --Yakov
> > > > > >>>>>
> > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > > > >> alexey.goncharuk@gmail.com
> > > > > >>>> :
> > > > > >>>>>
> > > > > >>>>>> 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
> > > > > >> comes
> > > > > >>> to
> > > > > >>>>> the
> > > > > >>>>>> next major version release.
> > > > > >>>>>>
> > > > > >>>>>> My question for now is how should we track such tasks?
> Should
> > it
> > > > > >> be a
> > > > > >>>>>> label, a parent task with subtasks, something else?
> > > > > >>>>>>
> > > > > >>>>>> I would go with a label + release version.
> > > > > >>>>>>
> > > > > >>>>>> --AG
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Sergi Vladykin <se...@gmail.com>.
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


2016-08-11 17:24 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:

> 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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> akuznetsov@gridgain.com>
> > wrote:
> >
> > > I remember couple more thing for 2.0
> > >
> > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > >
> >
> > Why?
> >
> >
> > > And may be drop **ignite-spark-2.10** module support as of **Spark** 2
> is
> > > on **scala 2.11**.
> > >
> >
> > I would drop it only if it is difficult to support. Do we know what kind
> of
> > impact will it have on the community? Anyone is still using 2.10?
> >
> >
> > >
> > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <dm...@gridgain.com>
> > wrote:
> > >
> > > > 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 <
> > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > >
> > > > —
> > > > Denis
> > > >
> > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <yz...@apache.org>
> > > wrote:
> > > > >
> > > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org
> >:
> > > > >
> > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> yzhdanov@apache.org>
> > > > 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
> > > > >>>
> > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >:
> > > > >>>
> > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > yzhdanov@apache.org>
> > > > >>>> 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
> > > may
> > > > >>>> block
> > > > >>>>> internal component notification (e.g. on discovery event)
> causing
> > > > >>>> topology
> > > > >>>>> hangings.
> > > > >>>>>
> > > > >>>>
> > > > >>>> Sure. There are a lot of features being added. Would be nice to
> > > assign
> > > > >> a
> > > > >>>> release manager for Ignite 2.0 and document all the discussed
> > > features
> > > > >> on
> > > > >>>> the Wiki.
> > > > >>>>
> > > > >>>>
> > > > >>>>>
> > > > >>>>> --Yakov
> > > > >>>>>
> > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > > >> alexey.goncharuk@gmail.com
> > > > >>>> :
> > > > >>>>>
> > > > >>>>>> 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
> > > > >> comes
> > > > >>> to
> > > > >>>>> the
> > > > >>>>>> next major version release.
> > > > >>>>>>
> > > > >>>>>> My question for now is how should we track such tasks? Should
> it
> > > > >> be a
> > > > >>>>>> label, a parent task with subtasks, something else?
> > > > >>>>>>
> > > > >>>>>> I would go with a label + release version.
> > > > >>>>>>
> > > > >>>>>> --AG
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite 2.0 tasks/roadmap

Posted by Sergey Kozlov <sk...@gridgain.com>.
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, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <ak...@gridgain.com>
> wrote:
>
> > I remember couple more thing for 2.0
> >
> > How about to drop **ignite-scalar** module in Ignite 2.0?
> >
>
> Why?
>
>
> > And may be drop **ignite-spark-2.10** module support as of **Spark** 2 is
> > on **scala 2.11**.
> >
>
> I would drop it only if it is difficult to support. Do we know what kind of
> impact will it have on the community? Anyone is still using 2.10?
>
>
> >
> > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <dm...@gridgain.com>
> wrote:
> >
> > > 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 <
> > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > >
> > > —
> > > Denis
> > >
> > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> > > >
> > > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> > > >
> > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yz...@apache.org>
> > > 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
> > > >>>
> > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >:
> > > >>>
> > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > yzhdanov@apache.org>
> > > >>>> 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
> > may
> > > >>>> block
> > > >>>>> internal component notification (e.g. on discovery event) causing
> > > >>>> topology
> > > >>>>> hangings.
> > > >>>>>
> > > >>>>
> > > >>>> Sure. There are a lot of features being added. Would be nice to
> > assign
> > > >> a
> > > >>>> release manager for Ignite 2.0 and document all the discussed
> > features
> > > >> on
> > > >>>> the Wiki.
> > > >>>>
> > > >>>>
> > > >>>>>
> > > >>>>> --Yakov
> > > >>>>>
> > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > > >> alexey.goncharuk@gmail.com
> > > >>>> :
> > > >>>>>
> > > >>>>>> 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
> > > >> comes
> > > >>> to
> > > >>>>> the
> > > >>>>>> next major version release.
> > > >>>>>>
> > > >>>>>> My question for now is how should we track such tasks? Should it
> > > >> be a
> > > >>>>>> label, a parent task with subtasks, something else?
> > > >>>>>>
> > > >>>>>> I would go with a label + release version.
> > > >>>>>>
> > > >>>>>> --AG
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <ak...@gridgain.com>
wrote:

> I remember couple more thing for 2.0
>
> How about to drop **ignite-scalar** module in Ignite 2.0?
>

Why?


> And may be drop **ignite-spark-2.10** module support as of **Spark** 2 is
> on **scala 2.11**.
>

I would drop it only if it is difficult to support. Do we know what kind of
impact will it have on the community? Anyone is still using 2.10?


>
> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <dm...@gridgain.com> wrote:
>
> > 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 <
> > https://issues.apache.org/jira/browse/IGNITE-3495>
> >
> > —
> > Denis
> >
> > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <yz...@apache.org>
> wrote:
> > >
> > > 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 2:41 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> > >
> > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yz...@apache.org>
> > 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
> > >>>
> > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org
> >:
> > >>>
> > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> yzhdanov@apache.org>
> > >>>> 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
> may
> > >>>> block
> > >>>>> internal component notification (e.g. on discovery event) causing
> > >>>> topology
> > >>>>> hangings.
> > >>>>>
> > >>>>
> > >>>> Sure. There are a lot of features being added. Would be nice to
> assign
> > >> a
> > >>>> release manager for Ignite 2.0 and document all the discussed
> features
> > >> on
> > >>>> the Wiki.
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> --Yakov
> > >>>>>
> > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> > >> alexey.goncharuk@gmail.com
> > >>>> :
> > >>>>>
> > >>>>>> 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
> > >> comes
> > >>> to
> > >>>>> the
> > >>>>>> next major version release.
> > >>>>>>
> > >>>>>> My question for now is how should we track such tasks? Should it
> > >> be a
> > >>>>>> label, a parent task with subtasks, something else?
> > >>>>>>
> > >>>>>> I would go with a label + release version.
> > >>>>>>
> > >>>>>> --AG
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite 2.0 tasks/roadmap

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
I remember couple more thing for 2.0

How about to drop **ignite-scalar** module in Ignite 2.0?
And may be drop **ignite-spark-2.10** module support as of **Spark** 2 is
on **scala 2.11**.

On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <dm...@gridgain.com> wrote:

> 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 <
> https://issues.apache.org/jira/browse/IGNITE-3495>
>
> —
> Denis
>
> > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> >
> > 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 2:41 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> >
> >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yz...@apache.org>
> 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
> >>>
> >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> >>>
> >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <yz...@apache.org>
> >>>> 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 may
> >>>> block
> >>>>> internal component notification (e.g. on discovery event) causing
> >>>> topology
> >>>>> hangings.
> >>>>>
> >>>>
> >>>> Sure. There are a lot of features being added. Would be nice to assign
> >> a
> >>>> release manager for Ignite 2.0 and document all the discussed features
> >> on
> >>>> the Wiki.
> >>>>
> >>>>
> >>>>>
> >>>>> --Yakov
> >>>>>
> >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >> alexey.goncharuk@gmail.com
> >>>> :
> >>>>>
> >>>>>> 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
> >> comes
> >>> to
> >>>>> the
> >>>>>> next major version release.
> >>>>>>
> >>>>>> My question for now is how should we track such tasks? Should it
> >> be a
> >>>>>> label, a parent task with subtasks, something else?
> >>>>>>
> >>>>>> I would go with a label + release version.
> >>>>>>
> >>>>>> --AG
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Ignite 2.0 tasks/roadmap

Posted by Denis Magda <dm...@gridgain.com>.
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 <https://issues.apache.org/jira/browse/IGNITE-3495>

—
Denis

> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> 
> 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 2:41 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> 
>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yz...@apache.org> 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
>>> 
>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
>>> 
>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <yz...@apache.org>
>>>> 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 may
>>>> block
>>>>> internal component notification (e.g. on discovery event) causing
>>>> topology
>>>>> hangings.
>>>>> 
>>>> 
>>>> Sure. There are a lot of features being added. Would be nice to assign
>> a
>>>> release manager for Ignite 2.0 and document all the discussed features
>> on
>>>> the Wiki.
>>>> 
>>>> 
>>>>> 
>>>>> --Yakov
>>>>> 
>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
>> alexey.goncharuk@gmail.com
>>>> :
>>>>> 
>>>>>> 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
>> comes
>>> to
>>>>> the
>>>>>> next major version release.
>>>>>> 
>>>>>> My question for now is how should we track such tasks? Should it
>> be a
>>>>>> label, a parent task with subtasks, something else?
>>>>>> 
>>>>>> I would go with a label + release version.
>>>>>> 
>>>>>> --AG
>>>>>> 
>>>>> 
>>>> 
>>> 
>>

Re: Ignite 2.0 tasks/roadmap

Posted by Yakov Zhdanov <yz...@apache.org>.
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 2:41 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:

> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yz...@apache.org> 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
> >
> > 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> >
> > > On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <yz...@apache.org>
> > > 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 may
> > > block
> > > > internal component notification (e.g. on discovery event) causing
> > > topology
> > > > hangings.
> > > >
> > >
> > > Sure. There are a lot of features being added. Would be nice to assign
> a
> > > release manager for Ignite 2.0 and document all the discussed features
> on
> > > the Wiki.
> > >
> > >
> > > >
> > > > --Yakov
> > > >
> > > > 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> alexey.goncharuk@gmail.com
> > >:
> > > >
> > > > > 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
> comes
> > to
> > > > the
> > > > > next major version release.
> > > > >
> > > > > My question for now is how should we track such tasks? Should it
> be a
> > > > > label, a parent task with subtasks, something else?
> > > > >
> > > > > I would go with a label + release version.
> > > > >
> > > > > --AG
> > > > >
> > > >
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yz...@apache.org> 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
>
> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
>
> > On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <yz...@apache.org>
> > 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 may
> > block
> > > internal component notification (e.g. on discovery event) causing
> > topology
> > > hangings.
> > >
> >
> > Sure. There are a lot of features being added. Would be nice to assign a
> > release manager for Ignite 2.0 and document all the discussed features on
> > the Wiki.
> >
> >
> > >
> > > --Yakov
> > >
> > > 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <alexey.goncharuk@gmail.com
> >:
> > >
> > > > 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 comes
> to
> > > the
> > > > next major version release.
> > > >
> > > > My question for now is how should we track such tasks? Should it be a
> > > > label, a parent task with subtasks, something else?
> > > >
> > > > I would go with a label + release version.
> > > >
> > > > --AG
> > > >
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Yakov Zhdanov <yz...@apache.org>.
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 <ds...@apache.org>:

> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <yz...@apache.org>
> 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 may
> block
> > internal component notification (e.g. on discovery event) causing
> topology
> > hangings.
> >
>
> Sure. There are a lot of features being added. Would be nice to assign a
> release manager for Ignite 2.0 and document all the discussed features on
> the Wiki.
>
>
> >
> > --Yakov
> >
> > 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
> >
> > > 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 comes to
> > the
> > > next major version release.
> > >
> > > My question for now is how should we track such tasks? Should it be a
> > > label, a parent task with subtasks, something else?
> > >
> > > I would go with a label + release version.
> > >
> > > --AG
> > >
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <yz...@apache.org> 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 may block
> internal component notification (e.g. on discovery event) causing topology
> hangings.
>

Sure. There are a lot of features being added. Would be nice to assign a
release manager for Ignite 2.0 and document all the discussed features on
the Wiki.


>
> --Yakov
>
> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
>
> > 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 comes to
> the
> > next major version release.
> >
> > My question for now is how should we track such tasks? Should it be a
> > label, a parent task with subtasks, something else?
> >
> > I would go with a label + release version.
> >
> > --AG
> >
>

Re: Ignite 2.0 tasks/roadmap

Posted by Yakov Zhdanov <yz...@apache.org>.
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
hangings.

--Yakov

2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:

> 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 comes to the
> next major version release.
>
> My question for now is how should we track such tasks? Should it be a
> label, a parent task with subtasks, something else?
>
> I would go with a label + release version.
>
> --AG
>