[jira] [Created] (IGNITE-1691) [Test] CacheStopAndDestroySelfTest.testDhtDoubleDestroy fails with NPE sometimes.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1691:
---

 Summary: [Test] CacheStopAndDestroySelfTest.testDhtDoubleDestroy 
fails with NPE sometimes.
 Key: IGNITE-1691
 URL: https://issues.apache.org/jira/browse/IGNITE-1691
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Veselovsky


The problem is that  c.context().config() returns null after the cache was 
cleaned up.
 for (IgniteCacheProxy c : g0.context().cache().jcaches()) {
CacheConfiguration cfg = c.context().config();


java.lang.NullPointerException: null
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:416)
at 
org.apache.ignite.internal.processors.cache.CacheStopAndDestroySelfTest.checkDestroyed(CacheStopAndDestroySelfTest.java:754)
at 
org.apache.ignite.internal.processors.cache.CacheStopAndDestroySelfTest.dhtDestroy(CacheStopAndDestroySelfTest.java:226)
at 
org.apache.ignite.internal.processors.cache.CacheStopAndDestroySelfTest.testDhtDoubleDestroy(CacheStopAndDestroySelfTest.java:199)

Hint: to achieve better reproducibility repeat dhtDestroy(); operation in the 
test not 2, but several tens times.




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

Do we need "IgniteCache.randomEntry()" method?

[Vladimir Ozerov]

Igniters,

We have the ticket about broken randomEntry() method:
https://issues.apache.org/jira/browse/IGNITE-512

This method can return null even if cache is not empty. And it is even
impossible to return an entry in constant time provided that concurrent
deletes and expirations could occur.

Do we really need this method? As for me it is better to deprecate it and
do not spend any efforts trying to make it work.

Thoughts?

[jira] [Created] (IGNITE-1692) [Test] DataStreamProcessorSelfTest.testReplicated fails sometimes.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1692:
---

 Summary: [Test] DataStreamProcessorSelfTest.testReplicated fails 
sometimes.
 Key: IGNITE-1692
 URL: https://issues.apache.org/jira/browse/IGNITE-1692
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Veselovsky


DataStreamProcessorSelfTest.testReplicated fails with ~7% probability with the 
following error:
{code}
org.apache.ignite.IgniteCheckedException: Failed to find server node for cache 
(all affinity nodes have left the grid or cache was stopped): null
at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture$Listener.apply(GridCompoundFuture.java:311)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture$Listener.apply(GridCompoundFuture.java:302)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:262)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:250)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:380)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:334)
at 
org.apache.ignite.testframework.GridTestUtils$5.run(GridTestUtils.java:675)
at 
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:966)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
Caused by: org.apache.ignite.cache.CacheServerNotFoundException: Failed to find 
server node for cache (all affinity nodes have left the grid or cache was 
stopped): null
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1604)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:56)
at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:122)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessorSelfTest$1.call(DataStreamProcessorSelfTest.java:232)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
Caused by: 
org.apache.ignite.internal.cluster.ClusterTopologyServerNotFoundException: 
Failed to find server node for cache (all affinity nodes have left the grid or 
cache was stopped): null
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.nodes(DataStreamerImpl.java:772)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:638)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:547)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:583)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessorSelfTest$1.call(DataStreamProcessorSelfTest.java:226)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
{code}



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

[jira] [Created] (IGNITE-1690) [Test] IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes fails.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1690:
---

 Summary: [Test] 
IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes fails.
 Key: IGNITE-1690
 URL: https://issues.apache.org/jira/browse/IGNITE-1690
 Project: Ignite
  Issue Type: Test
  Components: cache
Affects Versions: ignite-1.4
Reporter: Ivan Veselovsky


IgniteCacheCreateRestartSelfTest.testStopOriginatingNode sometimes 
fails (~5% probability) due to  inability to register a cache metrics MBean:

org.apache.ignite.IgniteCheckedException: Failed to register MBean for 
component: 
org.apache.ignite.internal.processors.cache.CacheMetricsMXBeanImpl@3a5e46b6
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at 
org.apache.ignite.internal.util.IgniteUtils.registerCacheMBean(IgniteUtils.java:4355)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:3267)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1526)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:813)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:937)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:725)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:709)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:686)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheCreateRestartSelfTest.testStopOriginatingNode(IgniteCacheCreateRestartSelfTest.java:104)



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

