Re: Apache Ignite 2.0 Release

[Dmitriy Setrakyan]

Awesome! Great addition to the project.

On Tue, Apr 11, 2017 at 8:27 PM, Denis Magda  wrote:

> Spring Data integration caught up the train and will be released in 2.0:
> https://issues.apache.org/jira/browse/IGNITE-1192 <
> https://issues.apache.org/jira/browse/IGNITE-1192>
>
> —
> Denis
>
> > On Apr 9, 2017, at 6:57 AM, Denis Magda  wrote:
> >
> > Val, yes, as far as I know we still need to merge to the master. The
> branch should be ready later the next week.
> >
> > Denis
> >
> > On Sat, Apr 8, 2017 at 6:14 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com >
> wrote:
> > Guys,
> >
> > There is no branch for 2.0 right now, correct? If I want to add something
> > there, do I just merge to master?
> >
> > -Val
> >
> > On Sat, Apr 8, 2017 at 10:18 AM, Alexander Paschenko <
> > alexander.a.pasche...@gmail.com >
> wrote:
> >
> > > I've fixed https://issues.apache.org/jira/browse/IGNITE-4354 <
> https://issues.apache.org/jira/browse/IGNITE-4354>, PR is
> > > https://github.com/apache/ignite/pull/1759  ignite/pull/1759>.
> > > Pavel, thank you very much for bringing that to my attention.
> > >
> > > - Alex
> > >
> > > 2017-04-07 20:28 GMT+03:00 Sergi Vladykin  >:
> > > > A bunch of SQL related tickets is delayed until H2 release on the
> next
> > > week.
> > > >
> > > > Sergi
> > > >
> > > > 2017-04-07 19:36 GMT+03:00 Alexey Goncharuk <
> alexey.goncha...@gmail.com 
> > > >:
> > > >
> > > >> Folks,
> > > >>
> > > >> The status of ignite-3477 is as follows: we've fixed almost all
> tests
> > > and
> > > >> currently waiting for ignite-4535 and ignite-4534 to be merged,
> which
> > > will
> > > >> happen once TC for those branches is completed. This should happen
> over
> > > the
> > > >> weekend.
> > > >>
> > > >> 2017-04-06 19:12 GMT+03:00 Alexey Kuznetsov  >:
> > > >>
> > > >> >  I've prepared
> > > >> >
> > > >> >  IGNITE-4349  https://issues.apache.org/jira/browse/IGNITE-4349>> -
> > > >> > Discontinue the schema-import utility
> > > >> >
> > > >> > Anton, could you review my changes related to Ignite *build*?
> > > >> > See: http://reviews.ignite.apache.org/ignite/review/IGNT-CR-163 <
> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-163>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Alexey Kuznetsov
> > > >> >
> > > >>
> > >
> >
>
>

Re: Move documentation from readme.io to GitHub pages

[Dmitriy Setrakyan]

Pavel,

We all agree that the documentation should be in our GIT repo in either
Markdown or AsciiDoc format. However, it is a very big undertaking to
migrate it from readme and properly structure it. If anyone in the
community would volunteer, would be great.

D.

On Tue, Apr 11, 2017 at 9:36 PM, Pavel Tupitsyn 
wrote:

> > Git approach is no way to go for us because all the documentation has to
> be hosted on ASF side
>
> Well, our Git repository [1] is hosted by ASF, isn't it?
> GitHub pages just generates HTML from MarkDown via Jekyll [2] static site
> generator.
>
> I understand the concern about GitHub pages, though.
> And Igor is right about different versions, seems like it may be not so
> easy with GH pages.
>
>
> So I propose to use Jekyll, but do not use GitHub pages:
> * Keep documentation in our Git repository in MarkDown format
> * Generate HTML when release comes out and upload it to ignite.apache.org
> (same as we do for API docs [3])
>
> Seems to be easy enough. The hardest part is to come up with a good
> template.
>
> Thoughts?
>
>
> [1] https://git-wip-us.apache.org/repos/asf?p=ignite.git
> [2] https://jekyllrb.com/
> [3] https://ignite.apache.org/releases/1.8.0/javadoc/
>
> On Tue, Apr 11, 2017 at 7:09 PM, Denis Magda  wrote:
>
> > Pavel,
> >
> > I totally agree that it’s becoming more and more inconvenient to run the
> > documentation on readme.io . At the same time the Git
> > approach is no way to go for us because all the documentation has to be
> > hosted on ASF side. Presently we violate this policy and I look forward
> we
> > fix it pretty soon.
> >
> > So, in general, all the documentation content has to become a part of
> > Apache Ignite site and available from there. Here are some of the
> examples
> > of another ASF projects:
> > http://spark.apache.org/docs/2.1.0/  >
> > https://zeppelin.apache.org/contribution/documentation.html <
> > https://zeppelin.apache.org/contribution/documentation.html>
> > https://hadoop.apache.org/docs/r2.7.2/  > docs/r2.7.2/>
> >
> > Are you aware of any ready-to-be-used documentation libs that can be
> > easily reused by us?
> >
> > —
> > Denis
> >
> > > On Apr 11, 2017, at 2:02 AM, Pavel Tupitsyn 
> > wrote:
> > >
> > > Igniters,
> > >
> > > Currently we host documentation on
> > > apacheignite.readme.io (and also apacheignite-net.readme.io,
> > > apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).
> > >
> > > readme.io has a lot of problems mostly due to lack of proper version
> > > control:
> > > * Each "version" is just a copy. When fixing something, you have to
> > update
> > > all versions.
> > > * No good way to review changes.
> > > * "Propose edit" functionality is a joke. You can only accept or reject
> > an
> > > edit, no way to communicate with contributor, etc
> > >
> > > GitHub Pages solves all these problems:
> > > https://github.com/blog/2233-publish-your-project-
> > documentation-with-github-pages
> > >
> > > Basically, we'll have a separate folder in our Git repository where
> > > documentation is stored in markdown format.
> > > This way the process for updating docs is exactly the same as any other
> > > code change.
> > > Pull request with new feature can contain the docs for this feature,
> and
> > so
> > > on.
> > >
> > > Thoughts?
> >
> >
>

Re: CREATE TABLE SQL command syntax

[Dmitriy Setrakyan]

Agree, the updated syntax looks better. One change though: KEY -> PRIMARY
KEY.

Sergi, what do you think?

D.

On Tue, Apr 11, 2017 at 9:50 PM, Pavel Tupitsyn 
wrote:

> I think "WITH" syntax is ugly and cumbersome.
>
> We should go with this one:
> CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> varchar, lastName varchar)
>
> All databases (i.e. [1], [2]) work this way, I see no reason to invent
> something different and confuse the users.
>
> [1]
> https://docs.microsoft.com/en-us/sql/t-sql/statements/create
> -table-transact-sql#syntax-1
> [2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html
>
> On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
> alexander.a.pasche...@gmail.com> wrote:
>
> > Dmitry,
> >
> > For H2 it would be something like this - please note all those quotes,
> > commas and equality signs that would be mandatory:
> >
> > CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
> > varchar) WITH "keyFields=id,uuid","affinityKey=id"
> >
> > With suggested approach, it would be something like
> >
> > CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> > varchar, lastName varchar)
> >
> > While this may not look like a drastic improvement in this particular
> > case, we someday most likely will want either an all-custom CREATE
> > CACHE command, or a whole bunch of new options for CREATE TABLE, if we
> > decide not to go with CREATE CACHE - I personally think that stuff
> > like
> >
> > CREATE TABLE ... WITH
> > "keyFields=id,uuid","affinityKey=id","cacheType=partitioned","atomicity=
> > atomic","partitions=3"
> >
> > which will arise if we continue to try to stuff everything into WITH
> > will just bring more ugliness with time, and that's not to mention
> > that new CREATE CACHE syntax will be impossible or relatively hard to
> > introduce as we will have to approve it with H2 folks, and that's how
> > it will be with any new param or command that we want.
> >
> > Allowing to plug custom parser into H2 (as we do now with table
> > engine) will let us introduce any syntax we want and focus on
> > usability and not on compromises and workarounds (which WITH keyword
> > currently is).
> >
> > - Alex
> >
> > 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan :
> > > Alexeander,
> > >
> > > Can you please provide an example of what the CREATE TABLE command
> would
> > > look like if we use WITH syntax from H2 vs. what you are proposing?
> > >
> > > D.
> > >
> > > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> > > alexander.a.pasche...@gmail.com> wrote:
> > >
> > >> Hello Igniters,
> > >>
> > >> Yup, it's THAT time once again as we haven't ultimately settled on
> > >> anything with the subj. as of yet, but I believe that now with DDL on
> > >> its way this talk can't be avoided anymore (sorry guys).
> > >>
> > >> The last time we talked about Ignite specific stuff we need to have in
> > >> CREATE TABLE (key fields list, affinity key, am I missing anything?),
> > >> the simplest approach suggested by Sergi was that we simply use WITH
> > >> part of H2's CREATE TABLE to pass stuff we need.
> > >>
> > >> This could work, but needless to say that such commands would look
> plain
> > >> ugly.
> > >>
> > >> I think we should go with custom syntax after all, BUT not in a way
> > >> suggested before by Sergi (propose Apache Ignite mode to H2).
> > >>
> > >> Instead, I suggest that we propose to H2 patch that would allow
> > >> plugging in *custom SQL parser* directly based on theirs (quite
> > >> elegant one) – I've had a look at their code, and this should not be
> > >> hard.
> > >>
> > >> Work on such a patch making syntax parsing overridable would take a
> > >> couple days which is not much time AND would give us the opportunity
> > >> to introduce to Ignite virtually any syntax we wish - both now and in
> > >> the future. Without worrying about compatibility with H2 ever again,
> > >> that is.
> > >>
> > >> Thoughts? After we agree on this principally and after H2 patch for
> > >> custom parsing is ready, we can roll our sleeves and focus on syntax
> > >> itself.
> > >>
> > >> - Alex
> > >>
> >
>

Re: CREATE TABLE SQL command syntax

[Pavel Tupitsyn]

I think "WITH" syntax is ugly and cumbersome.

We should go with this one:
CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
varchar, lastName varchar)

All databases (i.e. [1], [2]) work this way, I see no reason to invent
something different and confuse the users.

[1]
https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql#syntax-1
[2] https://www.postgresql.org/docs/9.1/static/sql-createtable.html

On Wed, Apr 12, 2017 at 6:12 AM, Alexander Paschenko <
alexander.a.pasche...@gmail.com> wrote:

> Dmitry,
>
> For H2 it would be something like this - please note all those quotes,
> commas and equality signs that would be mandatory:
>
> CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
> varchar) WITH "keyFields=id,uuid","affinityKey=id"
>
> With suggested approach, it would be something like
>
> CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
> varchar, lastName varchar)
>
> While this may not look like a drastic improvement in this particular
> case, we someday most likely will want either an all-custom CREATE
> CACHE command, or a whole bunch of new options for CREATE TABLE, if we
> decide not to go with CREATE CACHE - I personally think that stuff
> like
>
> CREATE TABLE ... WITH
> "keyFields=id,uuid","affinityKey=id","cacheType=partitioned","atomicity=
> atomic","partitions=3"
>
> which will arise if we continue to try to stuff everything into WITH
> will just bring more ugliness with time, and that's not to mention
> that new CREATE CACHE syntax will be impossible or relatively hard to
> introduce as we will have to approve it with H2 folks, and that's how
> it will be with any new param or command that we want.
>
> Allowing to plug custom parser into H2 (as we do now with table
> engine) will let us introduce any syntax we want and focus on
> usability and not on compromises and workarounds (which WITH keyword
> currently is).
>
> - Alex
>
> 2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan :
> > Alexeander,
> >
> > Can you please provide an example of what the CREATE TABLE command would
> > look like if we use WITH syntax from H2 vs. what you are proposing?
> >
> > D.
> >
> > On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> > alexander.a.pasche...@gmail.com> wrote:
> >
> >> Hello Igniters,
> >>
> >> Yup, it's THAT time once again as we haven't ultimately settled on
> >> anything with the subj. as of yet, but I believe that now with DDL on
> >> its way this talk can't be avoided anymore (sorry guys).
> >>
> >> The last time we talked about Ignite specific stuff we need to have in
> >> CREATE TABLE (key fields list, affinity key, am I missing anything?),
> >> the simplest approach suggested by Sergi was that we simply use WITH
> >> part of H2's CREATE TABLE to pass stuff we need.
> >>
> >> This could work, but needless to say that such commands would look plain
> >> ugly.
> >>
> >> I think we should go with custom syntax after all, BUT not in a way
> >> suggested before by Sergi (propose Apache Ignite mode to H2).
> >>
> >> Instead, I suggest that we propose to H2 patch that would allow
> >> plugging in *custom SQL parser* directly based on theirs (quite
> >> elegant one) – I've had a look at their code, and this should not be
> >> hard.
> >>
> >> Work on such a patch making syntax parsing overridable would take a
> >> couple days which is not much time AND would give us the opportunity
> >> to introduce to Ignite virtually any syntax we wish - both now and in
> >> the future. Without worrying about compatibility with H2 ever again,
> >> that is.
> >>
> >> Thoughts? After we agree on this principally and after H2 patch for
> >> custom parsing is ready, we can roll our sleeves and focus on syntax
> >> itself.
> >>
> >> - Alex
> >>
>

Re: Move documentation from readme.io to GitHub pages

[Pavel Tupitsyn]

> Git approach is no way to go for us because all the documentation has to
be hosted on ASF side

Well, our Git repository [1] is hosted by ASF, isn't it?
GitHub pages just generates HTML from MarkDown via Jekyll [2] static site
generator.

I understand the concern about GitHub pages, though.
And Igor is right about different versions, seems like it may be not so
easy with GH pages.


So I propose to use Jekyll, but do not use GitHub pages:
* Keep documentation in our Git repository in MarkDown format
* Generate HTML when release comes out and upload it to ignite.apache.org
(same as we do for API docs [3])

Seems to be easy enough. The hardest part is to come up with a good
template.

Thoughts?


[1] https://git-wip-us.apache.org/repos/asf?p=ignite.git
[2] https://jekyllrb.com/
[3] https://ignite.apache.org/releases/1.8.0/javadoc/

On Tue, Apr 11, 2017 at 7:09 PM, Denis Magda  wrote:

> Pavel,
>
> I totally agree that it’s becoming more and more inconvenient to run the
> documentation on readme.io . At the same time the Git
> approach is no way to go for us because all the documentation has to be
> hosted on ASF side. Presently we violate this policy and I look forward we
> fix it pretty soon.
>
> So, in general, all the documentation content has to become a part of
> Apache Ignite site and available from there. Here are some of the examples
> of another ASF projects:
> http://spark.apache.org/docs/2.1.0/ 
> https://zeppelin.apache.org/contribution/documentation.html <
> https://zeppelin.apache.org/contribution/documentation.html>
> https://hadoop.apache.org/docs/r2.7.2/  docs/r2.7.2/>
>
> Are you aware of any ready-to-be-used documentation libs that can be
> easily reused by us?
>
> —
> Denis
>
> > On Apr 11, 2017, at 2:02 AM, Pavel Tupitsyn 
> wrote:
> >
> > Igniters,
> >
> > Currently we host documentation on
> > apacheignite.readme.io (and also apacheignite-net.readme.io,
> > apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).
> >
> > readme.io has a lot of problems mostly due to lack of proper version
> > control:
> > * Each "version" is just a copy. When fixing something, you have to
> update
> > all versions.
> > * No good way to review changes.
> > * "Propose edit" functionality is a joke. You can only accept or reject
> an
> > edit, no way to communicate with contributor, etc
> >
> > GitHub Pages solves all these problems:
> > https://github.com/blog/2233-publish-your-project-
> documentation-with-github-pages
> >
> > Basically, we'll have a separate folder in our Git repository where
> > documentation is stored in markdown format.
> > This way the process for updating docs is exactly the same as any other
> > code change.
> > Pull request with new feature can contain the docs for this feature, and
> so
> > on.
> >
> > Thoughts?
>
>

Re: IGNITE-1192 Implementation (Integration with Spring Data)

[Denis Magda]

Folks, good news,

The integration has been just merged into the master branch and will be 
released in Apache Ignite 2.0.

