ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Fri, 09 Sep 2016 17:53:47 GMT
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