Re: Optimistic/serializable transactions implementation

[Alexey Kuznetsov]

Just one more question:

"- transaction with greater order should always 'win' transaction with
lower order"

Greater order means "younger"?

If it so, why should younger transactions win? Why not older?

Or user will have possibility to configure this aspect of conflict
resolution?

On Thu, Oct 15, 2015 at 3:07 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> 2015-10-15 10:58 GMT+03:00 Alexey Kuznetsov :
> >
> > Also it is not clear for me, how transaction order is assigned /
> > calculated?
> > If I start transaction t1 on none n1 and t2 on node n2, how it will be
> > calculated?
> >
> I believe that we can utilize nearXidVersion for this ordering (or some
> sort of it's modification). Since cache version contains local order,
> topology version and node ID and also is comparable, it is guaranteed that
> nearXidVersion is always unique and there is always an unambiguous order
> between any two Xid versions.
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Optimistic/serializable transactions implementation

[Semyon Boikov]

Hello,

I'm working on new implementation for optimistic/serializable transaction
mode (current implementation is inefficient and have bugs). This mode is
supposed to be used when concurrent transactions do not update the same
keys, in this case transactions can be executed more efficiently, but if
concurrent transactions have read of write conflicts then
TransactionOptimisticException can be thrown and transaction should be
retried. Also with current transactions implementation user should order
updated keys, otherwise deadlock is possible, we want to remove this
requirement for optimistic/serializable mode.

Issue with read/write conflicts can be detected if when read is performed
entry version is stored and then compared with current version when
transaction lock is acquired.

Another issue is avoid deadlocks when transactions acquire keys in
different order.

I created one possible solution using 'try-lock' approach: for each cache
entry we already have queue with current lock owner and transactions trying
to acquire entry lock.
When optimistic/serializable transaction tries to acquire entry lock it
checks that entry is not locked and there are no others transactions
waiting for lock entry, otherwise transaction fails with
TransactionOptimisticException. But this approach does not work well when
two transaction have lot of intersecting keys: it is possible that these
transaction will constantly conflict and will both constantly fail with
TransactionOptimisticException.

It seems there is better approach to resolve these conflicts to do not fail
all conflicting transactions:
- we should order all transactions by some attribute (e.g. all transactions
already have unique version)
- transaction with greater order should always 'win' transaction with lower
order
- per-entry queue with waiting transactions should be sorted by this order
- when transaction tries to acquire entry lock it is added in waiting queue
if queue is empty or last waiting transaction have lower order, otherwise
transaction fails

With this approach transaction lock assignment is ordered and transactions
with lower order never wait for transactions with greater order, so this
algorithm should not cause deadlocks.

I also created unit test simulating this algorithm and it did not reveal
any issues. Also in this unit tests I measured percent of rollbacks when
concurrent updates have lots of conflicts: with 'try-lock' approach percent
of rollbacks is ~80%, with new algorithm is ~1% (but of course with
real-life test results can be different).

Does anyone see problems with this locking approach?

Re: Optimistic/serializable transactions implementation

[Semyon Boikov]

Jira issue is https://issues.apache.org/jira/browse/IGNITE-1607, branch
ignite-1607

On Thu, Oct 15, 2015 at 10:58 AM, Alexey Kuznetsov 
wrote:

> Semyon, could you please give a link to JIRA issue (if any) and what branch
> contains your code?
>
> Also it is not clear for me, how transaction order is assigned /
> calculated?
> If I start transaction t1 on none n1 and t2 on node n2, how it will be
> calculated?
>
> Thanks.
>
> On Thu, Oct 15, 2015 at 2:00 PM, Semyon Boikov 
> wrote:
>
> > Hello,
> >
> > I'm working on new implementation for optimistic/serializable transaction
> > mode (current implementation is inefficient and have bugs). This mode is
> > supposed to be used when concurrent transactions do not update the same
> > keys, in this case transactions can be executed more efficiently, but if
> > concurrent transactions have read of write conflicts then
> > TransactionOptimisticException can be thrown and transaction should be
> > retried. Also with current transactions implementation user should order
> > updated keys, otherwise deadlock is possible, we want to remove this
> > requirement for optimistic/serializable mode.
> >
> > Issue with read/write conflicts can be detected if when read is performed
> > entry version is stored and then compared with current version when
> > transaction lock is acquired.
> >
> > Another issue is avoid deadlocks when transactions acquire keys in
> > different order.
> >
> > I created one possible solution using 'try-lock' approach: for each cache
> > entry we already have queue with current lock owner and transactions
> trying
> > to acquire entry lock.
> > When optimistic/serializable transaction tries to acquire entry lock it
> > checks that entry is not locked and there are no others transactions
> > waiting for lock entry, otherwise transaction fails with
> > TransactionOptimisticException. But this approach does not work well when
> > two transaction have lot of intersecting keys: it is possible that these
> > transaction will constantly conflict and will both constantly fail with
> > TransactionOptimisticException.
> >
> > It seems there is better approach to resolve these conflicts to do not
> fail
> > all conflicting transactions:
> > - we should order all transactions by some attribute (e.g. all
> transactions
> > already have unique version)
> > - transaction with greater order should always 'win' transaction with
> lower
> > order
> > - per-entry queue with waiting transactions should be sorted by this
> order
> > - when transaction tries to acquire entry lock it is added in waiting
> queue
> > if queue is empty or last waiting transaction have lower order, otherwise
> > transaction fails
> >
> > With this approach transaction lock assignment is ordered and
> transactions
> > with lower order never wait for transactions with greater order, so this
> > algorithm should not cause deadlocks.
> >
> > I also created unit test simulating this algorithm and it did not reveal
> > any issues. Also in this unit tests I measured percent of rollbacks when
> > concurrent updates have lots of conflicts: with 'try-lock' approach
> percent
> > of rollbacks is ~80%, with new algorithm is ~1% (but of course with
> > real-life test results can be different).
> >
> > Does anyone see problems with this locking approach?
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Optimistic/serializable transactions implementation

[Alexey Kuznetsov]

Semyon, could you please give a link to JIRA issue (if any) and what branch
contains your code?

Also it is not clear for me, how transaction order is assigned / calculated?
If I start transaction t1 on none n1 and t2 on node n2, how it will be
calculated?

Thanks.

On Thu, Oct 15, 2015 at 2:00 PM, Semyon Boikov  wrote:

> Hello,
>
> I'm working on new implementation for optimistic/serializable transaction
> mode (current implementation is inefficient and have bugs). This mode is
> supposed to be used when concurrent transactions do not update the same
> keys, in this case transactions can be executed more efficiently, but if
> concurrent transactions have read of write conflicts then
> TransactionOptimisticException can be thrown and transaction should be
> retried. Also with current transactions implementation user should order
> updated keys, otherwise deadlock is possible, we want to remove this
> requirement for optimistic/serializable mode.
>
> Issue with read/write conflicts can be detected if when read is performed
> entry version is stored and then compared with current version when
> transaction lock is acquired.
>
> Another issue is avoid deadlocks when transactions acquire keys in
> different order.
>
> I created one possible solution using 'try-lock' approach: for each cache
> entry we already have queue with current lock owner and transactions trying
> to acquire entry lock.
> When optimistic/serializable transaction tries to acquire entry lock it
> checks that entry is not locked and there are no others transactions
> waiting for lock entry, otherwise transaction fails with
> TransactionOptimisticException. But this approach does not work well when
> two transaction have lot of intersecting keys: it is possible that these
> transaction will constantly conflict and will both constantly fail with
> TransactionOptimisticException.
>
> It seems there is better approach to resolve these conflicts to do not fail
> all conflicting transactions:
> - we should order all transactions by some attribute (e.g. all transactions
> already have unique version)
> - transaction with greater order should always 'win' transaction with lower
> order
> - per-entry queue with waiting transactions should be sorted by this order
> - when transaction tries to acquire entry lock it is added in waiting queue
> if queue is empty or last waiting transaction have lower order, otherwise
> transaction fails
>
> With this approach transaction lock assignment is ordered and transactions
> with lower order never wait for transactions with greater order, so this
> algorithm should not cause deadlocks.
>
> I also created unit test simulating this algorithm and it did not reveal
> any issues. Also in this unit tests I measured percent of rollbacks when
> concurrent updates have lots of conflicts: with 'try-lock' approach percent
> of rollbacks is ~80%, with new algorithm is ~1% (but of course with
> real-life test results can be different).
>
> Does anyone see problems with this locking approach?
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[GitHub] ignite pull request: IGNITE-1677 .Net: Sign assemblies and store S...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1677 .Net: Sign assemblies and store SNK file in git



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

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

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

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


commit 7fd76bb0f218540f6efcc2e06bf1c7edb911f49f
Author: ptupitsyn 
Date:   2015-10-15T08:45:48Z

wip signing

commit 460cab2961169fe63c8e3404dfb524e4689079e7
Author: ptupitsyn 
Date:   2015-10-15T08:48:36Z

wip signing

commit edfe3450a5a217c7a86d4a5444b407f1257dc544
Author: ptupitsyn 
Date:   2015-10-15T09:15:00Z

wip

commit 87eb00b765a808b83dab424ba27eb6eebd19ed52
Author: ptupitsyn 
Date:   2015-10-15T09:16:42Z

wip signing




---
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: Optimistic/serializable transactions implementation

[Semyon Boikov]

>
> is starvation possible here?
> E.g. there are two nodes with GUIDs A and B. What will happen in the
> following case:
> 1) TX (A, 1) started and locked the key;
> 2) TX (B, 1) started and waiting for lock;
> 3) TX (A, 2) started and waiting for lock;
> 4) TX (A, 1) released the lock.
> 5) Who wins now? If this is (A, 2), then lock acquisition by the node B can
> be postponed indefinitely.


