Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+0=VoV0pvzfdz3fzAeAPpzHs=siwJPjbq2n0d4ZH1CUXrNQFA@mail.gmail.com>
References: <CABDss3iLRmQW3jzubDzkjiYZjMrG5wRiK+aiWG_A1sQr+isrHQ@mail.gmail.com>
	<CABDss3h1cXUk_r-9EJLYQo1pQ5ZJ_tRCmDKT7zf6+O_ObCtuUg@mail.gmail.com>
	<CAGcMBHjxyoO58aWVbV3r8jOh0apQfhAoiD_wLjefrQjwpJiR+w@mail.gmail.com>
	<CAGt6o8kQSNpGb7bgAQmk95sjdaFgUSgYvjZvaWdCRN_g=3H_5w@mail.gmail.com>
	<CA+0=VoV0pvzfdz3fzAeAPpzHs=siwJPjbq2n0d4ZH1CUXrNQFA@mail.gmail.com>
Date: Thu, 14 Jul 2016 18:35:23 +0300
Message-ID: <CAGt6o8kDF1PbZpMGB0m930ow3O6nZz4kQs=w6LCV3O-sTW-wcg@mail.gmail.com>
Subject: Re: Ignite 2.0 tasks/roadmap
From: Vladimir Ozerov <vozerov@gridgain.com>
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c122a9a1774cb05379a40c8
archived-at: Thu, 14 Jul 2016 15:35:35 -0000

--94eb2c122a9a1774cb05379a40c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yakov, I am not sure we fixed it. Plus sometimes we encode missing value as
-1, so it is written as 4 bytes still.

Dmitry, to my knowledge Unsafe will be available only when special VM flag
is set. It is not a problem for ignite.sh, but may cause usability issues
when running in embedded mode. Moreover, some methods will be removed from
Unsafe, e.g. monitorEnter(). So I doubt we even compilable with Java 9 now.

14 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3. 16:27 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Dmitriy Setrakyan" <
dsetrakyan@apache.org> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> Vova, why Unsafe removal? To my knowledge, Unsafe still remains in Java 9=
,
> no?
>
> On Thu, Jul 14, 2016 at 4:09 PM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > Several points from my side:
> > 1) Java 9 support - Unsafe removal, modules, etc..
> > 2) Rework our "messages" subsystem - we always read/write all fields,
> thus
> > transferring lots of zeros without any reason. We should support
> branching.
> > 3) Review all messages (especially cache, double-especially - atomic) i=
n
> > terms of performance. Most probably we will refactor/split some of them=
.
> >
> > 14 =D0=B8=D1=8E=D0=BB=D1=8F 2016 =D0=B3. 12:06 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C "Yakov Zhdanov" <yzhdanov@=
apache.org>
> > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> >
> > > Alex, a lot of excitement for Ignite-2.0 from my side! =3D)
> > >
> > > I agree with your points and I will take a close look at them in the
> > > nearest future.
> > >
> > > Here are some suggestions from me.
> > >
> > > I don't remember if I shared my thoughts on moving to single TCP port
> per
> > > node. So, I filed a new ticket -
> > > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> > > another one let's merge them.
> > >
> > > I would also think over removing communication SPI and discovery SPI
> and
> > > introducing communication and discovery processors instead. In some
> > places
> > > Ignite pretty much relies on internal implementation details of these
> > SPIs
> > > which makes implementation of any other SPI pretty complex task. Btw,
> did
> > > anyone did that? Removing SPIs will allow us to cleanup the code and
> use
> > > common abstractions and logic.
> > >
> > > I will give some more ideas going forward.
> > >
> > > Thanks!
> > >
> > > --Yakov
> > >
> > > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <alexey.goncharuk@gmail.co=
m
> >:
> > >
> > > > So, no excitement about Ignite 2.0? :)
> > > >
> > > > I went ahead and created a 2.0 version in Ignite Jira, and included
> the
> > > > following tickets so far based on the chance that this ticket will
> > > require
> > > > breaking changes in APIs/Configuration
> > > >  - IGNITE-3469 - Get rid of deprecated APIs and code
> > > >  - IGNTIE-3477 - Rework offheap storage
> > > >  - IGNITE-3478 - Transactional SQL
> > > >  - IGNITE-1605 - Provide stronger data loss check
> > > >  - IGNITE-3306 - Extend IgniteCluster interface with the methods to
> > send
> > > > and receive custom discovery events
> > > >
> > > > I believe that there are many more changes that we wanted to make b=
ut
> > > > delayed because they would break binary compatibility, so if you ha=
ve
> > > > something in mind - it's time to create a ticket or assign it to 2.=
0
> if
> > > it
> > > > exists. It's good to know the scope of work.
> > > >
> > > > Also, it would be great if you review/comment the above-mentioned
> > > tickets.
> > > >
> > > > Thanks,
> > > > AG
> > > >
> > >
> >
>

--94eb2c122a9a1774cb05379a40c8--