Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <36A4C1FB-C177-4C0D-A5A4-366081DAF82D@gridgain.com>
References: <CABDss3iLRmQW3jzubDzkjiYZjMrG5wRiK+aiWG_A1sQr+isrHQ@mail.gmail.com>
 <CAGcMBHgw6UM7SVNT+TgCFC+g6BZ=O-wDew+PhYT+v0CXo7vH+A@mail.gmail.com>
 <CA+0=VoUx1R11GpkYrH=gEKpw1==BGH=H5yWPR-Yj4BwuTmAzCg@mail.gmail.com>
 <CAGcMBHhugRxBugYkbOERRvWi8TLr9D9eV8+s-qDama=FBmNOgA@mail.gmail.com>
 <CA+0=VoXAdDwaXSH42UMRnN_OL+Vxs3=67J0omtrN-toKe5jpJw@mail.gmail.com>
 <CAGcMBHhoGv1Yz1x8LGu6a430UUvpcs6BR3DLBsUPxOr3vhGONA@mail.gmail.com>
 <50866D6B-2E72-4DFF-8B0C-26511CA5DE0E@gridgain.com> <CALH+G9o5EJfbe-auZrrcgVA9ZycFXDXPdw5oZ1ePMbqtC+jK=w@mail.gmail.com>
 <CA+0=VoVefda+4H4f6VgaTBwPDnj3zBKRkYMu8x3Jtw18_0XieA@mail.gmail.com>
 <CAMbfdjY9id2kt69mUF08zJa1M1SfWMWGKcvjiumwTZ2w=QxewQ@mail.gmail.com>
 <CA+eZwrEO7cvbPnLJRBtsYkuDgmYCHsReg6r-X-+k9AowagNuPg@mail.gmail.com>
 <CAMbfdjbEPP-=n5Eftww1cHKJoEs6QLK147Vtei2gEe==C-68ug@mail.gmail.com>
 <CALH+G9rymNw=YW4AuzgHf6ctmQxKm3CGsJPpQWFcvhtk3QT_qw@mail.gmail.com>
 <CAMbfdjZiiBysCSdTRpdiyFsC72a+-Q8tB0ptOj2ckkUjx6pjGg@mail.gmail.com>
 <CA+0=VoXnabDiFFcvreZA04qRMkXTDiR4pt8CPNnpc6KGdriAKg@mail.gmail.com>
 <CABuYRcoBqXWG+5xJzT_i0q-MEo0NufLbV5=ykxwtB7-rYu0vvg@mail.gmail.com>
 <0715BD29-9D92-414E-AB2B-187F87BB8E4C@gridgain.com> <CA+0=VoUqo4EXcq9ei45i634D-BA7VW++_GaP-Nn4HR2VAeOyvw@mail.gmail.com>
 <CAMbfdjYnrExZdrXH=nSvz1EbC3ooj-VzJKoRd43eYf33MOTN2A@mail.gmail.com>
 <CA+0=VoXsfDLNRrVnH3+qeEAa-yOSdLbxck4zUiWzgOcxeDvzQw@mail.gmail.com>
 <38F84FB5-0A3F-4885-A194-AD8762DDB769@gridgain.com> <CALH+G9pK8aCECCXkCrOCN4Ub-w+uzyq1_Ra+waEQt-gp8W=5FA@mail.gmail.com>
 <CAMbfdjaR0tG1vmRhh_D3qSrUwzuwQj-5DsVvKTZyYwzFHzgmew@mail.gmail.com>
 <0CA68644-0586-4B08-B29A-5012BA44B180@gridgain.com> <CAGt6o8kbCg32yUTb992_AryjDaksjgmZO1z290=9ZbhTeKJ_vw@mail.gmail.com>
 <CAMbfdjYyGxyGaNC7WW3r1at=6+h0FZVw_SHLFupfXjRY05BUCQ@mail.gmail.com>
 <5D5C865C-4BA4-4F11-B3F3-A3E0EB8B1F2A@gridgain.com> <CAMbfdjY4MUO4Z7L90v5bu26DvDg_nUqp-OY5f8d9SCrj-0R2og@mail.gmail.com>
 <36A4C1FB-C177-4C0D-A5A4-366081DAF82D@gridgain.com>
From: Alexey Goncharuk <alexey.goncharuk@gmail.com>
Date: Tue, 1 Nov 2016 12:39:32 +0300
Message-ID: <CABDss3jXFmUwOmBbTUqf7tSACDYoDSREP8uP1kmKUEjGLL7Viw@mail.gmail.com>
Subject: Re: Ignite 2.0 tasks/roadmap
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=f403045e221e0b03bf05403a1a23
archived-at: Tue, 01 Nov 2016 09:39:40 -0000

