Release branch v1.4 is created.

2015-09-02 Thread Vladimir Ozerov 
Igniters,

I created "ignite-1.4" branch from which the nearest release will be
created.

Re: SVN changes

2015-09-02 Thread Dmitriy Setrakyan 
On Tue, Sep 1, 2015 at 8:01 PM, Branko Čibej  wrote:

> On 02.09.2015 03:26, Dmitriy Setrakyan wrote:
> > Brane,
> >
> > Since recently I am constantly asked to confirm an SVN certificate before
> > updating or committing. This is really hurting my productivity :)
>
> Yeah, right, one extra keypress, heh.
>
> > Any advise on how this can be fixed?
>
> You should be able to permanently trust the certificate (that Infra
> replaced a while ago). Can you show me the command-line transcript from
> an svn commit? If the client doesn't offer you to permanently trust the
> cert, you're probably Doing Something Wrong™. Don't forget to include
> the output of 'svn --version'.
>

Brane, the situation is actually the reverse. The client always offers to
accept a certificate every time I execute any SVN command, even after  I
had already previously accepted it "permanently".

Here is the output of "svn --version":

--
dsetmac:root $ svn --version
svn, version 1.7.19 (r1643991)
   compiled Jun 17 2015, 13:48:11

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using
Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
  - handles 'http' scheme
  - handles 'https' scheme
---


> -- Brane
>

Documenting Cache Expirations

2015-09-02 Thread Dmitriy Setrakyan 
Igniters,

I just noticed that Cache Expirations are not documented (probably because
they are part of the JCache spec). Nevertheless, we have documentation for
Eviction Policies [1], and I think that not having time-based expiration
policies (ExpiryPolicy) there creates an impression that we don't have it.

Can someone who knows how ExpiryPolicy works in detail document it?

[1] https://apacheignite.readme.io/docs/evictions

Thanks,
D.

IGNITE-1195

2015-09-02 Thread Sergey Kozlov 
Hi Igniters

I suppose that issue below won't be fixed in nearest release 1.4.

IGNITE-1195 Released Ignite version 1.3.0 does not build with
-Dhadoop.version=2.6.0 

Thus I think we need to update DEVNOTES.txt and add workaround for building
hadoop edition for particular hadoop version. It could be something like
that:

*Ignite Hadoop Accelerator Maven Build Instructions*
**
*mvn clean package -DskipTests -Dignite.edition=hadoop
[-Dhadoop.version=X.X.X]*

*Use 'hadoop.version' parameter to build Ignite against a specific Hadoop
version. Due known issue IGNITE-1195
(https://issues.apache.org/jira/browse/IGNITE-1195
) module yarn must be
excluded for this case:*

*1. For maven version prior 3.2.1 **comment
out modules/yarn in pom.xml and build.*

*2. For maven version 3.2.1 or newest:  *
*mvn clean package -DskipTests -Dignite.edition=hadoop
-Dhadoop.version=X.X.X -pl !module/yarn*

Thoughts? Objections?

-- 
Sergey Kozlov

Queries failures on CI

2015-09-02 Thread Alexey Goncharuk 
Folks,

Did we make any changes to Indexing lately? I see that queries suite is
failing in 1.4/master branch with the following assertion. If this is a
known issue, can we at least properly mute the test so that it does not
overtime? Test is
*IgniteCacheQueryEvictsMultiThreadedSelfTest.testMultiThreadedSwapUnswapLongString*