Eduard, thanks for tremendous work done by you especially on the side of query 
generator module! In general, I’ve just polished your pull request, added more 
tests and introduced an example:
https://github.com/apache/ignite/tree/master/examples/src/main/java/org/apache/ignite/examples/springdata

A readme.io  documentation will be ready throughout 2 
nearest weeks.

—
Denis

> On Sep 1, 2016, at 1:43 AM, Eduard Shangareev  
> wrote:
> 
> Greetings, guys.
> 
> So, the current implementation was found adequate for the first version.
> But there are two issues which Semen found.
> 
> 1) now cache name is bound to a repository at compile time, could you
> please try to investigate if a more flexible binding is possible?
> 2) as I see now all spring-data integrations are hosted here -
> https://github.com/spring-projects, Could you please investigated how
> ignite integration can be added there?
> 
> First one, I don't see possibilities to provide cache names from Spring
> configuration to repository factory (except system properties).
> Second, I haven't found how to publish our spring-data implementation to
> spring-projects repository.
> 
> I will continue the investigation.
> But maybe someone already knows the answers.
> 
> 
> On Tue, Aug 9, 2016 at 2:46 PM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
> 
>> Guys, I have made a pull request.
>> 
>> https://github.com/apache/ignite/pull/931
>> 
>> 
>> New module spring-data was added.
>> 
>> The example of repository:
>> 
>> @RepositoryConfig(cacheName = "cache")
>> public interface FirstRepository extends IgniteRepository {
>>/** */
>>public List findByFirstName(String val);
>> 
>>/** */
>>public List findByFirstNameContaining(String val);
>> 
>>/** */
>>public List findByFirstNameRegex(String val, Pageable pageable);
>> 
>>/** */
>>public Collection findTopByFirstNameContaining(String val);
>> 
>>/** */
>>public Iterable findFirst10ByFirstNameLike(String val);
>> 
>>/** */
>>public int countByFirstNameLike(String val);
>> 
>>/** */
>>public int countByFirstNameLikeAndSecondNameLike(String like1, String 
>> like2);
>> 
>>/** */
>>public int countByFirstNameStartingWithOrSecondNameStartingWith(String 
>> like1, String like2);
>> 
>>/** */
>>public List> findBySecondNameLike(String 
>> val);
>> 
>>/** */
>>public Cache.Entry findTopBySecondNameLike(String val);
>> 
>>/** */
>>public Person findTopBySecondNameStartingWith(String val);
>> 
>>/** */
>>@Query("firstName = ?")
>>public List simpleQuery(String val);
>> 
>>/** */
>>@Query("firstName REGEXP ?")
>>public List queryWithSort(String val, Sort sort);
>> 
>>/** */
>>@Query("SELECT * FROM Person WHERE firstName REGEXP ?")
>>public List queryWithPageable(String val, Pageable pageable);
>> 
>>/** */
>>@Query("SELECT secondName FROM Person WHERE firstName REGEXP ?")
>>public List selectField(String val, Pageable pageable);
>> 
>>/** */
>>@Query("SELECT _key, secondName FROM Person WHERE firstName REGEXP ?")
>>public List selectSeveralField(String val, Pageable pageable);
>> 
>>/** */
>>@Query("SELECT count(1) FROM (SELECT DISTINCT secondName FROM Person 
>> WHERE firstName REGEXP ?)")
>>public int countQuery(String val);
>> }
>> 
>> 
>> A user should extend IgniteRepository and provide cache name via
>> @RepositoryConfig.
>> 
>> IgniteRepository extends CrudRepository and deprecates unsupported
>> operation (without id).
>> 
>> 
>> 
>> 
>> 
>> On Tue, Aug 9, 2016 at 12:06 AM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>> 
>>> Eduard,
>>> 
>>> It's up to you :) I'm just saying that we should split the big task into
>>> smaller ones.
>>> 
>>> -Val
>>> 
>>> On Mon, Aug 8, 2016 at 3:57 AM, Eduard Shangareev <
>>> eduard.shangar...@gmail.com> wrote:
>>> 
 Hi, Valentin.
 I am going to close these ticket with some prototype and create new ones
 (maybe, with umbrella one).
 
 Will it work?
 
 On Sat, Aug 6, 2016 at 8:03 AM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:
 
> Hi Eduard,
> 
> This is too much information :)
> 
> I think you should create separate tickets for different aspects of
 Spring
> Data integration and use IGNITE-1192 only as an umbrella, because
 otherwise
> it will be flooded by comments. This will allow to implement this
> functionality step by step and track the progress better.
> 
> Agree?
> 
> -Val
> 
> On Fri, Aug 5, 2016 at 4:17 AM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
> 

Re: CREATE TABLE SQL command syntax

[Alexander Paschenko]

Dmitry,

For H2 it would be something like this - please note all those quotes,
commas and equality signs that would be mandatory:

CREATE TABLE Person (id int, uid uuid, firstName varchar, lastName
varchar) WITH "keyFields=id,uuid","affinityKey=id"

With suggested approach, it would be something like

CREATE TABLE Person (id int AFFINITY KEY, uid uuid KEY, firstName
varchar, lastName varchar)

While this may not look like a drastic improvement in this particular
case, we someday most likely will want either an all-custom CREATE
CACHE command, or a whole bunch of new options for CREATE TABLE, if we
decide not to go with CREATE CACHE - I personally think that stuff
like

CREATE TABLE ... WITH
"keyFields=id,uuid","affinityKey=id","cacheType=partitioned","atomicity=atomic","partitions=3"

which will arise if we continue to try to stuff everything into WITH
will just bring more ugliness with time, and that's not to mention
that new CREATE CACHE syntax will be impossible or relatively hard to
introduce as we will have to approve it with H2 folks, and that's how
it will be with any new param or command that we want.

Allowing to plug custom parser into H2 (as we do now with table
engine) will let us introduce any syntax we want and focus on
usability and not on compromises and workarounds (which WITH keyword
currently is).

- Alex

2017-04-12 5:11 GMT+03:00 Dmitriy Setrakyan :
> Alexeander,
>
> Can you please provide an example of what the CREATE TABLE command would
> look like if we use WITH syntax from H2 vs. what you are proposing?
>
> D.
>
> On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
> alexander.a.pasche...@gmail.com> wrote:
>
>> Hello Igniters,
>>
>> Yup, it's THAT time once again as we haven't ultimately settled on
>> anything with the subj. as of yet, but I believe that now with DDL on
>> its way this talk can't be avoided anymore (sorry guys).
>>
>> The last time we talked about Ignite specific stuff we need to have in
>> CREATE TABLE (key fields list, affinity key, am I missing anything?),
>> the simplest approach suggested by Sergi was that we simply use WITH
>> part of H2's CREATE TABLE to pass stuff we need.
>>
>> This could work, but needless to say that such commands would look plain
>> ugly.
>>
>> I think we should go with custom syntax after all, BUT not in a way
>> suggested before by Sergi (propose Apache Ignite mode to H2).
>>
>> Instead, I suggest that we propose to H2 patch that would allow
>> plugging in *custom SQL parser* directly based on theirs (quite
>> elegant one) – I've had a look at their code, and this should not be
>> hard.
>>
>> Work on such a patch making syntax parsing overridable would take a
>> couple days which is not much time AND would give us the opportunity
>> to introduce to Ignite virtually any syntax we wish - both now and in
>> the future. Without worrying about compatibility with H2 ever again,
>> that is.
>>
>> Thoughts? After we agree on this principally and after H2 patch for
>> custom parsing is ready, we can roll our sleeves and focus on syntax
>> itself.
>>
>> - Alex
>>

Re: CREATE TABLE SQL command syntax

[Dmitriy Setrakyan]

Alexeander,

Can you please provide an example of what the CREATE TABLE command would
look like if we use WITH syntax from H2 vs. what you are proposing?

D.

On Tue, Apr 11, 2017 at 6:35 PM, Alexander Paschenko <
alexander.a.pasche...@gmail.com> wrote:

> Hello Igniters,
>
> Yup, it's THAT time once again as we haven't ultimately settled on
> anything with the subj. as of yet, but I believe that now with DDL on
> its way this talk can't be avoided anymore (sorry guys).
>
> The last time we talked about Ignite specific stuff we need to have in
> CREATE TABLE (key fields list, affinity key, am I missing anything?),
> the simplest approach suggested by Sergi was that we simply use WITH
> part of H2's CREATE TABLE to pass stuff we need.
>
> This could work, but needless to say that such commands would look plain
> ugly.
>
> I think we should go with custom syntax after all, BUT not in a way
> suggested before by Sergi (propose Apache Ignite mode to H2).
>
> Instead, I suggest that we propose to H2 patch that would allow
> plugging in *custom SQL parser* directly based on theirs (quite
> elegant one) – I've had a look at their code, and this should not be
> hard.
>
> Work on such a patch making syntax parsing overridable would take a
> couple days which is not much time AND would give us the opportunity
> to introduce to Ignite virtually any syntax we wish - both now and in
> the future. Without worrying about compatibility with H2 ever again,
> that is.
>
> Thoughts? After we agree on this principally and after H2 patch for
> custom parsing is ready, we can roll our sleeves and focus on syntax
> itself.
>
> - Alex
>

CREATE TABLE SQL command syntax

[Alexander Paschenko]

Hello Igniters,

Yup, it's THAT time once again as we haven't ultimately settled on
anything with the subj. as of yet, but I believe that now with DDL on
its way this talk can't be avoided anymore (sorry guys).

The last time we talked about Ignite specific stuff we need to have in
CREATE TABLE (key fields list, affinity key, am I missing anything?),
the simplest approach suggested by Sergi was that we simply use WITH
part of H2's CREATE TABLE to pass stuff we need.

This could work, but needless to say that such commands would look plain ugly.

I think we should go with custom syntax after all, BUT not in a way
suggested before by Sergi (propose Apache Ignite mode to H2).

Instead, I suggest that we propose to H2 patch that would allow
plugging in *custom SQL parser* directly based on theirs (quite
elegant one) – I've had a look at their code, and this should not be
hard.

Work on such a patch making syntax parsing overridable would take a
couple days which is not much time AND would give us the opportunity
to introduce to Ignite virtually any syntax we wish - both now and in
the future. Without worrying about compatibility with H2 ever again,
that is.

Thoughts? After we agree on this principally and after H2 patch for
custom parsing is ready, we can roll our sleeves and focus on syntax
itself.

- Alex

Re: Sorting fields of Binarilyzable objects on write

[Dmitriy Setrakyan]

On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin 
wrote:

> I'm just trying to understand the current state of things and risks. May be
> we need to do some adjustments here before 2.0 to be on the safe side.
>
> Actually looks like this not really important, we just have to clearly
> document that DML builds keys this way and require from user to do the same
> to be able to use cache API.
>


I think it is important from the usability stand point. A user can always
sort fields alphabetically in his or her mind. However, trying to remember
the field order from some QueryEntity is a lot harder.

Re: IGNITE-2741 - spring session design

[Rishi Yagnik]

Hi Val,

I will build it from master s and let you know by tomorrow.

Thanks,


On Tue, Apr 11, 2017 at 3:53 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Rishi,
>
> What was the issue with the HttpSessionCsrfTokenRepository? I didn't have
> any problems after I added code you provided.
>
> The fix for [1] is already in master. Can you try building from there and
> check if everything works fine for you?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4948
>
> -Val
>
> On Sat, Mar 18, 2017 at 5:15 PM, Denis Magda  wrote:
>
> > Somewhere in April. This will be clarified on the dev list soon.
> >
> > On Saturday, March 18, 2017, Rishi Yagnik  wrote:
> >
> > > Thanks, Val.
> > >
> > > When are we going to release Ignite 2.0 ? June ??
> > >
> > > Thanks,
> > >
> > > On Sat, Mar 18, 2017 at 6:02 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com > wrote:
> > >
> > > > Denis,
> > > >
> > > > Yes, this should be possible. I will try to finalize the fix asap.
> > > >
> > > > -Val
> > > >
> > > > On Fri, Mar 17, 2017 at 7:46 PM, Denis Magda  > > > wrote:
> > > >
> > > > > Val,
> > > > >
> > > > > Will it be possible to incorporate the fix into the nearest 2.0
> > > release?
> > > > >
> > > > > —
> > > > > Denis
> > > > >
> > > > > > On Mar 17, 2017, at 11:43 AM, Rishi Yagnik <
> rishiyag...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > Hi Val,
> > > > > >
> > > > > > Hope you are well, any update on web session clustering.
> > > > > >
> > > > > > Thanks,
> > > > > > Rishi
> > > > > >
> > > > > > On Sat, Mar 11, 2017 at 12:29 PM, Rishi Yagnik <
> > > rishiyag...@gmail.com >
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Val,
> > > > > >>
> > > > > >> Thanks looking forward for the fix..
> > > > > >>
> > > > > >> Take Care,
> > > > > >> Rishi
> > > > > >>
> > > > > >>> On Mar 11, 2017, at 11:31 AM, Valentin Kulichenko <
> > > > > >> valentin.kuliche...@gmail.com > wrote:
> > > > > >>>
> > > > > >>> Hi Rishi,
> > > > > >>>
> > > > > >>> I want to fix the bug first. It takes a bit longer than I
> > thought,
> > > > but
> > > > > I
> > > > > >>> should finish it over the weekend.
> > > > > >>>
> > > > > >>> -Val
> > > > > >>>
> > > > >  On Fri, Mar 10, 2017 at 4:13 AM, Rishi Yagnik <
> > > > rishiyag...@gmail.com >
> > > > > >> wrote:
> > > > > 
> > > > >  Hi Val,
> > > > > 
> > > > >  Did you chance to look into session handling issue ?
> > > > > 
> > > > >  Thanks,
> > > > > 
> > > > >  On Mon, Mar 6, 2017 at 3:37 PM, Rishi Yagnik <
> > > rishiyag...@gmail.com 
> > > > >
> > > > >  wrote:
> > > > > 
> > > > > > Hi Val,
> > > > > >
> > > > > > Do you think I can test a fix in 1.9 RC releases ? How are
> you
> > > > > planning
> > > > >  to
> > > > > > release a fix ?
> > > > > >
> > > > > > Did you also look into problem where storing xsrf token in
> > Ignite
> > > > > >> returns
> > > > > > an exception and does not behave as expected ?
> > > > > >
> > > > > > In SecurityConfig.java use HttpSessionCsrfTokenRepository
> with
> > > > > >> following
> > > > > > code -
> > > > > >
> > > > > > .csrfTokenRepository(csrfTokenRepository())
> > > > > >
> > > > > > private CsrfTokenRepository csrfTokenRepository() {
> > > > > >   HttpSessionCsrfTokenRepository repository = new
> > > > >  HttpSessionCsrfTokenRepository();
> > > > > >   repository.setHeaderName("X-XSRF-TOKEN");
> > > > > >   return repository;
> > > > > > }
> > > > > >
> > > > > > Thank you for all your help,
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 6, 2017 at 2:34 PM, Valentin Kulichenko <
> > > > > > valentin.kuliche...@gmail.com > wrote:
> > > > > >
> > > > > >> Hi Rishi,
> > > > > >>
> > > > > >> I got to the bottom of it. Basically, the session is
> replaced
> > in
> > > > > >> Spring
> > > > > >> filter, but caching happens based on the old version which
> > > doesn't
> > > > > >> have
> > > > > >> security attributes. The fix is going to be very easy, I
> will
> > do
> > > > it
> > > > > >> tomorrow.
> > > > > >>
> > > > > >> -Val
> > > > > >>
> > > > > >> On Mon, Mar 6, 2017 at 7:34 PM, Rishi Yagnik <
> > > > rishiyag...@gmail.com 
> > > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Val,
> > > > > >>>
> > > > > >>> Did you get chance to play around with the code ?
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>>
> > > > > >>> On Sun, Mar 5, 2017 at 7:25 PM, Rishi Yagnik <
> > > > > rishiyag...@gmail.com >
> > > > > >>> wrote:
> > > > > >>>
> > > > >  Val,
> > > > > 
> > > > >  Adding a filter before csrf filter will invoke the 

Changes in web session clustering

[Valentin Kulichenko]

Hi Saikat,

