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, 08 Sep 2016 06:23:35 GMT
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
>> 


Mime
View raw message