date:20170310

Re: Google Summer Of Code 2017

2017-03-10 Thread Denis Magda

Igniters,

We lost the battle but still might win the war. ASF has been accepted as one of 
participating organizations for GSoC2017. So we can take part as an ASF project!

I’ve added the following four tickets to ASF GSoC2017 list 
(https://issues.apache.org/jira/browse/TIKA-2262?filter=12339687):
* Machine Learning, Nikita Ivanov: 
https://issues.apache.org/jira/browse/IGNITE-4572 

* Spark Data Frames, Val Kulichenko: 
https://issues.apache.org/jira/browse/IGNITE-3084 

* Ignite R Library, Dmitriy Setrakyan: 
https://issues.apache.org/jira/browse/IGNITE-4605 

* Ignite Python Library, Denis Magda: 
https://issues.apache.org/jira/browse/IGNITE-4600

*Nikita*, *Val*, *Dmitriy*, as potential mentors you need to request an 
acknowledgement from the Apache Ignite PMC for being a mentor. Use the below 
template and *do not forget to copy ment...@community.apache.org 
*. ASF committee will use the email 
address you indicate to send the invite to be a mentor for Apache.

ASF committee requests that each mentor is acknowledged by a PMC member. This 
is to ensure the mentor is in good
standing with the community. When you receive a request for acknowledgement, 
please ACK it and cc
ment...@community.apache.org 


mentor request email template:

to: priv...@ignite.apache.org 
cc: ment...@community.apache.org 
subject: GSoC 2017 mentor request for 

Apache Ignite PMC,

Please acknowledge my request to become a mentor for Google Summer of Code 2017 
projects for Apache
Ignite.

I would like to receive the mentor invite to 



——

> On Feb 27, 2017, at 10:09 AM, Denis Magda  wrote:
> 
> Igniters,
> 
> Unfortunately, we have been rebuffed this year.
> 
> Thank you for applying to be a Google Summer of Code 2017 mentor 
> organization. Sadly, we were unable to accept Apache Ignite this year. We had 
> many more applications than available slots. We hope you will apply again in 
> the future!
> 
> 
> —
> Denis
> 
>> On Jan 24, 2017, at 6:59 PM, Denis Magda  wrote:
>> 
>> I’ve prepared the Apache Ignite application. These are the tasks:
>> https://goo.gl/4SpTzK
>> 
>> The mentors are:
>> - Nikita Ivanov (machine learning).
>> - Valentin Kulichenko (Spark Data Frames).
>> - Dmitriy Setrakyan (Node.JS Client).
>> - Denis Magda (Python and R Clients).
>> 
>> Val, please share your BIO. I’ll add it to the tasks’ list.
>> 
>> Also, Dmitriy and Val I added you as administrators. Accept the invites and 
>> after that our application will be considered completed.
>> 
>> —
>> Denis
>> 
>>> On Dec 29, 2016, at 6:59 PM, Denis Magda  wrote:
>>> 
>>> Igor R., is there anything that can be improved & refined in the existed 
>>> integration of Ignite and Cassandra and outsourced to Google Summer of 
>>> Code? 
>>> 
>>> —
>>> Denis
>>> 
 On Dec 22, 2016, at 10:29 AM, Denis Magda  wrote:
 
 This is great!
 
 So, we already have three mentors in total (Val, Dmitriy, Denis). Anyone 
 else?
 
 Any other tasks you think are suitable for this summer program?
 
 —
 Denis
 
> On Dec 21, 2016, at 4:26 PM, Valentin Kulichenko 
>  wrote:
> 
> I can take over DataFrames integration as I already did some investigation
> in this area. Spark also has GraphX and GraphFrames for graph processing,
> we can think about integration with them as well.
> 
> Machine learning also sounds very interesting.
> 
> -Val
> 
> On Wed, Dec 21, 2016 at 4:22 PM, Dmitriy Setrakyan 
> wrote:
> 
>> I can also do mentoring for any of the listed features.
>> 
>> On Wed, Dec 21, 2016 at 2:50 PM, Denis Magda  wrote:
>> 
>>> Alex, thanks for bringing this out!
>>> 
>>> This is a great opportunity for our community to find talented students
>>> who are capable of adding new features to Ignite. I can take care of all
>>> the paperwork. The features list won’t be a big deal as well. But we 
>>> need
>>> mentors who will voluntarily dedicate their time helping the
>> participants.
>>> 
>>> Well, here is a list of features that pop up immediately out of my head
>>> and that I would like to offer to GSoC (Google Summer Of Code).
>>> Native client for Python (data grid, compute grid, continuous queries).
>>> Native client for Node.JS (https://issues.apache.org/
>>> jira/browse/IGNITE-961 >> )
>>> Kubernetis integration (IGNITE-4159 >> jira/browse/IGNITE-4159>).
>>> Spark Data Frames API

Re: Merging all network components to a single one

2017-03-10 Thread Dmitriy Setrakyan

Agree with Denis. It is not practical to remove any existing SPIs unless we
come up with proper TCP SPI design and implementation.

I think it will be enough to simply deprecate the existing SPIs we plan to
remove, without physically removing them, until the design is finalized.

D.

On Fri, Mar 10, 2017 at 11:55 AM, Denis Magda  wrote:

> > Denis, I think we can allow this as well, but not as SPI since I want to
> > drop them and create 1 internal component to manage all
> interconnections. I
> > think this is enough since additions/changes will be rare and they will
> > result in changing internal code (including support of technologies you
> > mentioned). None of our users implemented discovery or communication on
> > their own, and I doubt if someone ever will. So, what is the purpose of
> > keeping SPIs?
>
> Yasha, I don’t insist to keep the SPIs but rather want to clarify that it
> will be feasible to provide a custom implementation of this new networking
> component if needed. Looks like this will be possible.
>
> > Dmitry, you are right - this seems to be a very complex change. However,
> we
> > can we move current implementations to internal packages, introduce
> > configuration properties/beans so we can release and continue development
> > in 2.0 without breaking compatibility.
>
> Let’s do this if there is a one who can take over the interface design and
> complete it by 2.0 release.
>
> —
> Denis
>
> > On Mar 10, 2017, at 7:39 AM, Yakov Zhdanov  wrote:
> >
> > Dmitry, you are right - this seems to be a very complex change. However,
> we
> > can we move current implementations to internal packages, introduce
> > configuration properties/beans so we can release and continue development
> > in 2.0 without breaking compatibility.
> >
> > Denis, I think we can allow this as well, but not as SPI since I want to
> > drop them and create 1 internal component to manage all
> interconnections. I
> > think this is enough since additions/changes will be rare and they will
> > result in changing internal code (including support of technologies you
> > mentioned). None of our users implemented discovery or communication on
> > their own, and I doubt if someone ever will. So, what is the purpose of
> > keeping SPIs?
> >
> > --Yakov
>
>

Re: More SEO and API doc cleanup

2017-03-10 Thread Denis Magda

Hello Mauricio,

Thanks a lot, I’ve reviewed and merged your changes!

>   - Setup rewrite rule on .htaccess so latest API doc can have always the 
> same URL ( for example https://ignite.apache.org/releases/latest/javadoc/ 
> )  In this case I pointed 
> it to version 1.9.0. This will prevent having to manually change all inbound 
> links every time a new release is done. Also will help search engines to 
> correctly identify the latest documentation that should be listed on results.


Many special thanks for this improvement. I wish we did this earlier.

BTW, what we need to do to update this latest doc reference when a new version 
is rolled out? Could you share the instructions?

—
Denis

> On Mar 10, 2017, at 1:54 PM, Mauricio Stekl  wrote:
> 
> Hello Igniters, 
> 
> I am sending a .patch file attached with some changes related to SEO that I 
> have done to Apache Ignite website. 
> 
> Here are some details: 
> 
>   - Setup rewrite rule on .htaccess so latest API doc can have always the 
> same URL ( for example https://ignite.apache.org/releases/latest/javadoc/ 
> )  In this case I pointed 
> it to version 1.9.0. This will prevent having to manually change all inbound 
> links every time a new release is done. Also will help search engines to 
> correctly identify the latest documentation that should be listed on results.
>   - Added NOINDEX meta tag to all API documentation for versions <= 
> 1.8.0. This will help crawlers to give more page authority to latest version 
> of the doc, and will avoid indexing more than 25.000 URLs.
>   - Added canonical url tags and GA tracking code to all .html files for 
> 1.9.0. 
>   - Updated some anchor tags on the homepage which were linking to the 
> features using only the icons and not the feature's title text.
>   - Updated sitemap.xml with 1.9.0 URLs.
>   - Updated the links on navigation so they point to latest version of 
> API documentation.
> 
> 
> I will appreciate if any of the committers could merge this on website’s repo.
> 
> Please let me know if you have any question.
> 
> Thanks in advance.
> 
> Best,
> Mauricio Stekl
> 
> 
>

Re: ignite-4804 - ready for review (Remove duplicated properties in parent-pom)

2017-03-10 Thread Denis Magda

After the sync ignite-2.0 will merge my commit and the other commit, that 
removed extra spark version, from the master and everything should be resolved 
after that.

—
Denis

> On Mar 10, 2017, at 12:32 PM, Vyacheslav Daradur  wrote:
> 
> 
> I'm talking about:
> 
> - master-branch had 2 dublicated properties [, 
> ] (your commit fix it 
> )
> - ignite-2.0 branch has 3 dublicated properties [, 
> , ]
> 
> After branch synchronization, ignite-2.0 branch will has one more dublicated 
> property [].
> 
> Am I missing something here?
> 
> 
> 2017-03-10 23:16 GMT+03:00 Denis Magda  >:
> The commit will be merged to ignite-2.0 the next time when the branches will 
> be put in sync.
> 
> —
> Denis
> 
>> On Mar 10, 2017, at 12:06 PM, Vyacheslav Daradur > > wrote:
>> 
>> Denis, thanks.
>> 
>> I've seen your commit in the master-branch.
>> 
>> Notice, the ignite-2.0 branch contains one more duplicated property: 
>> "1.5.2".
>> 
>> --
>> Best regards.
>> 
>> 2017-03-10 22:37 GMT+03:00 Denis Magda > >:
>> Hi,
>> 
>> Thanks a lot, I’ve merged your changes.
>> 
>> —
>> Denis
>> 
>> > On Mar 9, 2017, at 11:27 PM, Vyacheslav Daradur > > > wrote:
>> >
>> > Hello everyone.
>> >
>> > Please review changes. https://issues.apache.org/jira/browse/IGNITE-4804 
>> > 
>> >
>> > I found this mistake when I worked on an another issue.
>> > I created new issue (ignite-4804), because reviewer told me I should fix
>> > this in different task, because it didn't relates to that issue.

Re: ignite-4804 - ready for review (Remove duplicated properties in parent-pom)

2017-03-10 Thread Vyacheslav Daradur

I'm talking about:

- master-branch had 2 dublicated properties [,
] (your commit fix it

)
- ignite-2.0 branch has 3 dublicated properties [,
, ]

After branch synchronization, ignite-2.0 branch will has one more
dublicated property [].

Am I missing something here?


2017-03-10 23:16 GMT+03:00 Denis Magda :

> The commit will be merged to ignite-2.0 the next time when the branches
> will be put in sync.
>
> —
> Denis
>
> On Mar 10, 2017, at 12:06 PM, Vyacheslav Daradur 
> wrote:
>
> Denis, thanks.
>
> I've seen your commit in the master-branch.
>
> Notice, the ignite-2.0 branch contains one more duplicated property:
> "1.5.2".
>
> --
> Best regards.
>
> 2017-03-10 22:37 GMT+03:00 Denis Magda :
>
>> Hi,
>>
>> Thanks a lot, I’ve merged your changes.
>>
>> —
>> Denis
>>
>> > On Mar 9, 2017, at 11:27 PM, Vyacheslav Daradur 
>> wrote:
>> >
>> > Hello everyone.
>> >
>> > Please review changes. https://issues.apache.org/jira
>> /browse/IGNITE-4804
>> >
>> > I found this mistake when I worked on an another issue.
>> > I created new issue (ignite-4804), because reviewer told me I should fix
>> > this in different task, because it didn't relates to that issue.
>>
>>
>
>

Re: ignite-4804 - ready for review (Remove duplicated properties in parent-pom)

2017-03-10 Thread Denis Magda

The commit will be merged to ignite-2.0 the next time when the branches will be 
put in sync.

—
Denis

> On Mar 10, 2017, at 12:06 PM, Vyacheslav Daradur  wrote:
> 
> Denis, thanks.
> 
> I've seen your commit in the master-branch.
> 
> Notice, the ignite-2.0 branch contains one more duplicated property: 
> "1.5.2".
> 
> --
> Best regards.
> 
> 2017-03-10 22:37 GMT+03:00 Denis Magda  >:
> Hi,
> 
> Thanks a lot, I’ve merged your changes.
> 
> —
> Denis
> 
> > On Mar 9, 2017, at 11:27 PM, Vyacheslav Daradur  > > wrote:
> >
> > Hello everyone.
> >
> > Please review changes. https://issues.apache.org/jira/browse/IGNITE-4804 
> > 
> >
> > I found this mistake when I worked on an another issue.
> > I created new issue (ignite-4804), because reviewer told me I should fix
> > this in different task, because it didn't relates to that issue.
> 
>

Re: ignite-4804 - ready for review (Remove duplicated properties in parent-pom)

2017-03-10 Thread Vyacheslav Daradur

Denis, thanks.

I've seen your commit in the master-branch.

Notice, the ignite-2.0 branch contains one more duplicated property:
"1.5.2".

--
Best regards.

2017-03-10 22:37 GMT+03:00 Denis Magda :

> Hi,
>
> Thanks a lot, I’ve merged your changes.
>
> —
> Denis
>
> > On Mar 9, 2017, at 11:27 PM, Vyacheslav Daradur 
> wrote:
> >
> > Hello everyone.
> >
> > Please review changes. https://issues.apache.org/jira/browse/IGNITE-4804
> >
> > I found this mistake when I worked on an another issue.
> > I created new issue (ignite-4804), because reviewer told me I should fix
> > this in different task, because it didn't relates to that issue.
>
>

Re: assigning IGNITE-933

2017-03-10 Thread Denis Magda

Vadim,

Please prepare a pull-request and make sure that the test passes on TeamCity.

—
Denis

> On Mar 10, 2017, at 9:25 AM, Вадим Опольский  wrote:
> 
> Hello everyone!
> 
> Denis, I've successfully executed GridFailFastNodeFailureDetectionSelfTest in 
> IDE 10 times on VMware Workstation (3 GB RAM,  Intel Core i5-2520M) in single 
> core mode with 300 MILLISECONDS timeout.
> 
> What's the next step ?
> 
> Vadim
> 
> 
> 2017-03-07 22:25 GMT+03:00 Denis Magda  >:
> Vadim,
> 
> The timeout should be such that the test completes successfully on single 
> core machine as well as on multi-core servers. Setting timeout to 3 - 5 
> seconds should work.
> 
> —
> Denis
> 
>> On Mar 7, 2017, at 1:55 AM, Вадим Опольский > > wrote:
>> 
>> Denis,
>> 
>> I'm planning to adjust processing time of incoming and outgoing messages by 
>> JMH benchmarks.
>> 
>> What do you think are the parameters of commodity hardware/? RAM size? CPU 
>> speed ? or others ?
>> 
>> Vadim
>> 
>> 2017-03-06 22:36 GMT+03:00 Denis Magda > >:
>> Vadim,
>> 
>> How do you plan to adjust processing time of incoming and outgoing messages? 
>> In general, I don’t think that you need to move the direction of the 
>> communication layer.
>> 
>> I’m thinking that you just need to set some reasonable awaiting time so that 
>> the test passes on a commodity hardware.
>> 
>> —
>> Denis
>> 
>>> On Mar 6, 2017, at 2:31 AM, Вадим Опольский >> > wrote:
>>> 
>>> Hi everyone!
>>> 
>>> I executed test GridFailFastNodeFailureDetectionSelfTest.testFailFast fails 
>>> periodically with different values of node quantity and awaiting time. Test 
>>> fails if the awaiting time is less than 600 miliseconds. 
>>> I debugged test and understood that messaging took a lot of time in this 
>>> case.
>>> I want to measure (with 
>>> GridFailFastNodeFailureDetectionSelfTest.testFailFast) and increase speed 
>>> of receiving and sending message.
>>> 
>>> Denis, what do you think about it ?
>>> 
>>> 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 Hibernate? If so, I would be amazing 
>>> if you pick up this ticket reassigning on yourself:
>>> 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 
>>> > 
>>> >
>>> > Is it actual ?
>>> >
>>> > In which class and method you want me to make changes ?
>>> >
>>> > Vadim Opolski
> 
>

Re: Merging all network components to a single one

2017-03-10 Thread Denis Magda

> Denis, I think we can allow this as well, but not as SPI since I want to
> drop them and create 1 internal component to manage all interconnections. I
> think this is enough since additions/changes will be rare and they will
> result in changing internal code (including support of technologies you
> mentioned). None of our users implemented discovery or communication on
> their own, and I doubt if someone ever will. So, what is the purpose of
> keeping SPIs?

Yasha, I don’t insist to keep the SPIs but rather want to clarify that it will 
be feasible to provide a custom implementation of this new networking component 
if needed. Looks like this will be possible.

> Dmitry, you are right - this seems to be a very complex change. However, we
> can we move current implementations to internal packages, introduce
> configuration properties/beans so we can release and continue development
> in 2.0 without breaking compatibility.

Let’s do this if there is a one who can take over the interface design and 
complete it by 2.0 release.

—
Denis

> On Mar 10, 2017, at 7:39 AM, Yakov Zhdanov  wrote:
> 
> Dmitry, you are right - this seems to be a very complex change. However, we
> can we move current implementations to internal packages, introduce
> configuration properties/beans so we can release and continue development
> in 2.0 without breaking compatibility.
> 
> Denis, I think we can allow this as well, but not as SPI since I want to
> drop them and create 1 internal component to manage all interconnections. I
> think this is enough since additions/changes will be rare and they will
> result in changing internal code (including support of technologies you
> mentioned). None of our users implemented discovery or communication on
> their own, and I doubt if someone ever will. So, what is the purpose of
> keeping SPIs?
> 
> --Yakov

Re: ignite-4804 - ready for review (Remove duplicated properties in parent-pom)

2017-03-10 Thread Denis Magda

Hi,

Thanks a lot, I’ve merged your changes.

—
Denis

> On Mar 9, 2017, at 11:27 PM, Vyacheslav Daradur  wrote:
> 
> Hello everyone.
> 
> Please review changes. https://issues.apache.org/jira/browse/IGNITE-4804
> 
> I found this mistake when I worked on an another issue.
> I created new issue (ignite-4804), because reviewer told me I should fix
> this in different task, because it didn't relates to that issue.

Re: Request adding to contributors list

2017-03-10 Thread Denis Magda

Hi Kartrik,

I’ve added you to the contributors list. Now you can assign the ticket on 
yourself.

—
Denis

> On Mar 9, 2017, at 11:23 PM, kartik somani  
> wrote:
> 
> Hi Alexey,
> 
> My ID is kay_jpr.
> 
> Thanks & Regards,
> Kartik
> 
> On Fri, Mar 10, 2017 at 6:33 AM, Alexey Kuznetsov 
> wrote:
> 
>> Hi, Kartik!
>> 
>> What is your Apache JIRA ID?
>> 
>> On Fri, Mar 10, 2017 at 2:38 AM, Kartik Somani <
>> kartiksomani.offic...@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> Can someone add me to contributors list?
>>> 
>>> I want to assign a ticket to myself, but unable to.
>>> 
>>> Regards,
>>> Kartik
>>> 
>> 
>> 
>> 
>> --
>> Alexey Kuznetsov
>>

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

2017-03-10 Thread Александр Меньшиков

I'm sorry I didn't notice pair "acquireShared" and "releaseShared". Okay,
well, there are no races. But we still can use "getState()" in "assert"
instead "resFlag", that will allow us use boolean type. But if you think it
will not make code cleaner, then I will close issue.

2017-03-01 14:55 GMT+03:00 Александр Меньшиков :

> First of all I want to replace the "byte resFlag" on the "bool haveResult"
> only for aesthetic reasons. I think that use a byte as a boolean flag looks
> like C in 1983. And constructions like
>
> return haveResult ? (R)res : null;
>
> more readable unlike
>
> return resFlag == RES ? (R)res : null;
>
> because you don't know how many values the "resFlag" can have.
> But it's not big deal, so if community disagrees it's okay.
>
> About volatile:
>
> Class "GridFutureAdapter" uses zero value of the "resFlag" in assert for
> check that didn't call the "get0" before the "onDone".
> So I suggested to use the "getState()" for this check. But of course it's
> work only if "get0" and "onDone" are called in a same thread.
> But if threads are different (as you said), we have bug any way because
> the "resFlag" is not volatile.
> In the GridFutureAdapter we haven't any sync between write operations to
> the "resFlag" in the "onDone" and the read operation in the "get0". So
> the "get0" in the line "assert resFlag != 0" can throw AssertionError,
> because a thread with the "get0" may not see the write operation in
> "onDone" in other thread.
>
> So I think in this case we need to add volatile in the
> GridFutureAdapter.resFlag, and replace the GridFinishedFuture.resFlag on the
> GridFinishedFuture.haveResult (or not if you don't like it).
>
>
> 2017-02-28 19:39 GMT+03:00 Yakov Zhdanov :
>
>> Alexander,
>>
>> Can you please clarify this?
>>
>> >I suppose "volatile" is not need here, because right now if
>> GridFutureAdapter#onDone()
>> called in another thread than GridFutureAdapter#get0, it will produce
>> AssertionError.
>>
>> 1) 99.999% of time GridFutureAdapter#onDone() is called in some other
>> thread than the one which is frozen on get()
>> 2) What is volatile now which should not be?
>>
>> Regarding the flag - boolean and byte takes 1 byte in the object. I
>> suppose
>> some time ago there were 3 options, but now there are only 2. I don't
>> think
>> we need to change it now.
>>
>>
>>
>> --Yakov
>>
>> 2017-02-28 17:32 GMT+03:00 Александр Меньшиков :
>>
>> > Sorry, I mean I want to do fast work on this issue (not make code
>> faster).
>> > Your code is strange. You can see my view in my local temp PR:
>> >
>> > https://github.com/SharplEr/ignite/pull/4/files
>> >
>> > This is what I'm meaning.
>> >
>> > I suppose "volatile" is not need here, because right now if
>> > GridFutureAdapter#onDone() called in another thread than
>> > GridFutureAdapter#get0, it will produce AssertionError.
>> >
>> >
>> >
>> > 2017-02-28 16:57 GMT+03:00 Vladislav Pyatkov :
>> >
>> > > Alexander,
>> > >
>> > > Are you sure, which it will be faster?
>> > > The condition
>> > >
>> > > resFlag == RES and resFlag == ERR
>> > >
>> > > should be more complicated... like something this:
>> > >
>> > > getState() != 0 &&  !resFlag and getState() != 0 &&  resFlag
>> > >
>> > > But unlike getState(), restFag is not volatile...
>> > >
>> > > On Tue, Feb 28, 2017 at 4:26 PM, Александр Меньшиков <
>> > sharple...@gmail.com
>> > > > wrote:
>> > >
>> > >> Alexey, Vladislav, are you agree with me, or not? I want to do it
>> faster
>> > >> and move on.
>> > >>
>> > >> 2017-02-17 17:36 GMT+03:00 Александр Меньшиков > >:
>> > >>
>> > >>> We can check "onDone" method was called with using getState()
>> method.
>> > If
>> > >>> getState()!=0 then  resFlag!=0. Just look at code.
>> > >>>
>> > >>>
>> > >>> 2017-02-17 17:12 GMT+03:00 Александр Меньшиков <
>> sharple...@gmail.com>:
>> > >>>
>> >  Like I said, if "resFlag==0" (of course 0 came from initialization)
>> >  means "you still haven't called the method onDone()", better make
>> it
>> > clear.
>> > 
>> > 
>> > 
>> >  2017-02-17 14:48 GMT+03:00 Vladislav Pyatkov > >:
>> > 
>> > > Alexander,
>> > >
>> > > I think, the resFlag will be initiated as 0 (new
>> > GridFutureAdapter()),
>> > > but
>> > > 1 and 2 states will be acquired on live.
>> > >
>> > >
>> > > On Fri, Feb 17, 2017 at 1:56 PM, Александр Меньшиков <
>> > > sharple...@gmail.com>
>> > > wrote:
>> > >
>> > > > Alexey,
>> > > >
>> > > > I see only one place where writes in resFlag:
>> > > >
>> > > > if (err != null) {
>> > > > resFlag = ERR;
>> > > > this.res = err;
>> > > > }
>> > > > else {
>> > > > resFlag = RES;
>> > > > this.res = res;
>> > > >

Re: assigning IGNITE-933

2017-03-10 Thread Вадим Опольский

Hello everyone!

Denis, I've successfully executed GridFailFastNodeFailureDetectionSelfTest
in IDE 10 times on VMware Workstation (3 GB RAM,  Intel Core i5-2520M) in
single core mode with 300 MILLISECONDS timeout.

What's the next step ?

Vadim


2017-03-07 22:25 GMT+03:00 Denis Magda :

> Vadim,
>
> The timeout should be such that the test completes successfully on single
> core machine as well as on multi-core servers. Setting timeout to 3 - 5
> seconds should work.
>
> —
> Denis
>
> On Mar 7, 2017, at 1:55 AM, Вадим Опольский  wrote:
>
> Denis,
>
> I'm planning to adjust processing time of incoming and outgoing messages
> by JMH benchmarks.
>
> What do you think are the parameters of commodity hardware/? RAM size? CPU
> speed ? or others ?
>
> Vadim
>
> 2017-03-06 22:36 GMT+03:00 Denis Magda :
>
>> Vadim,
>>
>> How do you plan to adjust processing time of incoming and outgoing
>> messages? In general, I don’t think that you need to move the direction of
>> the communication layer.
>>
>> I’m thinking that you just need to set some reasonable awaiting time so
>> that the test passes on a commodity hardware.
>>
>> —
>> Denis
>>
>> On Mar 6, 2017, at 2:31 AM, Вадим Опольский  wrote:
>>
>> Hi everyone!
>>
>> I executed test GridFailFastNodeFailureDetectionSelfTest.testFailFast
>> fails periodically with different values of node quantity and awaiting
>> time. Test fails if the awaiting time is less than 600 miliseconds.
>> I debugged test and understood that messaging took a lot of time in this
>> case.
>> I want to measure (with GridFailFastNodeFailureDetecti
>> onSelfTest.testFailFast) and increase speed of receiving and sending
>> message.
>>
>> Denis, what do you think about it ?
>>
>> 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 Hibernate? If so, I would be
>>> amazing if you pick up this ticket reassigning on yourself:
>>> https://issues.apache.org/jira/browse/IGNITE-1794 >> 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
>>> >
>>> > Is it actual ?
>>> >
>>> > In which class and method you want me to make changes ?
>>> >
>>> > Vadim Opolski
>>
>>
>

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

2017-03-10 Thread Alexey Goncharuk

Yes, but I have added a few more today :)

