Re: Great blog about Ignite!

[李玉珏]

I wrote some, but it was not deep enough, and the authority was not enough.

在 16/3/4 09:39, Dmitriy Setrakyan 写道:

Couldn’t agree more. It will be great if more community members would
volunteer to write blogs or articles.

[GitHub] ignite pull request: Ignite 2753

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

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

Ignite 2753



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

$ git pull https://github.com/dkarachentsev/ignite ignite-2753

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

https://github.com/apache/ignite/pull/537.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 #537


commit 946dccb9e98419bf9921b12607667d74ef87ecda
Author: dkarachentsev 
Date:   2016-02-10T08:33:04Z

IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration.

commit 3d5999821d0efd6c026adbb3256c86bc798dc1c7
Author: dkarachentsev 
Date:   2016-02-10T08:50:09Z

Merge remote-tracking branch 'upstream/master'

commit 375eb11ba8c9076906971785fdb7bead294d8022
Author: dkarachentsev 
Date:   2016-02-11T09:47:18Z

Merge remote-tracking branch 'upstream/master'

commit 88a11b4554884acd2dbd956fcbd37a8932fbde8e
Author: dkarachentsev 
Date:   2016-02-12T08:39:32Z

Merge remote-tracking branch 'upstream/master'

commit d5f0cc8034fbbe6c34e1061fb7171e9574307413
Author: dkarachentsev 
Date:   2016-02-15T08:24:15Z

IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration. 
Delete method

commit 38a8d6c1d060f5fc120579fe4b348741a30b4a05
Author: dkarachentsev 
Date:   2016-02-15T08:26:58Z

IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration. 
Delete method

commit 7363051446ef571c1c814719b92ee7ce0b4706c4
Author: dkarachentsev 
Date:   2016-02-16T10:02:03Z

Merge remote-tracking branch 'upstream/master'

commit 3523de2a3bdfbb8fcf7a70e3a7be262577d32fce
Author: dkarachentsev 
Date:   2016-02-17T07:35:12Z

Merge remote-tracking branch 'upstream/master'

commit 92d856183d8e72df87d628a88baeeb7c3d56624e
Author: dkarachentsev 
Date:   2016-02-19T12:40:06Z

Merge remote-tracking branch 'upstream/master'

commit b4b251135a4cacf2b1e1f4c00bc2766a2dced681
Author: dkarachentsev 
Date:   2016-02-20T07:26:18Z

Merge remote-tracking branch 'upstream/master'

commit 301ab3e49ea4b20692d54ff3de2476ad6bf2b10e
Author: dkarachentsev 
Date:   2016-02-25T07:15:09Z

Merge remote-tracking branch 'upstream/master'

commit fed76e91927a867571054230d99182867a6b1206
Author: dkarachentsev 
Date:   2016-02-26T10:05:25Z

Merge remote-tracking branch 'upstream/master'

commit 0122e48e2d6d84cf608883a6946f8eefff516d3b
Author: dkarachentsev 
Date:   2016-03-01T12:19:37Z

Merge remote-tracking branch 'upstream/master'

commit 02c7ef877ec1bc620f716df57a72ba9bd8c6b369
Author: dkarachentsev 
Date:   2016-03-03T08:13:34Z

Merge remote-tracking branch 'upstream/master'

commit 87c38c16fea1fcc73e39b3e9dbdd519aadd8254e
Author: dkarachentsev 
Date:   2016-03-04T07:31:26Z

IGNITE-2753 - Binary object might be deserialized unexpectedly when cache 
store is enabled.




---
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: Switching back to review-then-commit process

[Roman Shtykh]

+1 on Raul’s proposal.
-Roman
 

On Friday, March 4, 2016 2:47 AM, Raul Kripalani  wrote:
 

 I would +1 RTC for a finite set of modules – core, complex or strategic
modules – in agreement with the community, e.g. ignite-core, ignite-spark,
ignite-hadoop, ignite-indexing, etc.

But it seems counterproductive to impose strict RTC for modules like
ignite-kafka, ignite-flume, ignite-twitter, ignite-camel, etc. If someone
changes a log in ignite-camel, I beg them not to wait for me (as the
expert) to review it. If the change is larger, I expect them to ping me for
a review *motu proprio*. Equally, it makes little sense for me to submit
for review a change I am personally making to ignite-camel: no one is going
to be interested in taking up this review and it'll probably end up in the
tail of their workqueue – likely just delaying the commit.

To sum up, my proposal:

* RTC for core, complex and strategic modules (community defines a finite
list).
* RTC or CTR, at committer's discretion, for other modules – with a
criteria of personal accountability and rationality.
* CTR for contributors for all modules, for obvious reasons (no commit
access ;-)).

Cheers,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk 

On Thu, Mar 3, 2016 at 5:09 PM, Dmitriy Setrakyan 
wrote:

> I hate to be religious about anything, but do think that for most of the
> functionality, RTC makes sense.
>
> On Thu, Mar 3, 2016 at 7:20 AM, Raul Kripalani  wrote:
>
> > I thought we were already on RTC process.
> >
> > What do you mean with contributors following this process?
> >
> > Raúl.
> > On 3 Mar 2016 11:54, "Denis Magda"  wrote:
> >
> > > Igniters,
> > >
> > > I would propose to switch back to review-then-commit process. This
> > process
> > > has to be followed by both contributors and committers.
> > >
> > > There is a reason for this I have in mind. Ignite is a complex platform
> > > with several big modules. Some of the people may be experts in module A
> > > while others in module B etc.
> > > If a committer, who is good in module A, makes changes in module B
> > merging
> > > the changes without a review this can break module's B internal
> > > functionality that the committer didn't take into account.
> > >
> > > My proposal is to introduce a list of maintainers for every Ignite
> module
> > > like it's done in Spark [1] and a rule that will require a committer to
> > get
> > > an approval from a module maintainer before merging changes.
> > >
> > > Thoughts?
> > >
> > > --
> > > Denis
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
> > >
> > >
> > >
> >
>

  

Re: distributed data types for ML applications

[Dmitriy Setrakyan]

Vladislav,

This would be a great contribution. For a feature like this, I would pick 1
ML library and propose the design first. Once the community agrees on the
design, you can proceed with the implementation.

Does this sound good?

D.

On Thu, Mar 3, 2016 at 11:22 AM, Vladisav Jelisavcic 
wrote:

> Igniters,
>
> is IGNITE-1251 still a thing?
> If so, I would really like to start working on this one.
>
> Best regards,
> Vladisav
>

Re: Great blog about Ignite!

[Dmitriy Setrakyan]

On Thu, Mar 3, 2016 at 3:51 PM, 李玉珏@163 <18624049...@163.com> wrote:

> Hi：
>
> Very good, I hope this article can more!
>
> Srini Penchikala wrote a series of articles on the InfoQ are as follows:
> Http://www.infoq.com/articles/apache-spark-introduction
> Http://www.infoq.com/articles/apache-spark-sql
> Http://www.infoq.com/articles/apache-spark-streaming
>
> If the Ignite community core members, can also write this article, and
> then published in the influential technology website, will be a very good
> thing.
>

Couldn’t agree more. It will be great if more community members would
volunteer to write blogs or articles.


>
> 在 16/3/4 05:35, Dmitriy Setrakyan 写道:
>
>
>> https://dzone.com/articles/linking-apache-ignite-and-apache-kafka-for-highly
>>
>> Roman, thanks for putting it together!
>>
>> D.
>>
>>
>
>

Re: Beta-releases for particular features.

[Dmitriy Setrakyan]

On Thu, Mar 3, 2016 at 4:34 PM, Alexey Kuznetsov 
wrote:

> How about odd/even releases?
> Odd releases will contain new/experimental features.
> Even releases - stable/bug fix releases.
>

I think it will get confusing. Do you know other projects that have the
same practice?