I assume transactions are ordered as TX(A, 1), TX(A, 2), TX(B, 1). In this
case when TX(A, 2) tries to get lock it sees that there is already
waiting TX(B,
1) with greater order and it fails. So TX(A, 1), TX(B, 1) will finish
succesfully, TX(A,2) should be retried.

On Thu, Oct 15, 2015 at 11:31 AM, Vladimir Ozerov 
wrote:

> is starvation possible here?
>
> E.g. there are two nodes with GUIDs A and B. What will happen in the
> following case:
> 1) TX (A, 1) started and locked the key;
> 2) TX (B, 1) started and waiting for lock;
> 3) TX (A, 2) started and waiting for lock;
> 4) TX (A, 1) released the lock.
> 5) Who wins now? If this is (A, 2), then lock acquisition by the node B can
> be postponed indefinitely.
>
> On Thu, Oct 15, 2015 at 11:18 AM, Alexey Kuznetsov <
> akuznet...@gridgain.com>
> wrote:
>
> > Just one more question:
> >
> > "- transaction with greater order should always 'win' transaction with
> > lower order"
> >
> > Greater order means "younger"?
> >
> > If it so, why should younger transactions win? Why not older?
> >
> > Or user will have possibility to configure this aspect of conflict
> > resolution?
> >
> > On Thu, Oct 15, 2015 at 3:07 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > 2015-10-15 10:58 GMT+03:00 Alexey Kuznetsov :
> > > >
> > > > Also it is not clear for me, how transaction order is assigned /
> > > > calculated?
> > > > If I start transaction t1 on none n1 and t2 on node n2, how it will
> be
> > > > calculated?
> > > >
> > > I believe that we can utilize nearXidVersion for this ordering (or some
> > > sort of it's modification). Since cache version contains local order,
> > > topology version and node ID and also is comparable, it is guaranteed
> > that
> > > nearXidVersion is always unique and there is always an unambiguous
> order
> > > between any two Xid versions.
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>

Re: Optimistic/serializable transactions implementation

[Semyon Boikov]

We did not decided yet exactly by which attribute transactions should be
ordered, but logically it is better when wins older transaction or
transaction having more keys.

On Thu, Oct 15, 2015 at 11:18 AM, Alexey Kuznetsov 
wrote:

> Just one more question:
>
> "- transaction with greater order should always 'win' transaction with
> lower order"
>
> Greater order means "younger"?
>
> If it so, why should younger transactions win? Why not older?
>
> Or user will have possibility to configure this aspect of conflict
> resolution?
>
> On Thu, Oct 15, 2015 at 3:07 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > 2015-10-15 10:58 GMT+03:00 Alexey Kuznetsov :
> > >
> > > Also it is not clear for me, how transaction order is assigned /
> > > calculated?
> > > If I start transaction t1 on none n1 and t2 on node n2, how it will be
> > > calculated?
> > >
> > I believe that we can utilize nearXidVersion for this ordering (or some
> > sort of it's modification). Since cache version contains local order,
> > topology version and node ID and also is comparable, it is guaranteed
> that
> > nearXidVersion is always unique and there is always an unambiguous order
> > between any two Xid versions.
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[jira] [Created] (IGNITE-1689) Need to add tooltip for 'System columns' button

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1689:
--

 Summary: Need to add tooltip for 'System columns' button
 Key: IGNITE-1689
 URL: https://issues.apache.org/jira/browse/IGNITE-1689
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


it is not clear why this option is necessary, what will change if user turn on 
it



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

[GitHub] ignite pull request: IGNITE-1682 .Net: Remove RemoteListen from Ev...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1682 .Net: Remove RemoteListen from Events API



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

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

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

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


commit ffb40655104eee9486dd22e3fa306131a8430353
Author: ptupitsyn 
Date:   2015-10-14T15:46:17Z

IGNITE-1682 .Net: Remove RemoteListen from Events API

commit 7a3034d5def1cb0443fed474cdd3cc81e242a1a5
Author: ptupitsyn 
Date:   2015-10-14T15:46:21Z

IGNITE-1682 .Net: Remove RemoteListen from Events API

commit 6b911bcdfc148b0065360a65cda233a99e4699f0
Author: ptupitsyn 
Date:   2015-10-14T15:49:10Z

fixing examples

commit c01fd16e59cbb61179e07e0a610c3eeb35d7eda0
Author: ptupitsyn 
Date:   2015-10-14T15:52:37Z

fix tests

commit 3ed95e25ce3ff64b213c28557575d3aa782c179d
Author: ptupitsyn 
Date:   2015-10-14T16:04:39Z

wip

commit aa91d006258cf46945e54f79e9f9de9e7ee91ab6
Author: ptupitsyn 
Date:   2015-10-15T08:08:59Z

fix delegates

commit b9f615c12c91c283c6a1254512e02211e9974c06
Author: ptupitsyn 
Date:   2015-10-15T08:10:58Z

wip




---
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-1696) .Net: Ignite does not start with IBM JDK

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1696:
---

 Summary: .Net: Ignite does not start with IBM JDK
 Key: IGNITE-1696
 URL: https://issues.apache.org/jira/browse/IGNITE-1696
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


ERROR: Failed to load jvm.dll ([option=JAVA_HOME, 
path=C:\Java\ibm_sdk71\jre\bin\server\jvm.dll, errorCode=126])



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

[GitHub] ignite pull request: IGNITE-1696 .Net: Ignite does not start with ...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1696 .Net: Ignite does not start with IBM JDK



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

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

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

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


commit 1cc4608c3ada6ed65b8de2ab1d1b5d08a62120d7
Author: ptupitsyn 
Date:   2015-10-15T16:07:37Z

IGNITE-1696 .Net: Ignite does not start with IBM JDK




---
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-1693 .Net: Rename IMessage.Send(IEnume...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1693 .Net: Rename IMessage.Send(IEnumerable, object) method.



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

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

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

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


commit b9ad889b87ce3614d6412f8043c5052bcbdcd076
Author: ptupitsyn 
Date:   2015-10-15T15:17:06Z

IGNITE-1693 .Net: Rename IMessage.Send(IEnumerable, object) method.




---
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-1697) IGFS: implement reliable Igfs failover logic

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1697:
---

 Summary: IGFS: implement reliable Igfs failover logic 
 Key: IGNITE-1697
 URL: https://issues.apache.org/jira/browse/IGNITE-1697
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
 Fix For: 1.5


Problems to solve:
1) currently a write lock for a file may stay taken forever if a node have 
taken the lock and then crashed.
2) Currently the blocks of file content are written not just as dataCache.put() 
operations , but sent using ad-hoc async messages. This was done earlier to 
improve performance. But in order to implement reliable failover we need to get 
rid of that and use simple put() or asyncPut() cache operations.