2017-03-10 19:03 GMT+03:00 ALEKSEY KUZNETSOV :

> Hmm, i have fixed all your remarks more than 20 days ago.
>
> пт, 10 мар. 2017 г. в 15:12, Alexey Goncharuk  >:
>
> > Alexey,
> >
> > Looks good. I've left my comments in the PR, please address them and I
> will
> > merge it.
> >
> > 2017-03-10 10:24 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > plz review ticket again
> > >
> > > чт, 9 мар. 2017 г. в 10:28, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > >
> > > > plz review ticket again
> > > >
> > > > вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com
> > > > >:
> > > >
> > > > plz review ticket again
> > > >
> > > > пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > >
> > > > Thanks, Aleksey,
> > > >
> > > > I will take a look this week.
> > > >
> > > > --AG
> > > >
> > > > 2017-02-20 10:25 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > Hi! Review my PR again, plz - https://github.com/apache/
> > > ignite/pull/1517
> > > > >
> > > > > пт, 17 февр. 2017 г. в 14:44, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com
> > > > > >:
> > > > >
> > > > > > thanx! my next PR review will be in up source
> > > > > >
> > > > > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com
> > > > > > >:
> > > > > >
> > > > > > Aleksey,
> > > > > >
> > > > > > I added a comment on GitHub, however, the community is moving
> > towards
> > > > the
> > > > > > UpSource review tool, so I suggest you open a PR review in Ignite
> > > > > UpSource:
> > > > > > http://reviews.ignite.apache.org/ignite/
> > > > > >
> > > > > > After you've registered, you should be able to open a review.
> > > > > >
> > > > > > --AG
> > > > > >
> > > > > > 2017-02-17 11:13 GMT+03:00 ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com
> > > > >:
> > > > > >
> > > > > > > Again, plz, review my PR :
> > > > https://github.com/apache/ignite/pull/1517
> > > > > > >
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-1178
> > > > > > > --
> > > > > > >
> > > > > > > *Best Regards,*
> > > > > > >
> > > > > > > *Kuznetsov Aleksey*
> > > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