>
> On Fri, Mar 4, 2016 at 1:46 AM, Dmitriy Setrakyan 
> wrote:
>
> > On Thu, Mar 3, 2016 at 1:17 AM, Yakov Zhdanov 
> wrote:
> >
> > > Roman, this is not about early and frequent releases, but about special
> > > beta releases.
> > >
> > > I agree with Dmitry and Pavel that we do not need such releases, but
> need
> > > to mark somehow that feature is experimental:
> > > - add notice to javadocs and readmeio docs (as Dmitry suggested)
> > > - add warning output to logs on the first use of API
> > >
> >
> > I like the warnings in the log a lot. To Roman’s point, I also think that
> > we should consider more frequent releases, especially   when there is a
> > feature that we want to make available to the community, experimental or
> > not.
> >
> >
> > > --Yakov
> > >
> > > 2016-03-03 11:50 GMT+03:00 Roman Shtykh :
> > >
> > > > I like Vladimir's idea.It is particularly useful when we implement
> > > > integrations with other systems. Releasing them early and, if needed,
> > > > oftenly, may attract more users of those systems and give advantages
> > over
> > > > competitors.
> > > > -Roman
> > > >
> > > >
> > > > On Wednesday, March 2, 2016 2:01 AM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org> wrote:
> > > >
> > > >
> > > >  In my opinion, if a certain feature is experimental, we should
> simply
> > > > mention it in the release notes and/or documentation. I would not
> > create
> > > a
> > > > separate beta release just for a certain feature.
> > > >
> > > > D.
> > > >
> > > > On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn <
> ptupit...@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I don't think that features like LINQ and ODBC need the same
> approach
> > > > > as IDEA EAP. IntelliJ has EAP because new features may have bugs
> > > > > or usability issues. With LINQ and ODBC our main concern are not
> > bugs,
> > > > > but unsupported use cases that we did not think of. Known use cases
> > > > > are covered with tests.
> > > > >
> > > > > Beta releases may not get enough attention to gather feedback.
> > > > > I think we should release these features right away and gradually
> add
> > > > > support
> > > > > for missing use cases, if any emerge. We are not going to change
> API
> > or
> > > > > break compatibility while adding these things in future.
> > > > >
> > > > > Furthermore, LINQ is only a usability feature. Users can always
> > switch
> > > to
> > > > > raw SQL
> > > > > if something can't be expressed in LINQ.
> > > > >
> > > > > On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I want to circulate again an idea of "betas" for particular
> product
> > > > > > features.
> > > > > >
> > > > > > For now we have several pretty cool features which are to be
> > released
> > > > > soon:
> > > > > > ODBC driver and LINQ in .NET. Features like this include
> > potentially
> > > > > > infinite amount of use cases and of course we cannot test all of
> > > them.
> > > > I
> > > > > > believe things like this should go through extended release cycle
> > so
> > > > that
> > > > > > we have time to get user's feedback before officially announcing
> > > them.
> > > > It
> > > > > > could be betas, early previews, whatever.
> > > > > >
> > > > > > The main idea is that we have a time window to obtain a feedback
> > and
> > > > > > stabilize the feature.
> > > > > >
> > > > > > This is a common practice for more or less big products. E.g. see
> > > > > Hazelcast
> > > > > > python client [1] and Intellij IDEA EAP 16 [2].
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > > > > > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Beta-releases for particular features.

[Alexey Kuznetsov]

How about odd/even releases?
Odd releases will contain new/experimental features.
Even releases - stable/bug fix releases.

On Fri, Mar 4, 2016 at 1:46 AM, Dmitriy Setrakyan 
wrote:

> On Thu, Mar 3, 2016 at 1:17 AM, Yakov Zhdanov  wrote:
>
> > Roman, this is not about early and frequent releases, but about special
> > beta releases.
> >
> > I agree with Dmitry and Pavel that we do not need such releases, but need
> > to mark somehow that feature is experimental:
> > - add notice to javadocs and readmeio docs (as Dmitry suggested)
> > - add warning output to logs on the first use of API
> >
>
> I like the warnings in the log a lot. To Roman’s point, I also think that
> we should consider more frequent releases, especially   when there is a
> feature that we want to make available to the community, experimental or
> not.
>
>
> > --Yakov
> >
> > 2016-03-03 11:50 GMT+03:00 Roman Shtykh :
> >
> > > I like Vladimir's idea.It is particularly useful when we implement
> > > integrations with other systems. Releasing them early and, if needed,
> > > oftenly, may attract more users of those systems and give advantages
> over
> > > competitors.
> > > -Roman
> > >
> > >
> > > On Wednesday, March 2, 2016 2:01 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org> wrote:
> > >
> > >
> > >  In my opinion, if a certain feature is experimental, we should simply
> > > mention it in the release notes and/or documentation. I would not
> create
> > a
> > > separate beta release just for a certain feature.
> > >
> > > D.
> > >
> > > On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn  >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I don't think that features like LINQ and ODBC need the same approach
> > > > as IDEA EAP. IntelliJ has EAP because new features may have bugs
> > > > or usability issues. With LINQ and ODBC our main concern are not
> bugs,
> > > > but unsupported use cases that we did not think of. Known use cases
> > > > are covered with tests.
> > > >
> > > > Beta releases may not get enough attention to gather feedback.
> > > > I think we should release these features right away and gradually add
> > > > support
> > > > for missing use cases, if any emerge. We are not going to change API
> or
> > > > break compatibility while adding these things in future.
> > > >
> > > > Furthermore, LINQ is only a usability feature. Users can always
> switch
> > to
> > > > raw SQL
> > > > if something can't be expressed in LINQ.
> > > >
> > > > On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I want to circulate again an idea of "betas" for particular product
> > > > > features.
> > > > >
> > > > > For now we have several pretty cool features which are to be
> released
> > > > soon:
> > > > > ODBC driver and LINQ in .NET. Features like this include
> potentially
> > > > > infinite amount of use cases and of course we cannot test all of
> > them.
> > > I
> > > > > believe things like this should go through extended release cycle
> so
> > > that
> > > > > we have time to get user's feedback before officially announcing
> > them.
> > > It
> > > > > could be betas, early previews, whatever.
> > > > >
> > > > > The main idea is that we have a time window to obtain a feedback
> and
> > > > > stabilize the feature.
> > > > >
> > > > > This is a common practice for more or less big products. E.g. see
> > > > Hazelcast
> > > > > python client [1] and Intellij IDEA EAP 16 [2].
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > > > > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> > > > >
> > > > > Vladimir.
> > > > >
> > > >
> > >
> > >
> > >
> > >
> >
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Great blog about Ignite!

[李玉珏]

Hi：

Very good, I hope this article can more!

Srini Penchikala wrote a series of articles on the InfoQ are as follows:
Http://www.infoq.com/articles/apache-spark-introduction
Http://www.infoq.com/articles/apache-spark-sql
Http://www.infoq.com/articles/apache-spark-streaming

If the Ignite community core members, can also write this article, and 
then published in the influential technology website, will be a very 
good thing.


在 16/3/4 05:35, Dmitriy Setrakyan 写道:

https://dzone.com/articles/linking-apache-ignite-and-apache-kafka-for-highly

Roman, thanks for putting it together!

D.

[jira] [Created] (IGNITE-2758) IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any classes

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2758:
---

 Summary: IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar 
doesn't contain any classes
 Key: IGNITE-2758
 URL: https://issues.apache.org/jira/browse/IGNITE-2758
 Project: Ignite
  Issue Type: Bug
  Components: build
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Priority: Blocker
 Fix For: 1.6


To observe the issue do this:
* Build the fabric ZIP file.
* Go to {{ignite-aws}} module folder.
* Unzip {{aws-java-sdk-1.10.29.jar}}.
* JAR file contains only pom.xml, no classes.

We need to make sure that all required AWS SDK components are included. At 
least we need these ones:
* aws-java-sdk-core
* aws-java-sdk-s3
* joda-time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Great blog about Ignite!

[Dmitriy Setrakyan]

https://dzone.com/articles/linking-apache-ignite-and-apache-kafka-for-highly

Roman, thanks for putting it together!

D.

distributed data types for ML applications

[Vladisav Jelisavcic]

Igniters,

is IGNITE-1251 still a thing?
If so, I would really like to start working on this one.

Best regards,
Vladisav

Re: Beta-releases for particular features.

