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 Wed, 07 Sep 2016 22:58:28 GMT
Sergey, I don't think we can fit redesigning of HTTP/REST into our 2.0
release. The 2.0 already looks pretty packed. Perhaps we should plan it for
the release after, like 2.1?

On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <skozlov@gridgain.com> wrote:

> Hi
>
> I suppose we should redesign HTTP REST API. We've a dozen issues around the
> REST implementation and the provided functionality is very limited and
> doesn't follow last changes for Ignite. The most suitable ticket is
> IGNITE-1774
> REST API should be implemented using Jersey
> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably we need
> to
> have a root ticket for that.
>
> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
> > Denis, thanks for taking a role of a release manger for 2.0. It is
> > definitely an important release for us and good supervision is going to
> be
> > very helpful.
> >
> > I have looked at the tickets and the list seems nice. I would also add a
> > ticket about migration of the JTA dependency to Geronimo as well,
> > IGNITE-3793 [1], however I am not sure if we might be able to do it prior
> > to 2.0.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >
> > D.
> >
> > On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dmagda@gridgain.com> wrote:
> >
> > > Community,
> > >
> > > Let me take a role of the release manager for Apache Ignite 2.0 and
> > > coordinate the process.
> > >
> > > So, my personal view is that Apache Ignite 2.0 should be released by
> the
> > > end of the year. This sounds like a good practice to make a major
> release
> > > once a year. I would suggest us following the same rule.
> > >
> > > Actual we have more than 3 month for development and I’ve prepare the
> > wiki
> > > page that contains tickets that are required to be released in 2.0 and
> > that
> > > are optional
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
> > >
> > > Proposed release date is December 23rd, 2016.
> > >
> > > The tickets that are required for the release basically break the
> > > compatibility and we postpone fixing them in minor release or they
> bring
> > > significant improvements into the product. Please review the page,
> > provide
> > > your comments and assign the tickets on yourself if you’re ready to
> work
> > on
> > > them.
> > >
> > > —
> > > Denis
> > >
> > > > On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > > >
> > > > There is one more use case where several types per cache can be
> useful
> > (I
> > > > know that it's utilized by some of our users). The use case is the
> > > > following: transactional updates with write-behind and foreign key
> > > > constraints on the database. In case data within transaction is
> > > collocated
> > > > and all types are in the same cache, it works, because there is only
> > one
> > > > write-behind queue. Once we split different types into different
> > caches,
> > > > there is no guarantee that objects will be written in the proper
> order
> > > and
> > > > that the constraints will not be violated.
> > > >
> > > > However, I think this is not a very clean way to achieve the result.
> > > > Probably we should just provide better support for this use case in
> > 2.0.
> > > > Basically, we somehow need to allow to share a single write-behind
> > queue
> > > > between different caches.
> > > >
> > > > Any thoughts?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > > wrote:
> > > >
> > > >> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <
> skozlov@gridgain.com>
> > > >> wrote:
> > > >>
> > > >>> Alexey
> > > >>>
> > > >>> You're right. Of course I meant growth of caches number.
> > > >>>
> > > >>> I see a few points here:
> > > >>>
> > > >>> 1. If a grid used by various applications the cache names may
> overlap
> > > >> (like
> > > >>> "accounts") and the application needs to use prefixed names and
> etc.
> > > >>> 2. For clear or destory caches I need to know their names (or
> iterate
> > > >> over
> > > >>> caches but I'm not sure that it is supported by API). For
> > destroy/clear
> > > >>> caches belonging to same group we will do it by single operation
> > > without
> > > >>> knowledge of cache names.
> > > >>> 3. Cache group can have cache attributes which will be inherited
> by a
> > > >> cache
> > > >>> created in that group (like eviction policy or cache mode).
> > > >>> 4. No reason to add specific feature like SqlShema if it applicable
> > for
> > > >>> regular caches as well.
> > > >>>
> > > >>
> > > >> Sergey K, setting the same SQL schema for multiple caches, as
> proposed
> > > by
> > > >> Sergi, solves a different problem of having too many SQL schemas due
> > to
> > > too
> > > >> many different caches. I think Sergi proposed a good solution for
> it.
> > > >>
> > > >>
> > > >>>
> > > >>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> > > >> akuznetsov@gridgain.com
> > > >>>>
> > > >>> wrote:
> > > >>>
> > > >>>> Sergey, I belive you mean "increase" instead of "reduce"?
> > > >>>>
> > > >>>> How grouping will help?
> > > >>>> To do some operation, for example, clear on group of cashes
at
> once?
> > > >>>>
> > > >>>> 11 Авг 2016 г. 22:06 пользователь "Sergey
Kozlov" <
> > > >> skozlov@gridgain.com>
> > > >>>> написал:
> > > >>>>
> > > >>>>> I mean not only SQL features for caches. Single type per
cache
> > > >>> definitely
> > > >>>>> reduces number of caches for regular user and grouping
caches
> will
> > > >> help
> > > >>>> to
> > > >>>>> manage caches in grid.
> > > >>>>>
> > > >>>>> On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin <
> > > >>>> sergi.vladykin@gmail.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> I'm aware of this issue. My plan was to allow setting
the same
> > > >> schema
> > > >>>>> name
> > > >>>>>> to different caches using CacheConfiguration.setSqlSchema(...).
> > > >> This
> > > >>>> way
> > > >>>>>> we
> > > >>>>>> will have separate caches but from SQL point of view
respective
> > > >>> tables
> > > >>>>> will
> > > >>>>>> reside in the same schema. No need to introduce new
concepts.
> > > >>>>>>
> > > >>>>>> Sergi
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com
> >:
> > > >>>>>>
> > > >>>>>>> HI
> > > >>>>>>>
> > > >>>>>>> Due to approach to disable to store more than
one type per
> cache
> > > >>> the
> > > >>>>>> cache
> > > >>>>>>> use becomes similar the table use for databases.
> > > >>>>>>> So I suppose would be good to introduce a
> database/schema-similar
> > > >>>>> concept
> > > >>>>>>> for caches. It may be implemented as a non-default
behavior for
> > > >>>>> backward
> > > >>>>>>> compatibility.
> > > >>>>>>>
> > > >>>>>>> On Sat, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan
<
> > > >>>>> dsetrakyan@apache.org
> > > >>>>>>>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov
<
> > > >>>>>>> akuznetsov@gridgain.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> I remember couple more thing for 2.0
> > > >>>>>>>>>
> > > >>>>>>>>> How about to drop **ignite-scalar** module
in Ignite 2.0?
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Why?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> And may be drop **ignite-spark-2.10**
module support as of
> > > >>>>> **Spark**
> > > >>>>>> 2
> > > >>>>>>> is
> > > >>>>>>>>> on **scala 2.11**.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> I would drop it only if it is difficult to
support. Do we know
> > > >>> what
> > > >>>>>> kind
> > > >>>>>>> of
> > > >>>>>>>> impact will it have on the community? Anyone
is still using
> > > >> 2.10?
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis
Magda <
> > > >>>> dmagda@gridgain.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Let’s add this [1] issue to the
list because it requires
> > > >>>>>> significant
> > > >>>>>>>> work
> > > >>>>>>>>>> on the side of metrics SPI.
> > > >>>>>>>>>>
> > > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3495
<
> > > >>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> > > >>>>>>>>>>
> > > >>>>>>>>>> —
> > > >>>>>>>>>> Denis
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov
Zhdanov <
> > > >>>>> yzhdanov@apache.org>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Not yet. The thing is that our
recent experience showed
> > > >>> that
> > > >>>> it
> > > >>>>>> was
> > > >>>>>>>> not
> > > >>>>>>>>>>> very good idea to go with caches.
E.g. when you try to
> > > >>>>>> deserialize
> > > >>>>>>>>> inside
> > > >>>>>>>>>>> continuous query listener on client
side it implicitly
> > > >>> calls
> > > >>>>>>>>> cache.get()
> > > >>>>>>>>>>> which in turn may cause deadlock
under some
> > > >> circumstances.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> --Yakov
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 2016-08-02 2:41 GMT+03:00 Dmitriy
Setrakyan <
> > > >>>>>> dsetrakyan@apache.org
> > > >>>>>>>> :
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46
AM, Yakov Zhdanov <
> > > >>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> One more point.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I insist on stop using
marshaller and meta caches but
> > > >>>> switch
> > > >>>>> to
> > > >>>>>>>>>> spreading
> > > >>>>>>>>>>>>> this info via custom discovery
events.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Do we have a ticket explaining
why this needs to be
> > > >> done?
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> --Yakov
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00
Dmitriy Setrakyan <
> > > >>>>>>>> dsetrakyan@apache.org
> > > >>>>>>>>>> :
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Jul 27, 2016
at 11:36 AM, Yakov Zhdanov <
> > > >>>>>>>>> yzhdanov@apache.org>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Guys, I think
we can also split event notification
> > > >> for
> > > >>>> user
> > > >>>>>>>>> listeners
> > > >>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>> internal system
listeners. I have been seeing a lot
> > > >> of
> > > >>>>> issues
> > > >>>>>>>>> caused
> > > >>>>>>>>>>>> by
> > > >>>>>>>>>>>>>>> some heavy or
blocking operations in user-defined
> > > >>>>> listeners.
> > > >>>>>>> This
> > > >>>>>>>>> may
> > > >>>>>>>>>>>>>> block
> > > >>>>>>>>>>>>>>> internal component
notification (e.g. on discovery
> > > >>> event)
> > > >>>>>>> causing
> > > >>>>>>>>>>>>>> topology
> > > >>>>>>>>>>>>>>> hangings.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Sure. There are a
lot of features being added. Would
> > > >> be
> > > >>>> nice
> > > >>>>>> to
> > > >>>>>>>>> assign
> > > >>>>>>>>>>>> a
> > > >>>>>>>>>>>>>> release manager for
Ignite 2.0 and document all the
> > > >>>>> discussed
> > > >>>>>>>>> features
> > > >>>>>>>>>>>> on
> > > >>>>>>>>>>>>>> the Wiki.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> --Yakov
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 2016-06-25 2:42
GMT+03:00 Alexey Goncharuk <
> > > >>>>>>>>>>>> alexey.goncharuk@gmail.com
> > > >>>>>>>>>>>>>> :
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Folks,
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Recently I
have seen a couple of emails suggesting
> > > >>>>>>>>>>>> tasks/improvements
> > > >>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>> we cannot
do in 1.x releases due to API
> > > >> compatibility
> > > >>>>>> reasons,
> > > >>>>>>>> so
> > > >>>>>>>>>>>>> they
> > > >>>>>>>>>>>>>>> are
> > > >>>>>>>>>>>>>>>> postponed
to 2.0. I would like to keep track of
> > > >> these
> > > >>>>> tasks
> > > >>>>>> in
> > > >>>>>>>>> some
> > > >>>>>>>>>>>>> way
> > > >>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>> our Jira to
make sure we do not have anything
> > > >> obsolete
> > > >>>>> when
> > > >>>>>> it
> > > >>>>>>>>>>>> comes
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>> next major
version release.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> My question
for now is how should we track such
> > > >> tasks?
> > > >>>>>> Should
> > > >>>>>>> it
> > > >>>>>>>>>>>> be a
> > > >>>>>>>>>>>>>>>> label, a parent
task with subtasks, something else?
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> I would go
with a label + release version.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> --AG
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Alexey Kuznetsov
> > > >>>>>>>>> GridGain Systems
> > > >>>>>>>>> www.gridgain.com
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Sergey Kozlov
> > > >>>>>>> GridGain Systems
> > > >>>>>>> www.gridgain.com
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Sergey Kozlov
> > > >>>>> GridGain Systems
> > > >>>>> www.gridgain.com
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Sergey Kozlov
> > > >>> GridGain Systems
> > > >>> www.gridgain.com
> > > >>>
> > > >>
> > >
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

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