2017-03-10 Thread ALEKSEY KUZNETSOV

Hmm, i have fixed all your remarks more than 20 days ago.

пт, 10 мар. 2017 г. в 15:12, Alexey Goncharuk :

> Alexey,
>
> Looks good. I've left my comments in the PR, please address them and I will
> merge it.
>
> 2017-03-10 10:24 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > plz review ticket again
> >
> > чт, 9 мар. 2017 г. в 10:28, ALEKSEY KUZNETSOV  >:
> >
> > > plz review ticket again
> > >
> > > вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > >
> > > plz review ticket again
> > >
> > > пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > Thanks, Aleksey,
> > >
> > > I will take a look this week.
> > >
> > > --AG
> > >
> > > 2017-02-20 10:25 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Hi! Review my PR again, plz - https://github.com/apache/
> > ignite/pull/1517
> > > >
> > > > пт, 17 февр. 2017 г. в 14:44, ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com
> > > > >:
> > > >
> > > > > thanx! my next PR review will be in up source
> > > > >
> > > > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > >:
> > > > >
> > > > > Aleksey,
> > > > >
> > > > > I added a comment on GitHub, however, the community is moving
> towards
> > > the
> > > > > UpSource review tool, so I suggest you open a PR review in Ignite
> > > > UpSource:
> > > > > http://reviews.ignite.apache.org/ignite/
> > > > >
> > > > > After you've registered, you should be able to open a review.
> > > > >
> > > > > --AG
> > > > >
> > > > > 2017-02-17 11:13 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > Again, plz, review my PR :
> > > https://github.com/apache/ignite/pull/1517
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/IGNITE-1178
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1613: IGNITE-4815: CollisionSPI.onCollision() confusing...