Solution plan:
1) use async put to write file data blocks.
2) do writing using scheme "lock" -> "reserve space" -> "write" -> "commit" -> 
"release lock".
3) The id of the node that locked a file should be readable from the lock id.
4) Upon taking a file lock the following procedure should be performed: 
if file is locked, take the node Id of the node that locked the file. After 
that ask DiscoveryProcessor if this node is alive. If it is not (node has left 
topology), perform cleanup procedure: delete all the data blocks of the 
reserved data range, then delete the lock.




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

[jira] [Created] (IGNITE-1694) .Net: More efficient way to call native methods.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1694:
---

 Summary: .Net: More efficient way to call native methods.
 Key: IGNITE-1694
 URL: https://issues.apache.org/jira/browse/IGNITE-1694
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


Currently we invoke native platform using 
"Marshal.GetDelegateForFunctionPointer". 

This is the least efficient way to call external code. What can be done to 
improve it:
1) Add [SuppressUnmanagedCodeSecurity] attribute.
2) Use P/Invoke instead. We do not use it now because we unpack native library 
in runtime into some temp folder, while PInvoke searches for libraries in 
predefined file system places. Need to evaluate whether we can switch back to 
P/Invoke somehow.

See 
http://ybeernet.blogspot.ru/2011/03/techniques-of-calling-unmanaged-code.html 
for more info.



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

