Re: Ensure that builder approach is used for all setters in public API

2017-02-02 Thread Valentin Kulichenko 
My only concern is MBean interfaces. These are not called from code, but
from MBean viewers, and I'm not sure setters not returning voids will be
properly treated as setters by these viewers. This needs to be checked.

-Val

On Thu, Feb 2, 2017 at 8:32 PM, Andrey Mashenkov  wrote:

> Val,
>
> Yes, you are right. I don't think we should care about compilation
> error on user side, as we break compatibility with previous versions.
> But we talk about public interfaces and may be someone has some cons
> or suggestions?
>
> On Fri, Feb 3, 2017 at 5:31 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Andrey,
> >
> > In which case compatibility is broken? If there is a method that returns
> > void and you change it to return some type, it doesn't break anything,
> > because currently nobody can assign the result of this method to a
> > variable. I.e. in old code the returned value will be always ignored,
> > therefore it can be of any type.
> >
> > Is there anything else that I'm missing?
> >
> > -Val
> >
> > On Thu, Feb 2, 2017 at 3:49 AM, Andrey Mashenkov <
> > andrey.mashen...@gmail.com
> > > wrote:
> >
> > > Hi Igniters,
> > >
> > >
> > > I'm working on IGNITE-4564 [1] to make our configuration classes and
> SPI
> > > classes more convenient.
> > >
> > > There is no problem to change return type in setter method signatures
> > > and override methods in child child classes to make them return more
> > > accurate type.
> > >
> > > But, I found that we have set methods in some of our interfaces and
> > > changing its signature may broke compatibility with user
> implementations.
> > >
> > > Here are example interfaces with setters:
> > > org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean
> > > org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyM
> > XBean
> > > org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean
> > > org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean
> > > org.apache.ignite.spi.checkpoint.CheckpointSpi
> > > org.apache.ignite.spi.collision.CollisionSpi
> > > org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean
> > >
> > > However we have interfaces with NO setters
> > > org.apache.ignite.spi.loadbalancing.adaptive.
> > > AdaptiveLoadBalancingSpiMBean.
> > >
> > > What can we do with it?
> > > Change signature of setters without regarding compatibility? Or may be
> it
> > > is possible to remove setters from some interfaces?
> > >
> > > Thought?
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-4564
> > >
> >
>
>
>
> --
> С уважением,
> Машенков Андрей Владимирович
> Тел. +7-921-932-61-82
>
> Best regards,
> Andrey V. Mashenkov
> Cerr: +7-921-932-61-82
>

Re: Ensure that builder approach is used for all setters in public API

2017-02-02 Thread Andrey Mashenkov 
Val,

Yes, you are right. I don't think we should care about compilation
error on user side, as we break compatibility with previous versions.
But we talk about public interfaces and may be someone has some cons
or suggestions?

On Fri, Feb 3, 2017 at 5:31 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Andrey,
>
> In which case compatibility is broken? If there is a method that returns
> void and you change it to return some type, it doesn't break anything,
> because currently nobody can assign the result of this method to a
> variable. I.e. in old code the returned value will be always ignored,
> therefore it can be of any type.
>
> Is there anything else that I'm missing?
>
> -Val
>
> On Thu, Feb 2, 2017 at 3:49 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > wrote:
>
> > Hi Igniters,
> >
> >
> > I'm working on IGNITE-4564 [1] to make our configuration classes and SPI
> > classes more convenient.
> >
> > There is no problem to change return type in setter method signatures
> > and override methods in child child classes to make them return more
> > accurate type.
> >
> > But, I found that we have set methods in some of our interfaces and
> > changing its signature may broke compatibility with user implementations.
> >
> > Here are example interfaces with setters:
> > org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean
> > org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyM
> XBean
> > org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean
> > org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean
> > org.apache.ignite.spi.checkpoint.CheckpointSpi
> > org.apache.ignite.spi.collision.CollisionSpi
> > org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean
> >
> > However we have interfaces with NO setters
> > org.apache.ignite.spi.loadbalancing.adaptive.
> > AdaptiveLoadBalancingSpiMBean.
> >
> > What can we do with it?
> > Change signature of setters without regarding compatibility? Or may be it
> > is possible to remove setters from some interfaces?
> >
> > Thought?
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-4564
> >
>



-- 
С уважением,
Машенков Андрей Владимирович
Тел. +7-921-932-61-82

Best regards,
Andrey V. Mashenkov
Cerr: +7-921-932-61-82

WFH today

2017-02-02 Thread Andrey Mashenkov 
Work from home by personal reasons.
Will be available since 14:00 MSK

Re: Apache Ignite 1.9

2017-02-02 Thread Denis Magda 
Excellent news Roman! Please keep us posted.

—
Denis

