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