[jira] [Created] (IGNITE-1693) .Net: Rename IMessage.Send(IEnumerable, object) method.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1693:
---

 Summary: .Net: Rename IMessage.Send(IEnumerable, object) method.
 Key: IGNITE-1693
 URL: https://issues.apache.org/jira/browse/IGNITE-1693
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


As some of integral .Net types implement "IEnumerable", we should rename the 
method
{code}
IMessage.Send(IEnumerable, object);
{code} 

to 

{code}
IMessage.SendAll(IEnumerable, object);
{code}



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

[jira] [Created] (IGNITE-1695) PortableMarshaller get "Can not set final java.util.Queue field org.apache.ignite.examples.computegrid" exception when ComputeContinuousMapperExample is running

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-1695:
--

 Summary: PortableMarshaller get "Can not set final java.util.Queue 
field org.apache.ignite.examples.computegrid" exception when 
ComputeContinuousMapperExample is running
 Key: IGNITE-1695
 URL: https://issues.apache.org/jira/browse/IGNITE-1695
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
 Environment: Ubuntu 14.04, community build #319
Reporter: Vasilisa  Sidorova
 Fix For: 1.5


-
DESCRIPTION
-
When default optimizedMarshaller is changed into portableMarshaller in  
example-ignite.xml then ComputeContinuousMapperExample is failed with this 
config due to incorrect work of portableMarshaller
-
STEPS FOR REPRODUCE
-
1. Build examples project in IDE
2.In the example-ignite.xml change property from:
{noformat}

 -->