2017-03-10 Thread AMashenkov

GitHub user AMashenkov opened a pull request:

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

IGNITE-4815: CollisionSPI.onCollision() confusing javadoc fixed



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

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

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

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


commit 1bc9b0f31fcc0f6e893713994663f19461423f38
Author: AMRepo 
Date:   2017-03-10T15:33:34Z

Javadoc fixed.




---
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: Merging all network components to a single one

2017-03-10 Thread Yakov Zhdanov

Dmitry, you are right - this seems to be a very complex change. However, we
can we move current implementations to internal packages, introduce
configuration properties/beans so we can release and continue development
in 2.0 without breaking compatibility.

Denis, I think we can allow this as well, but not as SPI since I want to
drop them and create 1 internal component to manage all interconnections. I
think this is enough since additions/changes will be rare and they will
result in changing internal code (including support of technologies you
mentioned). None of our users implemented discovery or communication on
their own, and I doubt if someone ever will. So, what is the purpose of
keeping SPIs?

--Yakov

[GitHub] ignite pull request #1612: IGNITE-4814

2017-03-10 Thread devozerov

GitHub user devozerov opened a pull request:

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

IGNITE-4814



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

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

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

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


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

commit 38cb67d45eb91e20ad4b92a490747534f5e8febb
Author: Pavel Tupitsyn 
Date:   2017-01-20T13:09:57Z

Merge branch 'master' into ignite-2.0

commit 82857d0cb6e2984a5359b822a9c903874414aa67
Author: Pavel Tupitsyn 
Date:   2017-01-23T10:12:12Z

Merge branch

[jira] [Created] (IGNITE-4815) CollisionSPI calls on every EVT_NODE_METRICS_UPDATED event.

2017-03-10 Thread Andrew Mashenkov (JIRA)

Andrew Mashenkov created IGNITE-4815:


 Summary: CollisionSPI calls on every EVT_NODE_METRICS_UPDATED 
event.
 Key: IGNITE-4815
 URL: https://issues.apache.org/jira/browse/IGNITE-4815
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Andrew Mashenkov
Priority: Minor
 Fix For: 2.0


It looks like CollisionSPI.onCollision() method has a confusing javadoc.




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

Re: distributed transaction of non-single coordinator

2017-03-10 Thread Дмитрий Рябов

What about to send special message to random/choosen node when we start
transaction? And when rollback procedure begins - this second node will
check state of originating node and if it is down then second node became
originating?

2017-03-10 17:25 GMT+03:00 Alexey Goncharuk :

> Aleksey,
>
> I think I am starting to get what you want, but I have a few concerns:
>  - What is the API for the proposed change? In your test, you pass an
> instance of transaction created on ignite(0) to the ignite instance
> ignite(1). This is obviously not possible in a truly distributed
> (multi-jvm) environment.
> - How will you synchronize cache update actions and transaction commit?
> Say, you have one node that decided to commit, but another node is still
> writing within this transaction. How do you make sure that two nodes will
> not call commit() and rollback() simultaneously?
>  - How do you make sure that either commit() or rollback() is called if an
> originator failed?
>
> 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов :
>
> > Alexey Goncharuk, heh, my initial understanding was that transferring of
> tx
> > ownership from one node to another will be happened automatically when
> > originating node is gone down.
> >
> > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > Im aiming to span transaction on multiple threads, nodes, jvms(soon).
> So
> > > every node is able to rollback, or commit common transaction.It turned
> > up i
> > > need to transfer tx between nodes in order to commit transaction in
> > > different node(in the same jvm).
> > >
> > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Aleksey,
> > > >
> > > > Do you mean that you want a concept of transferring of tx ownership
> > from
> > > > one node to another? My initial understanding was that you want to be
> > > able
> > > > to update keys in a transaction from multiple threads in parallel.
> > > >
> > > > --AG
> > > >
> > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > Well. Consider transaction started in one node, and continued in
> > > another
> > > > > one.
> > > > > The following test describes my idea:
> > > > >
> > > > > Ignite ignite1 = ignite(0);
> > > > >
> > > > > IgniteTransactions transactions = ignite1.transactions();
> > > > >
> > > > > IgniteCache cache = ignite1.getOrCreateCache("
> > > > > testCache");
> > > > >
> > > > > Transaction tx = transactions.txStart(concurrency, isolation);
> > > > >
> > > > > cache.put("key1", 1);
> > > > >
> > > > > cache.put("key2", 2);
> > > > >
> > > > > tx.stop();
> > > > >
> > > > > IgniteInternalFuture fut = GridTestUtils.runAsync(() -> {
> > > > > IgniteTransactions ts = ignite(1).transactions();
> > > > > Assert.assertNull(ts.tx());
> > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state());
> > > > > ts.txStart(tx);
> > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state());
> > > > > cache.put("key3", 3);
> > > > > Assert.assertTrue(cache.remove("key2"));
> > > > > tx.commit();
> > > > > return true;
> > > > > });
> > > > >
> > > > > fut.get();
> > > > >
> > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state());
> > > > > Assert.assertEquals((long)1, (long)cache.get("key1"));
> > > > > Assert.assertEquals((long)3, (long)cache.get("key3"));
> > > > > Assert.assertFalse(cache.containsKey("key2"));
> > > > >
> > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread:
> > > > >
> > > > > public void txStart(Transaction tx) {
> > > > > TransactionProxyImpl transactionProxy =
> (TransactionProxyImpl)tx;
> > > > > cctx.tm().reopenTx(transactionProxy.tx());
> > > > > transactionProxy.bindToCurrentThread();
> > > > > }
> > > > >
> > > > > In method *reopenTx* we alter *threadMap* so that it binds
> > transaction
> > > > > to current thread.
> > > > >
> > > > > How do u think about it ?
> > > > >
> > > > >
> > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda :
> > > > >
> > > > > > Hi Alexey,
> > > > > >
> > > > > > Please share the rational behind this and the thoughts, design
> > ideas
> > > > you
> > > > > > have in mind.
> > > > > >
> > > > > > —
> > > > > > Denis
> > > > > >
> > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <
> > > > > alkuznetsov...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi all! Im designing distributed transaction which can be
> started
> > > at
> > > > > one
> > > > > > > node, and continued at other one. Has anybody thoughts on it ?
> > > > > > > --
> > > > > > >
> > > > > > > *Best Regards,*
> > > > > > >
> > > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
>

Re: general question

2017-03-10 Thread ALEKSEY KUZNETSOV

I've done it, but from time to time transaction doesn't roll back. Perhaps,
its a known bug

пт, 10 мар. 2017 г. в 9:31, Alexey Goncharuk :

> Hi Aleksey,
>
> In order to ensure that a transaction is rolled back during a node failure,
> you need to orchestrate messages in such a way that at least one
> participating node does not receive a prepare request. As an example, you
> can look
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCachePrimaryNodeFailureRecoveryAbstractTest.
>
> --AG
>
> 2017-03-09 20:09 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Hi all! Is it possible to test on multiple jvm's ? Let's say, to have
> > multiple ignite instances deployed on different jvms ? If yes, how can i
> > create them and address them in code ?
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

2017-03-10 Thread Andrey Gura

Aleksey,

Thanks for your contribution! I've merged this PR into master branch.
See JIRA issue comment for details.

On Fri, Mar 10, 2017 at 2:58 PM, Andrey Gura  wrote:
> Aleksey,
>
> I don't see any new changes. So I'll check TC and merge changes today.
>
> On Fri, Mar 10, 2017 at 10:20 AM, ALEKSEY KUZNETSOV
>  wrote:
>> Hi! Can u plz review ticket once more
>>
>> вт, 7 мар. 2017 г. в 18:52, Andrey Gura :
>>
>>> Aleksey, thanks a lot!
>>>
>>> Answered in JIRA ticket.
>>>
>>> On Tue, Mar 7, 2017 at 1:27 PM, ALEKSEY KUZNETSOV
>>>  wrote:
>>> > Hi! I have fixed all sources. Plz, review it again
>>> >
>>> > пн, 6 мар. 2017 г. в 15:43, Andrey Gura :
>>> >
>>> >> Aleksey, thanks!
>>> >>
>>> >> I answered in JIRA ticket.
>>> >>
>>> >> On Mon, Mar 6, 2017 at 10:56 AM, ALEKSEY KUZNETSOV
>>> >>  wrote:
>>> >> > I've fixed the comments.
>>> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>>> >> >
>>> >> > пт, 3 мар. 2017 г. в 19:23, Andrey Gura :
>>> >> >
>>> >> >> Aleksey,
>>> >> >>
>>> >> >> GitHub isn't official review tool in Apache Ignite community. There
>>> >> >> are two ways for code review: upsource and comments in JIRA tickets.
>>> >> >> So, I think, we should finish review of this ticket in upsource.
>>> >> >>
>>> >> >> On Thu, Mar 2, 2017 at 11:30 AM, ALEKSEY KUZNETSOV
>>> >> >>  wrote:
>>> >> >> > lets review code at github rather than upsource later on. Because,
>>> the
>>> >> >> > later is too slow and bring no substantial benefits compared github
>>> >> >> >
>>> >> >> > ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
>>> >> >> >
>>> >> >> >> Hi, Aleksey!
>>> >> >> >>
>>> >> >> >> Thank you for contribution!
>>> >> >> >>
>>> >> >> >> I've reviewed your changes and have some comments (mostly
>>> cosmetic).
>>> >> >> >> Could you please fix this comment? See review in Upsource for
>>> >> details.
>>> >> >> >>
>>> >> >> >> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
>>> >> >> >>  wrote:
>>> >> >> >> > Plz, review my PR :
>>> >> >> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>>> >> >> >> > or https://github.com/apache/ignite/pull/1545
>>> >> >> >> > --
>>> >> >> >> >
>>> >> >> >> > *Best Regards,*
>>> >> >> >> >
>>> >> >> >> > *Kuznetsov Aleksey*
>>> >> >> >>
>>> >> >> > --
>>> >> >> >
>>> >> >> > *Best Regards,*
>>> >> >> >
>>> >> >> > *Kuznetsov Aleksey*
>>> >> >>
>>> >> > --
>>> >> >
>>> >> > *Best Regards,*
>>> >> >
>>> >> > *Kuznetsov Aleksey*
>>> >>
>>> > --
>>> >
>>> > *Best Regards,*
>>> >
>>> > *Kuznetsov Aleksey*
>>>
>> --
>>
>> *Best Regards,*
>>
>> *Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

