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 Tue, 02 Aug 2016 16:09:06 GMT
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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


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