> On Feb 2, 2017, at 6:26 PM, Roman Shtykh  wrote:
> 
> Denis,
> RocketMQ data streamer implementation is almost ready. But there are no 
> binaries in maven repositories now (it will be their 1st release under Apache 
> license). The release is very close to starting voting for, so hopefully it 
> can be done in the middle of February.
> Roman
> 
> 
>On Wednesday, February 1, 2017 4:13 AM, Denis Magda  
> wrote:
> 
> 
> Igniters,
> Looks like 2.0 will be slightly delayed since the community requires more 
> time to make the new page memory architecture faster. At the same time we 
> have a plenty of bug fixes and performance improvements that were merged or 
> close to be merged into the master and ready to be released.
> I propose to release all the changes we have in 1.9 close to the end of 
> February.
> According to the dev list discussions, we will be ready to release 
> performance optimizations done by Yakov and Sam close to the end of 2016 and 
> many SQL improvements driven by multiple folks.
> In addition, this is what we might expect in 1.9:- SQL execution over 
> specific partitions (https://issues.apache.org/jira/browse/IGNITE-4523). 
> Alexey Scherbakov.- Spark version upgrade 
> (https://issues.apache.org/jira/browse/IGNITE-3710). Anton V.- Spark RDD 
> Examples (https://issues.apache.org/jira/browse/IGNITE-4526). Manish Mishra.- 
> Rocket MQ data streamer (https://issues.apache.org/jira/browse/IGNITE-4539). 
> Roman Shtykh.- Hibernate 5 support 
> (https://issues.apache.org/jira/browse/IGNITE-1794). Mykola Pereyma.- .NET 
> DML (https://issues.apache.org/jira/browse/IGNITE-4045). Pavel Tupitsyn.- 
> .NET Transaction Scope API 
> (https://issues.apache.org/jira/browse/IGNITE-3430). Pavel Tupitsyn.- C++ 
> Continuous queries (https://issues.apache.org/jira/browse/IGNITE-1443). Igor 
> Sapego.- Kubernetes Support 
> (https://issues.apache.org/jira/browse/IGNITE-4159). Denis Magda.- JDBC batch 
> mode for DML (https://issues.apache.org/jira/browse/IGNITE-4269). Alexander 
> Paschenko.- Benchmarks automation 
> (https://issues.apache.org/jira/browse/IGNITE-4212). Oleg Ostanin.
> Guys, please confirm that you will be able to complete listed tasks by the 
> middle or by 20th of February. Anything else that is not in the list?
> BTW, is there anyone who can take a role of the release manager for 1.9?
> —Denis
>

Re: Apache Ignite 1.9

2017-02-02 Thread Roman Shtykh 
Denis,
RocketMQ data streamer implementation is almost ready. But there are no 
binaries in maven repositories now (it will be their 1st release under Apache 
license). The release is very close to starting voting for, so hopefully it can 
be done in the middle of February.
Roman


On Wednesday, February 1, 2017 4:13 AM, Denis Magda  
wrote:
 

 Igniters,
Looks like 2.0 will be slightly delayed since the community requires more time 
to make the new page memory architecture faster. At the same time we have a 
plenty of bug fixes and performance improvements that were merged or close to 
be merged into the master and ready to be released.
I propose to release all the changes we have in 1.9 close to the end of 
February.
According to the dev list discussions, we will be ready to release performance 
optimizations done by Yakov and Sam close to the end of 2016 and many SQL 
improvements driven by multiple folks.
In addition, this is what we might expect in 1.9:- SQL execution over specific 
partitions (https://issues.apache.org/jira/browse/IGNITE-4523). Alexey 
Scherbakov.- Spark version upgrade 
(https://issues.apache.org/jira/browse/IGNITE-3710). Anton V.- Spark RDD 
Examples (https://issues.apache.org/jira/browse/IGNITE-4526). Manish Mishra.- 
Rocket MQ data streamer (https://issues.apache.org/jira/browse/IGNITE-4539). 
Roman Shtykh.- Hibernate 5 support 
(https://issues.apache.org/jira/browse/IGNITE-1794). Mykola Pereyma.- .NET DML 
(https://issues.apache.org/jira/browse/IGNITE-4045). Pavel Tupitsyn.- .NET 
Transaction Scope API (https://issues.apache.org/jira/browse/IGNITE-3430). 
Pavel Tupitsyn.- C++ Continuous queries 
(https://issues.apache.org/jira/browse/IGNITE-1443). Igor Sapego.- Kubernetes 
Support (https://issues.apache.org/jira/browse/IGNITE-4159). Denis Magda.- JDBC 
batch mode for DML (https://issues.apache.org/jira/browse/IGNITE-4269). 
Alexander Paschenko.- Benchmarks automation 
(https://issues.apache.org/jira/browse/IGNITE-4212). Oleg Ostanin.
Guys, please confirm that you will be able to complete listed tasks by the 
middle or by 20th of February. Anything else that is not in the list?
BTW, is there anyone who can take a role of the release manager for 1.9?
—Denis

Re: Ensure that builder approach is used for all setters in public API

2017-02-02 Thread Valentin Kulichenko 
Andrey,

In which case compatibility is broken? If there is a method that returns
void and you change it to return some type, it doesn't break anything,
because currently nobody can assign the result of this method to a
variable. I.e. in old code the returned value will be always ignored,
therefore it can be of any type.

Is there anything else that I'm missing?

-Val

On Thu, Feb 2, 2017 at 3:49 AM, Andrey Mashenkov  wrote:

> Hi Igniters,
>
>
> I'm working on IGNITE-4564 [1] to make our configuration classes and SPI
> classes more convenient.
>
> There is no problem to change return type in setter method signatures
> and override methods in child child classes to make them return more
> accurate type.
>
> But, I found that we have set methods in some of our interfaces and
> changing its signature may broke compatibility with user implementations.
>
> Here are example interfaces with setters:
> org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean
> org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyMXBean
> org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean
> org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean
> org.apache.ignite.spi.checkpoint.CheckpointSpi
> org.apache.ignite.spi.collision.CollisionSpi
> org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean
>
> However we have interfaces with NO setters
> org.apache.ignite.spi.loadbalancing.adaptive.
> AdaptiveLoadBalancingSpiMBean.
>
> What can we do with it?
> Change signature of setters without regarding compatibility? Or may be it
> is possible to remove setters from some interfaces?
>
> Thought?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4564
>

[jira] [Created] (IGNITE-4649) Upgrade JCache dependency when Apache 2.0 license migration finalized

2017-02-02 Thread Denis Magda (JIRA) 
Denis Magda created IGNITE-4649:
---

 Summary: Upgrade JCache dependency when Apache 2.0 license 
migration finalized
 Key: IGNITE-4649
 URL: https://issues.apache.org/jira/browse/IGNITE-4649
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda


JCache's migration to Apache 2.0 license will be finished soon. Upgrade JCache 
dependency in Ignite's pom file once this happens. Also, make sure that 
Ignite's files with licenses will reflect the change.

Track JCache migration here:
https://github.com/jsr107/jsr107spec/issues/333#issuecomment-277106702

Relevant discussion on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/moving-to-geronimo-JCache-jar-td8118.html



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

Re: moving to geronimo JCache jar

2017-02-02 Thread Denis Magda 
Got more clarifications from the folks that driving the license upgrade. We 
need to wait until the process fully finishes:
https://github.com/jsr107/jsr107spec/issues/333#issuecomment-277106702 


Considering this let’s merge the current changes reverting this one

> #if ( $license.name.contains("JSR-000107 JCACHE 2.9 Public Review") )
>  #set( $licenseName = "Apache License, Version 2.0” )

and close the ticket.

I opened a new one for JCache license upgrade tracking:
https://issues.apache.org/jira/browse/IGNITE-4649 


—
Denis

> On Feb 2, 2017, at 11:12 AM, Denis Magda  wrote:
> 
> Well, there is some minor work left to be done before pushing JSR 107 to 
> Maven:
> https://github.com/jsr107/jsr107spec/issues/333 
> 
> However, it’s a matter of time since Oracle has already approved the new 
> license.
> 
> When JSR 107 1.1.0 gets released in Maven we will be required to update the 
> version in our dependencies and release a new version of Apache Ignite. This 
> is why I don’t see any issue if leave this workaround for 1.9 release
> 
> #if ( $license.name.contains("JSR-000107 JCACHE 2.9 Public Review") )
>  #set( $licenseName = "Apache License, Version 2.0” )
> 
> and remove it at the time when we will be upgrading to JSR 107 1.1.0.
> 
> Is there any other concern rather than code beauty?
> 
> —
> Denis
> 
>> On Feb 2, 2017, at 1:17 AM, Anton Vinogradov  
>> wrote:
>> 
>> Denis,
>> 
>> As you can see https://github.com/jsr107/jsr107spec/blob/master/pom.xml 
>>  has
>> version 1.*1*.0-SNAPSHOT and it's just not released at maven.
>> Can we ask cache-api team to release it?
>> 
>> Anyways, I see no issues here, we just have to keep current license
>> 
>> JSR-000107 JCACHE 2.9 Public Review - Updated Specification License
>>> https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt 
>>> 
>> 
>> 
>> and wait for cache-api 1.*1*.0 release.
>

Re: moving to geronimo JCache jar

2017-02-02 Thread Denis Magda 
Well, there is some minor work left to be done before pushing JSR 107 to Maven:
https://github.com/jsr107/jsr107spec/issues/333 

However, it’s a matter of time since Oracle has already approved the new 
license.

When JSR 107 1.1.0 gets released in Maven we will be required to update the 
version in our dependencies and release a new version of Apache Ignite. This is 
why I don’t see any issue if leave this workaround for 1.9 release

#if ( $license.name.contains("JSR-000107 JCACHE 2.9 Public Review") )
  #set( $licenseName = "Apache License, Version 2.0” )

and remove it at the time when we will be upgrading to JSR 107 1.1.0.

Is there any other concern rather than code beauty?

—
Denis

> On Feb 2, 2017, at 1:17 AM, Anton Vinogradov  wrote:
> 
> Denis,
> 
> As you can see https://github.com/jsr107/jsr107spec/blob/master/pom.xml 
>  has
> version 1.*1*.0-SNAPSHOT and it's just not released at maven.
> Can we ask cache-api team to release it?
> 
> Anyways, I see no issues here, we just have to keep current license
> 
> JSR-000107 JCACHE 2.9 Public Review - Updated Specification License
>> https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt 
>> 
> 
> 
> and wait for cache-api 1.*1*.0 release.

[GitHub] ignite pull request #1490: Ignite 4541

2017-02-02 Thread iveselovskiy 
GitHub user iveselovskiy opened a pull request:

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

Ignite 4541



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

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

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

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


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 80053984fbbd4c98b4747aed8800f425a78f6ee2
Author: iveselovskiy 
Date:   2017-01-12T15:07:54Z

Version #1: Hadoop terasort test workable in multi-JVM via #isMultiJvm

commit e8958390441bde0325d81379e2e49736c1a4b325
Author: iveselovskiy 
Date:   2017-01-16T10:45:35Z

Refactoring to avoid Ignite interface of remote nodes. .

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 98193ede922284f293bf2d9150cbec80c41a9aee
Author: iveselovskiy 
Date:   2017-01-19T10:11:05Z

ignite-4541: wip

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 'master' into ignite-2.0

# Conflicts:
#   
modules/hado

Re: Issues with local deployment of the Web Console

2017-02-02 Thread Denis Magda 
Hi Andrey,

Does it mean that as the fix you will use only specific versions of 
dependencies?

Can you add a temporal callout block to this documentation page [1] specifying 
all the steps of the suggested workaround? The callout will be remove after 1.9 
gets released.

[1] https://apacheignite.readme.io/docs/local-deployment 

 
—
Denis

> On Feb 1, 2017, at 8:04 PM, Andrey Novikov  wrote:
> 
> Hi Prachi,
> 
> Thanks for your investigation. I found that Web Console download latest
> released version of dependencies and this error occurred after Angular
> library updated in repository to incompatible version.
> 
> This problem was already fixed in "master" branch. As temporary workaround
> in your branch, you may  replace "^1.5.5" to "~1.5.5" in
> "modules/web-console/frontend/package.json" and then execute in console
> "npm update --no-optional" in "modules/web-console/frontend" folder.
> 
> 
> On Thu, Feb 2, 2017 at 7:10 AM, Prachi Garg  wrote:
> 
>> Looks like I can't attach images to dev list. I have uploded the images
>> here -
>> https://drive.google.com/drive/folders/0B13J0oQz4pZxZThkUlJfMWJhTGM?
>> usp=sharing
>> 
>> On Wed, Feb 1, 2017 at 3:11 PM, Prachi Garg  wrote:
>> 
>>> Engineers,
>>> 
>>> I deployed the Web Console locally, and found a couple of issues while
>>> trying to add and save a cluster on http://localhost:9000/configur
>>> ation/clusters page-
>>> 
>>>   1. There is no Java/XML code, on the right side.
>>>   2. No list of cluster names.
>>>   3. No 'undo' arrow/icon on the red button next to 'Save'
>>>   4. No green notification, on top right of the screen, for successfully
>>>   saving a cluster
>>>   5. I keep getting the notification/warning popup box for unsaved
>>>   changes although the log shows that a cluster is saved.
>>>   6. I have to manually refresh the page to see some of the updates.
>>>   7. I see some, not all, of the above mentioned issues when trying to
>>>   add and save a cache.
>>>   8. There is no Java or XML code on the Summary page.
>>> 
>>> Please see the attached images and the log below:
>>> 
>>> POST /configuration/clusters/save 400 13.376 ms - 44
>>> 
>>> POST /configuration/clusters/save 400 11.070 ms - 44
>>> 
>>> POST /configuration/clusters/save 400 10.033 ms - 44
>>> 
>>> POST /configuration/caches/save 400 8.311 ms - 41
>>> 
>>> POST /configuration/caches/save 400 7.587 ms - 41
>>> 
>>> 
>>> I followed this documentation for local deployment -
>>> https://apacheignite.readme.io/docs/local-deployment.
>>> 
>>> Thanks,
>>> 
>>> -Prachi
>>> 
>>> 
>>> 
>>

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

2017-02-02 Thread Denis Magda 
Oleg, thanks,

Could you share Ignite release binaries with your patch applied? You should be 
able to use TeamCity for that. Makes sense to see the new project structure and 
walk through final version of the instructions.

—
Denis

> On Feb 2, 2017, at 2:30 AM, Oleg Ostanin  wrote:
> 
> Denis,
> 
> Yes, the same identical README.txt as in the pull request will be placed in
> both benchmarks binaries and Ignite Yardstick module.
> 
> I've also created two DEVNOTES.txt with related building instructions.
> 
> On Wed, Feb 1, 2017 at 10:31 PM, Denis Magda  wrote:
> 
>> Anton,
>> 
>> I’m absolutely fine to make a single README if its instructions will be
>> identical for benchmarks binaries delivered in Ignite binary releases and
>> assembled with yardstick module directly. Oleg, is it feasible?
>> 
>> If to skip auto-generation idea then DEVNOTES split suggested by you is
>> the only option.
>> 
>> —
>> Denis
>> 
>>> On Feb 1, 2017, at 1:45 AM, Anton Vinogradov 
>> wrote:
>>> 
>>> Denis,
>>> 
>>> I don't like autogeneration.
>>> 
>>> In my view, we have to keep one README and ret rid of "Installation
>>> instructions" inside it.
>>> README should explain how to work with assembled yardstick. So, same
>> README
>>> will be uses at sources and inside release assembly.
>>> 
>>> Also we have to have to split DEVNOTES to DEVNOTES and
>> DEVNOTES.standalone,
>>> to explain how to assembly yardstick from sources.
>>> 
>>> Thoughts?
>>> 
>>> On Tue, Jan 31, 2017 at 9:18 PM, Denis Magda  wrote:
>>> 
 Oleg,
 
 Thanks for the clarification.
 
 My opinion is that we should leave ‘modules/yardstick/README.txt’ and
 ‘modules/yardstick/DEVNOTES.txt’ either unchanged or have only those
 instructions there that explain how to build and run benchmarks from
 ‘modules/yardstick’. This existing files can refer to the sources and
 compiled benchmarks that are in Ignite binary releases but this should
>> be a
 couple of statements, no more.
 
 As for the instructions related to the sources and binaries added to
 Ignite binaries, preferably they need to be added to auto-generated
 README.txt. *Anton*, is it feasible to do?
 
 Finally, when apply the reviews notes please build and share Ignite
 binaries with your patch. Want to see the new project structure and
>> final
 version of the instructions. Presently I can’t merge your changes due to
 some conflicts.
 
 *Anton*, please review modifications in the build procedures.
 
 —
 Denis
 
> On Jan 31, 2017, at 3:12 AM, Oleg Ostanin 
>> wrote:
> 
> Hi Denis,
> 
> Yes, we have included Ignite Yardstick source files with its pom.xml in
> Ignite binary release. "Building from standalone sources" is the
>> building
> instruction for these source files. "Building from Ignite Sources" is
>> the
> instruction for building Ignite Yardstick from `modules/yardstick` in
> Ignite source files.
> 
> On Tue, Jan 31, 2017 at 3:31 AM, Denis Magda 
>> wrote:
> 
>> Hi Oleg,
>> 
>> Great progress, thanks for keep driving this!
>> 
>> I’ve left some minor notes in GitHub’s pull-request. I have the
 following
>> questions aside:
>> 
>> - What is the difference between "Building from standalone sources"
>> and
>> "Building from Ignite Sources"? In my understanding, a user downloads
>> Apache Ignite release that has all the sources locally.
>> 
>> - I do remember we planned to add the benchmarks sources in a form of
>> a
>> ready to be used project with its own pom.xml (similar to examples).
>> Did
>> you put this task off?
>> 
>> —
>> Denis
>> 
>>> On Jan 27, 2017, at 2:13 AM, Oleg Ostanin 
 wrote:
>>> 
>>> Hi!
>>> 
>>> I've changed the README.txt and DEVNOTES.txt files. Also added a
>> simple
>>> config file for quick and easy start. Please take a look at them and
 tell
>>> me what you think.
>>> 
>>> https://github.com/apache/ignite/pull/1471
>>> 
>>> On Wed, Dec 28, 2016 at 8:59 AM, Ilya Suntsov >> 
>> wrote:
>>> 
 Denis,
 
 I think we can remove all configs except:
 
 benchmark-multicast.properties
 
 benchmark.properties
 
 ignite-base-config.xml
 
 ignite-localhost-config.xml
 
 ignite-multicast-config.xml
 
 2016-12-28 2:49 GMT+03:00 Denis Magda :
 
> I would have only those configs that are useful. Ilya Suntsov,
>> basing
>> on
> your experience, please suggest which configs makes sense to
>> include
>> into
> every Ignite release.
> 
> Oleg, also please note that community decided to include not only
>> the
> benchmarking binaries but the sources as well into every Apache
 Ignite
> release. I’ve update the ticket before. Hope y

[GitHub] ignite pull request #1489: IGNITE-4252 Fixed exception with local cache quer...

2017-02-02 Thread skalashnikov 
GitHub user skalashnikov opened a pull request:

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

IGNITE-4252 Fixed exception with local cache query started on partiti…

…oned cache

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

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

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

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


commit 42d0e97be861cf285c994faa1232e660adc12a08
Author: skalashnikov 
Date:   2017-02-02T16:50:15Z

IGNITE-4252 Fixed exception with local cache query started on partitioned 
cache




---
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: IGNITE-3244

2017-02-02 Thread Denis Magda 
Yes, this is exactly the reason why this ticket is created. Presently, binary 
marshaller ignores custom type for arrays. We need to find a way how to handle 
this.

—
Denis

> On Feb 2, 2017, at 6:23 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> I founded that cache.get(i) actually returns an array, containing
> TestObject. But somehow the type of returned value is Object[] not
> TestObject[]
> 
> ср, 1 февр. 2017 г. в 22:26, Denis Magda :
> 
>> Excellent, please share the way you want to fix the issue with the
>> community. You might get a valuable feedback before getting down to coding.
>> 
>> —
>> Denis
>> 
>>> On Feb 1, 2017, at 1:18 AM, ALEKSEY KUZNETSOV 
>> wrote:
>>> 
>>> will take https://issues.apache.org/jira/browse/IGNITE-3244
>>> --
>>> 
>>> *Best Regards,*
>>> 
>>> *Kuznetsov Aleksey*
>> 
>> --
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

Re: Apache Ignite 1.9

2017-02-02 Thread Denis Magda 
Terrific, thanks Pave!

—
Denis

> On Feb 2, 2017, at 7:38 AM, Pavel Tupitsyn  wrote:
> 
> Denis,
> 
> Regarding IGNITE-3430 TransactionScope:
> We have got to the bottom of the problem today and fixed it. All details
> are in the ticket.
> Feature is enabled in master branch again and will be included in 1.9.
> 
> Sorry for all that back-and-forth, just want to make sure that we don't
> ship broken stuff :)
> 
> Pavel
> 
> On Wed, Feb 1, 2017 at 11:05 PM, Denis Magda  wrote:
> 
>> Manish, wonderful news! Please ask me for review as before. Will do it
>> with pleasure.
>> 
>> —
>> Denis
>> 
>>> On Feb 1, 2017, at 12:03 PM, Manish Mishra  wrote:
>>> 
>>> Hi,
>>> I will be completing the proposed IGNITE - 4526 by the deadline. I will
>> be completing Java shared RDD example by 15th Feb. Thanks.
>>> 
>>> On Feb 2, 2017 1:09 AM, "Denis Magda" > dma...@apache.org>> wrote:
>>> Pavel, thanks.
>>> 
>>> Ok, if you’re absolutely sure that IGNITE-3430 depends on IGNITE-3477
>> then makes sense to postpone the release of this feature.
>>> 
>>> Igniters, does anyone else ready to release new functionality or bug
>> fixes under 1.9?
>>> 
>>> —
>>> Denis
>>> 
 On Feb 1, 2017, at 5:07 AM, Pavel Tupitsyn > > wrote:
 
 Denis,
 
 We found a problem with IGNITE-3430.
 I've disabled the feature in master branch and reopened the ticket.
 We should probably move this back to 2.0.
 
 Pavel
 
 On Wed, Feb 1, 2017 at 12:55 PM, Pavel Tupitsyn > >
 wrote:
 
> Regarding .NET:
> * DML and TransactionScope are merged.
> Examples and docs for TransactionScope are TBD (IGNITE-4619), I'll do
> these soon.
> * No other major features in .NET
> 
> Pavel
> 
> On Tue, Jan 31, 2017 at 10:13 PM, Denis Magda > > wrote:
> 
>> Igniters,
>> 
>> Looks like 2.0 will be slightly delayed since the community requires
>> more
>> time to make the new page memory architecture faster. At the same
>> time we
>> have a plenty of bug fixes and performance improvements that were
>> merged or
>> close to be merged into the master and ready to be released.
>> 
>> I propose to release all the changes we have in 1.9 close to the end
>> of
>> February.
>> 
>> According to the dev list discussions, we will be ready to release
>> performance optimizations done by Yakov and Sam close to the end of
>> 2016
>> and many SQL improvements driven by multiple folks.
>> 
>> In addition, this is what we might expect in 1.9:
>> - SQL execution over specific partitions (
>> https://issues.apache.org/jir 
>> a/browse/IGNITE-4523 > jira/browse/IGNITE-4523 > Alexey Scherbakov.
>> - Spark version upgrade (https://issues.apache.org/jir <
>> https://issues.apache.org/jir>
>> a/browse/IGNITE-3710 > jira/browse/IGNITE-3710 > Anton V.
>> - Spark RDD Examples (https://issues.apache.org/
>> jira/browse/IGNITE-4526 
>> <
>> https://issues.apache.org/jira/browse/IGNITE-4526 <
>> https://issues.apache.org/jira/browse/IGNITE-4526>>). Manish Mishra.
>> - Rocket MQ data streamer (https://issues.apache.org/jir <
>> https://issues.apache.org/jir>
>> a/browse/IGNITE-4539 > jira/browse/IGNITE-4539 > Roman Shtykh.
>> - Hibernate 5 support (https://issues.apache.org/
>> jira/browse/IGNITE-1794 >> 
>> > https://issues.apache.org/jira/browse/IGNITE-1794>>). Mykola Pereyma.
>> - .NET DML (https://issues.apache.org/jira/browse/IGNITE-4045 <
>> https://issues.apache.org/jira/browse/IGNITE-4045> <
>> https://issues.apache.org/jira/browse/IGNITE-4045 <
>> https://issues.apache.org/jira/browse/IGNITE-4045>>). Pavel Tupitsyn.
>> - .NET Transaction Scope API (https://issues.apache.org/jir <
>> https://issues.apache.org/jir>
>> a/browse/IGNITE-3430 > jira/browse/IGNITE-3430 > Pavel Tupitsyn.
>> - C++ Continuous queries (https://issues.apache.org/jir <
>> https://issues.apache.org/jir>
>> a/browse/IGNITE-1443 > jira/browse/IGNITE-1443 > Igor Sapego.
>> - Kubernetes Support (https://issues.apache.org/
>> jira/browse/IGNITE-4159 
>> <
>> https://issues.apache.org/jira/browse/IGNITE-4159 <
>> https://issues.apache.org/jira/br

[GitHub] ignite pull request #1488: IGNITE-4645

2017-02-02 Thread gvvinblade 
GitHub user gvvinblade opened a pull request:

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

IGNITE-4645



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

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

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

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


commit df4487388e477dc389091ef5bff99e0d08a87072
Author: Igor Seliverstov 
Date:   2017-02-02T15:41:47Z

IGNITE-4645 Best effort to avoid extra copying in binary marshaller




---
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: Apache Ignite 1.9

2017-02-02 Thread Pavel Tupitsyn 
Denis,

Regarding IGNITE-3430 TransactionScope:
We have got to the bottom of the problem today and fixed it. All details
are in the ticket.
Feature is enabled in master branch again and will be included in 1.9.

Sorry for all that back-and-forth, just want to make sure that we don't
ship broken stuff :)

Pavel

On Wed, Feb 1, 2017 at 11:05 PM, Denis Magda  wrote:

> Manish, wonderful news! Please ask me for review as before. Will do it
> with pleasure.
>
> —
> Denis
>
> > On Feb 1, 2017, at 12:03 PM, Manish Mishra  wrote:
> >
> > Hi,
> > I will be completing the proposed IGNITE - 4526 by the deadline. I will
> be completing Java shared RDD example by 15th Feb. Thanks.
> >
> > On Feb 2, 2017 1:09 AM, "Denis Magda"  dma...@apache.org>> wrote:
> > Pavel, thanks.
> >
> > Ok, if you’re absolutely sure that IGNITE-3430 depends on IGNITE-3477
> then makes sense to postpone the release of this feature.
> >
> > Igniters, does anyone else ready to release new functionality or bug
> fixes under 1.9?
> >
> > —
> > Denis
> >
> > > On Feb 1, 2017, at 5:07 AM, Pavel Tupitsyn  > wrote:
> > >
> > > Denis,
> > >
> > > We found a problem with IGNITE-3430.
> > > I've disabled the feature in master branch and reopened the ticket.
> > > We should probably move this back to 2.0.
> > >
> > > Pavel
> > >
> > > On Wed, Feb 1, 2017 at 12:55 PM, Pavel Tupitsyn  >
> > > wrote:
> > >
> > >> Regarding .NET:
> > >> * DML and TransactionScope are merged.
> > >>  Examples and docs for TransactionScope are TBD (IGNITE-4619), I'll do
> > >> these soon.
> > >> * No other major features in .NET
> > >>
> > >> Pavel
> > >>
> > >> On Tue, Jan 31, 2017 at 10:13 PM, Denis Magda  > wrote:
> > >>
> > >>> Igniters,
> > >>>
> > >>> Looks like 2.0 will be slightly delayed since the community requires
> more
> > >>> time to make the new page memory architecture faster. At the same
> time we
> > >>> have a plenty of bug fixes and performance improvements that were
> merged or
> > >>> close to be merged into the master and ready to be released.
> > >>>
> > >>> I propose to release all the changes we have in 1.9 close to the end
> of
> > >>> February.
> > >>>
> > >>> According to the dev list discussions, we will be ready to release
> > >>> performance optimizations done by Yakov and Sam close to the end of
> 2016
> > >>> and many SQL improvements driven by multiple folks.
> > >>>
> > >>> In addition, this is what we might expect in 1.9:
> > >>> - SQL execution over specific partitions (
> https://issues.apache.org/jir 
> > >>> a/browse/IGNITE-4523  jira/browse/IGNITE-4523  >>).
> > >>> Alexey Scherbakov.
> > >>> - Spark version upgrade (https://issues.apache.org/jir <
> https://issues.apache.org/jir>
> > >>> a/browse/IGNITE-3710  jira/browse/IGNITE-3710  >>).
> > >>> Anton V.
> > >>> - Spark RDD Examples (https://issues.apache.org/
> jira/browse/IGNITE-4526 
> <
> > >>> https://issues.apache.org/jira/browse/IGNITE-4526 <
> https://issues.apache.org/jira/browse/IGNITE-4526>>). Manish Mishra.
> > >>> - Rocket MQ data streamer (https://issues.apache.org/jir <
> https://issues.apache.org/jir>
> > >>> a/browse/IGNITE-4539  jira/browse/IGNITE-4539  >>).
> > >>> Roman Shtykh.
> > >>> - Hibernate 5 support (https://issues.apache.org/
> jira/browse/IGNITE-1794  >
> > >>>  https://issues.apache.org/jira/browse/IGNITE-1794>>). Mykola Pereyma.
> > >>> - .NET DML (https://issues.apache.org/jira/browse/IGNITE-4045 <
> https://issues.apache.org/jira/browse/IGNITE-4045> <
> > >>> https://issues.apache.org/jira/browse/IGNITE-4045 <
> https://issues.apache.org/jira/browse/IGNITE-4045>>). Pavel Tupitsyn.
> > >>> - .NET Transaction Scope API (https://issues.apache.org/jir <
> https://issues.apache.org/jir>
> > >>> a/browse/IGNITE-3430  jira/browse/IGNITE-3430  >>).
> > >>> Pavel Tupitsyn.
> > >>> - C++ Continuous queries (https://issues.apache.org/jir <
> https://issues.apache.org/jir>
> > >>> a/browse/IGNITE-1443  jira/browse/IGNITE-1443  >>).
> > >>> Igor Sapego.
> > >>> - Kubernetes Support (https://issues.apache.org/
> jira/browse/IGNITE-4159 
> <
> > >>> https://issues.apache.org/jira/browse/IGNITE-4159 <
> https://issues.apache.org/jira/browse/IGNITE-4159>>). Denis Magda.
> > >>> - JDBC batch mode for DML (https://issues.apache.org/jir <
> https://issues.a

[GitHub] ignite pull request #1487: IGNITE-3430 .NET: Enable TransactionScope API aga...

2017-02-02 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
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: IGNITE-3244

2017-02-02 Thread ALEKSEY KUZNETSOV 
I founded that cache.get(i) actually returns an array, containing
TestObject. But somehow the type of returned value is Object[] not
TestObject[]

ср, 1 февр. 2017 г. в 22:26, Denis Magda :

> Excellent, please share the way you want to fix the issue with the
> community. You might get a valuable feedback before getting down to coding.
>
> —
> Denis
>
> > On Feb 1, 2017, at 1:18 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > will take https://issues.apache.org/jira/browse/IGNITE-3244
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
> --

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1487: IGNITE-3430 .NET: Enable TransactionScope API aga...

2017-02-02 Thread ptupitsyn 
GitHub user ptupitsyn opened a pull request:

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

IGNITE-3430 .NET: Enable TransactionScope API again, fix and improve tests



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

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

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

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


commit 67bff84adde9810a44b3d2f4e0807830a03a42b9
Author: Pavel Tupitsyn 
Date:   2017-02-02T13:50:54Z

IGNITE-3430 enable functionality back, unignore and fix tests

commit 0a184515d44e5b32c639e465c37cf7e5fa731068
Author: Pavel Tupitsyn 
Date:   2017-02-02T13:59:06Z

Test all isolation levels




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

[jira] [Created] (IGNITE-4648) TransactionProxyImpl.prepare() does not wait for async operations to complete

2017-02-02 Thread Pavel Tupitsyn (JIRA) 
Pavel Tupitsyn created IGNITE-4648:
--

 Summary: TransactionProxyImpl.prepare() does not wait for async 
operations to complete
 Key: IGNITE-4648
 URL: https://issues.apache.org/jira/browse/IGNITE-4648
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.1


{{commit}} and {{rollback}} wait for async operations by calling 
{{tx.txState().awaitLastFut();}} (see {{GridCacheSharedContext}}).

There is no such thing in {{IgniteInternalTx.prepare()}} implementations.

Since {{prepare}} is an internal method, this is not an issue mostly, except 
for two things:
* JTA. {{CacheJtaResource}} calls {{prepare()}} explicitly. 
* .NET {{TransactionScope}} API. Same thing as JTA, basically. 
{{PlatformTransactions}} call {{prepare()}} as well.


As a result, if user starts an async operation within JTA transaction and then 
completes the tx, undefined behavior is possible.



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

Re: Unexpected behavior of DiscoveryCustomMessage acks

2017-02-02 Thread Vladimir Ozerov 
Sounds very nasty.

On Thu, Feb 2, 2017 at 3:50 PM, Sergey Chugunov 
wrote:

> Hello folks,
>
> Working on IGNITE-4302 
> I developed a protocol for delivering metadata updates to all nodes in
> cluster.
>
> This protocol relies on a guarantee of *DiscoveryCustomMessage* that each
> message is delivered to *CustomEventListener* exactly once; duplicates are
> not possible.
>
> But test *GridEventConsumeSelfTest::testMultithreadedWithNodeRestart*
> running with my latest code changes seems to fail exactly because of
> violation of this guarantee.
> I can see that acknowledge messages which are also DiscoveryCustomMessages
> make two passes across the cluster when some nodes are restarted.
>
> My question is: is it s bug or just a detail about guarantees around
> acknowledge messages?
> I can easily filter out these duplicates at the protocol level, but it is
> better to fix this in case it is a bug.
>
> Thanks,
> Sergey.
>

[jira] [Created] (IGNITE-4647) ComputeTask with custom classLoader fail

2017-02-02 Thread Stanilovsky Evgeny (JIRA) 
Stanilovsky Evgeny created IGNITE-4647:
--

 Summary: ComputeTask with custom classLoader fail
 Key: IGNITE-4647
 URL: https://issues.apache.org/jira/browse/IGNITE-4647
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.0
Reporter: Stanilovsky Evgeny
Priority: Minor
 Attachments: repro-2813.tar.gz

In case, when we want to run ComputeTask with custom classLoader and custom 
inherited IgniteCallable class initialized with instance from custom loader, 
catch error *java.lang.ClassNotFoundException*. 

-- deploy node code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);
icfg.setClassLoader(igniteLoader);

--client code --
IgniteConfiguration icfg = new IgniteConfiguration();
icfg.setGridName("grid");
icfg.setPeerClassLoadingEnabled(true);

all detailed info, how to reproduce in attach.

debug shows that function {code} processResourceRequest(UUID nodeId, 
GridDeploymentRequest req) {code} return classLoader {code} ClassLoader ldr = 
dep.classLoader(); {code} not that expected (that was setting throught 
icfg.setClassLoader(igniteLoader);) but classLoader from {code} 
ignite.compute().affinityCall("cache", i, igniteCallable); {code}{code} 
igniteCallable {code} object.



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

Unexpected behavior of DiscoveryCustomMessage acks

2017-02-02 Thread Sergey Chugunov 
Hello folks,

Working on IGNITE-4302 
I developed a protocol for delivering metadata updates to all nodes in
cluster.

This protocol relies on a guarantee of *DiscoveryCustomMessage* that each
message is delivered to *CustomEventListener* exactly once; duplicates are
not possible.

But test *GridEventConsumeSelfTest::testMultithreadedWithNodeRestart*
running with my latest code changes seems to fail exactly because of
violation of this guarantee.
I can see that acknowledge messages which are also DiscoveryCustomMessages
make two passes across the cluster when some nodes are restarted.

My question is: is it s bug or just a detail about guarantees around
acknowledge messages?
I can easily filter out these duplicates at the protocol level, but it is
better to fix this in case it is a bug.

Thanks,
Sergey.

Ensure that builder approach is used for all setters in public API

2017-02-02 Thread Andrey Mashenkov 
Hi Igniters,


I'm working on IGNITE-4564 [1] to make our configuration classes and SPI
classes more convenient.

There is no problem to change return type in setter method signatures
and override methods in child child classes to make them return more
accurate type.

But, I found that we have set methods in some of our interfaces and
changing its signature may broke compatibility with user implementations.

Here are example interfaces with setters:
org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicyMBean
org.apache.ignite.cache.eviction.igfs.IgfsPerBlockLruEvictionPolicyMXBean
org.apache.ignite.cache.eviction.lru.LruEvictionPolicyMBean
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicyMBean
org.apache.ignite.spi.checkpoint.CheckpointSpi
org.apache.ignite.spi.collision.CollisionSpi
org.apache.ignite.spi.collision.fifoqueue.FifoQueueCollisionSpiMBean

However we have interfaces with NO setters
org.apache.ignite.spi.loadbalancing.adaptive.AdaptiveLoadBalancingSpiMBean.

What can we do with it?
Change signature of setters without regarding compatibility? Or may be it
is possible to remove setters from some interfaces?

Thought?


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

[jira] [Created] (IGNITE-4646) Try to unmarshall direct messages in striped pool

2017-02-02 Thread Yakov Zhdanov (JIRA) 
Yakov Zhdanov created IGNITE-4646:
-

 Summary: Try to unmarshall direct messages in striped pool
 Key: IGNITE-4646
 URL: https://issues.apache.org/jira/browse/IGNITE-4646
 Project: Ignite
  Issue Type: Improvement
Reporter: Yakov Zhdanov
 Fix For: 2.0


During marshalling in NIO thread the following should be added to the write 
buffer and sent to peer:
1. chunk size - 16 bits (this probably puts limitation on max write buffer size 
of 64k or will require some changes to direct writer)
2. last  chunk - 1 bit
3. pool policy - 8 bits

Here is the scheme to explain how this should work.
{noformat}
[chunk size] [pool policy] [partition] [last flag] [chunk data] X <-- no more 
space in write buffer
[next chunk size] [last flag] [chunk data] <<-- we write next chunk once some 
space is available in write buffer, but we skip partition and policy flags and 
maybe others that should be sent only once.
...
...
[next chunk size] [last flag] [chunk data] <<-- last flag is true here
{noformat}

Examples
Write buffer - 64k
Message - 84k

# sender reserves space for chunk size
# reserves space for policy and last chunk flag
# marshalls message to buffer while it has free space (64k - SPACE will be 
written to buffer)
# puts size and flags to reserved space in the beginning
# sends buffer or part of it which makes some space available to further writes
# reserves space for next chunk size and flags
# marshalls message to buffer while it has free space (lets assume the rest of 
message fits)
# puts size and last=true to the reserved space and sends

Receiver:
# reads chunk size, stores the target pool and partition
# allocates heap buffer and copies chunk data to it from read buffer
# once all message chunks are fully read message should be submitted to a pool 
where it will be unmarshalled and processed




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

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

2017-02-02 Thread Oleg Ostanin 
Denis,

Yes, the same identical README.txt as in the pull request will be placed in
both benchmarks binaries and Ignite Yardstick module.

I've also created two DEVNOTES.txt with related building instructions.

On Wed, Feb 1, 2017 at 10:31 PM, Denis Magda  wrote:

> Anton,
>
> I’m absolutely fine to make a single README if its instructions will be
> identical for benchmarks binaries delivered in Ignite binary releases and
> assembled with yardstick module directly. Oleg, is it feasible?
>
> If to skip auto-generation idea then DEVNOTES split suggested by you is
> the only option.
>
> —
> Denis
>
> > On Feb 1, 2017, at 1:45 AM, Anton Vinogradov 
> wrote:
> >
> > Denis,
> >
> > I don't like autogeneration.
> >
> > In my view, we have to keep one README and ret rid of "Installation
> > instructions" inside it.
> > README should explain how to work with assembled yardstick. So, same
> README
> > will be uses at sources and inside release assembly.
> >
> > Also we have to have to split DEVNOTES to DEVNOTES and
> DEVNOTES.standalone,
> > to explain how to assembly yardstick from sources.
> >
> > Thoughts?
> >
> > On Tue, Jan 31, 2017 at 9:18 PM, Denis Magda  wrote:
> >
> >> Oleg,
> >>
> >> Thanks for the clarification.
> >>
> >> My opinion is that we should leave ‘modules/yardstick/README.txt’ and
> >> ‘modules/yardstick/DEVNOTES.txt’ either unchanged or have only those
> >> instructions there that explain how to build and run benchmarks from
> >> ‘modules/yardstick’. This existing files can refer to the sources and
> >> compiled benchmarks that are in Ignite binary releases but this should
> be a
> >> couple of statements, no more.
> >>
> >> As for the instructions related to the sources and binaries added to
> >> Ignite binaries, preferably they need to be added to auto-generated
> >> README.txt. *Anton*, is it feasible to do?
> >>
> >> Finally, when apply the reviews notes please build and share Ignite
> >> binaries with your patch. Want to see the new project structure and
> final
> >> version of the instructions. Presently I can’t merge your changes due to
> >> some conflicts.
> >>
> >> *Anton*, please review modifications in the build procedures.
> >>
> >> —
> >> Denis
> >>
> >>> On Jan 31, 2017, at 3:12 AM, Oleg Ostanin 
> wrote:
> >>>
> >>> Hi Denis,
> >>>
> >>> Yes, we have included Ignite Yardstick source files with its pom.xml in
> >>> Ignite binary release. "Building from standalone sources" is the
> building
> >>> instruction for these source files. "Building from Ignite Sources" is
> the
> >>> instruction for building Ignite Yardstick from `modules/yardstick` in
> >>> Ignite source files.
> >>>
> >>> On Tue, Jan 31, 2017 at 3:31 AM, Denis Magda 
> wrote:
> >>>
>  Hi Oleg,
> 
>  Great progress, thanks for keep driving this!
> 
>  I’ve left some minor notes in GitHub’s pull-request. I have the
> >> following
>  questions aside:
> 
>  - What is the difference between "Building from standalone sources"
> and
>  "Building from Ignite Sources"? In my understanding, a user downloads
>  Apache Ignite release that has all the sources locally.
> 
>  - I do remember we planned to add the benchmarks sources in a form of
> a
>  ready to be used project with its own pom.xml (similar to examples).
> Did
>  you put this task off?
> 
>  —
>  Denis
> 
> > On Jan 27, 2017, at 2:13 AM, Oleg Ostanin 
> >> wrote:
> >
> > Hi!
> >
> > I've changed the README.txt and DEVNOTES.txt files. Also added a
> simple
> > config file for quick and easy start. Please take a look at them and
> >> tell
> > me what you think.
> >
> > https://github.com/apache/ignite/pull/1471
> >
> > On Wed, Dec 28, 2016 at 8:59 AM, Ilya Suntsov  >
>  wrote:
> >
> >> Denis,
> >>
> >> I think we can remove all configs except:
> >>
> >> benchmark-multicast.properties
> >>
> >> benchmark.properties
> >>
> >> ignite-base-config.xml
> >>
> >> ignite-localhost-config.xml
> >>
> >> ignite-multicast-config.xml
> >>
> >> 2016-12-28 2:49 GMT+03:00 Denis Magda :
> >>
> >>> I would have only those configs that are useful. Ilya Suntsov,
> basing
>  on
> >>> your experience, please suggest which configs makes sense to
> include
>  into
> >>> every Ignite release.
> >>>
> >>> Oleg, also please note that community decided to include not only
> the
> >>> benchmarking binaries but the sources as well into every Apache
> >> Ignite
> >>> release. I’ve update the ticket before. Hope you followed the
>  discussion
> >> ;)
> >>> https://issues.apache.org/jira/browse/IGNITE-4212?
> >>> focusedCommentId=15765151&page=com.atlassian.jira.
> >>> plugin.system.issuetabpanels:comment-tabpanel#comment-15765151
> >>>
> >>> —
> >>> Denis
> >>>
>  On Dec 27, 2016, at 5:35 AM, Oleg Ostanin 
> >> wrote:
> 
> >

[jira] [Created] (IGNITE-4645) Best effort to avoid extra copying in binary marshaller

2017-02-02 Thread Yakov Zhdanov (JIRA) 
Yakov Zhdanov created IGNITE-4645:
-

 Summary: Best effort to avoid extra copying in binary marshaller
 Key: IGNITE-4645
 URL: https://issues.apache.org/jira/browse/IGNITE-4645
 Project: Ignite
  Issue Type: Bug
  Components: binary
Reporter: Yakov Zhdanov
 Fix For: 1.9


If we marshal a class that contain only primitives then we can predict the 
final byte array size and avoid copies to grow array and final trimming.



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

Re: moving to geronimo JCache jar

2017-02-02 Thread Anton Vinogradov 
Val,

cache-api lib license at maven now looks like

JSR-000107 JCACHE 2.9 Public Review - Updated Specification License
> https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt


and I see replacement at pull-request related to this thread

#if ( $license.name.contains("JSR-000107 JCACHE 2.9 Public Review") )
   #set( $licenseName = "Apache License, Version 2.0" )

and I don't like it :)

Denis,

As you can see https://github.com/jsr107/jsr107spec/blob/master/pom.xml has
version 1.*1*.0-SNAPSHOT and it's just not released at maven.
Can we ask cache-api team to release it?

Anyways, I see no issues here, we just have to keep current license

JSR-000107 JCACHE 2.9 Public Review - Updated Specification License
> https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt


and wait for cache-api 1.*1*.0 release.

On Wed, Feb 1, 2017 at 11:03 PM, Denis Magda  wrote:

> Guys,
>
> JSR 107 spec as well as the reference implementation were updated in all
> the places:
> https://github.com/jsr107/jsr107spec/blob/master/LICENSE.txt <
> https://github.com/jsr107/jsr107spec/blob/master/LICENSE.txt>
> https://github.com/jsr107/jsr107spec/blob/master/pom.xml <
> https://github.com/jsr107/jsr107spec/blob/master/pom.xml>
> https://github.com/jsr107/RI/blob/master/LICENSE.txt <
> https://github.com/jsr107/RI/blob/master/LICENSE.txt>
> https://github.com/jsr107/RI/blob/master/pom.xml <
> https://github.com/jsr107/RI/blob/master/pom.xml>
>
> Even if you go to Maven
> https://mvnrepository.com/artifact/javax.cache/cache-api/1.0.0 <
> https://mvnrepository.com/artifact/javax.cache/cache-api/1.0.0>
>
> and scroll down to Licenses section then you will see the following
>
> License URL
> JSR-000107 JCACHE 2.9 Public Review - Updated Specification License
> https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt <
> https://raw.github.com/jsr107/jsr107spec/master/LICENSE.txt>
>
> But if anyone clicks on the link he will see that, in fact, Maven shows
> outdated information.
>
> So, it’s Maven’s issue not ours. It might be fixed soon. We as a product
> that uses JSR 107 are free to claim in our license files that this JSR
> already conforms to Apache 2.0.
>
> —
> Denis
>
> > On Feb 1, 2017, at 3:08 AM, Alexander Fedotov <
> alexander.fedot...@gmail.com> wrote:
> >
> > Igniters, please advise on it.
> >
> > Also, does anyone know whether it's allowable by Apache License, Version
> > 2.0 to create a custom build and provide it via
> > Nexus, Artifactory, you name it. Currently, both the license and POM at
> > JSR107 GitHub are conformant, so it's just a matter
> > of a build being provided.
> >
> > On Wed, Feb 1, 2017 at 1:52 PM, Anton Vinogradov <
> avinogra...@gridgain.com>
> > wrote:
> >
> >> Guys,
> >>
> >> I've checked review and I don't like replacement "JSR 107  " with
> >> "Apache 2.0" even given they are equals.
> >> We should provide licenses way it is, even in case it so sophisticated
> :)
> >>
> >> On Wed, Feb 1, 2017 at 1:20 PM, Alexander Fedotov <
> >> alexander.fedot...@gmail.com> wrote:
> >>
> >>> PR updated
> >>>
> >>> On Tue, Jan 31, 2017 at 10:42 PM, Alexander Fedotov <
> >>> alexander.fedot...@gmail.com> wrote:
> >>>
>  Denis, it is my mistake to leave the header unchanged.
>  It should be fixed because from now on the generation of license notes
> >>> for
>  dependencies under Apache Software License is enabled according to the
>  point 3 in JIRA .
>  I'll fix it and your notes in Upsource and update the PR.
> 
> 
> 
>  On Tue, Jan 31, 2017 at 10:30 PM, Denis Magda 
> >> wrote:
> 
> > Alexander, provided review notes in the Upsource.
> >
> > However, I’m still a bit concerned about the content of
> > ignite-core-licenses.txt (see attached). The file says that it
> >> contains
> > licenses different from the Apache Software license but in fact lists
> > shmem, Intellij IDEA annotations and JSR 107 all of which are
> >> available
> > under Apache 2.0.
> >
> > Why is this so? Can someone explain? Dmitriy, probable you know the
> > reason.
> >
> >
> > —
> > Denis
> >
> >
> >> On Jan 30, 2017, at 12:19 PM, Denis Magda 
> >> wrote:
> >>
> >> Alexander, thanks!
> >>
> >> I’ll review it in the nearest couple of days.
> >>
> >> —
> >> Denis
> >>
> >>> On Jan 30, 2017, at 5:10 AM, Alexander Fedotov <
> > alexander.fedot...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Created Upsource review for the subject:
> >>> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-82
> >>>
> >>> On Mon, Jan 30, 2017 at 11:52 AM, Alexander Fedotov <
> >>> alexander.fedot...@gmail.com> wrote:
> >>>
>  Hi all,
> 
>  https://issues.apache.org/jira/browse/IGNITE-3793 is completed.
>  Kindly take a look at the corresponding PR
> > https://github.com/apache/i
>

[jira] [Created] (IGNITE-4644) Value from IgniteQueue in atomic mode could be lost

2017-02-02 Thread Dmitry Karachentsev (JIRA) 
Dmitry Karachentsev created IGNITE-4644:
---

 Summary: Value from IgniteQueue in atomic mode could be lost
 Key: IGNITE-4644
 URL: https://issues.apache.org/jira/browse/IGNITE-4644
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8
Reporter: Dmitry Karachentsev


Assume following case (operations are going concurrently):
1) Client1 -> offer. Add new index in queue.
2) On Client1 happens JVM pause or short-time problem with connectivity to 
cluster longer than 3 sec.
3) Client2 -> poll. Get index from cache, but no value available.
4) Client2 checks for value about 3 sec and if no value appears, just skip it.

Should be fixed somehow or make timeout configurable.



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