2017-03-10 Thread Alexey Goncharuk

Aleksey,

I think I am starting to get what you want, but I have a few concerns:
 - What is the API for the proposed change? In your test, you pass an
instance of transaction created on ignite(0) to the ignite instance
ignite(1). This is obviously not possible in a truly distributed
(multi-jvm) environment.
- How will you synchronize cache update actions and transaction commit?
Say, you have one node that decided to commit, but another node is still
writing within this transaction. How do you make sure that two nodes will
not call commit() and rollback() simultaneously?
 - How do you make sure that either commit() or rollback() is called if an
originator failed?

2017-03-10 15:38 GMT+03:00 Дмитрий Рябов :

> Alexey Goncharuk, heh, my initial understanding was that transferring of tx
> ownership from one node to another will be happened automatically when
> originating node is gone down.
>
> 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Im aiming to span transaction on multiple threads, nodes, jvms(soon). So
> > every node is able to rollback, or commit common transaction.It turned
> up i
> > need to transfer tx between nodes in order to commit transaction in
> > different node(in the same jvm).
> >
> > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Aleksey,
> > >
> > > Do you mean that you want a concept of transferring of tx ownership
> from
> > > one node to another? My initial understanding was that you want to be
> > able
> > > to update keys in a transaction from multiple threads in parallel.
> > >
> > > --AG
> > >
> > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Well. Consider transaction started in one node, and continued in
> > another
> > > > one.
> > > > The following test describes my idea:
> > > >
> > > > Ignite ignite1 = ignite(0);
> > > >
> > > > IgniteTransactions transactions = ignite1.transactions();
> > > >
> > > > IgniteCache cache = ignite1.getOrCreateCache("
> > > > testCache");
> > > >
> > > > Transaction tx = transactions.txStart(concurrency, isolation);
> > > >
> > > > cache.put("key1", 1);
> > > >
> > > > cache.put("key2", 2);
> > > >
> > > > tx.stop();
> > > >
> > > > IgniteInternalFuture fut = GridTestUtils.runAsync(() -> {
> > > > IgniteTransactions ts = ignite(1).transactions();
> > > > Assert.assertNull(ts.tx());
> > > > Assert.assertEquals(TransactionState.STOPPED, tx.state());
> > > > ts.txStart(tx);
> > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state());
> > > > cache.put("key3", 3);
> > > > Assert.assertTrue(cache.remove("key2"));
> > > > tx.commit();
> > > > return true;
> > > > });
> > > >
> > > > fut.get();
> > > >
> > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state());
> > > > Assert.assertEquals((long)1, (long)cache.get("key1"));
> > > > Assert.assertEquals((long)3, (long)cache.get("key3"));
> > > > Assert.assertFalse(cache.containsKey("key2"));
> > > >
> > > > In method *ts.txStart(...)* we just rebind *tx* to current thread:
> > > >
> > > > public void txStart(Transaction tx) {
> > > > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx;
> > > > cctx.tm().reopenTx(transactionProxy.tx());
> > > > transactionProxy.bindToCurrentThread();
> > > > }
> > > >
> > > > In method *reopenTx* we alter *threadMap* so that it binds
> transaction
> > > > to current thread.
> > > >
> > > > How do u think about it ?
> > > >
> > > >
> > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda :
> > > >
> > > > > Hi Alexey,
> > > > >
> > > > > Please share the rational behind this and the thoughts, design
> ideas
> > > you
> > > > > have in mind.
> > > > >
> > > > > —
> > > > > Denis
> > > > >
> > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hi all! Im designing distributed transaction which can be started
> > at
> > > > one
> > > > > > node, and continued at other one. Has anybody thoughts on it ?
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > >
> > > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>

[GitHub] ignite pull request #1611: Rebalancing optimizations.

2017-03-10 Thread ilantukh

GitHub user ilantukh opened a pull request:

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

Rebalancing optimizations.



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

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

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

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






---
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: distributed transaction of non-single coordinator

2017-03-10 Thread Дмитрий Рябов

Alexey Goncharuk, heh, my initial understanding was that transferring of tx
ownership from one node to another will be happened automatically when
originating node is gone down.

2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV :

> Im aiming to span transaction on multiple threads, nodes, jvms(soon). So
> every node is able to rollback, or commit common transaction.It turned up i
> need to transfer tx between nodes in order to commit transaction in
> different node(in the same jvm).
>
> пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk  >:
>
> > Aleksey,
> >
> > Do you mean that you want a concept of transferring of tx ownership from
> > one node to another? My initial understanding was that you want to be
> able
> > to update keys in a transaction from multiple threads in parallel.
> >
> > --AG
> >
> > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > Well. Consider transaction started in one node, and continued in
> another
> > > one.
> > > The following test describes my idea:
> > >
> > > Ignite ignite1 = ignite(0);
> > >
> > > IgniteTransactions transactions = ignite1.transactions();
> > >
> > > IgniteCache cache = ignite1.getOrCreateCache("
> > > testCache");
> > >
> > > Transaction tx = transactions.txStart(concurrency, isolation);
> > >
> > > cache.put("key1", 1);
> > >
> > > cache.put("key2", 2);
> > >
> > > tx.stop();
> > >
> > > IgniteInternalFuture fut = GridTestUtils.runAsync(() -> {
> > > IgniteTransactions ts = ignite(1).transactions();
> > > Assert.assertNull(ts.tx());
> > > Assert.assertEquals(TransactionState.STOPPED, tx.state());
> > > ts.txStart(tx);
> > > Assert.assertEquals(TransactionState.ACTIVE, tx.state());
> > > cache.put("key3", 3);
> > > Assert.assertTrue(cache.remove("key2"));
> > > tx.commit();
> > > return true;
> > > });
> > >
> > > fut.get();
> > >
> > > Assert.assertEquals(TransactionState.COMMITTED, tx.state());
> > > Assert.assertEquals((long)1, (long)cache.get("key1"));
> > > Assert.assertEquals((long)3, (long)cache.get("key3"));
> > > Assert.assertFalse(cache.containsKey("key2"));
> > >
> > > In method *ts.txStart(...)* we just rebind *tx* to current thread:
> > >
> > > public void txStart(Transaction tx) {
> > > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx;
> > > cctx.tm().reopenTx(transactionProxy.tx());
> > > transactionProxy.bindToCurrentThread();
> > > }
> > >
> > > In method *reopenTx* we alter *threadMap* so that it binds transaction
> > > to current thread.
> > >
> > > How do u think about it ?
> > >
> > >
> > > вт, 7 мар. 2017 г. в 22:38, Denis Magda :
> > >
> > > > Hi Alexey,
> > > >
> > > > Please share the rational behind this and the thoughts, design ideas
> > you
> > > > have in mind.
> > > >
> > > > —
> > > > Denis
> > > >
> > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hi all! Im designing distributed transaction which can be started
> at
> > > one
> > > > > node, and continued at other one. Has anybody thoughts on it ?
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > >
> > > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[jira] [Created] (IGNITE-4814) GridQueryProcessor: improve type registration logic

2017-03-10 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-4814:
---

 Summary: GridQueryProcessor: improve type registration logic
 Key: IGNITE-4814
 URL: https://issues.apache.org/jira/browse/IGNITE-4814
 Project: Ignite
  Issue Type: Task
Reporter: Vladimir Ozerov


Currently registration of every type causes {{GridQueryIndexing}} state change 
which is not cleaned up properly in case of exception.

Need to rework initialization routine to make sure that state is always clean 
and consistent.



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

Re: distributed transaction of non-single coordinator

2017-03-10 Thread ALEKSEY KUZNETSOV

Im aiming to span transaction on multiple threads, nodes, jvms(soon). So
every node is able to rollback, or commit common transaction.It turned up i
need to transfer tx between nodes in order to commit transaction in
different node(in the same jvm).

пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk :

> Aleksey,
>
> Do you mean that you want a concept of transferring of tx ownership from
> one node to another? My initial understanding was that you want to be able
> to update keys in a transaction from multiple threads in parallel.
>
> --AG
>
> 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Well. Consider transaction started in one node, and continued in another
> > one.
> > The following test describes my idea:
> >
> > Ignite ignite1 = ignite(0);
> >
> > IgniteTransactions transactions = ignite1.transactions();
> >
> > IgniteCache cache = ignite1.getOrCreateCache("
> > testCache");
> >
> > Transaction tx = transactions.txStart(concurrency, isolation);
> >
> > cache.put("key1", 1);
> >
> > cache.put("key2", 2);
> >
> > tx.stop();
> >
> > IgniteInternalFuture fut = GridTestUtils.runAsync(() -> {
> > IgniteTransactions ts = ignite(1).transactions();
> > Assert.assertNull(ts.tx());
> > Assert.assertEquals(TransactionState.STOPPED, tx.state());
> > ts.txStart(tx);
> > Assert.assertEquals(TransactionState.ACTIVE, tx.state());
> > cache.put("key3", 3);
> > Assert.assertTrue(cache.remove("key2"));
> > tx.commit();
> > return true;
> > });
> >
> > fut.get();
> >
> > Assert.assertEquals(TransactionState.COMMITTED, tx.state());
> > Assert.assertEquals((long)1, (long)cache.get("key1"));
> > Assert.assertEquals((long)3, (long)cache.get("key3"));
> > Assert.assertFalse(cache.containsKey("key2"));
> >
> > In method *ts.txStart(...)* we just rebind *tx* to current thread:
> >
> > public void txStart(Transaction tx) {
> > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx;
> > cctx.tm().reopenTx(transactionProxy.tx());
> > transactionProxy.bindToCurrentThread();
> > }
> >
> > In method *reopenTx* we alter *threadMap* so that it binds transaction
> > to current thread.
> >
> > How do u think about it ?
> >
> >
> > вт, 7 мар. 2017 г. в 22:38, Denis Magda :
> >
> > > Hi Alexey,
> > >
> > > Please share the rational behind this and the thoughts, design ideas
> you
> > > have in mind.
> > >
> > > —
> > > Denis
> > >
> > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com>
> > > wrote:
> > > >
> > > > Hi all! Im designing distributed transaction which can be started at
> > one
> > > > node, and continued at other one. Has anybody thoughts on it ?
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > >
> > > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

2017-03-10 Thread Alexey Goncharuk

Aleksey,

Do you mean that you want a concept of transferring of tx ownership from
one node to another? My initial understanding was that you want to be able
to update keys in a transaction from multiple threads in parallel.

--AG

2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV :

> Well. Consider transaction started in one node, and continued in another
> one.
> The following test describes my idea:
>
> Ignite ignite1 = ignite(0);
>
> IgniteTransactions transactions = ignite1.transactions();
>
> IgniteCache cache = ignite1.getOrCreateCache("
> testCache");
>
> Transaction tx = transactions.txStart(concurrency, isolation);
>
> cache.put("key1", 1);
>
> cache.put("key2", 2);
>
> tx.stop();
>
> IgniteInternalFuture fut = GridTestUtils.runAsync(() -> {
> IgniteTransactions ts = ignite(1).transactions();
> Assert.assertNull(ts.tx());
> Assert.assertEquals(TransactionState.STOPPED, tx.state());
> ts.txStart(tx);
> Assert.assertEquals(TransactionState.ACTIVE, tx.state());
> cache.put("key3", 3);
> Assert.assertTrue(cache.remove("key2"));
> tx.commit();
> return true;
> });
>
> fut.get();
>
> Assert.assertEquals(TransactionState.COMMITTED, tx.state());
> Assert.assertEquals((long)1, (long)cache.get("key1"));
> Assert.assertEquals((long)3, (long)cache.get("key3"));
> Assert.assertFalse(cache.containsKey("key2"));
>
> In method *ts.txStart(...)* we just rebind *tx* to current thread:
>
> public void txStart(Transaction tx) {
> TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx;
> cctx.tm().reopenTx(transactionProxy.tx());
> transactionProxy.bindToCurrentThread();
> }
>
> In method *reopenTx* we alter *threadMap* so that it binds transaction
> to current thread.
>
> How do u think about it ?
>
>
> вт, 7 мар. 2017 г. в 22:38, Denis Magda :
>
> > Hi Alexey,
> >
> > Please share the rational behind this and the thoughts, design ideas you
> > have in mind.
> >
> > —
> > Denis
> >
> > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> > wrote:
> > >
> > > Hi all! Im designing distributed transaction which can be started at
> one
> > > node, and continued at other one. Has anybody thoughts on it ?
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> >
> > --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

2017-03-10 Thread Alexey Goncharuk

Alexey,

Looks good. I've left my comments in the PR, please address them and I will
merge it.

2017-03-10 10:24 GMT+03:00 ALEKSEY KUZNETSOV :

> plz review ticket again
>
> чт, 9 мар. 2017 г. в 10:28, ALEKSEY KUZNETSOV :
>
> > plz review ticket again
> >
> > вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> >
> > plz review ticket again
> >
> > пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > Thanks, Aleksey,
> >
> > I will take a look this week.
> >
> > --AG
> >
> > 2017-02-20 10:25 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > Hi! Review my PR again, plz - https://github.com/apache/
> ignite/pull/1517
> > >
> > > пт, 17 февр. 2017 г. в 14:44, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > >
> > > > thanx! my next PR review will be in up source
> > > >
> > > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > >
> > > > Aleksey,
> > > >
> > > > I added a comment on GitHub, however, the community is moving towards
> > the
> > > > UpSource review tool, so I suggest you open a PR review in Ignite
> > > UpSource:
> > > > http://reviews.ignite.apache.org/ignite/
> > > >
> > > > After you've registered, you should be able to open a review.
> > > >
> > > > --AG
> > > >
> > > > 2017-02-17 11:13 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > Again, plz, review my PR :
> > https://github.com/apache/ignite/pull/1517
> > > > >
> > > > > https://issues.apache.org/jira/browse/IGNITE-1178
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[GitHub] ignite pull request #1610: Ignite 4813

2017-03-10 Thread iveselovskiy

GitHub user iveselovskiy opened a pull request:

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

Ignite 4813



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

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

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

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


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

commit 38cb67d45eb91e20ad4b92a490747534f5e8febb
Author: Pavel Tupitsyn 
Date:   2017-01-20T13:09:57Z

Merge branch 'master' into ignite-2.0

commit 82857d0cb6e2984a5359b822a9c903874414aa67
Author: Pavel Tupitsyn 
Date:   2017-01-23T10:12:12Z

Merge branch

Re: distributed transaction of non-single coordinator

2017-03-10 Thread ALEKSEY KUZNETSOV

Well. Consider transaction started in one node, and continued in another
one.
The following test describes my idea:

Ignite ignite1 = ignite(0);

IgniteTransactions transactions = ignite1.transactions();

IgniteCache cache = ignite1.getOrCreateCache("testCache");

Transaction tx = transactions.txStart(concurrency, isolation);

cache.put("key1", 1);

cache.put("key2", 2);

tx.stop();

IgniteInternalFuture fut = GridTestUtils.runAsync(() -> {
IgniteTransactions ts = ignite(1).transactions();
Assert.assertNull(ts.tx());
Assert.assertEquals(TransactionState.STOPPED, tx.state());
ts.txStart(tx);
Assert.assertEquals(TransactionState.ACTIVE, tx.state());
cache.put("key3", 3);
Assert.assertTrue(cache.remove("key2"));
tx.commit();
return true;
});

fut.get();

Assert.assertEquals(TransactionState.COMMITTED, tx.state());
Assert.assertEquals((long)1, (long)cache.get("key1"));
Assert.assertEquals((long)3, (long)cache.get("key3"));
Assert.assertFalse(cache.containsKey("key2"));

In method *ts.txStart(...)* we just rebind *tx* to current thread:

public void txStart(Transaction tx) {
TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx;
cctx.tm().reopenTx(transactionProxy.tx());
transactionProxy.bindToCurrentThread();
}

In method *reopenTx* we alter *threadMap* so that it binds transaction
to current thread.

How do u think about it ?


вт, 7 мар. 2017 г. в 22:38, Denis Magda :

> Hi Alexey,
>
> Please share the rational behind this and the thoughts, design ideas you
> have in mind.
>
> —
> Denis
>
> > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > Hi all! Im designing distributed transaction which can be started at one
> > node, and continued at other one. Has anybody thoughts on it ?
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
> --

*Best Regards,*

*Kuznetsov Aleksey*

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

2017-03-10 Thread Andrey Gura

Aleksey,

I don't see any new changes. So I'll check TC and merge changes today.

On Fri, Mar 10, 2017 at 10:20 AM, ALEKSEY KUZNETSOV
 wrote:
> Hi! Can u plz review ticket once more
>
> вт, 7 мар. 2017 г. в 18:52, Andrey Gura :
>
>> Aleksey, thanks a lot!
>>
>> Answered in JIRA ticket.
>>
>> On Tue, Mar 7, 2017 at 1:27 PM, ALEKSEY KUZNETSOV
>>  wrote:
>> > Hi! I have fixed all sources. Plz, review it again
>> >
>> > пн, 6 мар. 2017 г. в 15:43, Andrey Gura :
>> >
>> >> Aleksey, thanks!
>> >>
>> >> I answered in JIRA ticket.
>> >>
>> >> On Mon, Mar 6, 2017 at 10:56 AM, ALEKSEY KUZNETSOV
>> >>  wrote:
>> >> > I've fixed the comments.
>> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>> >> >
>> >> > пт, 3 мар. 2017 г. в 19:23, Andrey Gura :
>> >> >
>> >> >> Aleksey,
>> >> >>
>> >> >> GitHub isn't official review tool in Apache Ignite community. There
>> >> >> are two ways for code review: upsource and comments in JIRA tickets.
>> >> >> So, I think, we should finish review of this ticket in upsource.
>> >> >>
>> >> >> On Thu, Mar 2, 2017 at 11:30 AM, ALEKSEY KUZNETSOV
>> >> >>  wrote:
>> >> >> > lets review code at github rather than upsource later on. Because,
>> the
>> >> >> > later is too slow and bring no substantial benefits compared github
>> >> >> >
>> >> >> > ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
>> >> >> >
>> >> >> >> Hi, Aleksey!
>> >> >> >>
>> >> >> >> Thank you for contribution!
>> >> >> >>
>> >> >> >> I've reviewed your changes and have some comments (mostly
>> cosmetic).
>> >> >> >> Could you please fix this comment? See review in Upsource for
>> >> details.
>> >> >> >>
>> >> >> >> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
>> >> >> >>  wrote:
>> >> >> >> > Plz, review my PR :
>> >> >> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>> >> >> >> > or https://github.com/apache/ignite/pull/1545
>> >> >> >> > --
>> >> >> >> >
>> >> >> >> > *Best Regards,*
>> >> >> >> >
>> >> >> >> > *Kuznetsov Aleksey*
>> >> >> >>
>> >> >> > --
>> >> >> >
>> >> >> > *Best Regards,*
>> >> >> >
>> >> >> > *Kuznetsov Aleksey*
>> >> >>
>> >> > --
>> >> >
>> >> > *Best Regards,*
>> >> >
>> >> > *Kuznetsov Aleksey*
>> >>
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*

Re: IGNITE-13 (ready for review)

2017-03-10 Thread Вадим Опольский

Hi Valentin,

I cant find out why it's better on long string, but worse on a short
string. May be it needs to use special tools like such as oracle solaris
studio performance analyzer or other.

I've added links to the benchmark, unit test and results to the ticket and
switched status to patch available.

Vadim Opolski



2017-03-09 13:57 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Hi Vadim,
>
> Results are a bit confusing. Any idea why it's better on long string, but
> worse on a short string? If that's actually the case, there is no any
> reason to make the change and I would just close the ticket.
>
> -Val
>
> On Thu, Mar 9, 2017 at 9:20 AM, Вадим Опольский 
> wrote:
>
>> Hello everyone!
>>
>> Colleagues, take a look please at the results of measuring.
>>
>> Can I close this ticket ?
>>
>> Should I add JMH benchmark and unit test to Ignite project ?
>>
>> Results of measuring
>> https://github.com/javaller/mybenchmark/blob/master/out.txt
>>
>> Benchmark
>> https://github.com/javaller/mybenchmark/blob/master/src/main
>> /java/org/sample/ExampleTest.java
>>
>> UTest
>> https://github.com/javaller/mybenchmark/blob/master/src/main
>> /java/org/sample/BinaryMarshallerSelfTest.java
>>
>> *results of measuring*
>> Benchmark
>> (message)  Mode  Cnt
>> Score   Error  Units
>> LatchBenchmark.binaryHeapOutputStreamDirect
>> TestTestTestTestTestTestTestTestTest  avgt   50  128,036 ± 4,360  ns/op
>> LatchBenchmark.binaryHeapOutputStreamDirect
>> TestTestTestavgt   5044,934 ± 1,463  ns/op
>> LatchBenchmark.binaryHeapOutputStreamDirect
>> Test  avgt   5021,254 ± 0,776  ns/op
>> LatchBenchmark.binaryHeapOutputStreamInDirect
>> TestTestTestTestTestTestTestTestTest avgt   5083,262 ± 2,264  ns/op
>> LatchBenchmark.binaryHeapOutputStreamInDirect
>> TestTestTest   avgt   5058,975 ± 1,559  ns/op
>> LatchBenchmark.binaryHeapOutputStreamInDirect
>> Test avgt   5048,506 ± 1,116  ns/op
>>
>>
>> Vadim
>>
>> 2017-03-06 19:42 GMT+03:00 Вадим Опольский :
>>
>>> Hello, everybody!
>>>
>>> Valentin, I've corrected benchmark and received the results:
>>>
>>> Benchmark
>>> (message)  Mode  Cnt
>>> Score   Error  Units
>>> LatchBenchmark.binaryHeapOutputStreamDirect
>>> TestTestTestTestTestTestTestTestTest  avgt   50  128,036 ± 4,360  ns/op
>>> LatchBenchmark.binaryHeapOutputStreamDirect
>>> TestTestTestavgt   5044,934 ± 1,463  ns/op
>>> LatchBenchmark.binaryHeapOutputStreamDirect
>>> Test  avgt   5021,254 ± 0,776  ns/op
>>> LatchBenchmark.binaryHeapOutputStreamInDirect
>>> TestTestTestTestTestTestTestTestTest avgt   5083,262 ± 2,264  ns/op
>>> LatchBenchmark.binaryHeapOutputStreamInDirect
>>> TestTestTest   avgt   5058,975 ± 1,559  ns/op
>>> LatchBenchmark.binaryHeapOutputStreamInDirect
>>> Test avgt   5048,506 ± 1,116  ns/op
>>>
>>> https://github.com/javaller/MyBenchmark/blob/master/out_06_03_17_2.txt
>>>
>>> Whats the next step ?
>>>
>>>  Do I have to add benchmark to Ignite project ?
>>>
>>> Vadim Opolskiy
>>>
>>> 2017-03-03 21:11 GMT+03:00 Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com>:
>>>
 Hi Vadim,

 What do you mean by "copied benchmarks"? What changed singe previous
 iteration and why results are so different?

 As for duplicated loop, you don't need it. BinaryOutputStream allows to
 write a value to a particular position (even before already written data).
 So you can reserve 4 bytes for length, remember position, calculate length
 while encoding and writing bytes, and then write length.

 -Val

 On Fri, Mar 3, 2017 at 12:45 AM, Вадим Опольский 
 wrote:

> Valentin,
>
> What do you think about duplicated cycle in strToBinaryOutputStream ?
>
> How to calculate StrLen для outBinaryHeap without this cycle ?
>
> public class BinaryUtilsNew extends BinaryUtils {
>
> public static int getStrLen(String val) {
> int strLen = val.length();
> int utfLen = 0;
> int c;
>
> // Determine length of resulting byte array.
>
>
>
>
> *for (int cnt = 0; cnt < strLen; cnt++) {c = val.charAt(cnt); 
>if (c >= 0x0001 && c <= 0x007F)*utfLen++;
>* else if (c > 0x07FF)*
> utfLen += 3;
> else
> utfLen += 2;
> }
>
> return utfLen;
> }
>
> public static void strToUtf8BytesDirect(BinaryOutputStream 
> outBinaryHeap, String val) {
>
> int strLen = val.length();
> int c, cnt;
>
> int position =

[jira] [Created] (IGNITE-4813) Ignite map-reduce engine should set MRJobConfig.TASK_ATTEMPT_ID

2017-03-10 Thread Ivan Veselovsky (JIRA)

Ivan Veselovsky created IGNITE-4813:
---

 Summary: Ignite map-reduce engine should set 
MRJobConfig.TASK_ATTEMPT_ID
 Key: IGNITE-4813
 URL: https://issues.apache.org/jira/browse/IGNITE-4813
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 1.8
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
 Fix For: 2.0


Hadoop "join" example fails on Ignite with the error like this:

{code}
 Out: class org.apache.ignite.IgniteCheckedException: class 
org.apache.ignite.IgniteCheckedException: null
[14:27:29,636][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.impl.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:102)
[14:27:29,636][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.impl.v2.HadoopV2Task.run(HadoopV2Task.java:55)
[14:27:29,636][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.impl.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:266)
[14:27:29,636][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:209)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.impl.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:573)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[14:27:29,637][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
java.lang.Thread.run(Thread.java:745)
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out: Caused by: 
java.lang.NullPointerException
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl.(TaskAttemptContextImpl.java:49)
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.hadoop.mapreduce.lib.join.Parser$WNode.createRecordReader(Parser.java:348)
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.hadoop.mapreduce.lib.join.Parser$CNode.createRecordReader(Parser.java:486)
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.hadoop.mapreduce.lib.join.CompositeInputFormat.createRecordReader(CompositeInputFormat.java:143)
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   at 
org.apache.ignite.internal.processors.hadoop.impl.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:69)
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out:   ... 12 more
[14:27:29,638][INFO ][Thread-3][jvm-a6fc1c46] PID-31907  Out: 
{code}

This is because 
org.apache.ignite.internal.processors.hadoop.impl.v2.HadoopV2Context sets the 
job id and task id, but does not set task attempt id. In Hadoop this is done in 
method org.apache.hadoop.mapred.Task#localizeConfiguration .



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

[GitHub] ignite pull request #1609: Ignite 2.0 merge

2017-03-10 Thread devozerov

GitHub user devozerov opened a pull request:

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

Ignite 2.0 merge



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

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

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

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






---
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 #1608: ignite-4806 Fix infinite classloading discovery

2017-03-10 Thread zstan

GitHub user zstan opened a pull request:

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

ignite-4806 Fix infinite classloading discovery



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

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

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

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


commit da25c515ba2f30f0af663ecc46673982f101be53
Author: Evgeny Stanilovskiy 
Date:   2017-03-09T13:54:02Z

ignite-4806 Fix infinite classloading discovery




---
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: The difference between ignite instances with different startup type

2017-03-10 Thread Valentin Kulichenko

Hi,

Please show your configuration and the code.

-Val

On Fri, Mar 10, 2017 at 4:22 AM, 下奈若 <969959...@qq.com> wrote:

> Hi ,
>   I am accessing to Big Data field recently and I find Apache Ignite
> is a multipurpose tool that would be useful for me.
>   But I meet a problem while I run a demo code in Eclipse, I describe
> it  by steps as below :
>
>   STEP 1) I run %IGNITE_HOME%/bin/Iginte.bat with default config-file
> in windows(hostname=host1) and the Ignite node start normal(named it as
> instance1) :
>
>
> STEP 2) I start a new Ignite instance(named it as instance2) by java
> code in Eclipse in another windows(hostname=host2) :
>
>
>
>  STEP 3) In same Eclipse environment I start another Ignite instance(named
> it as instance3 in host2) for sending massage:
>
>
> RESULT:
> The instance2(instance started first in eclipse in host2) console
> shows the message "Hello Everyone!" which sended by instance3;
> The instance3(sending message instance in host2) console shows the
> message "Hello Everyone!";
>
> The instance1(in host1) shows nothing in bat window(this
> is why I send this email )
>
>
>
> Hoping for your response!
>
>   Thanks!
>
>

Re: IgniteConfiguration.gridName is very confusing

2017-03-10 Thread Alexander Fedotov

Hi,
PR updated. Currently no conflicts at
https://github.com/apache/ignite/pull/1435.

On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
alexander.fedot...@gmail.com> wrote:

> Sure. Will take a look.
>
> On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov  wrote:
>
>> Alexander,
>>
>> Page https://github.com/apache/ignite/pull/1435 reports several
>> conflicts.
>> Can you please check and resolve if necessary. Then resubmit for review
>> again.
>>
>> --Yakov
>>
>> 2017-03-03 13:24 GMT+03:00 Alexander Fedotov <
>> alexander.fedot...@gmail.com>:
>>
>> > Hi, it's ready for review
>> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>> >
>> > On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov 
>> > wrote:
>> >
>> > > Guys, I want to bring this up. What is the status of this ticket and
>> > > further steps?
>> > >
>> > > --Yakov
>> > >
>> > > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
>> > alexander.fedot...@gmail.com
>> > > >:
>> > >
>> > > > Done. But it looks like something went wrong since Upsource reports:
>> > > > "Review has too many files (1244), aborting".
>> > > >
>> > > > Also guys, I believe we need to merge this change in short time
>> because
>> > > > it's targeted for 2.0 and chances for a conflict are high.
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Jan 30, 2017 at 4:16 PM, Pavel Tupitsyn <
>> ptupit...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > Alexander,
>> > > > >
>> > > > > Please name the review appropriately and link it in the ticket as
>> > > > > described:
>> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+
>> > > > > to+Contribute#HowtoContribute-ReviewWithUpsource
>> > > > >
>> > > > > Thanks,
>> > > > > Pavel
>> > > > >
>> > > > > On Mon, Jan 30, 2017 at 4:00 PM, Alexander Fedotov <
>> > > > > alexander.fedot...@gmail.com> wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > Created Upsource review for the subject:
>> > > > > > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-81
>> > > > > >
>> > > > > > On Thu, Jan 19, 2017 at 7:59 PM, Alexander Fedotov <
>> > > > > > alexander.fedot...@gmail.com> wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I've completed working on IGNITE-3207
>> > > > > > > https://issues.apache.org/jira/browse/IGNITE-3207
>> > > > > > >
>> > > > > > > Looks like TC test results don't have problems related to my
>> > > changes
>> > > > > > > http://ci.ignite.apache.org/viewLog.html?buildId=423955;
>> > > > > > > tab=buildResultsDiv=IgniteTests_RunAll
>> > > > > > >
>> > > > > > > Kindly take a look at PR https://github.com/apache/
>> > > ignite/pull/1435/
>> > > > > > >
>> > > > > > > On Thu, Jan 12, 2017 at 1:16 AM, Denis Magda <
>> dma...@apache.org>
>> > > > > wrote:
>> > > > > > >
>> > > > > > >> Support Pavel’s point of view.
>> > > > > > >>
>> > > > > > >> Also Alexander please make sure that your changes are merged
>> > into
>> > > > > > >> ignite-2.0 branch rather than to the master. I think this
>> > > > > functionality
>> > > > > > >> has to be available in 2.0 first. Finally, please update 2.0
>> > > > Migration
>> > > > > > >> Guide once you’ve finished with this task:
>> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+
>> > > > > > >> Ignite+2.0+Migration+Guide > > > > > > >> luence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
>> > > > > > >>
>> > > > > > >> —
>> > > > > > >> Denis
>> > > > > > >>
>> > > > > > >> > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <
>> > > ptupit...@apache.org
>> > > > >
>> > > > > > >> wrote:
>> > > > > > >> >
>> > > > > > >> > I think we should fix log output as well and replace all
>> > "grid"
>> > > > > > >> occurences
>> > > > > > >> > with "instance".
>> > > > > > >> >
>> > > > > > >> > On Tue, Jan 10, 2017 at 12:55 PM, Alexander Fedotov <
>> > > > > > >> > alexander.fedot...@gmail.com> wrote:
>> > > > > > >> >
>> > > > > > >> >> Hi,
>> > > > > > >> >>
>> > > > > > >> >> I think we should leave null as a default value for
>> unnamed
>> > > > Ignite
>> > > > > > >> >> instances. At least that change should be considered out
>> of
>> > the
>> > > > > > current
>> > > > > > >> >> scope.
>> > > > > > >> >>
>> > > > > > >> >> What about naming, I'm also renaming log occurrences of
>> > "grid"
>> > > > and
>> > > > > > >> "grid
>> > > > > > >> >> name" where it stands reasonable.
>> > > > > > >> >> Are there places in the logging logic where we should
>> prefer
>> > > name
>> > > > > > >> "grid" or
>> > > > > > >> >> "grid name" instead of "Ignite instance name" or "Ignite
>> > > instance
>> > > > > > >> name" can
>> > > > > > >> >> be used without any semantic impact?
>> > > > > > >> >>
>> > > > > > >> >> On Sat, Dec 31, 2016 at 11:23 AM, Alexander Fedotov <
>> > > > > > >> >> alexander.fedot...@gmail.com> wrote:
>> > > > > > >> >>
>> > > > > > >> >>> Okay. From the all said above I suppose "instanceName"
>> > should
>> > > > work
>> > > > > > for
>> > > >

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

2017-03-10 Thread Andrey Gura

Maxim,

I'll take a look today.

10 марта 2017 г. 11:06 AM пользователь "Kozlov Maxim" 
написал:

> Andrey, Alexey, please review
> PR - https://github.com/apache/ignite/pull/1521 <
> https://github.com/apache/ignite/pull/1521>
> tests - http://ci.ignite.apache.org/viewType.html?buildTypeId=
> IgniteTests_RunAll_IgniteTests=pull%2F1521%
> 2Fhead=buildTypeStatusDiv  viewType.html?buildTypeId=IgniteTests_RunAll_
> IgniteTests=pull/1521/head=buildTypeStatusDiv>
>
> > 7 марта 2017 г., в 14:15, Andrey Gura  написал(а):
> >
> > Maxim,
> >
> > all GridClockSyncProcessor related code should be remove (objects,
> > messages, etc)
> >
> > On Tue, Mar 7, 2017 at 12:23 PM, Kozlov Maxim 
> wrote:
> >> Andrey, or better remove GridTimeSyncProcessorSelfTest class?
> >>
> >>> 7 марта 2017 г., в 12:21, Kozlov Maxim 
> написал(а):
> >>>
> >>> Andrey, in GridTimeSyncProcessorSelfTest class methods: testTimeSync()
> and testTimeSyncChangeCoordinator() also removed?
> >>>
> >>>
>  6 марта 2017 г., в 18:42, Andrey Gura  написал(а):
> 
>  Maxim,
> 
>  About SER_VER_COMPARATOR. You can use code branch that executes when
>  times are equal:
> 
>  int nodeOrder1 = ver1.nodeOrder();
>  int nodeOrder2 = ver2.nodeOrder();
> 
>  if (nodeOrder1 == nodeOrder2) {
>   long order1 = ver1.order();
>   long order2 = ver2.order();
> 
>   assert order1 != order2;
> 
>   return order1 > order2 ? 1 : -1;
>  }
>  else
>   return nodeOrder1 > nodeOrder2 ? 1 : -1;
> 
>  On Mon, Mar 6, 2017 at 6:32 PM, Alexey Goncharuk
>   wrote:
> > Maxim,
> >
> > Global time comparison is only needed for CLOCK mode, so you should
> modify
> > the code as if ignoreTime is always true.
> >
> > 2017-03-06 18:13 GMT+03:00 Kozlov Maxim :
> >
> >> ok,
> >> in GridCacheAtomicVersionComparator class, method
> >> compare(GridCacheVersion one, GridCacheVersion other, boolean
> ignoreTime)
> >> if (globalTime == otherGlobalTime || ignoreTime) {  // => if
> (ignoreTime) {
> >> .
> >> }
> >> else
> >>  return globalTime > otherGlobalTime ? 1 : -1;   // => return -1;
> >>
> >> and,
> >> GridCacheMvcc class,
> >> SER_VER_COMPARATOR is comparator by globalTime var. His remove and
> remove
> >> compareSerializableVersion?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> 6 марта 2017 г., в 16:51, Andrey Gura 
> написал(а):
> >>>
> >>> Maxim,
> >>>
> >>> updateTime() method should be removed.
> >>>
> >>> On Mon, Mar 6, 2017 at 12:12 PM, Kozlov Maxim <
> dreamx@gmail.com>
> >> wrote:
>  In CacheEntryImplEx class use ver.globalTime() in
> 
>  @Override public long updateTime() {
>  return ver.globalTime();
>  }
> 
>  Than is better to replace this variable?
> 
> 
> > 3 марта 2017 г., в 19:19, Andrey Gura 
> написал(а):
> >
> > Maxim,
> >
> > I think the next implementation will be good enough:
> >
> > public IgniteUuid asGridUuid() {
> > return new IgniteUuid(new UUID(nodeOrderDrId, topVer), order);
> > }
> >
> >
> > Serialization/deserialization of GridCacheVersion.globalTime
> field
> > should be removed.
> >
> > On Fri, Mar 3, 2017 at 5:57 PM, Kozlov Maxim <
> dreamx@gmail.com>
> >> wrote:
> >> Alexey,
> >>
> >> public IgniteUuid asGridUuid() {
> >> return new IgniteUuid(new UUID(nodeOrderDrId << 32, topVer <<
> 32),
> >> order);
> >> }
> >>
> >> So you want to change or not?
> >>
> >> And
> >> - GridCacheVersion.writeTo(ByteBuffer buf, MessageWriter
> writer)
> >> - GridCacheVersion.readFrom(ByteBuffer buf, MessageReader
> reader)
> >>
> >> use globalTime variable, must be removed case 0: (in both
> methods) or
> >> replace globalTime?
> >>
> >>
> >>
> >>> 2 марта 2017 г., в 16:58, Andrey Gura 
> написал(а):
> >>>
> >>> +1
> >>>
> >>> Removing of asGridUuid() method can lead to much code changes
> but it
> >>> should be avoided on this step.
> >>>
> >>> On Thu, Mar 2, 2017 at 4:56 PM, Alexey Goncharuk
> >>>  wrote:
>  Maxim,
> 
>  I see several usages of asGridUuid() method, so I would just
> remove
> >> global
>  time and use nodeOrderDrId and topVer as different parts of
> high
> >> and low
>  parts of the embedded UUID.
>

[jira] [Created] (IGNITE-4811) Reduce GC pressure using page memory

2017-03-10 Thread Igor Seliverstov (JIRA)

Igor Seliverstov created IGNITE-4811:


 Summary: Reduce GC pressure using page memory
 Key: IGNITE-4811
 URL: https://issues.apache.org/jira/browse/IGNITE-4811
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov
 Fix For: 2.0






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

40 matches

Mail list logo