[Dmitriy Setrakyan]

On Thu, Mar 3, 2016 at 1:17 AM, Yakov Zhdanov  wrote:

> Roman, this is not about early and frequent releases, but about special
> beta releases.
>
> I agree with Dmitry and Pavel that we do not need such releases, but need
> to mark somehow that feature is experimental:
> - add notice to javadocs and readmeio docs (as Dmitry suggested)
> - add warning output to logs on the first use of API
>

I like the warnings in the log a lot. To Roman’s point, I also think that
we should consider more frequent releases, especially   when there is a
feature that we want to make available to the community, experimental or
not.


> --Yakov
>
> 2016-03-03 11:50 GMT+03:00 Roman Shtykh :
>
> > I like Vladimir's idea.It is particularly useful when we implement
> > integrations with other systems. Releasing them early and, if needed,
> > oftenly, may attract more users of those systems and give advantages over
> > competitors.
> > -Roman
> >
> >
> > On Wednesday, March 2, 2016 2:01 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org> wrote:
> >
> >
> >  In my opinion, if a certain feature is experimental, we should simply
> > mention it in the release notes and/or documentation. I would not create
> a
> > separate beta release just for a certain feature.
> >
> > D.
> >
> > On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn 
> > wrote:
> >
> > > Hi,
> > >
> > > I don't think that features like LINQ and ODBC need the same approach
> > > as IDEA EAP. IntelliJ has EAP because new features may have bugs
> > > or usability issues. With LINQ and ODBC our main concern are not bugs,
> > > but unsupported use cases that we did not think of. Known use cases
> > > are covered with tests.
> > >
> > > Beta releases may not get enough attention to gather feedback.
> > > I think we should release these features right away and gradually add
> > > support
> > > for missing use cases, if any emerge. We are not going to change API or
> > > break compatibility while adding these things in future.
> > >
> > > Furthermore, LINQ is only a usability feature. Users can always switch
> to
> > > raw SQL
> > > if something can't be expressed in LINQ.
> > >
> > > On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > I want to circulate again an idea of "betas" for particular product
> > > > features.
> > > >
> > > > For now we have several pretty cool features which are to be released
> > > soon:
> > > > ODBC driver and LINQ in .NET. Features like this include potentially
> > > > infinite amount of use cases and of course we cannot test all of
> them.
> > I
> > > > believe things like this should go through extended release cycle so
> > that
> > > > we have time to get user's feedback before officially announcing
> them.
> > It
> > > > could be betas, early previews, whatever.
> > > >
> > > > The main idea is that we have a time window to obtain a feedback and
> > > > stabilize the feature.
> > > >
> > > > This is a common practice for more or less big products. E.g. see
> > > Hazelcast
> > > > python client [1] and Intellij IDEA EAP 16 [2].
> > > >
> > > > Thoughts?
> > > >
> > > > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > > > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> > > >
> > > > Vladimir.
> > > >
> > >
> >
> >
> >
> >
>

[GitHub] ignite pull request: IGNITE-2747: Replaced mktime and gmtime with ...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-2747: Replaced mktime and gmtime with safe analogues.

Merged with ignite-2557.

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

$ git pull https://github.com/isapego/ignite ignite-2747

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

https://github.com/apache/ignite/pull/536.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 #536


commit 3fb85ad44106bace16c71b6f06c235c0e76b4f97
Author: isapego 
Date:   2016-02-05T13:14:27Z

IGNITE-2557: queries test stub added.

commit a55f1b5c737e4380ee9e50c0f2bd473904ec08f8
Author: isapego 
Date:   2016-02-08T15:56:47Z

IGNITE-: Test for the Date type added.

commit 39186f4042b7453026bc7eaf088ed5c7b3462f70
Author: isapego 
Date:   2016-02-08T16:39:59Z

IGNITE-: Added ignite::Date class.

commit d7bf440fa0eff01babaf0979a4ea0827561f7500
Author: isapego 
Date:   2016-02-08T16:51:46Z

IGNITE-: Added Date reading and writing to binary utils.

commit 35a6e1edd7c9a1207b035935f86671c787618b45
Author: isapego 
Date:   2016-02-08T17:03:12Z

IGNITE-: Added Date to BinaryWriterImpl.

commit af8b0db6247352ae16c93c65a898255774773173
Author: isapego 
Date:   2016-02-08T17:19:36Z

IGNITE-: Added specialisation WriteTopObject.

commit 6f86354fd4ad3f2c0ac62ba3e5333551c6233805
Author: isapego 
Date:   2016-02-08T17:24:20Z

IGNITE-: BinaryRawWriter::WriteDate[Array] implemented.

commit 34bb1d68e096e083a85868dcf473f920e54c0af2
Author: isapego 
Date:   2016-02-08T18:05:37Z

IGNITE-: Implemented BinaryReaderImpl::ReadDate[Array].

commit b03b9bfc969d76f76e4a6e5fa401061b919cad47
Author: isapego 
Date:   2016-02-08T18:08:32Z

IGNITE-: Implemented BinaryRaqReader::ReadDate[Array].

commit e36f03bc5b16a074ab9308791d38a35b9bab1d72
Author: isapego 
Date:   2016-02-08T18:21:15Z

IGNITE-: Fix for the test.

commit 0a4b2e326b99a38336832a1289ae1461697efb3b
Author: isapego 
Date:   2016-02-08T18:28:58Z

IGNITE-: Added test for DateArray.

commit f08029aeb96a887c679f821f488b5d22b7a612fb
Author: isapego 
Date:   2016-02-08T18:44:16Z

IGNITE-: Added BinaryWriter::WriteDate[Array].

commit e80350a4a0ae7bb5ab714f0bcb21b3b14236a8d8
Author: isapego 
Date:   2016-02-08T18:47:53Z

IGNITE-: Added BinaryReader::ReadDate[Array].

commit 7428a3b1b3937d36f048916aeb773a2f058373f3
Author: isapego 
Date:   2016-02-08T19:06:36Z

IGNITE-: Tests for Date type reworked.

commit 14d921b89c6d89e0368a044bd3eeff4e4f6a503f
Author: isapego 
Date:   2016-02-09T13:12:26Z

IGNITE-: Added timestamp class.

commit 0263b602c85f0f5f5c94fb80d4571612fb923813
Author: isapego 
Date:   2016-02-09T13:28:56Z

IGNITE-: Added binary utils for Timestamp.

commit 937248c3ace1b070c1c558c7fe17ce2864e735a4
Author: isapego 
Date:   2016-02-09T13:36:48Z

IGNITE-: Timestamp binary type added.

commit 37db4a2a748582b7a83b51fdf46f8648e1fa4f87
Author: isapego 
Date:   2016-02-09T13:41:56Z

IGNITE-: Added BinaryWriterImpl::WriteTimestamp[Array]().

commit a5583a79bbfec3157ae595b7c22cefc3be614706
Author: isapego 
Date:   2016-02-09T13:51:03Z

IGNITE-: Added BinaryReaderImpl::ReadTimestamp[Array]().

commit 8e1a023ff3fbc480a9c6f17a239f7e11ce04f63b
Author: isapego 
Date:   2016-02-09T13:57:05Z

IGNITE-: Added BinaryWriter::WriteTimestamp[Array]().

commit 8a851fd65a69231ff7477882554143a9f085bfcb
Author: isapego 
Date:   2016-02-09T13:59:17Z

IGNITE-: Added BinaryReader::ReadTimestamp[Array]().

commit e4f2cdf5e0c7cbffd287c024191caff5e5bed9e1
Author: isapego 
Date:   2016-02-09T14:01:11Z

IGNITE-: Added BinaryRawReader::ReadTimestamp[Array]().

commit 26cd9ea51d1f627be21ad2aee3632602b3cf5126
Author: isapego 
Date:   2016-02-09T14:04:06Z

GNITE-: Added BinaryRawWriter::WriteTimestamp[Array]().

commit 67cacde49c67a5c86f88c3adf8873b27e1a4
Author: isapego 
Date:   2016-02-09T14:14:40Z

IGNITE-: Added tests for Timestamp binary type.

