ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Tue, 01 Nov 2016 09:39:32 GMT
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
>
>

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