I recall you made a lot of changes in web session clustering component.

I was working on [1] and found piece of code in WebSessionFilter#doFilterV2
that was supposed to handle the case of changed session ID. It was actually
never called because of the issue. I removed it and replaced with (I think)
more correct code. Can you please take a look at the latest changes and
check if I missed anything there?

[1] https://issues.apache.org/jira/browse/IGNITE-4948

-Val

Re: IGNITE-2741 - spring session design

[Valentin Kulichenko]

Hi Rishi,

What was the issue with the HttpSessionCsrfTokenRepository? I didn't have
any problems after I added code you provided.

The fix for [1] is already in master. Can you try building from there and
check if everything works fine for you?

[1] https://issues.apache.org/jira/browse/IGNITE-4948

-Val

On Sat, Mar 18, 2017 at 5:15 PM, Denis Magda  wrote:

> Somewhere in April. This will be clarified on the dev list soon.
>
> On Saturday, March 18, 2017, Rishi Yagnik  wrote:
>
> > Thanks, Val.
> >
> > When are we going to release Ignite 2.0 ? June ??
> >
> > Thanks,
> >
> > On Sat, Mar 18, 2017 at 6:02 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com > wrote:
> >
> > > Denis,
> > >
> > > Yes, this should be possible. I will try to finalize the fix asap.
> > >
> > > -Val
> > >
> > > On Fri, Mar 17, 2017 at 7:46 PM, Denis Magda  > > wrote:
> > >
> > > > Val,
> > > >
> > > > Will it be possible to incorporate the fix into the nearest 2.0
> > release?
> > > >
> > > > —
> > > > Denis
> > > >
> > > > > On Mar 17, 2017, at 11:43 AM, Rishi Yagnik  > >
> > > > wrote:
> > > > >
> > > > > Hi Val,
> > > > >
> > > > > Hope you are well, any update on web session clustering.
> > > > >
> > > > > Thanks,
> > > > > Rishi
> > > > >
> > > > > On Sat, Mar 11, 2017 at 12:29 PM, Rishi Yagnik <
> > rishiyag...@gmail.com >
> > > > > wrote:
> > > > >
> > > > >> Hi Val,
> > > > >>
> > > > >> Thanks looking forward for the fix..
> > > > >>
> > > > >> Take Care,
> > > > >> Rishi
> > > > >>
> > > > >>> On Mar 11, 2017, at 11:31 AM, Valentin Kulichenko <
> > > > >> valentin.kuliche...@gmail.com > wrote:
> > > > >>>
> > > > >>> Hi Rishi,
> > > > >>>
> > > > >>> I want to fix the bug first. It takes a bit longer than I
> thought,
> > > but
> > > > I
> > > > >>> should finish it over the weekend.
> > > > >>>
> > > > >>> -Val
> > > > >>>
> > > >  On Fri, Mar 10, 2017 at 4:13 AM, Rishi Yagnik <
> > > rishiyag...@gmail.com >
> > > > >> wrote:
> > > > 
> > > >  Hi Val,
> > > > 
> > > >  Did you chance to look into session handling issue ?
> > > > 
> > > >  Thanks,
> > > > 
> > > >  On Mon, Mar 6, 2017 at 3:37 PM, Rishi Yagnik <
> > rishiyag...@gmail.com 
> > > >
> > > >  wrote:
> > > > 
> > > > > Hi Val,
> > > > >
> > > > > Do you think I can test a fix in 1.9 RC releases ? How are you
> > > > planning
> > > >  to
> > > > > release a fix ?
> > > > >
> > > > > Did you also look into problem where storing xsrf token in
> Ignite
> > > > >> returns
> > > > > an exception and does not behave as expected ?
> > > > >
> > > > > In SecurityConfig.java use HttpSessionCsrfTokenRepository with
> > > > >> following
> > > > > code -
> > > > >
> > > > > .csrfTokenRepository(csrfTokenRepository())
> > > > >
> > > > > private CsrfTokenRepository csrfTokenRepository() {
> > > > >   HttpSessionCsrfTokenRepository repository = new
> > > >  HttpSessionCsrfTokenRepository();
> > > > >   repository.setHeaderName("X-XSRF-TOKEN");
> > > > >   return repository;
> > > > > }
> > > > >
> > > > > Thank you for all your help,
> > > > >
> > > > >
> > > > > On Mon, Mar 6, 2017 at 2:34 PM, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com > wrote:
> > > > >
> > > > >> Hi Rishi,
> > > > >>
> > > > >> I got to the bottom of it. Basically, the session is replaced
> in
> > > > >> Spring
> > > > >> filter, but caching happens based on the old version which
> > doesn't
> > > > >> have
> > > > >> security attributes. The fix is going to be very easy, I will
> do
> > > it
> > > > >> tomorrow.
> > > > >>
> > > > >> -Val
> > > > >>
> > > > >> On Mon, Mar 6, 2017 at 7:34 PM, Rishi Yagnik <
> > > rishiyag...@gmail.com 
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >>> Val,
> > > > >>>
> > > > >>> Did you get chance to play around with the code ?
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> On Sun, Mar 5, 2017 at 7:25 PM, Rishi Yagnik <
> > > > rishiyag...@gmail.com >
> > > > >>> wrote:
> > > > >>>
> > > >  Val,
> > > > 
> > > >  Adding a filter before csrf filter will invoke the custom
> > ignite
> > > > >> filter.
> > > > 
> > > >  Declare a custom filter class extends it with websession
> > filter
> > > > 
> > > >  public class CustomWebSessionFilter extends
> WebSessionFilter {
> > > > 
> > > > private static boolean igniteInitialize = false
> > > > 
> > > >  @Override public void doFilter(ServletRequest req,
> > > ServletResponse
> > > > >> res,
> > > >  FilterChain chain)
> > > 

[jira] [Created] (IGNITE-4948) Web session clustering fails to work with Spring Security

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4948:
---

 Summary: Web session clustering fails to work with Spring Security
 Key: IGNITE-4948
 URL: https://issues.apache.org/jira/browse/IGNITE-4948
 Project: Ignite
  Issue Type: Bug
  Components: websession
Affects Versions: 1.9
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 2.0


{{WebSessionFilter.doFilterV2}} method do not refresh the local instance of 
session after {{chain.doFilter}}. But it's possible that session is replaced by 
some other filter (e.g. due to login). And if after this replacement some 
attributes are added, they do not end up in cache.

dev@ list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-2741-spring-session-design-td14560.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Sorting fields of Binarilyzable objects on write

[Sergi Vladykin]

I'm just trying to understand the current state of things and risks. May be
we need to do some adjustments here before 2.0 to be on the safe side.

Actually looks like this not really important, we just have to clearly
document that DML builds keys this way and require from user to do the same
to be able to use cache API.

Sergi

2017-04-11 21:47 GMT+03:00 Dmitriy Setrakyan :

> Sergi, why do you not like the alphabetical order? Seems like it would be a
> much easier to understand requirement from the user standpoint. Do you see
> some issues here?
>
> On Mon, Apr 10, 2017 at 10:43 AM, Sergi Vladykin  >
> wrote:
>
> > I'm sorry, looks like I do not really well understand this stuff, but it
> is
> > still not clear to me why wouldn't we just take the order of key fields
> > given in QueryEntity and use it for both cases irrespectively to the
> order
> > of fields in regular Class or in Binarylizable?
> >
> > I mean lets say we have a Class (with unpredictable order of fields
> > according to reflection):
> >
> >Person implements Serializable
> >   {int age, double salary}
> >
> > Or we have a Binarylizable (with some unknown user defined order of
> > fields):
> >
> >   Person implements Binarylizable {
> >  writeBinary(w) {w.writeDouble("salary", salary),  w.writeInt(''age",
> > age)}
> >
> > Also we have a QueryEntity (age, salary)
> >
> > Why we can not take key fields names from QueryEntity in the given order
> > (age, salary) and get values from either "regular" Class or from
> > Binarylizable and calculate hash code?
> >
> > Sergi
> >
> > 2017-04-10 19:56 GMT+03:00 Vladimir Ozerov :
> >
> > > Guys,
> > >
> > > The problem is that order of fields serialization is unknown for
> regular
> > > objects, where "regular" stands for non-Binarilyzable class. Reflection
> > > returns fields in unpredictable order. For this reason you cannot match
> > > fields order between class and QueryEntity. This is why we introduced
> > > sorting, and this is why idea to rely on QueryEntity doesn't work.
> > >
> > > On Mon, Apr 10, 2017 at 7:01 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > Why "regular" are different here?
> > > >
> > > > Sergi
> > > >
> > > > 2017-04-10 18:59 GMT+03:00 Pavel Tupitsyn :
> > > >
> > > > > QueryEntity sorting is not an option for "regular" classes with
> > > > reflective
> > > > > serialization.
> > > > > We have to use alphabetical.
> > > > > Also, same class can participate in multiple query entities.
> > > > >
> > > > > 10 апр. 2017 г. 18:52 пользователь "Dmitriy Setrakyan" <
> > > > > dsetrak...@apache.org> написал:
> > > > >
> > > > > On Mon, Apr 10, 2017 at 8:28 AM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > The decision to use alphabetic order looks strange here. Using
> > order
> > > > > > provided in QueryEntity and require from user to have the same
> > order
> > > > > > in Binarylizable
> > > > > > looks more reasonable.
> > > > > >
> > > > >
> > > > > I think this would be much harder to verify. Alphabetical order is
> > more
> > > > > intuitive, no?
> > > > >
> > > >
> > >
> >
>

Re: IGNITE-1794 is ready for review

[Вадим Опольский]

Denis, yes, I mean issue  https://issues.apache.org/jira/browse/IGNITE-1794

Yes I added some fixes in addition to previous changes. This fixes repeat
the Semyon's fixes.

Vadim

2017-04-11 19:55 GMT+03:00 Denis Magda :

> Vadim,
>
> Do you mean this task?
> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794>
> As I see Semen has already promised to review it and merge into the master
> by the end of the week.
>
> Did you add anything else in addition to previous changes?
>
> —
> Denis
>
> > On Apr 11, 2017, at 9:51 AM, Вадим Опольский 
> wrote:
> >
> > Hello guys!
> >
> > I added folder hibernate5 as module to project settings and discovered
> some errors. Fixed errors in pull request - https://github.com/vopolski/
> ignite/pull/1/files 
> > But some tests from hibernate5 is failed. I'll fix them.
> >
> > How much time do I have?
> >
> > Vadim Opolski
> >
> > 2017-04-06 13:04 GMT+03:00 Вадим Опольский  >:
> > Dear sirs!
> >
> > Sorry for incorrect subject.
> >
> > https://github.com/apache/ignite/pull/1643  ignite/pull/1643>
> >
> > -- Forwarded message --
> > From: Вадим Опольский  >>
> > Date: 2017-03-24 15:48 GMT+03:00
> > Subject: ready for review IGNITE-933
> > To: dev@ignite.apache.org , Denis Magda <
> dma...@apache.org >, Valentin Kulichenko <
> valentin.kuliche...@gmail.com >
> >
> >
> > Hello everyone!
> >
> > Denis, Valentin, what should I do to close issue
> https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794> ?
> >
> > The tests in Team City executed successfully.
> >
> > Valentin, I renamed IgniteHibernateTestSuite ->
> IgniteHibernate5TestSuite. Can you create TeamCity Configuration ?
> >
> >
> >
> > Vadim Opolski
> >
> > 2017-03-21 11:30 GMT+03:00 Вадим Опольский  >:
> > Hello everybody.
> >
> > The issue  https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794> fixed originally by
> Mykola Pereyma.
> > I re-assigned issue https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794> on myself, because we
> haven’t got a note from him for a while.
> >
> > Denis, I merged pull request https://github.com/apache/ignite/pull/1146
>  with my fork.
> > Then I changed hibernate version to 5.2.7 and deleted ByteArrayType.java
> as per CI comments.
> > The tests from list below executed succesfully.
> >
> > Prepared new pull request - https://github.com/apache/ignite/pull/1643 <
> https://github.com/apache/ignite/pull/1643>
> >
> > What's the next step ?
> >
> > Tests:
> > HibernateL2CacheConfigurationSelfTest.java
> > HibernateL2CacheSelfTest.java
> > HibernateL2CacheTransactionalSelfTest.java
> > HibernateL2CacheTransactionalUseSyncSelfTest.java
> > CacheHibernateBlobStoreNodeRestartTest.java
> > CacheHibernateBlobStoreSelfTest.java
> > CacheHibernateStoreFactorySelfTest.java
> > CacheHibernateStoreSessionListenerSelfTest.java
> >
> >
> > Vadim Opolski
> >
> >
> > 2017-02-25 2:38 GMT+03:00 Denis Magda >:
> > > Yes, I have some experience with Hibernate. The issue № IGNITE-1974 is
> interesting for me. How I can assignee it to me? It is assigning with
> Mykola Pereyma now.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794> <
> https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794>>
> >
> > Just re-assign it on yourself ;) Hope that Mykola is fine with this
> because we haven’t got a note from him for a while.
> >
> > —
> > Denis
> >
> > > On Feb 24, 2017, at 12:24 PM, Вадим Опольский  > wrote:
> > >
> > > Hi Denis,
> > >
> > > OK, I spotted the problem in the code and I will be try to resolve it.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-933 <
> https://issues.apache.org/jira/browse/IGNITE-933> <
> https://issues.apache.org/jira/browse/IGNITE-933 <
> https://issues.apache.org/jira/browse/IGNITE-933>>
> > >
> > > Yes, I have some experience with Hibernate. The issue № IGNITE-1974 is
> interesting for me. How I can assignee it to me? It is assigning with
> Mykola Pereyma now.
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794> <
> https://issues.apache.org/jira/browse/IGNITE-1794 <
> https://issues.apache.org/jira/browse/IGNITE-1794>>
> > >
> > > Vadim Opolski
> > >
> > > 2017-02-24 5:55 GMT+03:00 Denis 

Re: IGNITE-1794 is ready for review

[Вадим Опольский]

Hi Semyon!

I've seen all fixes abut hibernate5 in ignite-3477-master. Will you finish
this issue?

Vadim Opolski

2017-04-11 19:54 GMT+03:00 Semyon Boikov :

> Hi Vadim,
>
> I already fixed all issues with hibernate5 tests and merged in
> ignite-3477-master, it will be merged in master soon.
>
> Thanks
>
> On Tue, Apr 11, 2017 at 7:51 PM, Вадим Опольский 
> wrote:
>
> > Hello guys!
> >
> > I added folder hibernate5 as module to project settings and discovered
> some
> > errors. Fixed errors in pull request -
> > https://github.com/vopolski/ignite/pull/1/files
> > But some tests from hibernate5 is failed. I'll fix them.
> >
> > How much time do I have?
> >
> > Vadim Opolski
> >
> > 2017-04-06 13:04 GMT+03:00 Вадим Опольский :
> >
> > > Dear sirs!
> > >
> > > Sorry for incorrect subject.
> > >
> > > https://github.com/apache/ignite/pull/1643
> > >
> > > -- Forwarded message --
> > > From: Вадим Опольский 
> > > Date: 2017-03-24 15:48 GMT+03:00
> > > Subject: ready for review IGNITE-933
> > > To: dev@ignite.apache.org, Denis Magda , Valentin
> > > Kulichenko 
> > >
> > >
> > > Hello everyone!
> > >
> > > Denis, Valentin, what should I do to close issue
> > > https://issues.apache.org/jira/browse/IGNITE-1794 ?
> > >
> > > The tests in Team City executed successfully.
> > >
> > > Valentin, I renamed IgniteHibernateTestSuite ->
> > IgniteHibernate5TestSuite.
> > > Can you create TeamCity Configuration ?
> > >
> > >
> > >
> > > Vadim Opolski
> > >
> > > 2017-03-21 11:30 GMT+03:00 Вадим Опольский :
> > >
> > >> Hello everybody.
> > >>
> > >> The issue  https://issues.apache.org/jira/browse/IGNITE-1794 fixed
> > >> originally by Mykola Pereyma.
> > >> I re-assigned issue https://issues.apache.org/jira/browse/IGNITE-1794
> > on
> > >> myself, because we haven’t got a note from him for a while.
> > >>
> > >> Denis, I merged pull request https://github.com/apache/
> ignite/pull/1146
> > with
> > >> my fork.
> > >> Then I changed hibernate version to 5.2.7 and deleted
> ByteArrayType.java
> > >> as per CI comments.
> > >> The tests from list below executed succesfully.
> > >>
> > >> Prepared new pull request - https://github.com/apache/
> ignite/pull/1643
> > >>
> > >> What's the next step ?
> > >>
> > >> Tests:
> > >> HibernateL2CacheConfigurationSelfTest.java
> > >> HibernateL2CacheSelfTest.java
> > >> HibernateL2CacheTransactionalSelfTest.java
> > >> HibernateL2CacheTransactionalUseSyncSelfTest.java
> > >> CacheHibernateBlobStoreNodeRestartTest.java
> > >> CacheHibernateBlobStoreSelfTest.java
> > >> CacheHibernateStoreFactorySelfTest.java
> > >> CacheHibernateStoreSessionListenerSelfTest.java
> > >>
> > >>
> > >> Vadim Opolski
> > >>
> > >>
> > >> 2017-02-25 2:38 GMT+03:00 Denis Magda :
> > >>
> > >>> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974
> > is
> > >>> interesting for me. How I can assignee it to me? It is assigning with
> > >>> Mykola Pereyma now.
> > >>> >
> > >>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> > >>> https://issues.apache.org/jira/browse/IGNITE-1794>
> > >>>
> > >>> Just re-assign it on yourself ;) Hope that Mykola is fine with this
> > >>> because we haven’t got a note from him for a while.
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> > >>> > On Feb 24, 2017, at 12:24 PM, Вадим Опольский <
> vaopols...@gmail.com>
> > >>> wrote:
> > >>> >
> > >>> > Hi Denis,
> > >>> >
> > >>> > OK, I spotted the problem in the code and I will be try to resolve
> > it.
> > >>> >
> > >>> > https://issues.apache.org/jira/browse/IGNITE-933 <
> > >>> https://issues.apache.org/jira/browse/IGNITE-933>
> > >>> >
> > >>> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974
> > is
> > >>> interesting for me. How I can assignee it to me? It is assigning with
> > >>> Mykola Pereyma now.
> > >>> >
> > >>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> > >>> https://issues.apache.org/jira/browse/IGNITE-1794>
> > >>> >
> > >>> > Vadim Opolski
> > >>> >
> > >>> > 2017-02-24 5:55 GMT+03:00 Denis Magda  >>> dma...@apache.org>>:
> > >>> > Hi Vadim,
> > >>> >
> > >>> > Yes, this issue might be still relevant. I can’t guide you through
> > >>> but, basically, you need to reproduce the issue, spot it in the code
> > and
> > >>> propose a fix.
> > >>> >
> > >>> > BTW, do you have any experience with Hibernate? If so, I would be
> > >>> amazing if you pick up this ticket reassigning on yourself:
> > >>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> > >>> https://issues.apache.org/jira/browse/IGNITE-1794> <
> > >>> https://issues.apache.org/jira/browse/IGNITE-1794 <
> > >>> https://issues.apache.org/jira/browse/IGNITE-1794>>
> > >>> >
> > >>> > —
> > >>> > Denis
> > >>> >
> > >>> > > On Feb 23, 2017, at 2:40 AM, Вадим Опольский <
> vaopols...@gmail.com