Re: Do we need "IgniteCache.randomEntry()" method?

[Sergi Vladykin]

Agree, it is doubtfully useful.

Sergi

2015-10-15 17:26 GMT+03:00 Roman :

> And another ticket for randomEntry()
> https://issues.apache.org/jira/browse/IGNITE-1180
>
>
>  On Thursday, October 15, 2015 9:47 PM, Vladimir Ozerov <
> voze...@gridgain.com> wrote:
>
>
>  Igniters,
>
> We have the ticket about broken randomEntry() method:
> https://issues.apache.org/jira/browse/IGNITE-512
>
> This method can return null even if cache is not empty. And it is even
> impossible to return an entry in constant time provided that concurrent
> deletes and expirations could occur.
>
> Do we really need this method? As for me it is better to deprecate it and
> do not spend any efforts trying to make it work.
>
> Thoughts?
>
>
>
>

Re: Do we need "IgniteCache.randomEntry()" method?

[Roman]

And another ticket for randomEntry() 
https://issues.apache.org/jira/browse/IGNITE-1180 


 On Thursday, October 15, 2015 9:47 PM, Vladimir Ozerov 
 wrote:
   

 Igniters,

We have the ticket about broken randomEntry() method:
https://issues.apache.org/jira/browse/IGNITE-512

This method can return null even if cache is not empty. And it is even
impossible to return an entry in constant time provided that concurrent
deletes and expirations could occur.

Do we really need this method? As for me it is better to deprecate it and
do not spend any efforts trying to make it work.

Thoughts?


  

URI deployment ticket

[Valentin Kulichenko]

Artem,

I merged the ticket [1] where you fixed URI deployment JavaDoc and one of
the tests started to fail after that [2]. I think something is just missing
on test classpath, can you please take a look?

[1] https://issues.apache.org/jira/browse/IGNITE-1559
[2] http://204.14.53.153/viewLog.html?buildId=69208

-Val

Re: [jira] [Created] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper

[Dmitriy Setrakyan]

Hi Michael,

I have added you to the Ignite contributors and assigned the ticket to you.
Welcome to the Ignite community!

Now you can assign any ticket to yourself, so feel free to pick any other
ticket you would like to work on.

You should also get familiar with various Ignite resources listed here:
https://ignite.apache.org/community/resources.html

