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 <[email protected]> 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 <[email protected]> wrote: > > > I would move it to 2.1 or 2.2. > > > > — > > Denis > > > > > On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <[email protected]> > > 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 <[email protected]> > > 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 < > > [email protected]> > > >> 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 <[email protected]> > > 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 < > > >>>> [email protected]> 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 < > > >>>> [email protected]> > > >>>>> wrote: > > >>>>> > > >>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov < > > >> [email protected]> > > >>>>>> 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 < > > >>>>>> [email protected] > > >>>>>>>> > > >>>>>>> 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" < > > >>>>>> [email protected]> > > >>>>>>>> написал: > > >>>>>>>> > > >>>>>>>>> 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 < > > >>>>>>>> [email protected]> > > >>>>>>>>> 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 < > [email protected] > > >>> : > > >>>>>>>>>> > > >>>>>>>>>>> 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 < > > >>>>>>>>> [email protected] > > >>>>>>>>>>> > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov < > > >>>>>>>>>>> [email protected]> > > >>>>>>>>>>>> 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 < > > >>>>>>>> [email protected]> > > >>>>>>>>>>>> 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 < > > >>>>>>>>> [email protected]> > > >>>>>>>>>>>>> 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 < > > >>>>>>>>>> [email protected] > > >>>>>>>>>>>> : > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov < > > >>>>>>>>>>> [email protected]> > > >>>>>>>>>>>>>> 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 < > > >>>>>>>>>>>> [email protected] > > >>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < > > >>>>>>>>>>>>> [email protected]> > > >>>>>>>>>>>>>>>>>> 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 < > > >>>>>>>>>>>>>>>> [email protected] > > >>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> 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