commit 78f7acaaf7812ae9ac700b7da4051baa8bd10807
Author: isapego 
Date:   2016-02-09T14:33:49Z

IGNITE-: Fix for autotools build system.

commit 5863322968f7f8e2171972a1b0b3ad0c9b2748c7
Author: isapego 
Date:   

Re: Contributions that are waiting for review

[Dmitriy Setrakyan]

My preference would be Jenkins. Raul, do you know how to set it up?

On Thu, Mar 3, 2016 at 10:08 AM, Raul Kripalani  wrote:

> Cool! Do you think you can host it at GridGain?
>
> Else, we could run it as a Jenkins job in the ASF Jenkins.
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io | twitter: @raulvk 
>
> On Thu, Mar 3, 2016 at 3:38 PM, Pavel Tupitsyn 
> wrote:
>
> > +1 for Raul, great idea.
> > We can also include a column with "days since last update" to see how
> long
> > each issue has been waiting.
> >
> > I have some experience with JIRA REST API, so maybe I could help with
> this.
> >
> > On Thu, Mar 3, 2016 at 6:24 PM, Raul Kripalani  wrote:
> >
> > > How about a nightly job that fetches all tickets from JIRA which are
> > > unresolved and have Patch Available = true, and (1) sends them to the
> dev
> > > ML or (2) posts it in Gitter?
> > >
> > > Will it help raise awareness and put them on the radar?
> > >
> > > Raúl.
> > > On 2 Mar 2016 20:47, "Denis Magda"  wrote:
> > >
> > > >
> > > > I would better ask contributors to ping committers on the dev list
> > when a
> > > > patch is available asking for review.
> > > > It can happen that committers missed or forgot to do the review and a
> > > > contributor can remind them sending one more email to the dev list.
> > > >
> > > > I don't see anything wrong with this approach. It's an open source
> > > project
> > > > and most of the people don't keep an eye on new contributions that
> have
> > > to
> > > > be released.
> > > >
> > > > PATCH_AVAILABLE stat is a right point. But I won't execute this
> filter
> > > all
> > > > the time checking for pending reviews and some of the committers
> don't
> > > move
> > > > the ticket to the CLOSED state when everything is merged.
> > > > The latter was discussed some time ago there.
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On 3/2/2016 6:02 PM, Anton Vinogradov wrote:
> > > >
> > > >> Denis,
> > > >>
> > > >> We have a special status at Ignite JIRA - PATCH AVAILABLE which
> means
> > > that
> > > >> issue ready to be reviewed.
> > > >> Currently 59 issues has such status according to
> > > >>
> > > >>
> > >
> >
> https://issues.apache.org/jira/issues/?filter=-2=project%20%3D%20Ignite%20and%20status%20%3D%20%22Patch%20Available%22
> > > >>
> > > >> I think we have to add notes that this status can be used only
> during
> > > >> waiting of review and we will have no problems with actual "required
> > > >> review" list in future.
> > > >>
> > > >>
> > > >> On Wed, Mar 2, 2016 at 4:08 PM, Roman Shtykh
> >  > > >
> > > >> wrote:
> > > >>
> > > >> I have also asked for review of the following tickets but failed to
> > get
> > > a
> > > >>> feedback.
> > > >>> They are not complicated, but I would appreciate a quick review.
> > Thank
> > > >>> you!
> > > >>>
> > > >>> [IGNITE-2563] Queries: ArrayIndexOutOfBoundsException when using
> > > BOOL_AND
> > > >>>
> > > >>> https://issues.apache.org/jira/browse/IGNITE-2563
> > > >>>
> > > >>> IGNITE-2416 TcpDiscoverySharedFsIpFinder doesn't work with IPv6
> > > addresses
> > > >>> https://issues.apache.org/jira/browse/IGNITE-2416
> > > >>>
> > > >>> and a new one
> > > >>>
> > > >>> IGNITE-2710 Session not unbind from current request after invoking
> > > >>> request.getSession().invalidate()
> > > >>> https://issues.apache.org/jira/browse/IGNITE-2710
> > > >>>
> > > >>> -Roman
> > > >>>
> > > >>>
> > > >>> On Wednesday, March 2, 2016 6:38 PM, Denis Magda <
> > dma...@gridgain.com>
> > > >>> wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>> Ignite committers,
> > > >>>
> > > >>> There is a number of contributions that have to be reviewed.
> > > >>>
> > > >>> Please pick them up basing on your experience and provide your
> review
> > > >>> notes.
> > > >>>
> > > >>> Ignite 2718: Missing ZookeeperIpFinder dependencies
> > > >>> 
> > > >>> IGNITE-2693: withKeepBinary and non-binary marshallers
> > > >>> 
> > > >>> IGNITE-2735: Fixes distributed semaphore local node stopping issue.
> > > >>> 
> > > >>> *IGNITE-642: Implements cache distributed reentrant lock
> > > >>> 
> > > >>>
> > > >>>
> > > >>> *Regards,
> > > >>> Denis
> > > >>>
> > > >>>
> > > >
> > >
> >
>

Re: Contributions that are waiting for review

[Raul Kripalani]

Cool! Do you think you can host it at GridGain?

Else, we could run it as a Jenkins job in the ASF Jenkins.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk 

On Thu, Mar 3, 2016 at 3:38 PM, Pavel Tupitsyn 
wrote:

> +1 for Raul, great idea.
> We can also include a column with "days since last update" to see how long
> each issue has been waiting.
>
> I have some experience with JIRA REST API, so maybe I could help with this.
>
> On Thu, Mar 3, 2016 at 6:24 PM, Raul Kripalani  wrote:
>
> > How about a nightly job that fetches all tickets from JIRA which are
> > unresolved and have Patch Available = true, and (1) sends them to the dev
> > ML or (2) posts it in Gitter?
> >
> > Will it help raise awareness and put them on the radar?
> >
> > Raúl.
> > On 2 Mar 2016 20:47, "Denis Magda"  wrote:
> >
> > >
> > > I would better ask contributors to ping committers on the dev list
> when a
> > > patch is available asking for review.
> > > It can happen that committers missed or forgot to do the review and a
> > > contributor can remind them sending one more email to the dev list.
> > >
> > > I don't see anything wrong with this approach. It's an open source
> > project
> > > and most of the people don't keep an eye on new contributions that have
> > to
> > > be released.
> > >
> > > PATCH_AVAILABLE stat is a right point. But I won't execute this filter
> > all
> > > the time checking for pending reviews and some of the committers don't
> > move
> > > the ticket to the CLOSED state when everything is merged.
> > > The latter was discussed some time ago there.
> > >
> > > --
> > > Denis
> > >
> > > On 3/2/2016 6:02 PM, Anton Vinogradov wrote:
> > >
> > >> Denis,
> > >>
> > >> We have a special status at Ignite JIRA - PATCH AVAILABLE which means
> > that
> > >> issue ready to be reviewed.
> > >> Currently 59 issues has such status according to
> > >>
> > >>
> >
> https://issues.apache.org/jira/issues/?filter=-2=project%20%3D%20Ignite%20and%20status%20%3D%20%22Patch%20Available%22
> > >>
> > >> I think we have to add notes that this status can be used only during
> > >> waiting of review and we will have no problems with actual "required
> > >> review" list in future.
> > >>
> > >>
> > >> On Wed, Mar 2, 2016 at 4:08 PM, Roman Shtykh
>  > >
> > >> wrote:
> > >>
> > >> I have also asked for review of the following tickets but failed to
> get
> > a
> > >>> feedback.
> > >>> They are not complicated, but I would appreciate a quick review.
> Thank
> > >>> you!
> > >>>
> > >>> [IGNITE-2563] Queries: ArrayIndexOutOfBoundsException when using
> > BOOL_AND
> > >>>
> > >>> https://issues.apache.org/jira/browse/IGNITE-2563
> > >>>
> > >>> IGNITE-2416 TcpDiscoverySharedFsIpFinder doesn't work with IPv6
> > addresses
> > >>> https://issues.apache.org/jira/browse/IGNITE-2416
> > >>>
> > >>> and a new one
> > >>>
> > >>> IGNITE-2710 Session not unbind from current request after invoking
> > >>> request.getSession().invalidate()
> > >>> https://issues.apache.org/jira/browse/IGNITE-2710
> > >>>
> > >>> -Roman
> > >>>
> > >>>
> > >>> On Wednesday, March 2, 2016 6:38 PM, Denis Magda <
> dma...@gridgain.com>
> > >>> wrote:
> > >>>
> > >>>
> > >>>
> > >>> Ignite committers,
> > >>>
> > >>> There is a number of contributions that have to be reviewed.
> > >>>
> > >>> Please pick them up basing on your experience and provide your review
> > >>> notes.
> > >>>
> > >>> Ignite 2718: Missing ZookeeperIpFinder dependencies
> > >>> 
> > >>> IGNITE-2693: withKeepBinary and non-binary marshallers
> > >>> 
> > >>> IGNITE-2735: Fixes distributed semaphore local node stopping issue.
> > >>> 
> > >>> *IGNITE-642: Implements cache distributed reentrant lock
> > >>> 
> > >>>
> > >>>
> > >>> *Regards,
> > >>> Denis
> > >>>
> > >>>
> > >
> >
>

