ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Ignite 2.0 tasks/roadmap
Date Tue, 17 Jan 2017 17:54:22 GMT
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 <skozlov@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 <dmagda@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 <skozlov@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 <dmagda@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 <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.
> > > >> 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 <dmagda@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message