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 <skoz...@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 <dsetrak...@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 <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 > > > >>> > > > >> > > > > > > > > > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com >
