On Tue, Jan 17, 2017 at 8:35 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote:
> Guys, > > Do you think there is any reason to keep optimized marshaller on public API > in Ignite 2.0? It has several disadvantages, the major being non-conformant > with Java serialization guarantees(namely, the inability to add/remove > fields). On the other hand, Binary marshaller supports all this and much > more, and as fast as optimized. > > Given that Binary marshaller rolls back to optimized in case of > Externalizable or presence of writeReplace/readResolve, I think it makes > sense just to move it to the private package. > > Another positive effect - this will almost halve the number of test suites > we need to run on TC. > > Thoughts? > No objections from me. Although, we should still make sure that we run all the Externalizable test suites with Binary Marshaller. > > 2016-11-10 18:34 GMT+03:00 Sergey Kozlov <skoz...@gridgain.com>: > > > IGNITE-4211 Update Sprint dependency to latest stable version > > <https://issues.apache.org/jira/browse/IGNITE-4211> > > > > On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dma...@gridgain.com> > wrote: > > > > > Sound reasonable. Please create a ticket and paste it number into this > > > discussion. > > > > > > — > > > Denis > > > > > > > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <skoz...@gridgain.com> > > wrote: > > > > > > > > Hi > > > > > > > > It seems the Spring dependency looks outdated for now. Apache Ignite > > > still > > > > uses 4.1.0 released two years ago. Could we include to the list of > > issues > > > > for the release 2.0 to update to latest stable version (4.3.4 at the > > > > moment)? > > > > > > > > On Tue, Nov 1, 2016 at 12:39 PM, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com> wrote: > > > > > > > >> Yakov, > > > >> > > > >> I've created a ticket for using discovery custom events instead of > > > >> marshaller cache: https://issues.apache.org/jira/browse/IGNITE-4157 > > > >> > > > >> Guys, feel free to comment. > > > >> > > > >> Thanks! > > > >> AG > > > >> > > > >> 2016-09-09 20:53 GMT+03:00 Denis Magda <dma...@gridgain.com>: > > > >> > > > >>> I’ve created an umbrella ticket for REST > > > >>> https://issues.apache.org/jira/browse/IGNITE-3879 < > > > >>> https://issues.apache.org/jira/browse/IGNITE-3879> > > > >>> > > > >>> And I wouldn’t deprecate anything until the next version gets > > released > > > ;) > > > >>> > > > >>> — > > > >>> Denis > > > >>> > > > >>>> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <skoz...@gridgain.com> > > > >> wrote: > > > >>>> > > > >>>> Denis > > > >>>> > > > >>>> Generally I'm fine for your approach. I think for 2.0 (or may be > > for a > > > >>> next > > > >>>> 1.x minor version) we can note that currently REST API is > > deprecated. > > > >> It > > > >>>> will allow us to replace REST by a new implementation once it will > > be > > > >>> done. > > > >>>> > > > >>>> On Fri, Sep 9, 2016 at 4:11 PM, Denis Magda <dma...@gridgain.com> > > > >> wrote: > > > >>>> > > > >>>>> Sergey, > > > >>>>> > > > >>>>> I do agree with you that Ignite’s REST API implementation has to > be > > > >>>>> revisited. Your concerns sound reasonable. But personally I > > wouldn’t > > > >>> rush > > > >>>>> trying to release it under 2.0 because NodeJS won’t be a part of > > this > > > >>>>> release while it can propose additional requirements to the next > > > >>> generation > > > >>>>> of REST API implementation. > > > >>>>> > > > >>>>> Does it make sense to you? > > > >>>>> > > > >>>>> — > > > >>>>> Denis > > > >>>>> > > > >>>>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skoz...@gridgain.com > > > > > >>> wrote: > > > >>>>>> > > > >>>>>> Vova, > > > >>>>>> > > > >>>>>> There are more issues than processing (String, String) only: we > > > can't > > > >>>>>> process JSON objects as values, current implementation doesn't > > > follow > > > >>>>>> general RESTfull API requirements. > > > >>>>>> Moreover we're still have no connectors for PHP, Python and > other > > > >>> popular > > > >>>>>> languages for web development of LAMP market and REST API is a > > > single > > > >>> way > > > >>>>>> get access to Apache Ignite. > > > >>>>>> > > > >>>>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov < > > > >> voze...@gridgain.com > > > >>>> > > > >>>>>> wrote: > > > >>>>>> > > > >>>>>>> Denis, > > > >>>>>>> > > > >>>>>>> Very good catch! Our REST API in ir is current appearance are > > > >>> virtually > > > >>>>>>> useless because it only operates on strings. We'd better to > > design > > > >> the > > > >>>>> new > > > >>>>>>> one.with blackjack and etc.. > > > >>>>>>> > > > >>>>>>> On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda < > dma...@gridgain.com > > > > > > >>>>> wrote: > > > >>>>>>> > > > >>>>>>>> Basically, we can have two versions of the REST API if we want > > to > > > >>> care > > > >>>>>>>> about the compatibility and remove the old one (deprecated) at > > > some > > > >>>>> point > > > >>>>>>>> of time. Moreover, NodeJS feature [1] can highly influence on > > the > > > >>> next > > > >>>>>>>> generation of our REST API implementation. So I wouldn’t > > introduce > > > >>> the > > > >>>>>>> next > > > >>>>>>>> version of REST API implementation before NodeJS component is > > > done. > > > >>>>>>>> > > > >>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961 > > > >>>>>>>> > > > >>>>>>>> — > > > >>>>>>>> Denis > > > >>>>>>>> > > > >>>>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov < > > skoz...@gridgain.com> > > > >>>>>>> wrote: > > > >>>>>>>>> > > > >>>>>>>>> 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 < > > > >>>>>>>> akuznet...@gridgain.com> > > > >>>>>>>>> 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 < > > > dma...@gridgain.com > > > >>> > > > >>>>>>>> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>>> I would move it to 2.1 or 2.2. > > > >>>>>>>>>>> > > > >>>>>>>>>>> — > > > >>>>>>>>>>> Denis > > > >>>>>>>>>>> > > > >>>>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan < > > > >>>>>>> dsetrak...@apache.org> > > > >>>>>>>>>>> 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 < > > > >>>>> 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 > > > >>>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> -- > > > >>>>>>>>>> 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 > > > > > > > > > > > > -- > > Sergey Kozlov > > GridGain Systems > > www.gridgain.com > > >