--f403045e221e0b03bf05403a1a23
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <dmagda@gridgain.com>:

> I=E2=80=99ve 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=E2=80=99t deprecate anything until the next version gets rel=
eased ;)
>
> =E2=80=94
> Denis
>
> > On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <skozlov@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. I=
t
> > 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 <dmagda@gridgain.com> wrote=
:
> >
> >> Sergey,
> >>
> >> I do agree with you that Ignite=E2=80=99s REST API implementation has =
to be
> >> revisited. Your concerns sound reasonable. But personally I wouldn=E2=
=80=99t
> rush
> >> trying to release it under 2.0 because NodeJS won=E2=80=99t 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?
> >>
> >> =E2=80=94
> >> Denis
> >>
> >>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skozlov@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 <vozerov@gridgain.co=
m
> >
> >>> 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 t=
he
> >> new
> >>>> one.with blackjack and etc..
> >>>>
> >>>> On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda <dmagda@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=E2=80=99t in=
troduce
> the
> >>>> next
> >>>>> version of REST API implementation before NodeJS component is done.
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> >>>>>
> >>>>> =E2=80=94
> >>>>> Denis
> >>>>>
> >>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <skozlov@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 <
> >>>>> akuznetsov@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 <dmagda@gridgain.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> I would move it to 2.1 or 2.2.
> >>>>>>>>
> >>>>>>>> =E2=80=94
> >>>>>>>> Denis
> >>>>>>>>
> >>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> >>>> dsetrakyan@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 <
> >> skozlov@gridgain.com
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi
> >>>>>>>>>>
> >>>>>>>>>> I suppose we should redesign HTTP REST API. We've a dozen issu=
es
> >>>>>>> around
> >>>>>>>> the
> >>>>>>>>>> REST implementation and the provided functionality is very
> limited
> >>>>> and
> >>>>>>>>>> doesn't follow last changes for Ignite. The most suitable tick=
et
> >> 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 <
> >>>>>>>> dsetrakyan@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 i=
s
> >>>> 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 <
> dmagda@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=E2=80=
=99ve
> >> 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 brea=
k
> >> the
> >>>>>>>>>>>> compatibility and we postpone fixing them in minor release o=
r
> >>>> they
> >>>>>>>>>> bring
> >>>>>>>>>>>> significant improvements into the product. Please review the
> >>>> page,
> >>>>>>>>>>> provide
> >>>>>>>>>>>> your comments and assign the tickets on yourself if you=E2=
=80=99re
> ready
> >>>> to
> >>>>>>>>>> work
> >>>>>>>>>>> on
> >>>>>>>>>>>> them.
> >>>>>>>>>>>>
> >>>>>>>>>>>> =E2=80=94
> >>>>>>>>>>>> Denis
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> >>>>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> There is one more use case where several types per cache ca=
n
> 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 transactio=
n
> is
> >>>>>>>>>>>> collocated
> >>>>>>>>>>>>> and all types are in the same cache, it works, because ther=
e
> 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 th=
e
> >>>>>>> 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 <
> >>>>>>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> >>>>>>>>>> skozlov@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 nam=
es
> >>>> 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 <
> >>>>>>>>>>>>>> akuznetsov@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 =D0=90=D0=B2=D0=B3 2016 =D0=B3. 22:06 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Sergey Kozlov" <
> >>>>>>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>>>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I mean not only SQL features for caches. Single type pe=
r
> >>>> 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.vladykin@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 <
> >>>>>>> skozlov@gridgain.com
> >>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> HI
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Due to approach to disable to store more than one typ=
e
> >> 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 <
> >>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignit=
e
> >>>> 2.0?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Why?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module suppor=
t
> 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 stil=
l
> >>>> using
> >>>>>>>>>>>>>> 2.10?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>>>>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Let=E2=80=99s add this [1] issue to the list becau=
se 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>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> =E2=80=94
> >>>>>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>> yzhdanov@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 t=
ry
> >> 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 <
> >>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> One more point.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I insist on stop using marshaller and meta cach=
es
> >>>> 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 <
> >>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdano=
v
> <
> >>>>>>>>>>>>>>>>>>>>> yzhdanov@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 al=
l
> >> the
> >>>>>>>>>>>>>>>>> discussed
> >>>>>>>>>>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>> the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> --Yakov
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>>>>>> alexey.goncharuk@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 anythin=
g
> >>>>>>>>>>>>>> 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, somethin=
g
> >>>> 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
>
>

--f403045e221e0b03bf05403a1a23--