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
|