ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Ignite 2.0 tasks/roadmap
Date Sat, 03 Sep 2016 18:28:41 GMT
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
> >>>
> >>
>
>

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