[02:39:01]W: [org.apache.ignite:ignite-indexing]
[02:39:01,929][ERROR][ignite-#834%sys-cache.IgniteCacheQueryEvictsMultiThreadedSelfTest1%][GridNearTxLocal]
Heuristic transaction failure.
[02:39:01]W: [org.apache.ignite:ignite-indexing] class
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
Failed to locally write to cache (all transaction entries will be
invalidated, however there was a window when entries for this transaction
were visible to others): GridDhtTxLocal
[nearNodeId=00a2b8a1-198c-45f3-aa82-adb33ee55000,
nearFutId=37ef1969f41-ec90ce17-5c89-4a99-8cb1-5cec40fa2958,
nearMiniId=57ef1969f41-ec90ce17-5c89-4a99-8cb1-5cec40fa2958,
nearFinFutId=null, nearFinMiniId=null, nearXidVer=GridCacheVersion
[topVer=52716956, nodeOrderDrId=3, globalTime=1441237141914,
order=1441261300138], super=GridDhtTxLocalAdapter [dhtThreadId=1391,
needsCompletedVers=true, nearNodes=[],
dhtNodes=[203cbcf4-42ed-4206-862a-fb103ccc4002], explicitLock=false,
super=IgniteTxLocalAdapter [txMap={IgniteTxKey [key=KeyCacheObjectImpl
[val=295, hasValBytes=true], cacheId=1]=IgniteTxEntry
[key=KeyCacheObjectImpl [val=295, hasValBytes=true], cacheId=1,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=295, hasValBytes=true],
cacheId=1], val=[op=CREATE, val=CacheObjectImpl [val=5661,
hasValBytes=true]], prevVal=[op=NOOP, val=null], entryProcessorsCol=null,
entryProcessorCalcVal=null, ttl=-1, conflictExpireTime=-1,
conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
filtersPassed=false, filtersSet=false, entry=GridDhtCacheEntry
[rdrs=[ReaderId [nodeId=00a2b8a1-198c-45f3-aa82-adb33ee55000,
msgId=5878442, txFut=null]], locPart=GridDhtLocalPartition [id=295,
mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=31, idxGen=245],
state=OWNING, reservations=0, empty=false, createTime=09/03/2015 02:35:53,
mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry
[key=KeyCacheObjectImpl [val=295, hasValBytes=true], val=null,
startVer=1441237229285, ver=GridCacheVersion [topVer=52716956,
nodeOrderDrId=2, globalTime=1441237141794, order=1441261274992],
hash=1602434376, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
[locs=[GridCacheMvccCandidate [nodeId=10bea8f9-0e89-43b9-aca4-593722da0001,
ver=GridCacheVersion [topVer=52716956, nodeOrderDrId=2,
globalTime=1441237141915, order=1441261300364], timeout=0,
ts=1441237141910, threadId=1793, id=4661373, topVer=AffinityTopologyVersion
[topVer=3, minorTopVer=0], reentry=null,
otherNodeId=00a2b8a1-198c-45f3-aa82-adb33ee55000, otherVer=GridCacheVersion
[topVer=52716956, nodeOrderDrId=3, globalTime=1441237141914,
order=1441261300138], mappedDhtNodes=null, mappedNearNodes=null,
ownerVer=null, key=KeyCacheObjectImpl [val=295, hasValBytes=true],
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0,
prevVer=null, nextVer=null]], rmts=null]], flags=3]]], prepared=true,
locked=false, nodeId=null, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, xidVer=null]}, completedBase=null,
sndTransformedVals=false, super=IgniteTxAdapter [xidVer=GridCacheVersion
[topVer=52716956, nodeOrderDrId=2, globalTime=1441237141915,
order=1441261300364], writeVer=GridCacheVersion [topVer=52716956,
nodeOrderDrId=2, globalTime=1441237141915, order=1441261300365],
implicit=true, implicitSingle=true, loc=true, threadId=1793,
startTime=1441237141910, nodeId=10bea8f9-0e89-43b9-aca4-593722da0001,
startVer=GridCacheVersion [topVer=52716956, nodeOrderDrId=2,
globalTime=1441237141915, order=1441261300364], endVer=null,
isolation=READ_COMMITTED, concurrency=OPTIMISTIC, timeout=0,
sysInvalidate=false, sys=false, plc=2, commitVer=null,
finalizing=USER_FINISH, preparing=false, state=COMMITTING, timedOut=false,
topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], duration=0ms,
onePhaseCommit=true], size=1]]]
[02:39:01]W: [org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:1036)
[02:39:01]W: [org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.finish(GridDhtTxLocalAdapter.java:794)
[02:39:01]W: [org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finish(GridDhtTxLocal.java:655)
[02:39:01]W: [org.apache.ignite:ignite-indexing] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitAsync(GridDhtTxLocal.java:555)
[02:39:01]W: [org.apache.ignite:ignite-indexing] at

Re: Portable objects

2015-09-02 Thread Denis Magda 

Val,

Yes, the portable API and its implementation is already a part of both 
master and 1.4 branches.


--
Denis

On 9/2/2015 11:54 PM, Valentin Kulichenko wrote:

Igniters,

Are portable objects already migrated and will be released as a part of 1.4
(I see that APIs and configuration changes are already in master)? I just
thought it's a pretty big change and we were going to include it only in
1.5, correct me if I'm wrong.

-Val

Re: IGNITE-1195

2015-09-02 Thread Sergey Kozlov 
It's not for 2.6.0 only. Same issue are for 2.5.2 and 2.7.1

On Wed, Sep 2, 2015 at 10:28 PM, Dmitriy Setrakyan 
wrote:

> Is there any reason why support for the Hadoop 2.6 version is not going to
> work? Can someone describe what needs to be done for us to fix this?
>
> On Wed, Sep 2, 2015 at 11:58 AM, Sergey Kozlov 
> wrote:
>
> > Hi Igniters
> >
> > I suppose that issue below won't be fixed in nearest release 1.4.
> >
> > IGNITE-1195 Released Ignite version 1.3.0 does not build with
> > -Dhadoop.version=2.6.0 <
> https://issues.apache.org/jira/browse/IGNITE-1195>
> >
> > Thus I think we need to update DEVNOTES.txt and add workaround for
> building
> > hadoop edition for particular hadoop version. It could be something like
> > that:
> >
> > *Ignite Hadoop Accelerator Maven Build Instructions*
> > **
> > *mvn clean package -DskipTests -Dignite.edition=hadoop
> > [-Dhadoop.version=X.X.X]*
> >
> > *Use 'hadoop.version' parameter to build Ignite against a specific Hadoop
> > version. Due known issue IGNITE-1195
> > (https://issues.apache.org/jira/browse/IGNITE-1195
> > ) module yarn must be
> > excluded for this case:*
> >
> > *1. For maven version prior 3.2.1 **comment
> > out modules/yarn in pom.xml and build.*
> >
> > *2. For maven version 3.2.1 or newest:  *
> > *mvn clean package -DskipTests -Dignite.edition=hadoop
> > -Dhadoop.version=X.X.X -pl !module/yarn*
> >
> > Thoughts? Objections?
> >
> > --
> > Sergey Kozlov
> >
>



-- 
Sergey Kozlov

Portable objects

2015-09-02 Thread Valentin Kulichenko 
Igniters,

Are portable objects already migrated and will be released as a part of 1.4
(I see that APIs and configuration changes are already in master)? I just
thought it's a pretty big change and we were going to include it only in
1.5, correct me if I'm wrong.

-Val

Re: IGNITE-1195

2015-09-02 Thread Dmitriy Setrakyan 
On Wed, Sep 2, 2015 at 12:31 PM, Sergey Kozlov  wrote:

> It's not for 2.6.0 only. Same issue are for 2.5.2 and 2.7.1
>

I think the same question stands - what is the main challenge here?


>
> On Wed, Sep 2, 2015 at 10:28 PM, Dmitriy Setrakyan 
> wrote:
>
> > Is there any reason why support for the Hadoop 2.6 version is not going
> to
> > work? Can someone describe what needs to be done for us to fix this?
> >
> > On Wed, Sep 2, 2015 at 11:58 AM, Sergey Kozlov 
> > wrote:
> >
> > > Hi Igniters
> > >
> > > I suppose that issue below won't be fixed in nearest release 1.4.
> > >
> > > IGNITE-1195 Released Ignite version 1.3.0 does not build with
> > > -Dhadoop.version=2.6.0 <
> > https://issues.apache.org/jira/browse/IGNITE-1195>
> > >
> > > Thus I think we need to update DEVNOTES.txt and add workaround for
> > building
> > > hadoop edition for particular hadoop version. It could be something
> like
> > > that:
> > >
> > > *Ignite Hadoop Accelerator Maven Build Instructions*
> > > **
> > > *mvn clean package -DskipTests -Dignite.edition=hadoop
> > > [-Dhadoop.version=X.X.X]*
> > >
> > > *Use 'hadoop.version' parameter to build Ignite against a specific
> Hadoop
> > > version. Due known issue IGNITE-1195
> > > (https://issues.apache.org/jira/browse/IGNITE-1195
> > > ) module yarn must
> be
> > > excluded for this case:*
> > >
> > > *1. For maven version prior 3.2.1 **comment
> > > out modules/yarn in pom.xml and build.*
> > >
> > > *2. For maven version 3.2.1 or newest:  *
> > > *mvn clean package -DskipTests -Dignite.edition=hadoop
> > > -Dhadoop.version=X.X.X -pl !module/yarn*
> > >
> > > Thoughts? Objections?
> > >
> > > --
> > > Sergey Kozlov
> > >
> >
>
>
>
> --
> Sergey Kozlov
>

Re: SVN changes

2015-09-02 Thread Dmitriy Setrakyan 
On Wed, Sep 2, 2015 at 2:53 AM, Branko Čibej  wrote:
>
> Also, any info about the platform you're using, and what kind of
> authentication store you're using (KWallet? Gnome Keyring? OSX
> Keychain?) would be useful here.
>

I am running on Mac. To my knowledge I am not using any authentication
store.

I should also mention that this started happening after Apache SVN was
upgraded to a newer version recently.

D.

Re: Coding style changed!

2015-09-02 Thread Anton Vinogradov 
Because we should have no mistakes at Ignite Java.
Checking that build logs contains no "Javadoc Warnings" helps to guarantee
that.

On Wed, Sep 2, 2015 at 2:02 PM, Sergi Vladykin 
wrote:

> I think these warnings are valid, since we are really using proprietary
> APIs like Unsafe.
> Why should we hide them?
>
> Sergi
>
> 2015-09-01 16:29 GMT+03:00 Anton Vinogradov :
>
> > Hello,
> >
> > Since codestyle was changed javadoc starts to warn about using of
> > proprietary API.
> >
> > For example:
> > Javadoc Warnings
> >
> >
> ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java:29:
> > warning: Unsafe is internal proprietary API and may be removed in a
> future
> > release
> > import sun.misc.Unsafe;
> >
> > Using import sun.misc.* solves this problem. IDEA codestyle can be
> > configured to use implicit imports for specified packages.
> > Specifying sun.misc, sun.nio.ch, com.sun.jmx.mbeanserver fixed build
> > output.
> >
> > Does anybody know other way to suspend this warning without suspending
> > others?
> >
> >
> > On Tue, Sep 1, 2015 at 9:21 AM, Denis Magda  wrote:
> >
> > > I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to reflect the
> > > changes.
> > >
> > > --
> > > Denis
> > >
> > >
> > > On 8/31/2015 5:48 PM, Sergi Vladykin wrote:
> > >
> > >> Guys,
> > >>
> > >> As discussed, I changed all the imports in master to explicit ones.
> > >>
> > >> Settings for Idea you can see here:
> > >>
> > >>
> >
> https://issues.apache.org/jira/secure/attachment/12753298/Screen%20Shot%202015-08-31%20at%202.18.27%20PM.png
> > >>
> > >> Coding guidelines will be updated soon.
> > >>
> > >> Sergi
> > >>
> > >>
> > >
> >
>

Re: Coding style changed!

2015-09-02 Thread Sergi Vladykin 
Can we ignore this this type of warning in JavaDoc checker?
I don't like the idea of having some special imports because of that.

Sergi

2015-09-02 14:32 GMT+03:00 Anton Vinogradov :

> .. I mean at Ignite Javadoc
>
> On Wed, Sep 2, 2015 at 2:31 PM, Anton Vinogradov  >
> wrote:
>
> > Because we should have no mistakes at Ignite Java.
> > Checking that build logs contains no "Javadoc Warnings" helps to
> guarantee
> > that.
> >
> > On Wed, Sep 2, 2015 at 2:02 PM, Sergi Vladykin  >
> > wrote:
> >
> >> I think these warnings are valid, since we are really using proprietary
> >> APIs like Unsafe.
> >> Why should we hide them?
> >>
> >> Sergi
> >>
> >> 2015-09-01 16:29 GMT+03:00 Anton Vinogradov :
> >>
> >> > Hello,
> >> >
> >> > Since codestyle was changed javadoc starts to warn about using of
> >> > proprietary API.
> >> >
> >> > For example:
> >> > Javadoc Warnings
> >> >
> >> >
> >>
> ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java:29:
> >> > warning: Unsafe is internal proprietary API and may be removed in a
> >> future
> >> > release
> >> > import sun.misc.Unsafe;
> >> >
> >> > Using import sun.misc.* solves this problem. IDEA codestyle can be
> >> > configured to use implicit imports for specified packages.
> >> > Specifying sun.misc, sun.nio.ch, com.sun.jmx.mbeanserver fixed build
> >> > output.
> >> >
> >> > Does anybody know other way to suspend this warning without suspending
> >> > others?
> >> >
> >> >
> >> > On Tue, Sep 1, 2015 at 9:21 AM, Denis Magda 
> >> wrote:
> >> >
> >> > > I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to reflect
> >> the
> >> > > changes.
> >> > >
> >> > > --
> >> > > Denis
> >> > >
> >> > >
> >> > > On 8/31/2015 5:48 PM, Sergi Vladykin wrote:
> >> > >
> >> > >> Guys,
> >> > >>
> >> > >> As discussed, I changed all the imports in master to explicit ones.
> >> > >>
> >> > >> Settings for Idea you can see here:
> >> > >>
> >> > >>
> >> >
> >>
> https://issues.apache.org/jira/secure/attachment/12753298/Screen%20Shot%202015-08-31%20at%202.18.27%20PM.png
> >> > >>
> >> > >> Coding guidelines will be updated soon.
> >> > >>
> >> > >> Sergi
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >
> >
>

[GitHub] ignite pull request: ignite-1351: move portable API examples

2015-09-02 Thread dmagda 
GitHub user dmagda opened a pull request:

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

ignite-1351: move portable API examples

Refer to https://issues.apache.org/jira/browse/IGNITE-1351 for more info

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

$ git pull https://github.com/dmagda/incubator-ignite ignite-1351

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

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


commit ad887c16975ef4a06d19547302e455724552fe83
Author: Denis Magda 
Date:   2015-09-02T09:11:26Z

ignite-1351: moved (open sourced) portable API examples from GridGain to 
Ignite




---
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: IGNITE-1354 Platform: AFTER_GRID_STOP lifecyc...

2015-09-02 Thread ptupitsyn 
GitHub user ptupitsyn opened a pull request:

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

IGNITE-1354 Platform: AFTER_GRID_STOP lifecycle events do not work

Filter AfterStop events on Java side.

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

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

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

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


commit d734b6e4dfcb79c7707f3f55abc445674e23409a
Author: ptupitsyn 
Date:   2015-09-02T10:08:56Z

IGNITE-1354 Platform: AFTER_GRID_STOP lifecycle events do not work

Filter AfterStop events on Java side.




---
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: IGNITE-1354 Platform: AFTER_GRID_STOP lifecyc...

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

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


---
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-1355) Potential NPE in CacheAffinityProxy

