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 Thu, 10 Nov 2016 14:57:03 GMT
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


Mime
View raw message