You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Alexey Goncharuk <al...@gmail.com> on 2017/01/17 16:35:32 UTC
Re: Ignite 2.0 tasks/roadmap
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?
2016-11-10 18:34 GMT+03:00 Sergey Kozlov <sk...@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 <dm...@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 <sk...@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.goncharuk@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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.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 <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’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 <
> 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.
> > >>>>>>>>>>>
> > >>>>>>>>>>> —
> > >>>>>>>>>>> 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
> > >> 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 <
> > >>>>>>>>>>> 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
> > >> 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 <
> > >>> 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’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.kulichenko@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 <
> > >>>>>>>>>>>>>>> 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
> > >> 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 <
> > >>>>>>>>>>>>>>>>> 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 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > >>>>>>>>>>>>>>>>> skozlov@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.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
> > >> 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
> <
> > >>>>>>>>>>>>>>>>>>>> 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
> > >> 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 <
> > >>>>>>>>>>>>>>>>>>> dmagda@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 <
> > >>>>>>>>>>>>>>>>>>>> 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
> > >> 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 <
> > >>>>>>>>>>>>>>>>>>>>> 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
> > >> 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 <
> > >>>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > >>>>>>>>>>>>>>>>>>>>>>>>> :
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
> > >> Zhdanov
> > >>> <
> > >>>>>>>>>>>>>>>>>>>>>>>> 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
> > >> all
> > >>>>> 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
> > >> 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
>
Re: Ignite 2.0 tasks/roadmap
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Jan 17, 2017 at 8:35 AM, Alexey Goncharuk <
alexey.goncharuk@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 <sk...@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 <dm...@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 <sk...@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.goncharuk@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 <dm...@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 <sk...@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 <dm...@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 <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.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 <
> 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’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 <
> > 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.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> —
> > > >>>>>>>>>>> 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
> > > >> 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 <
> > > >>>>>>>>>>> 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
> > > >> 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 <
> > > >>> 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’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.kulichenko@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 <
> > > >>>>>>>>>>>>>>> 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
> > > >> 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 <
> > > >>>>>>>>>>>>>>>>> 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 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> > > >>>>>>>>>>>>>>>>> skozlov@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.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
> > > >> 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
> > <
> > > >>>>>>>>>>>>>>>>>>>> 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
> > > >> 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 <
> > > >>>>>>>>>>>>>>>>>>> dmagda@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 <
> > > >>>>>>>>>>>>>>>>>>>> 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
> > > >> 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
> <
> > > >>>>>>>>>>>>>>>>>>>>> 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
> > > >> 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 <
> > > >>>>>>>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> > > >>>>>>>>>>>>>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov
> > > >> Zhdanov
> > > >>> <
> > > >>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >> all
> > > >>>>> 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
> > > >> 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
> >
>