2015-09-02 Thread Semen Boikov (JIRA) 
Semen Boikov created IGNITE-1355:


 Summary: Potential NPE in CacheAffinityProxy
 Key: IGNITE-1355
 URL: https://issues.apache.org/jira/browse/IGNITE-1355
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Semen Boikov
Assignee: Yakov Zhdanov
 Fix For: ignite-1.5


NPE was observed on TC:
{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor$AffinityInfo.access$1800(GridAffinityProcessor.java:537)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor$CacheAffinityProxy.mapPartitionToPrimaryAndBackups(GridAffinityProcessor.java:879)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:423)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheCrossCacheTxFailoverTest.crossCacheTxFailover(IgniteCacheCrossCacheTxFailoverTest.java:355)
{noformat}

As I see method CacheAffinityProxy.cache() can return null, but there are no 
checks for null.



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

Re: Coding style changed!

2015-09-02 Thread Sergi Vladykin 
I think these warnings are valid, since we are really using proprietary
APIs like Unsafe.
Why should we hide them?

Sergi

2015-09-01 16:29 GMT+03:00 Anton Vinogradov :

> Hello,
>
> Since codestyle was changed javadoc starts to warn about using of
> proprietary API.
>
> For example:
> Javadoc Warnings
>
> ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java:29:
> warning: Unsafe is internal proprietary API and may be removed in a future
> release
> import sun.misc.Unsafe;
>
> Using import sun.misc.* solves this problem. IDEA codestyle can be
> configured to use implicit imports for specified packages.
> Specifying sun.misc, sun.nio.ch, com.sun.jmx.mbeanserver fixed build
> output.
>
> Does anybody know other way to suspend this warning without suspending
> others?
>
>
> On Tue, Sep 1, 2015 at 9:21 AM, Denis Magda  wrote:
>
> > I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to reflect the
> > changes.
> >
> > --
> > Denis
> >
> >
> > On 8/31/2015 5:48 PM, Sergi Vladykin wrote:
> >
> >> Guys,
> >>
> >> As discussed, I changed all the imports in master to explicit ones.
> >>
> >> Settings for Idea you can see here:
> >>
> >>
> https://issues.apache.org/jira/secure/attachment/12753298/Screen%20Shot%202015-08-31%20at%202.18.27%20PM.png
> >>
> >> Coding guidelines will be updated soon.
> >>
> >> Sergi
> >>
> >>
> >
>