Before you start developing, take a look at Ignite development process and
coding guidelines:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

If you have any questions, please send them here. I also would like to
encourage you to participate or start discussions on our dev list.

Looking forward to your contributions.

D.

On Thu, Oct 15, 2015 at 1:33 PM, endian675  wrote:

> As suggsted on the User list, I would like to take this JIRA on.
>
>
>
> --
> View this message in context:
> http://apache-ignite-developers.2346864.n4.nabble.com/jira-Created-IGNITE-1681-loadAll-threshold-is-not-configurable-for-CacheStoreBalancingWrapper-tp4015p4074.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

[GitHub] ignite pull request: IGNITE-1622 - Fixed cache.clear() with near c...

[vkulichenko]

Github user vkulichenko closed the pull request at:

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


---
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-1701) Bump Spark dependenency to 1.5.1 (the latest stable)

[Konstantin Boudnik (JIRA)]

Konstantin Boudnik created IGNITE-1701:
--

 Summary: Bump Spark dependenency to 1.5.1 (the latest stable)
 Key: IGNITE-1701
 URL: https://issues.apache.org/jira/browse/IGNITE-1701
 Project: Ignite
  Issue Type: Improvement
  Components: build
Affects Versions: ignite-1.4
Reporter: Konstantin Boudnik
Assignee: Konstantin Boudnik
 Fix For: 1.5


At the moment, {{ignite-spark}} module is built against spark 1.3.1 which is 
like 3 versions old already. Let's bump the version to 1.5.1, which is the 
latest stable.

In the process, I'd like to add an ability to specify the version of Spark 
during the build time, like it is done for Hadoop now.



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

[jira] [Created] (IGNITE-1698) SqlFieldsQuery works incorrectly in case of topology changes

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-1698:
---

 Summary: SqlFieldsQuery works incorrectly in case of topology 
changes
 Key: IGNITE-1698
 URL: https://issues.apache.org/jira/browse/IGNITE-1698
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura


{{SqlFieldsQuery}} returns duplicate rows. Steps to reproduce:

# Start one node
# Create cache nad populate data.
# Start second node
# Execute query

Result: {{QueryCursor}} retrieves duplicate rows.



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

[jira] [Created] (IGNITE-1699) Method org.apache.ignite.internal.util.GridJavaProcess#kill should be more reliable.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1699:
---

 Summary: Method 
org.apache.ignite.internal.util.GridJavaProcess#kill should be more reliable.
 Key: IGNITE-1699
 URL: https://issues.apache.org/jira/browse/IGNITE-1699
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Veselovsky


Test 
IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
 sometimes fails with the nelow error.

I see the following problems in this method:
1) exeption (if any) should better contain the actual process exit code if it 
was different from the expected one;
2) assertion on zero exit code ( 
org/apache/ignite/internal/util/GridJavaProcess.java:197) of the killing 
command is not always correct , e.g. on Unix systems killing of an unexisting 
process returns 1. So, if the process finished before kill was invoked, the 
method will fail with assertion error.

{code}
java.lang.AssertionError: Process killing was not successful
at 
org.apache.ignite.internal.util.GridJavaProcess.kill(GridJavaProcess.java:197)
at 
org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.interactWithClient(IpcSharedMemoryCrashDetectionSelfTest.java:343)
at 
org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling(IpcSharedMemoryCrashDetectionSelfTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
{code}



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

[jira] [Created] (IGNITE-1700) IgniteQueueExample fails with " org.apache.ignite.internal.portable.PortableObjectImpl cannot be cast to org.apache.ignite.internal.processors.datastructures.GridCacheQu

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-1700:
--

 Summary: IgniteQueueExample fails with " 
org.apache.ignite.internal.portable.PortableObjectImpl cannot be cast to 
org.apache.ignite.internal.processors.datastructures.GridCacheQueueHeader" 
exception when it's running with portableMarshaller
 Key: IGNITE-1700
 URL: https://issues.apache.org/jira/browse/IGNITE-1700
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
 Environment: Ubuntu 14.04, community 1.5.0 build #319
Reporter: Vasilisa  Sidorova
 Fix For: 1.5


-
DESCRIPTION
-
When default optimizedMarshaller is changed into portableMarshaller in 
example-ignite.xml then IgniteQueueExample is failed with this config 
-
STEPS FOR REPRODUCE
-
1. Build examples project in IDE
2.In the example-ignite.xml change property from:

 -->