Re: Switching back to review-then-commit process

[Raul Kripalani]

On Thu, Mar 3, 2016 at 5:46 PM, Raul Kripalani  wrote:

> * CTR for contributors for all modules, for obvious reasons (no commit
> access ;-)).
>

Obviously, I meant RTC!

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk 

Re: Switching back to review-then-commit process

[Dmitriy Setrakyan]

+1 on Raul’s proposal, specifically ignite-core should always follow RTC
process.

On Thu, Mar 3, 2016 at 9:46 AM, Raul Kripalani  wrote:

> I would +1 RTC for a finite set of modules – core, complex or strategic
> modules – in agreement with the community, e.g. ignite-core, ignite-spark,
> ignite-hadoop, ignite-indexing, etc.
>
> But it seems counterproductive to impose strict RTC for modules like
> ignite-kafka, ignite-flume, ignite-twitter, ignite-camel, etc. If someone
> changes a log in ignite-camel, I beg them not to wait for me (as the
> expert) to review it. If the change is larger, I expect them to ping me for
> a review *motu proprio*. Equally, it makes little sense for me to submit
> for review a change I am personally making to ignite-camel: no one is going
> to be interested in taking up this review and it'll probably end up in the
> tail of their workqueue – likely just delaying the commit.
>
> To sum up, my proposal:
>
> * RTC for core, complex and strategic modules (community defines a finite
> list).
> * RTC or CTR, at committer's discretion, for other modules – with a
> criteria of personal accountability and rationality.
> * CTR for contributors for all modules, for obvious reasons (no commit
> access ;-)).
>
> Cheers,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io | twitter: @raulvk 
>
> On Thu, Mar 3, 2016 at 5:09 PM, Dmitriy Setrakyan 
> wrote:
>
> > I hate to be religious about anything, but do think that for most of the
> > functionality, RTC makes sense.
> >
> > On Thu, Mar 3, 2016 at 7:20 AM, Raul Kripalani  wrote:
> >
> > > I thought we were already on RTC process.
> > >
> > > What do you mean with contributors following this process?
> > >
> > > Raúl.
> > > On 3 Mar 2016 11:54, "Denis Magda"  wrote:
> > >
> > > > Igniters,
> > > >
> > > > I would propose to switch back to review-then-commit process. This
> > > process
> > > > has to be followed by both contributors and committers.
> > > >
> > > > There is a reason for this I have in mind. Ignite is a complex
> platform
> > > > with several big modules. Some of the people may be experts in
> module A
> > > > while others in module B etc.
> > > > If a committer, who is good in module A, makes changes in module B
> > > merging
> > > > the changes without a review this can break module's B internal
> > > > functionality that the committer didn't take into account.
> > > >
> > > > My proposal is to introduce a list of maintainers for every Ignite
> > module
> > > > like it's done in Spark [1] and a rule that will require a committer
> to
> > > get
> > > > an approval from a module maintainer before merging changes.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
> > > >
> > > >
> > > >
> > >
> >
>

Re: Switching back to review-then-commit process

[Raul Kripalani]

I would +1 RTC for a finite set of modules – core, complex or strategic
modules – in agreement with the community, e.g. ignite-core, ignite-spark,
ignite-hadoop, ignite-indexing, etc.

But it seems counterproductive to impose strict RTC for modules like
ignite-kafka, ignite-flume, ignite-twitter, ignite-camel, etc. If someone
changes a log in ignite-camel, I beg them not to wait for me (as the
expert) to review it. If the change is larger, I expect them to ping me for
a review *motu proprio*. Equally, it makes little sense for me to submit
for review a change I am personally making to ignite-camel: no one is going
to be interested in taking up this review and it'll probably end up in the
tail of their workqueue – likely just delaying the commit.

To sum up, my proposal:

* RTC for core, complex and strategic modules (community defines a finite
list).
* RTC or CTR, at committer's discretion, for other modules – with a
criteria of personal accountability and rationality.
* CTR for contributors for all modules, for obvious reasons (no commit
access ;-)).

Cheers,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk 

On Thu, Mar 3, 2016 at 5:09 PM, Dmitriy Setrakyan 
wrote:

> I hate to be religious about anything, but do think that for most of the
> functionality, RTC makes sense.
>
> On Thu, Mar 3, 2016 at 7:20 AM, Raul Kripalani  wrote:
>
> > I thought we were already on RTC process.
> >
> > What do you mean with contributors following this process?
> >
> > Raúl.
> > On 3 Mar 2016 11:54, "Denis Magda"  wrote:
> >
> > > Igniters,
> > >
> > > I would propose to switch back to review-then-commit process. This
> > process
> > > has to be followed by both contributors and committers.
> > >
> > > There is a reason for this I have in mind. Ignite is a complex platform
> > > with several big modules. Some of the people may be experts in module A
> > > while others in module B etc.
> > > If a committer, who is good in module A, makes changes in module B
> > merging
> > > the changes without a review this can break module's B internal
> > > functionality that the committer didn't take into account.
> > >
> > > My proposal is to introduce a list of maintainers for every Ignite
> module
> > > like it's done in Spark [1] and a rule that will require a committer to
> > get
> > > an approval from a module maintainer before merging changes.
> > >
> > > Thoughts?
> > >
> > > --
> > > Denis
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
> > >
> > >
> > >
> >
>

Re: Switching back to review-then-commit process

[Anton Vinogradov]

+1 (but I hope it's still up to a committer to decide whether a change
should need a review or not.)

On Thu, Mar 3, 2016 at 8:09 PM, Dmitriy Setrakyan 
wrote:

> I hate to be religious about anything, but do think that for most of the
> functionality, RTC makes sense.
>
> On Thu, Mar 3, 2016 at 7:20 AM, Raul Kripalani  wrote:
>
> > I thought we were already on RTC process.
> >
> > What do you mean with contributors following this process?
> >
> > Raúl.
> > On 3 Mar 2016 11:54, "Denis Magda"  wrote:
> >
> > > Igniters,
> > >
> > > I would propose to switch back to review-then-commit process. This
> > process
> > > has to be followed by both contributors and committers.
> > >
> > > There is a reason for this I have in mind. Ignite is a complex platform
> > > with several big modules. Some of the people may be experts in module A
> > > while others in module B etc.
> > > If a committer, who is good in module A, makes changes in module B
> > merging
> > > the changes without a review this can break module's B internal
> > > functionality that the committer didn't take into account.
> > >
> > > My proposal is to introduce a list of maintainers for every Ignite
> module
> > > like it's done in Spark [1] and a rule that will require a committer to
> > get
> > > an approval from a module maintainer before merging changes.
> > >
> > > Thoughts?
> > >
> > > --
> > > Denis
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
> > >
> > >
> > >
> >
>

[GitHub] ignite pull request: Format miliseconds as they will be 3 digits

[alpert]

GitHub user alpert opened a pull request:

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

Format miliseconds as they will be 3 digits

Fixes #517 

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

$ git pull https://github.com/alpert/ignite IGNITE-2690

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