[GitHub] ignite pull request: ignite-1353: fixed type resolving conflicts i...

2015-09-02 Thread dmagda 
GitHub user dmagda opened a pull request:

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

ignite-1353: fixed type resolving conflicts in portable context

Refer to https://issues.apache.org/jira/browse/IGNITE-1353 for more details.

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

$ git pull https://github.com/dmagda/incubator-ignite ignite-1353

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

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


commit c1d60ad1644482992490146f768479d601b2d197
Author: Denis Magda 
Date:   2015-09-02T13:32:08Z

ignite-1353: fixed type resolving conflicts between predefined and user 
types




---
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-1360) Extend platform processor lifecycle.

2015-09-02 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1360:
---

 Summary: Extend platform processor lifecycle.
 Key: IGNITE-1360
 URL: https://issues.apache.org/jira/browse/IGNITE-1360
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.5


Currently platform processor lifecycle is the same as for all other processors 
wiht 4 callbacks: onStart, onKernalStart, onKernalStop, onStop.

This appears to be not enough for platforms. IN particular, it doesn't let us 
flush all write-behind store data correctly and doesn't allow for normal 
AFTER_NODE_STOP lifecycle callback.
Also it makes platfomr initialization more painful because some callbacks might 
reach the platform when it is not initialized yet.

