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/07/14 01:43:04 UTC
Re: Ignite 2.0 tasks/roadmap
So, no excitement about Ignite 2.0? :)
I went ahead and created a 2.0 version in Ignite Jira, and included the
following tickets so far based on the chance that this ticket will require
breaking changes in APIs/Configuration
- IGNITE-3469 - Get rid of deprecated APIs and code
- IGNTIE-3477 - 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>.
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
>