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