To mitigate this problem we should extend platform processor with two more 
callbacks: "onBeforeStart" and "onAfterStop". Careful management of these 
callbacks will let us get rid of all aforementioned problems.



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

Re: Coding style changed!

2015-09-02 Thread Anton Vinogradov 
Problem fixed using top secret -XDenableSunApiLintControl param.
Thanks for stopping me :)

On Wed, Sep 2, 2015 at 3:30 PM, Anton Vinogradov 
wrote:

> I did not found how to do that, will try to search again.
>
>
> On Wed, Sep 2, 2015 at 3:01 PM, Sergi Vladykin 
> wrote:
>
>> Can we ignore this this type of warning in JavaDoc checker?
>> I don't like the idea of having some special imports because of that.
>>
>> Sergi
>>
>> 2015-09-02 14:32 GMT+03:00 Anton Vinogradov :
>>
>> > .. I mean at Ignite Javadoc
>> >
>> > On Wed, Sep 2, 2015 at 2:31 PM, Anton Vinogradov <
>> avinogra...@gridgain.com
>> > >
>> > wrote:
>> >
>> > > Because we should have no mistakes at Ignite Java.
>> > > Checking that build logs contains no "Javadoc Warnings" helps to
>> > guarantee
>> > > that.
>> > >
>> > > On Wed, Sep 2, 2015 at 2:02 PM, Sergi Vladykin <
>> sergi.vlady...@gmail.com
>> > >
>> > > wrote:
>> > >
>> > >> I think these warnings are valid, since we are really using
>> proprietary
>> > >> APIs like Unsafe.
>> > >> Why should we hide them?
>> > >>
>> > >> Sergi
>> > >>
>> > >> 2015-09-01 16:29 GMT+03:00 Anton Vinogradov <
>> avinogra...@gridgain.com>:
>> > >>
>> > >> > Hello,
>> > >> >
>> > >> > Since codestyle was changed javadoc starts to warn about using of
>> > >> > proprietary API.
>> > >> >
>> > >> > For example:
>> > >> > Javadoc Warnings
>> > >> >
>> > >> >
>> > >>
>> >
>> ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java:29:
>> > >> > warning: Unsafe is internal proprietary API and may be removed in a
>> > >> future
>> > >> > release
>> > >> > import sun.misc.Unsafe;
>> > >> >
>> > >> > Using import sun.misc.* solves this problem. IDEA codestyle can be
>> > >> > configured to use implicit imports for specified packages.
>> > >> > Specifying sun.misc, sun.nio.ch, com.sun.jmx.mbeanserver fixed
>> build
>> > >> > output.
>> > >> >
>> > >> > Does anybody know other way to suspend this warning without
>> suspending
>> > >> > others?
>> > >> >
>> > >> >
>> > >> > On Tue, Sep 1, 2015 at 9:21 AM, Denis Magda 
>> > >> wrote:
>> > >> >
>> > >> > > I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to
>> reflect
>> > >> the
>> > >> > > changes.
>> > >> > >
>> > >> > > --
>> > >> > > Denis
>> > >> > >
>> > >> > >
>> > >> > > On 8/31/2015 5:48 PM, Sergi Vladykin wrote:
>> > >> > >
>> > >> > >> Guys,
>> > >> > >>
>> > >> > >> As discussed, I changed all the imports in master to explicit
>> ones.
>> > >> > >>
>> > >> > >> Settings for Idea you can see here:
>> > >> > >>
>> > >> > >>
>> > >> >
>> > >>
>> >
>> https://issues.apache.org/jira/secure/attachment/12753298/Screen%20Shot%202015-08-31%20at%202.18.27%20PM.png
>> > >> > >>
>> > >> > >> Coding guidelines will be updated soon.
>> > >> > >>
>> > >> > >> Sergi
>> > >> > >>
>> > >> > >>
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>