https://github.com/apache/ignite/pull/534.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 #534


commit 119b063018a4d349f08d13b8ead39c58d07466e0
Author: alpert 
Date:   2016-03-03T17:20:44Z

Format miliseconds as they will be 3 digits




---
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: Switching back to review-then-commit process

[Dmitriy Setrakyan]

I hate to be religious about anything, but do think that for most of the
functionality, RTC makes sense.

On Thu, Mar 3, 2016 at 7:20 AM, Raul Kripalani  wrote:

> I thought we were already on RTC process.
>
> What do you mean with contributors following this process?
>
> Raúl.
> On 3 Mar 2016 11:54, "Denis Magda"  wrote:
>
> > Igniters,
> >
> > I would propose to switch back to review-then-commit process. This
> process
> > has to be followed by both contributors and committers.
> >
> > There is a reason for this I have in mind. Ignite is a complex platform
> > with several big modules. Some of the people may be experts in module A
> > while others in module B etc.
> > If a committer, who is good in module A, makes changes in module B
> merging
> > the changes without a review this can break module's B internal
> > functionality that the committer didn't take into account.
> >
> > My proposal is to introduce a list of maintainers for every Ignite module
> > like it's done in Spark [1] and a rule that will require a committer to
> get
> > an approval from a module maintainer before merging changes.
> >
> > Thoughts?
> >
> > --
> > Denis
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
> >
> >
> >
>

Re: IGNITE-2693 - could someone take a look and help me with a quick review

[Anton Vinogradov]

Hello,

commented at issue

On Thu, Mar 3, 2016 at 5:28 PM, Dood@ODDO  wrote:

> Hello,
>
> This is my second Ignite ticket and if I understand correctly, it is a
> simple fix - I submitted a patch recently, it is only a few lines. Can
> someone take a look and see if I am on the right track or did I completely
> misunderstand it... :-)
>
> Thanks!
>

[jira] [Created] (IGNITE-2757) [Failed test] Test GridTaskCancelSingleNodeSelfTest.testImmediateCancellation fails in rare cases

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-2757:
---

 Summary: [Failed test] Test 
GridTaskCancelSingleNodeSelfTest.testImmediateCancellation fails in rare cases
 Key: IGNITE-2757
 URL: https://issues.apache.org/jira/browse/IGNITE-2757
 Project: Ignite
  Issue Type: Test
Reporter: Andrey Gura
Assignee: Andrey Gura
 Fix For: 1.6


Test {{GridTaskCancelSingleNodeSelfTest.testImmediateCancellation}} fails in 
rare cases.

{noformat}
java.lang.AssertionError: Failed on iteration [i=2, finished=0, cancelled=0, 
rejected=1]
at 
org.apache.ignite.internal.GridTaskCancelSingleNodeSelfTest.checkCancellation(GridTaskCancelSingleNodeSelfTest.java:127)
at 
org.apache.ignite.internal.GridTaskCancelSingleNodeSelfTest.testImmediateCancellation(GridTaskCancelSingleNodeSelfTest.java:64)
{noformat}

And more rare failures happen with:

{noformat}
java.lang.AssertionError: Failed on iteration [i=2, finished=1, cancelled=1, 
rejected=0]
at 
org.apache.ignite.internal.GridTaskCancelSingleNodeSelfTest.checkCancellation(GridTaskCancelSingleNodeSelfTest.java:127)
at 
org.apache.ignite.internal.GridTaskCancelSingleNodeSelfTest.testImmediateCancellation(GridTaskCancelSingleNodeSelfTest.java:64)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Contributions that are waiting for review

[Pavel Tupitsyn]

+1 for Raul, great idea.
We can also include a column with "days since last update" to see how long
each issue has been waiting.

I have some experience with JIRA REST API, so maybe I could help with this.

On Thu, Mar 3, 2016 at 6:24 PM, Raul Kripalani  wrote:

> How about a nightly job that fetches all tickets from JIRA which are
> unresolved and have Patch Available = true, and (1) sends them to the dev
> ML or (2) posts it in Gitter?
>
> Will it help raise awareness and put them on the radar?
>
> Raúl.
> On 2 Mar 2016 20:47, "Denis Magda"  wrote:
>
> >
> > I would better ask contributors to ping committers on the dev list when a
> > patch is available asking for review.
> > It can happen that committers missed or forgot to do the review and a
> > contributor can remind them sending one more email to the dev list.
> >
> > I don't see anything wrong with this approach. It's an open source
> project
> > and most of the people don't keep an eye on new contributions that have
> to
> > be released.
> >
> > PATCH_AVAILABLE stat is a right point. But I won't execute this filter
> all
> > the time checking for pending reviews and some of the committers don't
> move
> > the ticket to the CLOSED state when everything is merged.
> > The latter was discussed some time ago there.
> >
> > --
> > Denis
> >
> > On 3/2/2016 6:02 PM, Anton Vinogradov wrote:
> >
> >> Denis,
> >>
> >> We have a special status at Ignite JIRA - PATCH AVAILABLE which means
> that
> >> issue ready to be reviewed.
> >> Currently 59 issues has such status according to
> >>
> >>
> https://issues.apache.org/jira/issues/?filter=-2=project%20%3D%20Ignite%20and%20status%20%3D%20%22Patch%20Available%22
> >>
> >> I think we have to add notes that this status can be used only during
> >> waiting of review and we will have no problems with actual "required
> >> review" list in future.
> >>
> >>
> >> On Wed, Mar 2, 2016 at 4:08 PM, Roman Shtykh  >
> >> wrote:
> >>
> >> I have also asked for review of the following tickets but failed to get
> a
> >>> feedback.
> >>> They are not complicated, but I would appreciate a quick review. Thank
> >>> you!
> >>>
> >>> [IGNITE-2563] Queries: ArrayIndexOutOfBoundsException when using
> BOOL_AND
> >>>
> >>> https://issues.apache.org/jira/browse/IGNITE-2563
> >>>
> >>> IGNITE-2416 TcpDiscoverySharedFsIpFinder doesn't work with IPv6
> addresses
> >>> https://issues.apache.org/jira/browse/IGNITE-2416
> >>>
> >>> and a new one
> >>>
> >>> IGNITE-2710 Session not unbind from current request after invoking
> >>> request.getSession().invalidate()
> >>> https://issues.apache.org/jira/browse/IGNITE-2710
> >>>
> >>> -Roman
> >>>
> >>>
> >>> On Wednesday, March 2, 2016 6:38 PM, Denis Magda 
> >>> wrote:
> >>>
> >>>
> >>>
> >>> Ignite committers,
> >>>
> >>> There is a number of contributions that have to be reviewed.
> >>>
> >>> Please pick them up basing on your experience and provide your review
> >>> notes.
> >>>
> >>> Ignite 2718: Missing ZookeeperIpFinder dependencies
> >>> 
> >>> IGNITE-2693: withKeepBinary and non-binary marshallers
> >>> 
> >>> IGNITE-2735: Fixes distributed semaphore local node stopping issue.
> >>> 
> >>> *IGNITE-642: Implements cache distributed reentrant lock
> >>> 
> >>>
> >>>
> >>> *Regards,
> >>> Denis
> >>>
> >>>
> >
>

Re: Contributions that are waiting for review

[Raul Kripalani]

How about a nightly job that fetches all tickets from JIRA which are
unresolved and have Patch Available = true, and (1) sends them to the dev
ML or (2) posts it in Gitter?

Will it help raise awareness and put them on the radar?

Raúl.
On 2 Mar 2016 20:47, "Denis Magda"  wrote:

>
> I would better ask contributors to ping committers on the dev list when a
> patch is available asking for review.
> It can happen that committers missed or forgot to do the review and a
> contributor can remind them sending one more email to the dev list.
>
> I don't see anything wrong with this approach. It's an open source project
> and most of the people don't keep an eye on new contributions that have to
> be released.
>
> PATCH_AVAILABLE stat is a right point. But I won't execute this filter all
> the time checking for pending reviews and some of the committers don't move
> the ticket to the CLOSED state when everything is merged.
> The latter was discussed some time ago there.
>
> --
> Denis
>
> On 3/2/2016 6:02 PM, Anton Vinogradov wrote:
>
>> Denis,
>>
>> We have a special status at Ignite JIRA - PATCH AVAILABLE which means that
>> issue ready to be reviewed.
>> Currently 59 issues has such status according to
>>
>> https://issues.apache.org/jira/issues/?filter=-2=project%20%3D%20Ignite%20and%20status%20%3D%20%22Patch%20Available%22
>>
>> I think we have to add notes that this status can be used only during
>> waiting of review and we will have no problems with actual "required
>> review" list in future.
>>
>>
>> On Wed, Mar 2, 2016 at 4:08 PM, Roman Shtykh 
>> wrote:
>>
>> I have also asked for review of the following tickets but failed to get a
>>> feedback.
>>> They are not complicated, but I would appreciate a quick review. Thank
>>> you!
>>>
>>> [IGNITE-2563] Queries: ArrayIndexOutOfBoundsException when using BOOL_AND
>>>
>>> https://issues.apache.org/jira/browse/IGNITE-2563
>>>
>>> IGNITE-2416 TcpDiscoverySharedFsIpFinder doesn't work with IPv6 addresses
>>> https://issues.apache.org/jira/browse/IGNITE-2416
>>>
>>> and a new one
>>>
>>> IGNITE-2710 Session not unbind from current request after invoking
>>> request.getSession().invalidate()
>>> https://issues.apache.org/jira/browse/IGNITE-2710
>>>
>>> -Roman
>>>
>>>
>>> On Wednesday, March 2, 2016 6:38 PM, Denis Magda 
>>> wrote:
>>>
>>>
>>>
>>> Ignite committers,
>>>
>>> There is a number of contributions that have to be reviewed.
>>>
>>> Please pick them up basing on your experience and provide your review
>>> notes.
>>>
>>> Ignite 2718: Missing ZookeeperIpFinder dependencies
>>> 
>>> IGNITE-2693: withKeepBinary and non-binary marshallers
>>> 
>>> IGNITE-2735: Fixes distributed semaphore local node stopping issue.
>>> 
>>> *IGNITE-642: Implements cache distributed reentrant lock
>>> 
>>>
>>>
>>> *Regards,
>>> Denis
>>>
>>>
>

Re: Switching back to review-then-commit process

[Raul Kripalani]

I thought we were already on RTC process.

What do you mean with contributors following this process?

Raúl.
On 3 Mar 2016 11:54, "Denis Magda"  wrote:

> Igniters,
>
> I would propose to switch back to review-then-commit process. This process
> has to be followed by both contributors and committers.
>
> There is a reason for this I have in mind. Ignite is a complex platform
> with several big modules. Some of the people may be experts in module A
> while others in module B etc.
> If a committer, who is good in module A, makes changes in module B merging
> the changes without a review this can break module's B internal
> functionality that the committer didn't take into account.
>
> My proposal is to introduce a list of maintainers for every Ignite module
> like it's done in Spark [1] and a rule that will require a committer to get
> an approval from a module maintainer before merging changes.
>
> Thoughts?
>
> --
> Denis
>
> [1]
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
>
>
>

IGNITE-2693 - could someone take a look and help me with a quick review

[Dood]

Hello,

This is my second Ignite ticket and if I understand correctly, it is a 
simple fix - I submitted a patch recently, it is only a few lines. Can 
someone take a look and see if I am on the right track or did I 
completely misunderstand it... :-)


Thanks!

Re: Switching back to review-then-commit process

[Dood]

+1 - sounds very reasonable and practical.

On 3/3/2016 5:54 AM, Denis Magda wrote:

Igniters,

I would propose to switch back to review-then-commit process. This 
process has to be followed by both contributors and committers.


There is a reason for this I have in mind. Ignite is a complex 
platform with several big modules. Some of the people may be experts 
in module A while others in module B etc.
If a committer, who is good in module A, makes changes in module B 
merging the changes without a review this can break module's B 
internal functionality that the committer didn't take into account.


My proposal is to introduce a list of maintainers for every Ignite 
module like it's done in Spark [1] and a rule that will require a 
committer to get an approval from a module maintainer before merging 
changes.


Thoughts?

--
Denis

[1] 
https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers 

Re: Switching back to review-then-commit process

[Alexey Kuznetsov]

+1 from me. I could be a maintainer for following modules: visor-console,
schema-import-utility, ignite-web-console, scalar.

We could even copy-paste rules from Spark wiki to ours.

On Thu, Mar 3, 2016 at 6:54 PM, Denis Magda  wrote:

> Igniters,
>
> I would propose to switch back to review-then-commit process. This process
> has to be followed by both contributors and committers.
>
> There is a reason for this I have in mind. Ignite is a complex platform
> with several big modules. Some of the people may be experts in module A
> while others in module B etc.
> If a committer, who is good in module A, makes changes in module B merging
> the changes without a review this can break module's B internal
> functionality that the committer didn't take into account.
>
> My proposal is to introduce a list of maintainers for every Ignite module
> like it's done in Spark [1] and a rule that will require a committer to get
> an approval from a module maintainer before merging changes.
>
> Thoughts?
>
> --
> Denis
>
> [1]
> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[jira] [Created] (IGNITE-2756) StreamVisitorExample returns empty result set

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-2756:
-

 Summary: StreamVisitorExample returns empty result set
 Key: IGNITE-2756
 URL: https://issues.apache.org/jira/browse/IGNITE-2756
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.6
Reporter: Sergey Kozlov


1. Start {{ExampleNodeStartup}}
2. Start {{StreamVisitorExample}}
{noformat}
[15:31:22] Ignite node started OK (id=4395613e)
[15:31:22] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=7.1GB]
Number of tuples streamed into Ignite: 50
Number of tuples streamed into Ignite: 100
...
Number of tuples streamed into Ignite: 950
Number of tuples streamed into Ignite: 1000
Top performing financial instruments: 
Query result set is empty.
[15:31:47] Ignite node stopped OK [uptime=00:00:25:209]

Process finished with exit code 0
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2755) Optimize gulp build tasks

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-2755:
-

 Summary: Optimize gulp build tasks
 Key: IGNITE-2755
 URL: https://issues.apache.org/jira/browse/IGNITE-2755
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitriyff
Assignee: Dmitriyff






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2754) IGFS: Create separate processor for listing remove.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2754:
---

 Summary: IGFS: Create separate processor for listing remove.
 Key: IGNITE-2754
 URL: https://issues.apache.org/jira/browse/IGNITE-2754
 Project: Ignite
  Issue Type: Improvement
  Components: IGFS
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


Instead of passing the whole listing entry, we can only pass required file name 
and ID.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2739 .NET: Implemented AffinityKey sup...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-2739 .NET: Implemented AffinityKey support



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

$ git pull https://github.com/ptupitsyn/ignite ignite-2739

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

https://github.com/apache/ignite/pull/533.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 #533


commit 51541fed8f51d17cbf4019adcdbf0563558b77ce
Author: Pavel Tupitsyn 
Date:   2016-03-02T13:23:13Z

IGNITE-2739 .NET: AffinityKey support

commit bedc43f5b957825c515f787529b57acc7c189e34
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:09:20Z

wip

commit ebc1ba9e723b9dec478bc403d6d39dc6cd54a839
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:10:11Z

wip

commit 3bf8228951ce24cad40ed8bc7aa82681d55480c7
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:20:01Z

wip

commit 734a403cff8ef78994c760a0db39417c8190d899
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:21:08Z

wip

commit 003c83c47a539581326e1e7961ba5ac03a527be5
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:35:49Z

wip attribute scan

commit 2468f695cc55c15f0cd1a0d34a59757e8662
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:40:31Z

Metadata test works

commit ef37bd333fd32fdc4219d4eba356bc2e7f664079
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:46:45Z

xmldoc

commit 61200075ad6740d6594364bab8d9eed2e7c636f1
Author: Pavel Tupitsyn 
Date:   2016-03-02T14:48:34Z

wip

commit b94a27077ad1e1710a4ef5ac1e1bc22dcd19db3a
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:10:31Z

