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 <dma...@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.kuliche...@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 < > dsetrak...@apache.org> > > wrote: > > > >> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <skoz...@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 < > >> akuznet...@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" < > >> skoz...@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.vlady...@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 <skoz...@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 < > >>>>> dsetrak...@apache.org > >>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov < > >>>>>>> akuznet...@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 < > >>>> dma...@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 < > >>>>> yzhda...@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 < > >>>>>> dsetrak...@apache.org > >>>>>>>> : > >>>>>>>>>>> > >>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov < > >>>>>>> yzhda...@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 < > >>>>>>>> dsetrak...@apache.org > >>>>>>>>>> : > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < > >>>>>>>>> yzhda...@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.goncha...@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 > >>> > >> > >