[jira] [Created] (IGNITE-1356) Move platforms Java public API to Ignite.

2015-09-02 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1356:
---

 Summary: Move platforms Java public API to Ignite.
 Key: IGNITE-1356
 URL: https://issues.apache.org/jira/browse/IGNITE-1356
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.5






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

[jira] [Created] (IGNITE-1352) Platforms: move cpp and .Net examples to Ignite

2015-09-02 Thread Denis Magda (JIRA) 
Denis Magda created IGNITE-1352:
---

 Summary: Platforms: move cpp and .Net examples to Ignite
 Key: IGNITE-1352
 URL: https://issues.apache.org/jira/browse/IGNITE-1352
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Vladimir Ozerov


Move the platform examples to Ignite.

Portable API examples have already been moved and the changes should be 
committed to the master soon. Track IGNITE-1351 status for that.

When the platform examples are moved make sure that 
{{CacheClientPortableCrossPlatformExample}} works as expected.



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

Re: SVN changes

2015-09-02 Thread Branko Čibej 
On 02.09.2015 09:27, Dmitriy Setrakyan wrote:
> On Tue, Sep 1, 2015 at 8:01 PM, Branko Čibej  wrote:
>
>> On 02.09.2015 03:26, Dmitriy Setrakyan wrote:
>>> Brane,
>>>
>>> Since recently I am constantly asked to confirm an SVN certificate before
>>> updating or committing. This is really hurting my productivity :)
>> Yeah, right, one extra keypress, heh.
>>
>>> Any advise on how this can be fixed?
>> You should be able to permanently trust the certificate (that Infra
>> replaced a while ago). Can you show me the command-line transcript from
>> an svn commit? If the client doesn't offer you to permanently trust the
>> cert, you're probably Doing Something Wrong™. Don't forget to include
>> the output of 'svn --version'.
>>
> Brane, the situation is actually the reverse. The client always offers to
> accept a certificate every time I execute any SVN command, even after  I
> had already previously accepted it "permanently".
>
> Here is the output of "svn --version":
>
> --
> dsetmac:root $ svn --version
> svn, version 1.7.19 (r1643991)
>compiled Jun 17 2015, 13:48:11
>
> Copyright (C) 2014 The Apache Software Foundation.
> This software consists of contributions made by many people; see the NOTICE
> file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using
> Neon.
>   - handles 'http' scheme
>   - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.
>   - handles 'http' scheme
>   - handles 'https' scheme
> ---