Re: Stable binary key representation

[Denis Magda]

I don’t see either unless a key’s field is of a float type. However, it sounds 
like an artificial use case.

Thanks for the details.

—
Denis

> On Apr 11, 2017, at 11:50 AM, Dmitriy Setrakyan  wrote:
> 
> Denis, I think it is important that we know which specific field to use for
> the affinity resolution, but I don't see any issue in using both, primary
> and foreign keys, for hashcode and equality. Do you?
> 
> D.
> 
> On Tue, Apr 11, 2017 at 11:46 AM, Igor Sapego  wrote:
> 
>> Denis,
>> 
>> The whole binary representation of the object is used now
>> for hash code generation and equality comparison. So the
>> answer - all fields are used for this.
>> 
>> Best Regards,
>> Igor
>> 
>> On Mon, Apr 10, 2017 at 9:50 PM, Denis Magda  wrote:
>> 
>>> Considering this simple example
>>> 
>>> INSERT (id, orgId, name, age, address) into Person…
>>> 
>>> where id and orgId define Person’s affinity key - PersonKey(id, orgId)
>>> 
>>> How do we know which fields to use for hash code generation and equality
>>> comparison? QueryEntity?
>>> 
>>> No, it’s unclear how to document it properly.
>>> 
>>> —
>>> Denis
>>> 
 On Apr 10, 2017, at 11:14 AM, Vladimir Ozerov 
>>> wrote:
 
 There is no more such resolver. It was removed.
 
 On Mon, Apr 10, 2017 at 8:58 PM, Denis Magda 
>> wrote:
 
> Vovan,
> 
> Before I fix the documentation, what’t the replacement for
> BinaryFieldIdentiyResolver we used to define field for hash code
> calculation and equality comparison when DML statements are used?
> https://apacheignite.readme.io/docs/binary-marshaller#
> section-binary-field-identity-resolver  io/docs/binary-marshaller#section-binary-field-identity-resolver>
> 
> —
> Denis
> 
>> On Apr 9, 2017, at 7:39 AM, Vladimir Ozerov 
> wrote:
>> 
>> Resolvers were essential for DML because we had broken comparison
> semantics
>> of binary objects. This is not the case now.
>> 
>> Resolver as a whole is normal practice. E.g. it is implemented in
>> .NET
>>> on
>> core language level and widely used in many cases. Hazelcast has it
>> as
> well
>> AFAIK. So it is wrong to think that the whole idea is useless. Think
>> of
> it
>> as a comparator's brother.
>> 
>> The only reason why we need to remove it is missing hash index in new
>> architecture. It makes sense, as it is better to have AI 2.0 without
> them,
>> than no AI 2.0 :-)
>> 
>> 09 апр. 2017 г. 17:31 пользователь "Sergi Vladykin" <
>> sergi.vlady...@gmail.com> написал:
>> 
>>> I guess Resolvers were added to DML just because they already
>> existed
> since
>>> 1.9 and we were forced to support them in all the parts of our
>>> product.
>>> 
>>> We have to stop this practice to add features without clear real
>> life
> use
>>> cases for them.
>>> 
>>> Sergi
>>> 
>>> 2017-04-09 17:00 GMT+03:00 Denis Magda :
>>> 
 Sergi, Vovan,
 
 Sorry for being annoying but I still didn't get an answer on
>> whether
> the
 resolvers are the must for DML. The main reason why we made them up
> some
 time ago is to support specific DML use cases. However I can't
>> recall
> the
 use cases.
 
 --
 Denis
 
 On Sun, Apr 9, 2017 at 6:54 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com
 
 wrote:
 
> Ok, we need to do 2 things here:
> 
> 1. Drop the resolvers from the source code.
> 2. Write a good page in docs on "What makes a correct cache key".
> 
> Who can do that?
> 
> Sergi
> 
> 2017-04-07 9:48 GMT+03:00 Sergi Vladykin <
>> sergi.vlady...@gmail.com
 :
> 
>> It is possible to try adding support of comparison to Resolvers,
>>> but
 the
>> whole approach looks wrong and for now it is better to get rid of
>>> it
> while
>> we have a chance to break compatibility.
>> 
>> Sergi
>> 
>> 2017-04-07 9:19 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>> 
>>> The discussion should've been started with that :) If supporting
> resolvers
>>> in new architecture is not possible or means too big effort,
>> then
>>> it's
>>> definitely not worth it.
>>> 
>>> -Val
>>> 
>>> On Thu, Apr 6, 2017 at 8:52 PM, Vladimir Ozerov <
>>> voze...@gridgain.com
> 
>>> wrote:
>>> 
 Dima,
 
 Yes, they may explode some internals of our indexes.
 
 06 апр. 2017 г. 23:32 пользователь 

Re: Stable binary key representation

[Dmitriy Setrakyan]

Denis, I think it is important that we know which specific field to use for
the affinity resolution, but I don't see any issue in using both, primary
and foreign keys, for hashcode and equality. Do you?

D.

On Tue, Apr 11, 2017 at 11:46 AM, Igor Sapego  wrote:

> Denis,
>
> The whole binary representation of the object is used now
> for hash code generation and equality comparison. So the
> answer - all fields are used for this.
>
> Best Regards,
> Igor
>
> On Mon, Apr 10, 2017 at 9:50 PM, Denis Magda  wrote:
>
> > Considering this simple example
> >
> > INSERT (id, orgId, name, age, address) into Person…
> >
> > where id and orgId define Person’s affinity key - PersonKey(id, orgId)
> >
> > How do we know which fields to use for hash code generation and equality
> > comparison? QueryEntity?
> >
> > No, it’s unclear how to document it properly.
> >
> > —
> > Denis
> >
> > > On Apr 10, 2017, at 11:14 AM, Vladimir Ozerov 
> > wrote:
> > >
> > > There is no more such resolver. It was removed.
> > >
> > > On Mon, Apr 10, 2017 at 8:58 PM, Denis Magda 
> wrote:
> > >
> > >> Vovan,
> > >>
> > >> Before I fix the documentation, what’t the replacement for
> > >> BinaryFieldIdentiyResolver we used to define field for hash code
> > >> calculation and equality comparison when DML statements are used?
> > >> https://apacheignite.readme.io/docs/binary-marshaller#
> > >> section-binary-field-identity-resolver  > >> io/docs/binary-marshaller#section-binary-field-identity-resolver>
> > >>
> > >> —
> > >> Denis
> > >>
> > >>> On Apr 9, 2017, at 7:39 AM, Vladimir Ozerov 
> > >> wrote:
> > >>>
> > >>> Resolvers were essential for DML because we had broken comparison
> > >> semantics
> > >>> of binary objects. This is not the case now.
> > >>>
> > >>> Resolver as a whole is normal practice. E.g. it is implemented in
> .NET
> > on
> > >>> core language level and widely used in many cases. Hazelcast has it
> as
> > >> well
> > >>> AFAIK. So it is wrong to think that the whole idea is useless. Think
> of
> > >> it
> > >>> as a comparator's brother.
> > >>>
> > >>> The only reason why we need to remove it is missing hash index in new
> > >>> architecture. It makes sense, as it is better to have AI 2.0 without
> > >> them,
> > >>> than no AI 2.0 :-)
> > >>>
> > >>> 09 апр. 2017 г. 17:31 пользователь "Sergi Vladykin" <
> > >>> sergi.vlady...@gmail.com> написал:
> > >>>
> >  I guess Resolvers were added to DML just because they already
> existed
> > >> since
> >  1.9 and we were forced to support them in all the parts of our
> > product.
> > 
> >  We have to stop this practice to add features without clear real
> life
> > >> use
> >  cases for them.
> > 
> >  Sergi
> > 
> >  2017-04-09 17:00 GMT+03:00 Denis Magda :
> > 
> > > Sergi, Vovan,
> > >
> > > Sorry for being annoying but I still didn't get an answer on
> whether
> > >> the
> > > resolvers are the must for DML. The main reason why we made them up
> > >> some
> > > time ago is to support specific DML use cases. However I can't
> recall
> > >> the
> > > use cases.
> > >
> > > --
> > > Denis
> > >
> > > On Sun, Apr 9, 2017 at 6:54 AM, Sergi Vladykin <
> > >> sergi.vlady...@gmail.com
> > >
> > > wrote:
> > >
> > >> Ok, we need to do 2 things here:
> > >>
> > >> 1. Drop the resolvers from the source code.
> > >> 2. Write a good page in docs on "What makes a correct cache key".
> > >>
> > >> Who can do that?
> > >>
> > >> Sergi
> > >>
> > >> 2017-04-07 9:48 GMT+03:00 Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >:
> > >>
> > >>> It is possible to try adding support of comparison to Resolvers,
> > but
> > > the
> > >>> whole approach looks wrong and for now it is better to get rid of
> > it
> > >> while
> > >>> we have a chance to break compatibility.
> > >>>
> > >>> Sergi
> > >>>
> > >>> 2017-04-07 9:19 GMT+03:00 Valentin Kulichenko <
> > >>> valentin.kuliche...@gmail.com>:
> > >>>
> >  The discussion should've been started with that :) If supporting
> > >> resolvers
> >  in new architecture is not possible or means too big effort,
> then
> >  it's
> >  definitely not worth it.
> > 
> >  -Val
> > 
> >  On Thu, Apr 6, 2017 at 8:52 PM, Vladimir Ozerov <
> >  voze...@gridgain.com
> > >>
> >  wrote:
> > 
> > > Dima,
> > >
> > > Yes, they may explode some internals of our indexes.
> > >
> > > 06 апр. 2017 г. 23:32 пользователь "Dmitriy Setrakyan" <
> > > dsetrak...@apache.org> написал:
> > >
> > >> Guys,
> > >>
> > >> Isn't the main issue here that we cannot use the Identity
> > > 

Re: Sorting fields of Binarilyzable objects on write

[Dmitriy Setrakyan]

Sergi, why do you not like the alphabetical order? Seems like it would be a
much easier to understand requirement from the user standpoint. Do you see
some issues here?

On Mon, Apr 10, 2017 at 10:43 AM, Sergi Vladykin 
wrote:

> I'm sorry, looks like I do not really well understand this stuff, but it is
> still not clear to me why wouldn't we just take the order of key fields
> given in QueryEntity and use it for both cases irrespectively to the order
> of fields in regular Class or in Binarylizable?
>
> I mean lets say we have a Class (with unpredictable order of fields
> according to reflection):
>
>Person implements Serializable
>   {int age, double salary}
>
> Or we have a Binarylizable (with some unknown user defined order of
> fields):
>
>   Person implements Binarylizable {
>  writeBinary(w) {w.writeDouble("salary", salary),  w.writeInt(''age",
> age)}
>
> Also we have a QueryEntity (age, salary)
>
> Why we can not take key fields names from QueryEntity in the given order
> (age, salary) and get values from either "regular" Class or from
> Binarylizable and calculate hash code?
>
> Sergi
>
> 2017-04-10 19:56 GMT+03:00 Vladimir Ozerov :
>
> > Guys,
> >
> > The problem is that order of fields serialization is unknown for regular
> > objects, where "regular" stands for non-Binarilyzable class. Reflection
> > returns fields in unpredictable order. For this reason you cannot match
> > fields order between class and QueryEntity. This is why we introduced
> > sorting, and this is why idea to rely on QueryEntity doesn't work.
> >
> > On Mon, Apr 10, 2017 at 7:01 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > Why "regular" are different here?
> > >
> > > Sergi
> > >
> > > 2017-04-10 18:59 GMT+03:00 Pavel Tupitsyn :
> > >
> > > > QueryEntity sorting is not an option for "regular" classes with
> > > reflective
> > > > serialization.
> > > > We have to use alphabetical.
> > > > Also, same class can participate in multiple query entities.
> > > >
> > > > 10 апр. 2017 г. 18:52 пользователь "Dmitriy Setrakyan" <
> > > > dsetrak...@apache.org> написал:
> > > >
> > > > On Mon, Apr 10, 2017 at 8:28 AM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > The decision to use alphabetic order looks strange here. Using
> order
> > > > > provided in QueryEntity and require from user to have the same
> order
> > > > > in Binarylizable
> > > > > looks more reasonable.
> > > > >
> > > >
> > > > I think this would be much harder to verify. Alphabetical order is
> more
> > > > intuitive, no?
> > > >
> > >
> >
>

Re: Stable binary key representation

[Igor Sapego]

Denis,

The whole binary representation of the object is used now
for hash code generation and equality comparison. So the
answer - all fields are used for this.

Best Regards,
Igor

On Mon, Apr 10, 2017 at 9:50 PM, Denis Magda  wrote:

> Considering this simple example
>
> INSERT (id, orgId, name, age, address) into Person…
>
> where id and orgId define Person’s affinity key - PersonKey(id, orgId)
>
> How do we know which fields to use for hash code generation and equality
> comparison? QueryEntity?
>
> No, it’s unclear how to document it properly.
>
> —
> Denis
>
> > On Apr 10, 2017, at 11:14 AM, Vladimir Ozerov 
> wrote:
> >
> > There is no more such resolver. It was removed.
> >
> > On Mon, Apr 10, 2017 at 8:58 PM, Denis Magda  wrote:
> >
> >> Vovan,
> >>
> >> Before I fix the documentation, what’t the replacement for
> >> BinaryFieldIdentiyResolver we used to define field for hash code
> >> calculation and equality comparison when DML statements are used?
> >> https://apacheignite.readme.io/docs/binary-marshaller#
> >> section-binary-field-identity-resolver  >> io/docs/binary-marshaller#section-binary-field-identity-resolver>
> >>
> >> —
> >> Denis
> >>
> >>> On Apr 9, 2017, at 7:39 AM, Vladimir Ozerov 
> >> wrote:
> >>>
> >>> Resolvers were essential for DML because we had broken comparison
> >> semantics
> >>> of binary objects. This is not the case now.
> >>>
> >>> Resolver as a whole is normal practice. E.g. it is implemented in .NET
> on
> >>> core language level and widely used in many cases. Hazelcast has it as
> >> well
> >>> AFAIK. So it is wrong to think that the whole idea is useless. Think of
> >> it
> >>> as a comparator's brother.
> >>>
> >>> The only reason why we need to remove it is missing hash index in new
> >>> architecture. It makes sense, as it is better to have AI 2.0 without
> >> them,
> >>> than no AI 2.0 :-)
> >>>
> >>> 09 апр. 2017 г. 17:31 пользователь "Sergi Vladykin" <
> >>> sergi.vlady...@gmail.com> написал:
> >>>
>  I guess Resolvers were added to DML just because they already existed
> >> since
>  1.9 and we were forced to support them in all the parts of our
> product.
> 
>  We have to stop this practice to add features without clear real life
> >> use
>  cases for them.
> 
>  Sergi
> 
>  2017-04-09 17:00 GMT+03:00 Denis Magda :
> 
> > Sergi, Vovan,
> >
> > Sorry for being annoying but I still didn't get an answer on whether
> >> the
> > resolvers are the must for DML. The main reason why we made them up
> >> some
> > time ago is to support specific DML use cases. However I can't recall
> >> the
> > use cases.
> >
> > --
> > Denis
> >
> > On Sun, Apr 9, 2017 at 6:54 AM, Sergi Vladykin <
> >> sergi.vlady...@gmail.com
> >
> > wrote:
> >
> >> Ok, we need to do 2 things here:
> >>
> >> 1. Drop the resolvers from the source code.
> >> 2. Write a good page in docs on "What makes a correct cache key".
> >>
> >> Who can do that?
> >>
> >> Sergi
> >>
> >> 2017-04-07 9:48 GMT+03:00 Sergi Vladykin  >:
> >>
> >>> It is possible to try adding support of comparison to Resolvers,
> but
> > the
> >>> whole approach looks wrong and for now it is better to get rid of
> it
> >> while
> >>> we have a chance to break compatibility.
> >>>
> >>> Sergi
> >>>
> >>> 2017-04-07 9:19 GMT+03:00 Valentin Kulichenko <
> >>> valentin.kuliche...@gmail.com>:
> >>>
>  The discussion should've been started with that :) If supporting
> >> resolvers
>  in new architecture is not possible or means too big effort, then
>  it's
>  definitely not worth it.
> 
>  -Val
> 
>  On Thu, Apr 6, 2017 at 8:52 PM, Vladimir Ozerov <
>  voze...@gridgain.com
> >>
>  wrote:
> 
> > Dima,
> >
> > Yes, they may explode some internals of our indexes.
> >
> > 06 апр. 2017 г. 23:32 пользователь "Dmitriy Setrakyan" <
> > dsetrak...@apache.org> написал:
> >
> >> Guys,
> >>
> >> Isn't the main issue here that we cannot use the Identity
> > Resolvers
> >> in
> >> BTrees in the 2.0 version? If yes, then we have to remove them
>  no
>  matter
> >> what.
> >>
> >> D.
> >>
> >> On Thu, Apr 6, 2017 at 1:23 PM, Sergi Vladykin <
>  sergi.vlady...@gmail.com
> >>
> >> wrote:
> >>
> >>> Binary key representation is stable when we always have equal
> > serialized
> >>> bytes when the original keys are equal.
> >>>
> >>> Resolver allows you to have some extra info in the Key and
>  equal
>  

Re: AffinityKeyMapper: break compatibility before 2.0

[Dmitriy Setrakyan]

OK, let's drop it. But we should provide clear instructions in the 2.0
migration guide about this change.

On Tue, Apr 11, 2017 at 1:33 AM, Sergi Vladykin 
wrote:

> +1 to Vladimir.
>
> Sergi
>
> 2017-04-11 10:48 GMT+03:00 Vladimir Ozerov :
>
> > Dima,
> >
> > The whole idea of AffinityKeyMapper appears to be wrong since we will
> have
> > only BinaryMarshaller. We do not have classes on server, how can we rely
> on
> > interface this class extends? I think we should do the following:
> > 1) Allow @AffinityKeyMapped annotation on fields only (it doesn't work on
> > methods with binary anyway).
> > 2) Drop AffinityKeyMapper completely.
> > 3) Hopefully, at some point we will implement old Yakov's idea of
> > declarative extensions to binary objects, which will handle "affintiy
> key",
> > "equals/hashCode" and "compareTo" cases without necessity to have any
> > interface implementation classes on the server.
> >
> > Thoughts?
> >
> > On Tue, Apr 11, 2017 at 10:41 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > I agree that this interface is problematic. However, I don't think that
> > > dropping it right away would be fair to our users. Can we deprecate it
> > and
> > > print out a warning that AffinityKeyMapper cannot be used with DDL
> > > statements?
> > >
> > > D.
> > >
> > > On Tue, Apr 11, 2017 at 12:32 AM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Guys,
> > > >
> > > > We are moving in direction of better distributed SQL support, it
> means
> > > that
> > > > we always will need to know an affinity field name for key type.
> > > >
> > > > Now we have AffinityKeyMapper which hides it from us.
> > > >
> > > > Since we have other means of configuring the affinity key, e.g
> > > > CacheKeyConfiguration and @AffinityKeyMapped, I suggest to either
> drop
> > > this
> > > > interface or change it so that it just return affinity key field name
> > > > instead of the affinity key field value. I prefer dropping it.
> > > >
> > > > What do you think?
> > > >
> > > > Sergi
> > > >
> > >
> >
>

[GitHub] ignite pull request #1776: Ignite 4587 review

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/1776

Ignite 4587 review



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-4587-review

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1776.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1776


commit f0dcbbdecd10ee9afee3cb0c5a96bb1540d0c06a
Author: Max Kozlov 
Date:   2017-02-13T09:20:51Z

Delete CLOCK mode in CacheAtomicWriteOrderMode.

commit a37ff76168613007d3ca09c06688bc6456e4c330
Author: Max Kozlov 
Date:   2017-02-13T09:27:28Z

Delete use CLOCK for ignite-core.

commit 25d4ea5003773b739baba2c2d5c3e7be2194ba7a
Author: Max Kozlov 
Date:   2017-02-13T09:43:59Z

Fix tests CLOCK change to PRIMARY and delete same test.

commit fcc4d8567b9ec39bb9632cf64da5f4b4390a5928
Author: Max Kozlov 
Date:   2017-02-13T13:14:25Z

Delete CLOCK, and remove check FULL_SYNC.

commit 062d631d6b6968963bcb6ef6431d622366b11706
Author: Max Kozlov 
Date:   2017-02-13T13:15:41Z

Change from CLOCK to PRIMARY in CacheConfigurationTest.cs.

commit 92e11e85cc3490b8544746e2b98336a29316c725
Author: Max Kozlov 
Date:   2017-02-13T17:00:29Z

Fix method fastMap.

commit bc7a9bd88b8d9fc18a291adbb7eb05dd1c2c0862
Author: Max Kozlov 
Date:   2017-02-27T11:33:08Z

Merge branch 'master' into ignite-4587

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicSingleUpdateFuture.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateFuture.java

commit a61e5661d182fec218f7a0ee6a3b8f484e9a7643
Author: Max Kozlov 
Date:   2017-02-27T11:40:22Z

Remove isFastMap method in GridDhtAtomicCache class because always returns 
false.

commit 8a96fdf199bf476bd417192d795fcf4d1135deb8
Author: Max Kozlov 
Date:   2017-02-27T13:25:13Z

Remove field updVer in GridNearAtomicAbstractUpdateFuture. Remove parametr 
updVer in GridNearAtomicSingleUpdateFuture.mapSingleUpdate, 
GridNearAtomicUpdateFuture.mapSingleUpdate and 
GridNearAtomicUpdateFuture.mapUpdate.

commit 72c15e5974fa253b919d001677e98a87ed219991
Author: Max Kozlov 
Date:   2017-03-01T13:01:35Z

Remove CacheAtomicWriteOrderMode.java and refactoring core module.

commit 97fdb0e03492047fe64191059a1725775e335b7b
Author: Max Kozlov 
Date:   2017-03-01T13:04:13Z

Refactoring yardstick module.

commit 82790a862f93378a09a8e8a7b52956bbe77f9085
Author: Max Kozlov 
Date:   2017-03-01T13:05:32Z

Refactoring idexing module.

commit 3d5c1345dc550b622569b0e63e019a4ae92539a8
Author: Max Kozlov 
Date:   2017-03-01T13:27:44Z

Refactoring visor-console module.

commit 5adaa1160190896b653ad4c5ea1035bc6c86048c
Author: Max Kozlov 
Date:   2017-03-01T20:41:21Z

Some loose change.

commit a60841220c1fe20c22e3122090bcfb98fa1f4b18
Author: Max Kozlov 
Date:   2017-03-01T20:41:46Z

Delete PRIMARY in test config.

commit ed3370f2fd750485a11d850b515092e4b26b6940
Author: Max Kozlov 
Date:   2017-03-01T20:42:42Z

Delete support write order mode in web-console.

commit 59af0367fe7b74ebb826c1cb57adc8cacf13ee49
Author: Max Kozlov 
Date:   2017-03-01T20:43:19Z

Delete write order mode in dotnet platform.

commit 32d2308647646027fa5792d05e532a041a974e73
Author: Max Kozlov 
Date:   2017-03-01T20:44:55Z

Delete atomicWriteOrderMode in config cpp platform.

commit 6265f33bf9401bf8c5449bb3da7daeadca086b3b
Author: Max Kozlov 
Date:   2017-03-01T22:21:35Z

Remove and rename tests.

commit 9b02f81f2e9d21ad2c2ad4e5fe4efd52545f59fb
Author: Max Kozlov 
Date:   2017-03-07T11:45:24Z

Remove GridClockSyncProcessor and related code removed.

commit decc8021f7ae5c0073f8cf15c7ca64a57305aa3b
Author: Max Kozlov 
Date:   2017-03-09T11:34:40Z

Remove GridClockSyncProcessor, GridTimeSyncProcessorSelfTest and related.

commit bdc8f2078fe914f4bd85ce0c7dc6ca8689e223e4
Author: Max Kozlov 
Date:   2017-03-09T14:20:44Z

Remove globalTime.

commit 20a87f832e4b3f46c8da511e85e08f1f6203b693
Author: Max Kozlov 
Date:   2017-03-09T15:29:23Z

Remove updateTime.

commit ea3d5de8437df5cafcf8315dde1ac6d113eef6ad
Author: Max Kozlov 
Date:   2017-03-09T15:35:52Z

wip

Re: IGNITE-1794 is ready for review

[Denis Magda]

Vadim, 

Do you mean this task?
> https://issues.apache.org/jira/browse/IGNITE-1794 
> 
As I see Semen has already promised to review it and merge into the master by 
the end of the week.

Did you add anything else in addition to previous changes?

—
Denis

> On Apr 11, 2017, at 9:51 AM, Вадим Опольский  wrote:
> 
> Hello guys!
> 
> I added folder hibernate5 as module to project settings and discovered some 
> errors. Fixed errors in pull request - 
> https://github.com/vopolski/ignite/pull/1/files 
> 
> But some tests from hibernate5 is failed. I'll fix them.
> 
> How much time do I have?
> 
> Vadim Opolski
> 
> 2017-04-06 13:04 GMT+03:00 Вадим Опольский  >:
> Dear sirs!
> 
> Sorry for incorrect subject.
> 
> https://github.com/apache/ignite/pull/1643 
> 
> 
> -- Forwarded message --
> From: Вадим Опольский >
> Date: 2017-03-24 15:48 GMT+03:00
> Subject: ready for review IGNITE-933
> To: dev@ignite.apache.org , Denis Magda 
> >, Valentin Kulichenko 
> >
> 
> 
> Hello everyone!
> 
> Denis, Valentin, what should I do to close issue 
> https://issues.apache.org/jira/browse/IGNITE-1794 
>  ?
> 
> The tests in Team City executed successfully.
> 
> Valentin, I renamed IgniteHibernateTestSuite -> IgniteHibernate5TestSuite. 
> Can you create TeamCity Configuration ?
> 
> 
> 
> Vadim Opolski
> 
> 2017-03-21 11:30 GMT+03:00 Вадим Опольский  >:
> Hello everybody.
> 
> The issue  https://issues.apache.org/jira/browse/IGNITE-1794 
>  fixed originally by 
> Mykola Pereyma.
> I re-assigned issue https://issues.apache.org/jira/browse/IGNITE-1794 
>  on myself, because we 
> haven’t got a note from him for a while.
> 
> Denis, I merged pull request https://github.com/apache/ignite/pull/1146 
>  with my fork.
> Then I changed hibernate version to 5.2.7 and deleted ByteArrayType.java as 
> per CI comments.
> The tests from list below executed succesfully.
> 
> Prepared new pull request - https://github.com/apache/ignite/pull/1643 
> 
> 
> What's the next step ?
> 
> Tests:
> HibernateL2CacheConfigurationSelfTest.java
> HibernateL2CacheSelfTest.java
> HibernateL2CacheTransactionalSelfTest.java
> HibernateL2CacheTransactionalUseSyncSelfTest.java
> CacheHibernateBlobStoreNodeRestartTest.java
> CacheHibernateBlobStoreSelfTest.java
> CacheHibernateStoreFactorySelfTest.java
> CacheHibernateStoreSessionListenerSelfTest.java
> 
> 
> Vadim Opolski
> 
> 
> 2017-02-25 2:38 GMT+03:00 Denis Magda  >:
> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974 is 
> > interesting for me. How I can assignee it to me? It is assigning with 
> > Mykola Pereyma now.
> >
> > https://issues.apache.org/jira/browse/IGNITE-1794 
> >  
> >  > >
> 
> Just re-assign it on yourself ;) Hope that Mykola is fine with this because 
> we haven’t got a note from him for a while.
> 
> —
> Denis
> 
> > On Feb 24, 2017, at 12:24 PM, Вадим Опольский  > > wrote:
> >
> > Hi Denis,
> >
> > OK, I spotted the problem in the code and I will be try to resolve it.
> >
> > https://issues.apache.org/jira/browse/IGNITE-933 
> >  
> >  > >
> >
> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974 is 
> > interesting for me. How I can assignee it to me? It is assigning with 
> > Mykola Pereyma now.
> >
> > https://issues.apache.org/jira/browse/IGNITE-1794 
> >  
> >  > >
> >
> > Vadim Opolski
> >
> > 2017-02-24 5:55 GMT+03:00 Denis Magda  >   > >>:
> > Hi Vadim,
> >
> > Yes, this issue might be still relevant. I can’t guide you through but, 
> > basically, you need to reproduce the issue, spot it in the code and propose 
> > a fix.
> >
> > BTW, do you have any experience with 

Re: IGNITE-1794 is ready for review

[Semyon Boikov]

Hi Vadim,

I already fixed all issues with hibernate5 tests and merged in
ignite-3477-master, it will be merged in master soon.

Thanks

On Tue, Apr 11, 2017 at 7:51 PM, Вадим Опольский 
wrote:

> Hello guys!
>
> I added folder hibernate5 as module to project settings and discovered some
> errors. Fixed errors in pull request -
> https://github.com/vopolski/ignite/pull/1/files
> But some tests from hibernate5 is failed. I'll fix them.
>
> How much time do I have?
>
> Vadim Opolski
>
> 2017-04-06 13:04 GMT+03:00 Вадим Опольский :
>
> > Dear sirs!
> >
> > Sorry for incorrect subject.
> >
> > https://github.com/apache/ignite/pull/1643
> >
> > -- Forwarded message --
> > From: Вадим Опольский 
> > Date: 2017-03-24 15:48 GMT+03:00
> > Subject: ready for review IGNITE-933
> > To: dev@ignite.apache.org, Denis Magda , Valentin
> > Kulichenko 
> >
> >
> > Hello everyone!
> >
> > Denis, Valentin, what should I do to close issue
> > https://issues.apache.org/jira/browse/IGNITE-1794 ?
> >
> > The tests in Team City executed successfully.
> >
> > Valentin, I renamed IgniteHibernateTestSuite ->
> IgniteHibernate5TestSuite.
> > Can you create TeamCity Configuration ?
> >
> >
> >
> > Vadim Opolski
> >
> > 2017-03-21 11:30 GMT+03:00 Вадим Опольский :
> >
> >> Hello everybody.
> >>
> >> The issue  https://issues.apache.org/jira/browse/IGNITE-1794 fixed
> >> originally by Mykola Pereyma.
> >> I re-assigned issue https://issues.apache.org/jira/browse/IGNITE-1794
> on
> >> myself, because we haven’t got a note from him for a while.
> >>
> >> Denis, I merged pull request https://github.com/apache/ignite/pull/1146
> with
> >> my fork.
> >> Then I changed hibernate version to 5.2.7 and deleted ByteArrayType.java
> >> as per CI comments.
> >> The tests from list below executed succesfully.
> >>
> >> Prepared new pull request - https://github.com/apache/ignite/pull/1643
> >>
> >> What's the next step ?
> >>
> >> Tests:
> >> HibernateL2CacheConfigurationSelfTest.java
> >> HibernateL2CacheSelfTest.java
> >> HibernateL2CacheTransactionalSelfTest.java
> >> HibernateL2CacheTransactionalUseSyncSelfTest.java
> >> CacheHibernateBlobStoreNodeRestartTest.java
> >> CacheHibernateBlobStoreSelfTest.java
> >> CacheHibernateStoreFactorySelfTest.java
> >> CacheHibernateStoreSessionListenerSelfTest.java
> >>
> >>
> >> Vadim Opolski
> >>
> >>
> >> 2017-02-25 2:38 GMT+03:00 Denis Magda :
> >>
> >>> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974
> is
> >>> interesting for me. How I can assignee it to me? It is assigning with
> >>> Mykola Pereyma now.
> >>> >
> >>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> >>> https://issues.apache.org/jira/browse/IGNITE-1794>
> >>>
> >>> Just re-assign it on yourself ;) Hope that Mykola is fine with this
> >>> because we haven’t got a note from him for a while.
> >>>
> >>> —
> >>> Denis
> >>>
> >>> > On Feb 24, 2017, at 12:24 PM, Вадим Опольский 
> >>> wrote:
> >>> >
> >>> > Hi Denis,
> >>> >
> >>> > OK, I spotted the problem in the code and I will be try to resolve
> it.
> >>> >
> >>> > https://issues.apache.org/jira/browse/IGNITE-933 <
> >>> https://issues.apache.org/jira/browse/IGNITE-933>
> >>> >
> >>> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974
> is
> >>> interesting for me. How I can assignee it to me? It is assigning with
> >>> Mykola Pereyma now.
> >>> >
> >>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> >>> https://issues.apache.org/jira/browse/IGNITE-1794>
> >>> >
> >>> > Vadim Opolski
> >>> >
> >>> > 2017-02-24 5:55 GMT+03:00 Denis Magda >> dma...@apache.org>>:
> >>> > Hi Vadim,
> >>> >
> >>> > Yes, this issue might be still relevant. I can’t guide you through
> >>> but, basically, you need to reproduce the issue, spot it in the code
> and
> >>> propose a fix.
> >>> >
> >>> > BTW, do you have any experience with Hibernate? If so, I would be
> >>> amazing if you pick up this ticket reassigning on yourself:
> >>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
> >>> https://issues.apache.org/jira/browse/IGNITE-1794> <
> >>> https://issues.apache.org/jira/browse/IGNITE-1794 <
> >>> https://issues.apache.org/jira/browse/IGNITE-1794>>
> >>> >
> >>> > —
> >>> > Denis
> >>> >
> >>> > > On Feb 23, 2017, at 2:40 AM, Вадим Опольский  >>> > wrote:
> >>> > >
> >>> > > Dear sirs !
> >>> > >
> >>> > > I want to resolve issue IGNITE-933
> >>> > >
> >>> > > https://issues.apache.org/jira/browse/IGNITE-933 <
> >>> https://issues.apache.org/jira/browse/IGNITE-933>
> >>> > >
> >>> > > Is it actual ?
> >>> > >
> >>> > > In which class and method you want me to make changes ?
> >>> > >
> >>> > > Vadim Opolski
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
> >
>

Re: transaction , waiting for prepare response

[Andrey Gura]

Aleksey,

timer like you are mentioned exists - it is transaction timeout.

On Tue, Apr 11, 2017 at 3:25 PM, ALEKSEY KUZNETSOV
 wrote:
> Igniters! If we started transaction, and in phase prepare the primary node
> doesnt receive GridDhtPrepareResponse then the transaction got stuck for a
> long time. Why don't we have got timer that causes rollback if transaction
> time on waiting has expired   ?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*

Re: IGNITE-1794 is ready for review

[Вадим Опольский]

Hello guys!

I added folder hibernate5 as module to project settings and discovered some
errors. Fixed errors in pull request -
https://github.com/vopolski/ignite/pull/1/files
But some tests from hibernate5 is failed. I'll fix them.

How much time do I have?

Vadim Opolski

2017-04-06 13:04 GMT+03:00 Вадим Опольский :

> Dear sirs!
>
> Sorry for incorrect subject.
>
> https://github.com/apache/ignite/pull/1643
>
> -- Forwarded message --
> From: Вадим Опольский 
> Date: 2017-03-24 15:48 GMT+03:00
> Subject: ready for review IGNITE-933
> To: dev@ignite.apache.org, Denis Magda , Valentin
> Kulichenko 
>
>
> Hello everyone!
>
> Denis, Valentin, what should I do to close issue
> https://issues.apache.org/jira/browse/IGNITE-1794 ?
>
> The tests in Team City executed successfully.
>
> Valentin, I renamed IgniteHibernateTestSuite -> IgniteHibernate5TestSuite.
> Can you create TeamCity Configuration ?
>
>
>
> Vadim Opolski
>
> 2017-03-21 11:30 GMT+03:00 Вадим Опольский :
>
>> Hello everybody.
>>
>> The issue  https://issues.apache.org/jira/browse/IGNITE-1794 fixed
>> originally by Mykola Pereyma.
>> I re-assigned issue https://issues.apache.org/jira/browse/IGNITE-1794 on
>> myself, because we haven’t got a note from him for a while.
>>
>> Denis, I merged pull request https://github.com/apache/ignite/pull/1146 with
>> my fork.
>> Then I changed hibernate version to 5.2.7 and deleted ByteArrayType.java
>> as per CI comments.
>> The tests from list below executed succesfully.
>>
>> Prepared new pull request - https://github.com/apache/ignite/pull/1643
>>
>> What's the next step ?
>>
>> Tests:
>> HibernateL2CacheConfigurationSelfTest.java
>> HibernateL2CacheSelfTest.java
>> HibernateL2CacheTransactionalSelfTest.java
>> HibernateL2CacheTransactionalUseSyncSelfTest.java
>> CacheHibernateBlobStoreNodeRestartTest.java
>> CacheHibernateBlobStoreSelfTest.java
>> CacheHibernateStoreFactorySelfTest.java
>> CacheHibernateStoreSessionListenerSelfTest.java
>>
>>
>> Vadim Opolski
>>
>>
>> 2017-02-25 2:38 GMT+03:00 Denis Magda :
>>
>>> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974 is
>>> interesting for me. How I can assignee it to me? It is assigning with
>>> Mykola Pereyma now.
>>> >
>>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
>>> https://issues.apache.org/jira/browse/IGNITE-1794>
>>>
>>> Just re-assign it on yourself ;) Hope that Mykola is fine with this
>>> because we haven’t got a note from him for a while.
>>>
>>> —
>>> Denis
>>>
>>> > On Feb 24, 2017, at 12:24 PM, Вадим Опольский 
>>> wrote:
>>> >
>>> > Hi Denis,
>>> >
>>> > OK, I spotted the problem in the code and I will be try to resolve it.
>>> >
>>> > https://issues.apache.org/jira/browse/IGNITE-933 <
>>> https://issues.apache.org/jira/browse/IGNITE-933>
>>> >
>>> > Yes, I have some experience with Hibernate. The issue № IGNITE-1974 is
>>> interesting for me. How I can assignee it to me? It is assigning with
>>> Mykola Pereyma now.
>>> >
>>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
>>> https://issues.apache.org/jira/browse/IGNITE-1794>
>>> >
>>> > Vadim Opolski
>>> >
>>> > 2017-02-24 5:55 GMT+03:00 Denis Magda > dma...@apache.org>>:
>>> > Hi Vadim,
>>> >
>>> > Yes, this issue might be still relevant. I can’t guide you through
>>> but, basically, you need to reproduce the issue, spot it in the code and
>>> propose a fix.
>>> >
>>> > BTW, do you have any experience with Hibernate? If so, I would be
>>> amazing if you pick up this ticket reassigning on yourself:
>>> > https://issues.apache.org/jira/browse/IGNITE-1794 <
>>> https://issues.apache.org/jira/browse/IGNITE-1794> <
>>> https://issues.apache.org/jira/browse/IGNITE-1794 <
>>> https://issues.apache.org/jira/browse/IGNITE-1794>>
>>> >
>>> > —
>>> > Denis
>>> >
>>> > > On Feb 23, 2017, at 2:40 AM, Вадим Опольский >> > wrote:
>>> > >
>>> > > Dear sirs !
>>> > >
>>> > > I want to resolve issue IGNITE-933
>>> > >
>>> > > https://issues.apache.org/jira/browse/IGNITE-933 <
>>> https://issues.apache.org/jira/browse/IGNITE-933>
>>> > >
>>> > > Is it actual ?
>>> > >
>>> > > In which class and method you want me to make changes ?
>>> > >
>>> > > Vadim Opolski
>>> >
>>> >
>>>
>>>
>>
>
>

[jira] [Created] (IGNITE-4947) Create AI 2.0 TC suites

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4947:
---

 Summary: Create AI 2.0 TC suites
 Key: IGNITE-4947
 URL: https://issues.apache.org/jira/browse/IGNITE-4947
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.0
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 2.0


Due to OptimizedMarshaller removal from public API per IGNITE-4938, we need 
all-new post-OptimizedMarshaller set of TC suites that will be used by default 
after 2.0 is released.

What has to be done:

- Remove all OptimizedMarshaller specific suites
- Make all 'binary' suites 'standard'



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1775: Ignite 4938

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

https://github.com/apache/ignite/pull/1775

Ignite 4938



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-4938

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1775.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1775


commit faa8681ab35e2332a7b16210492468495eb9518e
Author: Alexander Paschenko 
Date:   2017-04-10T16:47:17Z

IGNITE-4938 De-pub of OptimizedMarshaller - take 1

commit a3686db055a55c87484ebad04e37f13ad06f93ce
Author: Alexander Paschenko 
Date:   2017-04-11T11:43:48Z

Merge branch 'master' into ignite-4938

commit 7942d585fde3fd11964f479b0442caa2ba0459d1
Author: Alexander Paschenko 
Date:   2017-04-11T16:10:37Z

IGNITE-4938 De-pub of OptimizedMarshaller - take 2




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Move documentation from readme.io to GitHub pages

[Denis Magda]

Pavel,

I totally agree that it’s becoming more and more inconvenient to run the 
documentation on readme.io . At the same time the Git 
approach is no way to go for us because all the documentation has to be hosted 
on ASF side. Presently we violate this policy and I look forward we fix it 
pretty soon.

So, in general, all the documentation content has to become a part of Apache 
Ignite site and available from there. Here are some of the examples of another 
ASF projects:
http://spark.apache.org/docs/2.1.0/ 
https://zeppelin.apache.org/contribution/documentation.html 

https://hadoop.apache.org/docs/r2.7.2/ 

Are you aware of any ready-to-be-used documentation libs that can be easily 
reused by us?

—
Denis

> On Apr 11, 2017, at 2:02 AM, Pavel Tupitsyn  wrote:
> 
> Igniters,
> 
> Currently we host documentation on
> apacheignite.readme.io (and also apacheignite-net.readme.io,
> apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).
> 
> readme.io has a lot of problems mostly due to lack of proper version
> control:
> * Each "version" is just a copy. When fixing something, you have to update
> all versions.
> * No good way to review changes.
> * "Propose edit" functionality is a joke. You can only accept or reject an
> edit, no way to communicate with contributor, etc
> 
> GitHub Pages solves all these problems:
> https://github.com/blog/2233-publish-your-project-documentation-with-github-pages
> 
> Basically, we'll have a separate folder in our Git repository where
> documentation is stored in markdown format.
> This way the process for updating docs is exactly the same as any other
> code change.
> Pull request with new feature can contain the docs for this feature, and so
> on.
> 
> Thoughts?

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

[Denis Magda]

Hello,

Do you have sample code?

—
Denis
> On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> Hi, igniters!
> While doing https://issues.apache.org/jira/browse/IGNITE-4401 ticket i came
> across the fact that cache querying returns null , while cache still has
> got entry.
> Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
> Cache get operation : ignite().cache("eduPropCache").get(new AffinityKey("1",
> "1")) non-null
> I cannot even imagine what could be wrong with it.
> 
> 
> 
> -- 
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Denis Magda]

Yasha,

I’ve updated the javadoc for IgniteConfiguration.metricsUpdateFrequency and 
merged the changes into your branch (see JIRA). The rest is fine for now. An 
advance documentation on how the heartbeats are implemented can be done in 
readme.io .

—
Denis

> On Apr 11, 2017, at 1:07 AM, Yakov Zhdanov  wrote:
> 
> Messages renaming is never compatible =)
> 
> Denis, did you try to update javadocs?
> 
> --Yakov
> 
> 2017-04-10 21:41 GMT+03:00 Denis Magda :
> 
>> Yasha,
>> 
>> Thanks, I’ve replied you in the ticket.
>> 
>> In a nutshel, let’s try to merge current breaking changes to 2.0 and do
>> the rest of compatible refactoring in further releases. Are you agree with
>> this?
>> 
>> —
>> Denis
>> 
>>> On Apr 10, 2017, at 8:39 AM, Yakov Zhdanov  wrote:
>>> 
>>> Alex Belyak, please go ahead. Thank you for your help! There were some
>> work
>>> I did not expect to happen.
>>> 
>>> 
>>> --Yakov
>>> 
>>> 2017-04-10 18:13 GMT+03:00 Sasha Belyak :
>>> 
 Yakov, I can do replacement "heartbeat" -> "metricsUpdate". Can I get
 https://issues.apache.org/jira/browse/IGNITE-4799 ?
 
 2017-04-10 14:50 GMT+03:00 Yakov Zhdanov :
 
> Guys, I have finished with initial changes. There were a little bit
>> more
> work to do than I originally estimated.
> 
> Denis, can you please reply in the ticket? I would like you to propose
> documentation changes. Can you help?
> 
> There is also another question - we have a lot of "heartbeat" mentions
>> in
> TCP disco - missed heartbeats, client heartbeats, heartbeat message.
> Should
> we go ahead and refactor this as well e.g. to maxMissedMetricUpdates?
> 
> Also there are some changes to platforms and webconsole required. Alex
> Kuznetsov and Pavel Tupitsyn can you take a look at respective parts?
> 
> --
> Yakov
> 
 
 
>> 
>> 

Re: IgniteSemaphore and failoverSafe flag

[Dmitry Karachentsev]

Hi Vladislav,

