ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 10 Nov 2016 09:27:54 GMT
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

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