What's the value of the store-auth-creds setting in your
~/.subversion/servers or /etc/subversion/servers file?

-- Brane

[jira] [Created] (IGNITE-1353) PortableContext.typeId() incorrectly resolves type ID for predefined system types.

2015-09-02 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1353:
---

 Summary: PortableContext.typeId() incorrectly resolves type ID for 
predefined system types.
 Key: IGNITE-1353
 URL: https://issues.apache.org/jira/browse/IGNITE-1353
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.4


See PortableContext.typeId() method.
First it checks whether type is "system", and only then try picking predefiend 
ID. As a result, predefined types like IgniteBiTuple are written with wrong IDs.



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

Re: SVN changes

2015-09-02 Thread Branko Čibej 
On 02.09.2015 11:29, Branko Čibej wrote:
> On 02.09.2015 09:27, Dmitriy Setrakyan wrote:
>> On Tue, Sep 1, 2015 at 8:01 PM, Branko Čibej  wrote:
>>
>>> On 02.09.2015 03:26, Dmitriy Setrakyan wrote:
 Brane,

 Since recently I am constantly asked to confirm an SVN certificate before
 updating or committing. This is really hurting my productivity :)
>>> Yeah, right, one extra keypress, heh.
>>>
 Any advise on how this can be fixed?
>>> You should be able to permanently trust the certificate (that Infra
>>> replaced a while ago). Can you show me the command-line transcript from
>>> an svn commit? If the client doesn't offer you to permanently trust the
>>> cert, you're probably Doing Something Wrong™. Don't forget to include
>>> the output of 'svn --version'.
>>>
>> Brane, the situation is actually the reverse. The client always offers to
>> accept a certificate every time I execute any SVN command, even after  I
>> had already previously accepted it "permanently".
>>
>> Here is the output of "svn --version":
>>
>> --
>> dsetmac:root $ svn --version
>> svn, version 1.7.19 (r1643991)
>>compiled Jun 17 2015, 13:48:11
>>
>> Copyright (C) 2014 The Apache Software Foundation.
>> This software consists of contributions made by many people; see the NOTICE
>> file for more information.
>> Subversion is open source software, see http://subversion.apache.org/
>>
>> The following repository access (RA) modules are available:
>>
>> * ra_neon : Module for accessing a repository via WebDAV protocol using
>> Neon.
>>   - handles 'http' scheme
>>   - handles 'https' scheme
>> * ra_svn : Module for accessing a repository using the svn network protocol.
>>   - handles 'svn' scheme
>> * ra_local : Module for accessing a repository on local disk.
>>   - handles 'file' scheme
>> * ra_serf : Module for accessing a repository via WebDAV protocol using
>> serf.
>>   - handles 'http' scheme
>>   - handles 'https' scheme
>> ---
> What's the value of the store-auth-creds setting in your
> ~/.subversion/servers or /etc/subversion/servers file?

Also, any info about the platform you're using, and what kind of
authentication store you're using (KWallet? Gnome Keyring? OSX
Keychain?) would be useful here.

-- Brane

Re: Ignite 1.4

2015-09-02 Thread Yakov Zhdanov 
Yes, we will be moving almost all the issues to further versions.

Branch has already been created.

--Yakov

2015-09-01 22:14 GMT+03:00 Branko Čibej :

> On 01.09.2015 20:46, Konstantin Boudnik wrote:
> > On Tue, Sep 01, 2015 at 08:45PM, Sergey Kozlov wrote:
> >> FYI: We've at least 161 unclosed issues planned to fix in version 1.4
> > If there're so many issues to go - perhaps it makes sense not to branch
> out
> > this early to avoid extra merges?
>
> Or just go ahead and release 1.4 and get those issues addressed in 1.5.
> It's not as if skipping a  "planned to fix" issue would be the end of
> the world.
>
> -- Brane
>
>

