You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Denis Magda <dm...@gridgain.com> on 2016/09/03 00:17:27 UTC
Re: Ignite 2.0 tasks/roadmap
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 <va...@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 <ds...@apache.org>
> wrote:
>
>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <sk...@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 <sk...@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
>>>
>>
Re: Ignite 2.0 tasks/roadmap
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Jan 17, 2017 at 8:35 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:
> Guys,
>
> Do you think there is any reason to keep optimized marshaller on public API
> in Ignite 2.0? It has several disadvantages, the major being non-conformant
> with Java serialization guarantees(namely, the inability to add/remove
> fields). On the other hand, Binary marshaller supports all this and much
> more, and as fast as optimized.
>
> Given that Binary marshaller rolls back to optimized in case of
> Externalizable or presence of writeReplace/readResolve, I think it makes
> sense just to move it to the private package.
>
> Another positive effect - this will almost halve the number of test suites
> we need to run on TC.
>
> Thoughts?
>
No objections from me. Although, we should still make sure that we run all
the Externalizable test suites with Binary Marshaller.
>
> 2016-11-10 18:34 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
>
> > IGNITE-4211 Update Sprint dependency to latest stable version
> > <https://issues.apache.org/jira/browse/IGNITE-4211>
> >
> > On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dm...@gridgain.com>
> wrote:
> >
> > > Sound reasonable. Please create a ticket and paste it number into this
> > > discussion.
> > >
> > > —
> > > Denis
> > >
> > > > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@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 <dm...@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 <sk...@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 <dm...@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
> > >
> > >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>
Re: Ignite 2.0 tasks/roadmap
Posted by Alexey Goncharuk <al...@gmail.com>.
Guys,
Do you think there is any reason to keep optimized marshaller on public API
in Ignite 2.0? It has several disadvantages, the major being non-conformant
with Java serialization guarantees(namely, the inability to add/remove
fields). On the other hand, Binary marshaller supports all this and much
more, and as fast as optimized.
Given that Binary marshaller rolls back to optimized in case of
Externalizable or presence of writeReplace/readResolve, I think it makes
sense just to move it to the private package.
Another positive effect - this will almost halve the number of test suites
we need to run on TC.
Thoughts?
2016-11-10 18:34 GMT+03:00 Sergey Kozlov <sk...@gridgain.com>:
> IGNITE-4211 Update Sprint dependency to latest stable version
> <https://issues.apache.org/jira/browse/IGNITE-4211>
>
> On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dm...@gridgain.com> wrote:
>
> > Sound reasonable. Please create a ticket and paste it number into this
> > discussion.
> >
> > —
> > Denis
> >
> > > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>
Re: Ignite 2.0 tasks/roadmap
Posted by Sergey Kozlov <sk...@gridgain.com>.
IGNITE-4211 Update Sprint dependency to latest stable version
<https://issues.apache.org/jira/browse/IGNITE-4211>
On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dm...@gridgain.com> wrote:
> Sound reasonable. Please create a ticket and paste it number into this
> discussion.
>
> —
> Denis
>
> > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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
>
>
--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Re: Ignite 2.0 tasks/roadmap
Posted by Denis Magda <dm...@gridgain.com>.
Sound reasonable. Please create a ticket and paste it number into this discussion.
—
Denis
> On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <dm...@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 <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <dm...@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 <sk...@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 <dm...@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 <sk...@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 <dm...@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 <sk...@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 <dm...@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
>
>
Re: Ignite 2.0 tasks/roadmap
Posted by Denis Magda <dm...@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 <sk...@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 <dm...@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 <sk...@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 <vo...@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 <dm...@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 <sk...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <dm...@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 <sk...@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 <vo...@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 <dm...@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 <sk...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Denis Magda <dm...@gridgain.com>.
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 <sk...@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 <vo...@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 <dm...@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 <sk...@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 <dm...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <vo...@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 <dm...@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 <sk...@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 <dm...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <dm...@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 <sk...@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 <dm...@gridgain.com>
> wrote:
> >>
> >>> I would move it to 2.1 or 2.2.
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@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 <sk...@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 <dm...@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
>
>
Re: Ignite 2.0 tasks/roadmap
Posted by Denis Magda <dm...@gridgain.com>.
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 <sk...@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 <ak...@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 <dm...@gridgain.com> wrote:
>>
>>> I would move it to 2.1 or 2.2.
>>>
>>> —
>>> Denis
>>>
>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@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 <sk...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <ak...@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 <dm...@gridgain.com> wrote:
>
> > I would move it to 2.1 or 2.2.
> >
> > —
> > Denis
> >
> > > On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@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 <sk...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
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 <dm...@gridgain.com> wrote:
> I would move it to 2.1 or 2.2.
>
> —
> Denis
>
> > On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@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 <sk...@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 <dm...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Denis Magda <dm...@gridgain.com>.
I would move it to 2.1 or 2.2.
—
Denis
> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <ds...@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 <sk...@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 <ds...@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 <dm...@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
>>
Re: Ignite 2.0 tasks/roadmap
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <sk...@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 <ds...@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 <dm...@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
>
Re: Ignite 2.0 tasks/roadmap
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <ds...@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 <dm...@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 <sk...@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 <sk...@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
Re: Ignite 2.0 tasks/roadmap
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <dm...@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 <sk...@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 <sk...@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
> >>>
> >>
>
>