Thanks for your contribution! But it seems doesn't fix related tickets, 
in particular [1].

Could you please take a look?

[1] https://issues.apache.org/jira/browse/IGNITE-4173

Thanks!

06.04.2017 16:27, Vladisav Jelisavcic пишет:

Hey Dmitry,

sorry for the late reply, I'll try to bake a pr later during the day.

Best regards,
Vladisav



On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev 
> wrote:


Hi Vladislav,

I see you're developing [1] for a while, did you have any chance
to fix it? If no, is there any estimate?

[1] https://issues.apache.org/jira/browse/IGNITE-1977


Thanks!

-Dmitry.



20.03.2017 10:28, Alexey Goncharuk пишет:

I think re-creation should be handled by a user who will make
sure that
nobody else is currently executing the guarded logic before the
re-creation. This is exactly the same semantics as with
BrokenBarrierException for j.u.c.CyclicBarrier.

2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic
>:

Hi everyone,

I agree with Val, he's got a point; recreating the lock
doesn't seem
possible
(at least not the with the transactional cache
lock/semaphore we have).
Is this re-create behavior really needed?

Best regards,
Vladisav



On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com
> wrote:

Guys,

How does recreation of the lock helps? My
understanding is that scenario

is

the following:

1. Client A creates and acquires a lock, and then
starts to execute

guarded

logic.
2. Client B tries to acquire the same lock and parks
to wait.
3. Before client A unlocks, all affinity nodes for the
lock fail, lock
disappears from the cache.
4. Client B fails with exception, recreates the lock,
acquires it, and
starts to execute guarded logic concurrently with
client A.

In my view this is wrong anyway, regardless of whether
this happens
silently or with an exception handled in user's code.
Because this code
doesn't have any way to know if client A still holds
the lock or not.

Am I missing something?

-Val

On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <

dsetrak...@apache.org 

wrote:

On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com
> wrote:

Which user operation would result in
exception? To my knowledge,

user

may

already be holding the lock and not
invoking any Ignite APIs, no?

Yes, this is exactly my point.

Imagine that a node already holds a lock and
another node is waiting

for

the lock. If all partition nodes leave the
grid and the lock is

re-created,

this second node will immediately acquire the
lock and we will have

two

lock owners. I think in this case this second
node (blocked on

lock())

should get an exception saying that the lock
was lost (which is, by

the

way, the current behavior), and the first node
should get an

exception

on

unlock.

Makes sense.

[GitHub] ignite pull request #1774: IGNITE-4946

[gvvinblade]

GitHub user gvvinblade opened a pull request:

https://github.com/apache/ignite/pull/1774

IGNITE-4946



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-4946

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1774.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1774


commit d23d2e0401045b19f2ba0124c92d00ff1d18dcb8
Author: Igor Seliverstov 
Date:   2017-04-11T12:57:04Z

[IGNITE-4946] GridCacheP2PUndeploySelfTest became failed




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-4946) GridCacheP2PUndeploySelfTest became failed

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-4946:


 Summary: GridCacheP2PUndeploySelfTest became failed
 Key: IGNITE-4946
 URL: https://issues.apache.org/jira/browse/IGNITE-4946
 Project: Ignite
  Issue Type: Bug
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov


There are a race between GridDhtPartitionsExchangeFuture which cleans caches 
after undeployment and GridDeploymentPerVersionStore which makes the 
undeployment.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

transaction , waiting for prepare response

[ALEKSEY KUZNETSOV]

Igniters! If we started transaction, and in phase prepare the primary node
doesnt receive GridDhtPrepareResponse then the transaction got stuck for a
long time. Why don't we have got timer that causes rollback if transaction
time on waiting has expired   ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1726: IGNITE-3583: Replaced passing by value with passi...

[isapego]

Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/1726


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1663: IGNITE-3575: CPP: Implemented remote filters for ...

[isapego]

Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/1663


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1724: IGNITE-3582 CPP: Replaced pointers with reference...

[isapego]

Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/1724


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-4945) Web console: Redesign filter controls for tables.

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-4945:
--

 Summary: Web console: Redesign filter controls for tables.
 Key: IGNITE-4945
 URL: https://issues.apache.org/jira/browse/IGNITE-4945
 Project: Ignite
  Issue Type: Sub-task
  Components: UI, wizards
Affects Versions: 1.9
Reporter: Andrey Novikov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4944) Web Console Highlight hovered line in table

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-4944:
--

 Summary: Web Console Highlight hovered line in table
 Key: IGNITE-4944
 URL: https://issues.apache.org/jira/browse/IGNITE-4944
 Project: Ignite
  Issue Type: Sub-task
  Components: UI, wizards
Reporter: Andrey Novikov


Should work for tables with grouping and pinned columns.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

CachePojoStore data loading with binary marshaller

[Dmitriy Govorukhin]

Hi all,

I found problem related to CacheJdbcPojoStore. If try to load data, with
enabled binary marshaller,
error may occur. Problem in entryMappings (this map helps resolve stored
type when data loading).
If binary marshaller disable we just  put entry with java type in this map,
if enable we put java type + binary type.

..

   checkTypeConfiguration(cacheName, valKind, valType,
type.getValueFields());

   entryMappings.put(keyTypeId, new EntryMapping(cacheName, dialect, type,
keyKind, valKind, sqlEscapeAll));

   // Add one more binding to binary typeId for POJOs,
   // because object could be passed to store in binary format.
   if (binarySupported && keyKind == TypeKind.POJO) {
   keyTypeId = typeIdForTypeName(TypeKind.BINARY, keyType);

   valKind = valKind == TypeKind.POJO ? TypeKind.BINARY : valKind;

   entryMappings.put(keyTypeId, new EntryMapping(cacheName, dialect,
type, TypeKind.BINARY, valKind, sqlEscapeAll));
}

...


I think it is wrong, because after we use this map like  iterator for load,
and final result dependent from which mapping will be first java or binary.

Collection processedKeyTypes = new HashSet<>();

for (EntryMapping em : mappings.values()) {
String keyType = em.keyType();

if (processedKeyTypes.contains(keyType))
continue;

processedKeyTypes.add(keyType);

.

I think we must add only binary mapping for user pojo if binary marshaller
enable.

Re: Move documentation from readme.io to GitHub pages

[Igor Sapego]

Pavel,

I totally agree with you, but what about documentations for different
versions? How do you suppose to solve this problem with GitHub pages?

On Tue, Apr 11, 2017 at 12:02 PM, Pavel Tupitsyn 
wrote:

> Igniters,
>
> Currently we host documentation on
> apacheignite.readme.io (and also apacheignite-net.readme.io,
> apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).
>
> readme.io has a lot of problems mostly due to lack of proper version
> control:
> * Each "version" is just a copy. When fixing something, you have to update
> all versions.
> * No good way to review changes.
> * "Propose edit" functionality is a joke. You can only accept or reject an
> edit, no way to communicate with contributor, etc
>
> GitHub Pages solves all these problems:
> https://github.com/blog/2233-publish-your-project-
> documentation-with-github-pages
>
> Basically, we'll have a separate folder in our Git repository where
> documentation is stored in markdown format.
> This way the process for updating docs is exactly the same as any other
> code change.
> Pull request with new feature can contain the docs for this feature, and so
> on.
>
> Thoughts?
>

TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

[ALEKSEY KUZNETSOV]

Hi, igniters!
While doing https://issues.apache.org/jira/browse/IGNITE-4401 ticket i came
across the fact that cache querying returns null , while cache still has
got entry.
Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1
Cache get operation : ignite().cache("eduPropCache").get(new AffinityKey("1",
"1")) non-null
I cannot even imagine what could be wrong with it.



-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1773: IGNITE-4565

[devozerov]

GitHub user devozerov opened a pull request:

https://github.com/apache/ignite/pull/1773

IGNITE-4565



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-4565

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1773.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1773


commit fcadf67cf134d603f4b8c9364ab4584cc40efed6
Author: devozerov 
Date:   2017-02-02T08:54:10Z

IGNITE-4570: DDL parsing.

commit 796c933ac70d75f4f642f5b351abc762effd
Author: devozerov 
Date:   2017-03-02T11:29:53Z

Merge branch 'ignite-2.0' into ignite-4565-ddl

commit c05be524a9b73356d26474aa9962434155d111f3
Author: Alexander Paschenko 
Date:   2017-03-03T10:55:41Z

IGNITE-4633 Introduced component type for DDL statements processor.

commit f79ead47a895eb6d205ea0f2a813efb23b67c989
Author: Alexander Paschenko 
Date:   2017-03-03T11:57:10Z

IGNITE-4635: Introduced DDL worker thread.

commit d97716ef9024aea562899d0b8b17c32c49e41f4b
Author: devozerov 
Date:   2017-03-03T12:40:00Z

Added schema version.

commit 19f0568f4653dfcace6148ded0bd357e4be65a48
Author: devozerov 
Date:   2017-03-09T08:06:38Z

Merge branch 'ignite-2.0' into ignite-4565-ddl

commit f6fa2659d88994f7942f1ac5e1fff65e697ac541
Author: devozerov 
Date:   2017-03-09T11:05:27Z

Creating correct path for index create.

commit f4a56fe67739ca6b8666cec6c0b2f7bce288d191
Author: devozerov 
Date:   2017-03-09T11:31:17Z

Moved full-text index into separate property.

commit 157db2b6bfd40a76af3ee695665fe9c6c4a4b54e
Author: devozerov 
Date:   2017-03-09T12:04:09Z

Removed unnecessary GridQueryIndexType.

commit d8d2ad8f93efedd4787ec04a9886b28266f7ac8d
Author: devozerov 
Date:   2017-03-09T12:32:28Z

WIP on general wire-up.

commit fc2cf15fd31ebfb05052bf297aeaec959d61af1e
Author: devozerov 
Date:   2017-03-09T13:07:42Z

Started working on disco messages.

commit 0721eb98f5c856afb8e4bbd3607c4d00492f8ff9
Author: devozerov 
Date:   2017-03-09T13:11:07Z

Minors.

commit 323f77545e30ebfde00b81a741546914dd18b283
Author: devozerov 
Date:   2017-03-09T13:26:29Z

Merge branch 'ignite-2.0' into ignite-4565-ddl

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/GridCacheQueryManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/IgniteH2Indexing.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/ddl/DdlTask.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridLuceneIndex.java

commit be88fa26f86e31c0ef562f9484412dde684327ef
Author: devozerov 
Date:   2017-03-09T13:49:26Z

Merge branch 'ignite-2.0' into ignite-4565-ddl

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java

commit 539f1d84063c731460bb18bf59a0602c27482d22
Author: devozerov 
Date:   2017-03-09T13:50:37Z

Minors.

commit 752e71490b79f27fb182353ae7c7babb84f0b0fd
Author: devozerov 
Date:   2017-03-09T13:53:54Z

Minors.

commit 20bd9eddaacfa05c5a4db3d951fda544d53d5410
Author: devozerov 
Date:   2017-03-09T14:00:11Z

Merge branch 'ignite-2.0' into ignite-4565-ddl

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java

commit a4d01a632506b82a1cedb9538a843229feb543be
Author: devozerov 
Date:   2017-03-09T14:03:38Z

Finished refactoring.

commit 9622039a540957ef73f558dbc99da0dbe88f38da
Author: devozerov 
Date:   2017-03-09T14:28:14Z

WIP.

commit 318ddedafc810fefdba12ac2334ac467c746dc04
Author: devozerov 
Date:   2017-03-09T14:31:53Z

WIP.

commit 9e32da96efb1cef44c81a360e35a494715b6483b
Author: devozerov 
Date:   2017-03-09T14:54:37Z

WIP.

commit cd477c039a082eb37e10848cb3aee71c01c01e20
Author: devozerov 
Date:   2017-03-09T15:05:21Z

WIP.

commit abf2f3389ee9036039be58a1e3b18c30d52a8f20
Author: devozerov 
Date:   2017-03-09T15:12:12Z

Minors.

commit 

[jira] [Created] (IGNITE-4943) Web Console: Improve design of tables with grouping on Admin Panel Screen

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-4943:
--

 Summary: Web Console: Improve design of tables with grouping on 
Admin Panel Screen
 Key: IGNITE-4943
 URL: https://issues.apache.org/jira/browse/IGNITE-4943
 Project: Ignite
  Issue Type: Sub-task
  Components: UI, wizards
Affects Versions: 1.9
Reporter: Andrey Novikov






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4942) Remove old JdbcQueryTask

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4942:
---

 Summary: Remove old JdbcQueryTask
 Key: IGNITE-4942
 URL: https://issues.apache.org/jira/browse/IGNITE-4942
 Project: Ignite
  Issue Type: Task
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
Priority: Minor
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4941) Remove GridDhtPartitionSupplyMessage

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4941:
---

 Summary: Remove GridDhtPartitionSupplyMessage
 Key: IGNITE-4941
 URL: https://issues.apache.org/jira/browse/IGNITE-4941
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Move documentation from readme.io to GitHub pages

[Pavel Tupitsyn]

Igniters,

Currently we host documentation on
apacheignite.readme.io (and also apacheignite-net.readme.io,
apacheignite-cpp.readme.io, apacheignite-mix.readme.io, etc).

readme.io has a lot of problems mostly due to lack of proper version
control:
* Each "version" is just a copy. When fixing something, you have to update
all versions.
* No good way to review changes.
* "Propose edit" functionality is a joke. You can only accept or reject an
edit, no way to communicate with contributor, etc

GitHub Pages solves all these problems:
https://github.com/blog/2233-publish-your-project-documentation-with-github-pages

Basically, we'll have a separate folder in our Git repository where
documentation is stored in markdown format.
This way the process for updating docs is exactly the same as any other
code change.
Pull request with new feature can contain the docs for this feature, and so
on.

Thoughts?

Re: Prohibit stateful affinity (FairAffinityFunction)

[Yakov Zhdanov]

Guys, after some thoughts I would say that even distribution is more
important for affinity function than traffic on rebalancing (which should
be kept to minimum also). Even distribution gives even load on stable
topology, while rebalancing is somet disaster. Apparently, grids should
spend more time in stable state than in failure recovery. And rebalancing
can be configured to cause as less impact to the system as possible.

Dmitry, M. Griggs fixed keys distribution over partitions, but not
partitions over nodes. This change is in ignite-4828, I reviewed it and
will merge it today.

Taras, your numbers are very suspicious also - do you really have 26
partitions migrated on 64 nodes topology when 1 node leaves? I will review
your changes one more time and provide comments here.

--Yakov

2017-04-10 18:12 GMT+03:00 Taras Ledkov :

> I updated the issue [1] with the table of the average count of migrated
> primary partitions when one node leaves.
>
> [1]. https://issues.apache.org/jira/browse/IGNITE-3018?focusedCom
> mentId=15963015=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15963015
>
>
>
> On 10.04.2017 18:00, Sergi Vladykin wrote:
>
>> Absolutely agree, lets get some numbers on RendezvousAffinity with both
>> variants: useBalancer enabled and disabled. Taras, can you provide them?
>>
>> Anyways at the moment we need to make a decision on what will get into
>> 2.0.
>> I'm for dropping (or hiding) all the suspicious stuff and adding it back
>> if
>> we fix it. Thus I'm going to move FairAffinity into private package now.
>>
>> Sergi
>>
>> 2017-04-10 16:55 GMT+03:00 Vladimir Ozerov :
>>
>> Sergi,
>>>
>>> AFAIK the only reason why RendezvousAffinity is used by default is that
>>> behavior on rebalance is no less important than steady state performance,
>>> especially on large deployments and cloud environments, when nodes
>>> constantly joins and leaves topology. Let's stop guessing and discuss the
>>> numbers - how many partitions reassignments happen with new
>>> RendezvousAffinity flavor? I haven't seen any results so far.
>>>
>>> On Mon, Apr 10, 2017 at 4:39 PM, Andrey Gura  wrote:
>>>
>>> Guys,

 It seems that both mentioned problem have the same root cause: each
 cache has personal affinity function instance and it leads to
 perfromance problem (we retry the same calcualtions for each cache)
 and problem related with fact that FailAffinityFunction is statefull
 (some co-located cache has different assignment if it was started on
 different topology).

 Obvious solution is the same affinity for some cache set. As result
 all caches from one set will use the same assignment that will be
 calculated exactly once and will not depend on cache start topology.






 On Mon, Apr 10, 2017 at 4:05 PM, Sergi Vladykin
  wrote:

> As for default value for useBalancer flag, I agree with Yakov, it must
>
 be
>>>
 enabled by default. Because performance in steady state is usually more
> important than performance of rebalancing. For edge cases it can be
> disabled.
>
> Sergi
>
> 2017-04-10 15:04 GMT+03:00 Sergi Vladykin :
>
> If the RendezvousAffinity with enabled useBalancer is not much worse
>>
> than

> FairAffinity, I see no reason to keep the latter.
>>
>> Sergi
>>
>> 2017-04-10 13:00 GMT+03:00 Vladimir Ozerov :
>>
>> Guys,
>>>
>>> We should not have it enabled by default because as Taras mentioned:
>>>
>> "but

> in this case there is not guarantee that a partition doesn't move
>>>
>> from
>>>
 one

> node to another when node leave topology". Let's avoid any rush here.
>>> There
>>> is nothing terribly wrong with FairAffinity. It is not enabled by
>>>
>> default

> and at the very least we can always mark it as deprecated. It is
>>>
>> better to

> test rigorously rendezvous affinity first in terms of partition
>>> distribution and partition migration and decide whether results are
>>> acceptable.
>>>
>>> On Mon, Apr 10, 2017 at 12:43 PM, Yakov Zhdanov >> wrote:
>>>
>>> We should have it enabled by default.

 --Yakov

 2017-04-10 12:42 GMT+03:00 Sergi Vladykin <

>>> sergi.vlady...@gmail.com
>>>
 :
>
>> Why wouldn't we have useBalancer always enabled?
>
> Sergi
>
> 2017-04-10 12:31 GMT+03:00 Taras Ledkov :
>
> Folks,
>>
>> I worked on issue https://issues.apache.org/
>>
> jira/browse/IGNITE-3018

> that

> is related to performance of Rendezvous AF.
>>
>> 

Re: AffinityKeyMapper: break compatibility before 2.0

[Sergi Vladykin]

+1 to Vladimir.

Sergi

2017-04-11 10:48 GMT+03:00 Vladimir Ozerov :

> Dima,
>
> The whole idea of AffinityKeyMapper appears to be wrong since we will have
> only BinaryMarshaller. We do not have classes on server, how can we rely on
> interface this class extends? I think we should do the following:
> 1) Allow @AffinityKeyMapped annotation on fields only (it doesn't work on
> methods with binary anyway).
> 2) Drop AffinityKeyMapper completely.
> 3) Hopefully, at some point we will implement old Yakov's idea of
> declarative extensions to binary objects, which will handle "affintiy key",
> "equals/hashCode" and "compareTo" cases without necessity to have any
> interface implementation classes on the server.
>
> Thoughts?
>
> On Tue, Apr 11, 2017 at 10:41 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I agree that this interface is problematic. However, I don't think that
> > dropping it right away would be fair to our users. Can we deprecate it
> and
> > print out a warning that AffinityKeyMapper cannot be used with DDL
> > statements?
> >
> > D.
> >
> > On Tue, Apr 11, 2017 at 12:32 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > wrote:
> >
> > > Guys,
> > >
> > > We are moving in direction of better distributed SQL support, it means
> > that
> > > we always will need to know an affinity field name for key type.
> > >
> > > Now we have AffinityKeyMapper which hides it from us.
> > >
> > > Since we have other means of configuring the affinity key, e.g
> > > CacheKeyConfiguration and @AffinityKeyMapped, I suggest to either drop
> > this
> > > interface or change it so that it just return affinity key field name
> > > instead of the affinity key field value. I prefer dropping it.
> > >
> > > What do you think?
> > >
> > > Sergi
> > >
> >
>

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Yakov Zhdanov]

Messages renaming is never compatible =)

Denis, did you try to update javadocs?

--Yakov

2017-04-10 21:41 GMT+03:00 Denis Magda :

> Yasha,
>
> Thanks, I’ve replied you in the ticket.
>
> In a nutshel, let’s try to merge current breaking changes to 2.0 and do
> the rest of compatible refactoring in further releases. Are you agree with
> this?
>
> —
> Denis
>
> > On Apr 10, 2017, at 8:39 AM, Yakov Zhdanov  wrote:
> >
> > Alex Belyak, please go ahead. Thank you for your help! There were some
> work
> > I did not expect to happen.
> >
> >
> > --Yakov
> >
> > 2017-04-10 18:13 GMT+03:00 Sasha Belyak :
> >
> >> Yakov, I can do replacement "heartbeat" -> "metricsUpdate". Can I get
> >> https://issues.apache.org/jira/browse/IGNITE-4799 ?
> >>
> >> 2017-04-10 14:50 GMT+03:00 Yakov Zhdanov :
> >>
> >>> Guys, I have finished with initial changes. There were a little bit
> more
> >>> work to do than I originally estimated.
> >>>
> >>> Denis, can you please reply in the ticket? I would like you to propose
> >>> documentation changes. Can you help?
> >>>
> >>> There is also another question - we have a lot of "heartbeat" mentions
> in
> >>> TCP disco - missed heartbeats, client heartbeats, heartbeat message.
> >>> Should
> >>> we go ahead and refactor this as well e.g. to maxMissedMetricUpdates?
> >>>
> >>> Also there are some changes to platforms and webconsole required. Alex
> >>> Kuznetsov and Pavel Tupitsyn can you take a look at respective parts?
> >>>
> >>> --
> >>> Yakov
> >>>
> >>
> >>
>
>

Re: one point optimisation

[ALEKSEY KUZNETSOV]

Hi! Your talking about node ordering?
What is the point of the ordering?
How is it implemented?
Thanks for the answering in advance!

ср, 5 апр. 2017 г. в 15:14, Alexey Goncharuk :

> This optimization does not work when near cache is enabled because we need
> the same ordering on near nodes. You should see the expected number of
> messages with near cache disabled.
>
> 2017-04-05 15:09 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > yes
> >
> > ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk  >:
> >
> > > Do you have a near cache enabled?
> > >
> > > 2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > The test shows as follows:
> > > > assertMessageCount(GridNearTxPrepareRequest.class, 1);
> > > > assertMessageCount(GridDhtTxPrepareRequest.class, 1);
> > > > assertMessageCount(GridDhtTxPrepareResponse.class, 1);
> > > > assertMessageCount(GridNearTxPrepareResponse.class, 1);
> > > > assertMessageCount(GridNearTxFinishRequest.class, 1);
> > > > assertMessageCount(GridDhtTxFinishRequest.class, 0);
> > > > assertMessageCount(GridNearTxFinishResponse.class, 1);
> > > >
> > > > ср, 5 апр. 2017 г. в 14:53, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > > >
> > > > > Aleksey,
> > > > >
> > > > > Can you elaborate on which of the extra messages you observe?
> > > > >
> > > > > --AG
> > > > >
> > > > > 2017-04-04 14:17 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > any thoughts on one phase commit realization ?
> > > > > >
> > > > > > пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > I've attached test that prints messages exchange . Which shows
> us
> > > > that
> > > > > > > there are more messages then you declared in article. Perhaps,
> > > > > > > implementation has changed.
> > > > > > > I created it on base of IgniteOnePhaseCommitNearSelfTest
> > > > > > >
> > > > > > > пн, 3 апр. 2017 г. в 19:03, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >:
> > > > > > >
> > > > > > > Aleksey,
> > > > > > >
> > > > > > > The blog describes the 1-phase commit at a high level, but I am
> > > still
> > > > > > > curious about the differences you found. Can you share them
> here?
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Mon, Apr 3, 2017 at 2:11 AM, ALEKSEY KUZNETSOV <
> > > > > > > alkuznetsov...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Regarding IgniteOnePhaseCommitNearSelfTest test , ignite's
> one
> > > > phase
> > > > > > > > optimisation works not as you said.
> > > > > > > > I attached picture of message exchange. There are partial
> > prepare
> > > > > phase
> > > > > > > > exists, along with finish phase.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > пн, 3 апр. 2017 г. в 10:55, Christos Erotocritou <
> > > > > > chris...@gridgain.com
> > > > > > > >:
> > > > > > > >
> > > > > > > >> As far as I know a partition is always allocated to a
> specific
> > > > node
> > > > > > and
> > > > > > > >> does not span nodes. Ignite has default 1024 partitions on
> > start
> > > > > that
> > > > > > > are
> > > > > > > >> split equally across nodes.
> > > > > > > >>
> > > > > > > >> > On 3 Apr 2017, at 08:10, ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >> >
> > > > > > > >> > in ur blog u texted belonging to the same partition is
> > > nessesary
> > > > > > for 1
> > > > > > > >> > phase commit. But its not guarantee belonging to the same
> > > node.
> > > > > > > >> Partition
> > > > > > > >> > may span many nodes
> > > > > > > >> >
> > > > > > > >> > вс, 2 Апр 2017 г., 13:46 ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com
> > > > > > > >:
> > > > > > > >> >
> > > > > > > >> >> thank u !
> > > > > > > >> >>
> > > > > > > >> >> пт, 31 Мар 2017 г., 21:06 Denis Magda  >:
> > > > > > > >> >>
> > > > > > > >> >> Here is a good blog post about 1phase commit impl in
> Ignite
> > > and
> > > > > its
> > > > > > > >> >> advantages:
> > > > > > > >> >>
> > > > > > > >> >> http://gridgain.blogspot.com/
> > 2014/09/one-phase-commit-fast-
> > > > > > > >> transactions-for.html
> > > > > > > >> >> <
> > > > > > > >> >> http://gridgain.blogspot.com/
> > 2014/09/one-phase-commit-fast-
> > > > > > > >> transactions-for.html
> > > > > > > >> >>>
> > > > > > > >> >>
> > > > > > > >> >> Took a reference to it from there:
> > > > > > > >> >>
> > > > > > > >> >>
> https://apacheignite.readme.io/docs/transactions#section-
> > > > > > > >> two-phase-commit-2pc
> > > > > > > >> >> <
> > > > > > > >> >>
> https://apacheignite.readme.io/docs/transactions#section-
> > > > > > > >> two-phase-commit-2pc
> > > > > > > >> >>>
> > > > > > > >> >>
> > > > > > > >> >> —
> > > > > > > >> >> Denis
> > 

Re: AffinityKeyMapper: break compatibility before 2.0

[Vladimir Ozerov]

Dima,

The whole idea of AffinityKeyMapper appears to be wrong since we will have
only BinaryMarshaller. We do not have classes on server, how can we rely on
interface this class extends? I think we should do the following:
1) Allow @AffinityKeyMapped annotation on fields only (it doesn't work on
methods with binary anyway).
2) Drop AffinityKeyMapper completely.
3) Hopefully, at some point we will implement old Yakov's idea of
declarative extensions to binary objects, which will handle "affintiy key",
"equals/hashCode" and "compareTo" cases without necessity to have any
interface implementation classes on the server.

Thoughts?

On Tue, Apr 11, 2017 at 10:41 AM, Dmitriy Setrakyan 
wrote:

> I agree that this interface is problematic. However, I don't think that
> dropping it right away would be fair to our users. Can we deprecate it and
> print out a warning that AffinityKeyMapper cannot be used with DDL
> statements?
>
> D.
>
> On Tue, Apr 11, 2017 at 12:32 AM, Sergi Vladykin  >
> wrote:
>
> > Guys,
> >
> > We are moving in direction of better distributed SQL support, it means
> that
> > we always will need to know an affinity field name for key type.
> >
> > Now we have AffinityKeyMapper which hides it from us.
> >
> > Since we have other means of configuring the affinity key, e.g
> > CacheKeyConfiguration and @AffinityKeyMapped, I suggest to either drop
> this
> > interface or change it so that it just return affinity key field name
> > instead of the affinity key field value. I prefer dropping it.
> >
> > What do you think?
> >
> > Sergi
> >
>

Re: AffinityKeyMapper: break compatibility before 2.0

[Dmitriy Setrakyan]

I agree that this interface is problematic. However, I don't think that
dropping it right away would be fair to our users. Can we deprecate it and
print out a warning that AffinityKeyMapper cannot be used with DDL
statements?

D.

On Tue, Apr 11, 2017 at 12:32 AM, Sergi Vladykin 
wrote:

> Guys,
>
> We are moving in direction of better distributed SQL support, it means that
> we always will need to know an affinity field name for key type.
>
> Now we have AffinityKeyMapper which hides it from us.
>
> Since we have other means of configuring the affinity key, e.g
> CacheKeyConfiguration and @AffinityKeyMapped, I suggest to either drop this
> interface or change it so that it just return affinity key field name
> instead of the affinity key field value. I prefer dropping it.
>
> What do you think?
>
> Sergi
>

AffinityKeyMapper: break compatibility before 2.0

[Sergi Vladykin]

Guys,

We are moving in direction of better distributed SQL support, it means that
we always will need to know an affinity field name for key type.

Now we have AffinityKeyMapper which hides it from us.

Since we have other means of configuring the affinity key, e.g
CacheKeyConfiguration and @AffinityKeyMapped, I suggest to either drop this
interface or change it so that it just return affinity key field name
instead of the affinity key field value. I prefer dropping it.

What do you think?

Sergi

[jira] [Created] (IGNITE-4940) GridCacheWriteBehindStore lose more data then necessary

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-4940:


 Summary: GridCacheWriteBehindStore lose more data then necessary
 Key: IGNITE-4940
 URL: https://issues.apache.org/jira/browse/IGNITE-4940
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Alexander Belyak
Priority: Minor


Unnecessary data loss happen in case of slowdown or errors in underlying store 
& populate new data in cache:
1) Writer add new cache entry and check cache size
2) If cache size > criticalSize (by default criticalSize = 1.5 * cacheSize) - 
writer will try to flush single value synchronously
At this point we have:
N flusher threads wich trying to flush data in batch mode
1+ writer threads wich trying to flush single value
Both writer and flusher use updateStore procedure, but if updateStore get 
Exception from underlying store it will check cacheSize and if it will be 
greater chen criticalCacheSize - it log cache overflow event and return true 
(as if data was sucessfully stored). Then data will be removed from writeBehind 
cache.
Moreower, we can loss not only single value, but 1+ batch if flusher's threads 
will get store exception on overflowed cache.
Reproduce:
{panel}
/**
 * Tests that cache would keep values if underlying store fails.
 *
 * @throws Exception If failed.
 */
private void testStoreFailure(boolean writeCoalescing) throws Exception {
delegate.setShouldFail(true);

initStore(2, writeCoalescing);

Set exp;

try {
Thread timer = new Thread(new Runnable() {
@Override
public void run() {
try {
U.sleep(FLUSH_FREQUENCY*2);
} catch (IgniteInterruptedCheckedException e) {
assertTrue("Timer was interrupted", false);
}
delegate.setShouldFail(false);
}
});
timer.start();
exp = runPutGetRemoveMultithreaded(10, 10);

timer.join();

info(">>> There are " + store.getWriteBehindErrorRetryCount() + " 
entries in RETRY state");

// Despite that we set shouldFail flag to false, flush thread may 
just have caught an exception.
// If we move store to the stopping state right away, this value 
will be lost. That's why this sleep
// is inserted here to let all exception handlers in write-behind 
store exit.
U.sleep(1000);
}
finally {
shutdownStore();
}

Map map = delegate.getMap();

Collection extra = new HashSet<>(map.keySet());

extra.removeAll(exp);

assertTrue("The underlying store contains extra keys: " + extra, 
extra.isEmpty());

Collection missing = new HashSet<>(exp);

missing.removeAll(map.keySet());

assertTrue("Missing keys in the underlying store: " + missing, 
missing.isEmpty());

for (Integer key : exp)
assertEquals("Invalid value for key " + key, "val" + key, 
map.get(key));
}
{panel}
Solution: test cache size before inserting new value +
a) with some kind of synchronization to prevent cacheSize growing more then 
criticalCacheSize (strong restriction)
b) remove cache size test from updateStore - cache can grow more then 
cacheCriticalSize in single point - if we get race on updateCache...
I preferr b becouse of less synchronization pressure (cache can store 1 or 2 
extra elements)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)