[jira] [Created] (IGNITE-1359) Inject platform processor into Ignite lifecycle.

2015-09-02 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1359:
---

 Summary: Inject platform processor into Ignite lifecycle.
 Key: IGNITE-1359
 URL: https://issues.apache.org/jira/browse/IGNITE-1359
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.4


Processor creation sequence should be as follows:
1) Ask plugins for their processor. Stop in case of non-null result.
2) Check for PlatformConfiguration. If not null - create fully-fledged 
processor through reflection if it is present in classpath. Stop if created.
3) Return no-op processor.



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

[jira] [Created] (IGNITE-1357) Move Java bootstrap logic to Ignite.

2015-09-02 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-1357:
---

 Summary: Move Java bootstrap logic to Ignite.
 Key: IGNITE-1357
 URL: https://issues.apache.org/jira/browse/IGNITE-1357
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.5






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

[jira] [Created] (IGNITE-1358) PortableMarshaller: 'userType' flag is not written for objects of some types

2015-09-02 Thread Denis Magda (JIRA) 
Denis Magda created IGNITE-1358:
---

 Summary: PortableMarshaller: 'userType' flag is not written for 
objects of some types
 Key: IGNITE-1358
 URL: https://issues.apache.org/jira/browse/IGNITE-1358
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Priority: Critical


The 'userType' flag is not written when the following classes are serialized:
- enums;
- object and enum arrays;
- classes.

This leads to the situation that the predefined types map is ignored during 
deserialization and the type is always considered as user's.

To support this feature requires changes in the portable protocol.

For now there is a workaround in the code.
 



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

Re: Coding style changed!

2015-09-02 Thread Anton Vinogradov 
I did not found how to do that, will try to search again.


On Wed, Sep 2, 2015 at 3:01 PM, Sergi Vladykin 
wrote:

> Can we ignore this this type of warning in JavaDoc checker?
> I don't like the idea of having some special imports because of that.
>
> Sergi
>
> 2015-09-02 14:32 GMT+03:00 Anton Vinogradov :
>
> > .. I mean at Ignite Javadoc
> >
> > On Wed, Sep 2, 2015 at 2:31 PM, Anton Vinogradov <
> avinogra...@gridgain.com
> > >
> > wrote:
> >
> > > Because we should have no mistakes at Ignite Java.
> > > Checking that build logs contains no "Javadoc Warnings" helps to
> > guarantee
> > > that.
> > >
> > > On Wed, Sep 2, 2015 at 2:02 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > > wrote:
> > >
> > >> I think these warnings are valid, since we are really using
> proprietary
> > >> APIs like Unsafe.
> > >> Why should we hide them?
> > >>
> > >> Sergi
> > >>
> > >> 2015-09-01 16:29 GMT+03:00 Anton Vinogradov  >:
> > >>
> > >> > Hello,
> > >> >
> > >> > Since codestyle was changed javadoc starts to warn about using of
> > >> > proprietary API.
> > >> >
> > >> > For example:
> > >> > Javadoc Warnings
> > >> >
> > >> >
> > >>
> >
> ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java:29:
> > >> > warning: Unsafe is internal proprietary API and may be removed in a
> > >> future
> > >> > release
> > >> > import sun.misc.Unsafe;
> > >> >
> > >> > Using import sun.misc.* solves this problem. IDEA codestyle can be
> > >> > configured to use implicit imports for specified packages.
> > >> > Specifying sun.misc, sun.nio.ch, com.sun.jmx.mbeanserver fixed
> build
> > >> > output.
> > >> >
> > >> > Does anybody know other way to suspend this warning without
> suspending
> > >> > others?
> > >> >
> > >> >
> > >> > On Tue, Sep 1, 2015 at 9:21 AM, Denis Magda 
> > >> wrote:
> > >> >
> > >> > > I've updated '{ignite_folder}/idea/ignite_codeStyle.xml' to
> reflect
> > >> the
> > >> > > changes.
> > >> > >
> > >> > > --
> > >> > > Denis
> > >> > >
> > >> > >
> > >> > > On 8/31/2015 5:48 PM, Sergi Vladykin wrote:
> > >> > >
> > >> > >> Guys,
> > >> > >>
> > >> > >> As discussed, I changed all the imports in master to explicit
> ones.
> > >> > >>
> > >> > >> Settings for Idea you can see here:
> > >> > >>
> > >> > >>
> > >> >
> > >>
> >
> https://issues.apache.org/jira/secure/attachment/12753298/Screen%20Shot%202015-08-31%20at%202.18.27%20PM.png
> > >> > >>
> > >> > >> Coding guidelines will be updated soon.
> > >> > >>
> > >> > >> Sergi
> > >> > >>
> > >> > >>
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>