wip

commit b8b60bbf4dc892482b0a3a37b622202b51e2a342
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:18:42Z

wip

commit d3828bc1b0fa57e90869053dc37abf5971b89d70
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:41:27Z

wip

commit ff52d8b7e5b411fc2d9532a85d35ae95bd50dd2a
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:42:54Z

wip

commit b27862e4d932adaa391afe66da18c0c1cd7184ce
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:51:50Z

wip

commit 7ae3bf68733ae2791597037d31f3c239a8f4ee03
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:54:30Z

wip

commit fdf770121b101a3f4e6cb942689307a5201abf30
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:55:33Z

wip

commit cc664c990707d049022cb90ce1aae80870b27ed9
Author: Pavel Tupitsyn 
Date:   2016-03-02T15:59:12Z

wip

commit 78f2f809c0eb08530067a5c1dd37eb6e11925024
Author: Pavel Tupitsyn 
Date:   2016-03-02T16:04:36Z

wip

commit c86c7b85d3152e8faaa431093f8b96bbc07fffc9
Author: Pavel Tupitsyn 
Date:   2016-03-02T16:37:36Z

wip

commit deb4867f4a3e6da13f5be45b2e9886c759538f00
Author: Pavel Tupitsyn 
Date:   2016-03-03T09:32:09Z

Merge remote-tracking branch 'remotes/upstream/master' into ignite-2739

commit c50f0ce8c600dd1f0c94d0984325998d1421221b
Author: Pavel Tupitsyn 
Date:   2016-03-03T09:34:55Z

Test interop

commit 5b27eeea50409c27a3496374e835eed7c3dbbf6e
Author: Pavel Tupitsyn 
Date:   2016-03-03T09:40:45Z

Cleanup

commit 428fd93b688481d066abea38665f8544ad7cc69f
Author: Pavel Tupitsyn 
Date:   2016-03-03T09:47:27Z

Update examples




---
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: Beta-releases for particular features.

[Yakov Zhdanov]

Roman, this is not about early and frequent releases, but about special
beta releases.

I agree with Dmitry and Pavel that we do not need such releases, but need
to mark somehow that feature is experimental:
- add notice to javadocs and readmeio docs (as Dmitry suggested)
- add warning output to logs on the first use of API

--Yakov

2016-03-03 11:50 GMT+03:00 Roman Shtykh :

> I like Vladimir's idea.It is particularly useful when we implement
> integrations with other systems. Releasing them early and, if needed,
> oftenly, may attract more users of those systems and give advantages over
> competitors.
> -Roman
>
>
> On Wednesday, March 2, 2016 2:01 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org> wrote:
>
>
>  In my opinion, if a certain feature is experimental, we should simply
> mention it in the release notes and/or documentation. I would not create a
> separate beta release just for a certain feature.
>
> D.
>
> On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn 
> wrote:
>
> > Hi,
> >
> > I don't think that features like LINQ and ODBC need the same approach
> > as IDEA EAP. IntelliJ has EAP because new features may have bugs
> > or usability issues. With LINQ and ODBC our main concern are not bugs,
> > but unsupported use cases that we did not think of. Known use cases
> > are covered with tests.
> >
> > Beta releases may not get enough attention to gather feedback.
> > I think we should release these features right away and gradually add
> > support
> > for missing use cases, if any emerge. We are not going to change API or
> > break compatibility while adding these things in future.
> >
> > Furthermore, LINQ is only a usability feature. Users can always switch to
> > raw SQL
> > if something can't be expressed in LINQ.
> >
> > On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Igniters,
> > >
> > > I want to circulate again an idea of "betas" for particular product
> > > features.
> > >
> > > For now we have several pretty cool features which are to be released
> > soon:
> > > ODBC driver and LINQ in .NET. Features like this include potentially
> > > infinite amount of use cases and of course we cannot test all of them.
> I
> > > believe things like this should go through extended release cycle so
> that
> > > we have time to get user's feedback before officially announcing them.
> It
> > > could be betas, early previews, whatever.
> > >
> > > The main idea is that we have a time window to obtain a feedback and
> > > stabilize the feature.
> > >
> > > This is a common practice for more or less big products. E.g. see
> > Hazelcast
> > > python client [1] and Intellij IDEA EAP 16 [2].
> > >
> > > Thoughts?
> > >
> > > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> > >
> > > Vladimir.
> > >
> >
>
>
>
>

Re: Beta-releases for particular features.

[Roman Shtykh]

I like Vladimir's idea.It is particularly useful when we implement integrations 
with other systems. Releasing them early and, if needed, oftenly, may attract 
more users of those systems and give advantages over competitors.
-Roman
 

On Wednesday, March 2, 2016 2:01 AM, Dmitriy Setrakyan 
 wrote:
 

 In my opinion, if a certain feature is experimental, we should simply
mention it in the release notes and/or documentation. I would not create a
separate beta release just for a certain feature.

D.

On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn 
wrote:

> Hi,
>
> I don't think that features like LINQ and ODBC need the same approach
> as IDEA EAP. IntelliJ has EAP because new features may have bugs
> or usability issues. With LINQ and ODBC our main concern are not bugs,
> but unsupported use cases that we did not think of. Known use cases
> are covered with tests.
>
> Beta releases may not get enough attention to gather feedback.
> I think we should release these features right away and gradually add
> support
> for missing use cases, if any emerge. We are not going to change API or
> break compatibility while adding these things in future.
>
> Furthermore, LINQ is only a usability feature. Users can always switch to
> raw SQL
> if something can't be expressed in LINQ.
>
> On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov 
> wrote:
>
> > Igniters,
> >
> > I want to circulate again an idea of "betas" for particular product
> > features.
> >
> > For now we have several pretty cool features which are to be released
> soon:
> > ODBC driver and LINQ in .NET. Features like this include potentially
> > infinite amount of use cases and of course we cannot test all of them. I
> > believe things like this should go through extended release cycle so that
> > we have time to get user's feedback before officially announcing them. It
> > could be betas, early previews, whatever.
> >
> > The main idea is that we have a time window to obtain a feedback and
> > stabilize the feature.
> >
> > This is a common practice for more or less big products. E.g. see
> Hazelcast
> > python client [1] and Intellij IDEA EAP 16 [2].
> >
> > Thoughts?
> >
> > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> >
> > Vladimir.
> >
>


   

[GitHub] ignite pull request: IGNTIE-2723 fixed java class input

[Dmitriyff]

GitHub user Dmitriyff opened a pull request:

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

IGNTIE-2723 fixed java class input



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

$ git pull https://github.com/Dmitriyff/ignite ignite-2723

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

https://github.com/apache/ignite/pull/532.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 #532


commit ece7a9508635b9dce77a79120c16a98dadea5ada
Author: Dmitriyff 
Date:   2016-03-03T08:41:22Z

IGNTIE-2723 fixed java class input




---
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-2753) Binary object might be deserialized unexpectedly when cache store is enabled.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2753:
---

 Summary: Binary object might be deserialized unexpectedly when 
cache store is enabled.
 Key: IGNITE-2753
 URL: https://issues.apache.org/jira/browse/IGNITE-2753
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Dmitry Karachentsev
Priority: Critical
 Fix For: 1.6


*Problem*
See {{GridCacheMapEntry}} class. There are lots of calls to store like this:
{code}
cctx.store().put(null, keyValue(false), CU.value(val, cctx, false), ver);
{code}

When {{keyValue()}} is called, it might force object deserialization. And if 
there is no class on the server, the following exception might appear:
{code}
g.apache.ignite.binary.BinaryInvalidTypeException: 
com.jefco.portfoliotrading.gets.common.CurrencyKey
at 
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:558)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1442)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.keyValue(GridCacheMapEntry.java:1261)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3326)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:1598)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
 ~[ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:304)
 [ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:49)
 [ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:79)
 [ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
 [ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
 [ignite-core-1.5.7.jar:1.5.7]
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
 [ignite-core-1.5.7.jar:1.5.7]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:1.8.0_51]
{code}

*Proposed solution*
Pass key and value directly to store manager. It should already handle 
everything correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)