[jira] [Resolved] (IGNITE-3321) Address possible data corruption in Persistent Store implementations

[Alexandre Boudnik (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Boudnik resolved IGNITE-3321.
---
Resolution: Not A Bug

Misunderstanding: CacheStore's methods invoked on the node where transaction 
has started.

> Address possible data corruption in Persistent Store implementations
> 
>
> Key: IGNITE-3321
> URL: https://issues.apache.org/jira/browse/IGNITE-3321
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.6
> Environment: any
>Reporter: Alexandre Boudnik
>Assignee: Alexandre Boudnik
>Priority: Critical
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> When records from partitions on different nodes are committed, each node uses 
> its own SQL connection. It is possible that one of DML statements will fail 
> on one of the connections, while others have committed successfully.
> And we need to make a very hard decision:
> - If we ignore fail then we will lose some changes.
> - If we throw an exception we will make inconsistent changes.



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

[jira] [Closed] (IGNITE-3321) Address possible data corruption in Persistent Store implementations

[Alexandre Boudnik (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Boudnik closed IGNITE-3321.
-

> Address possible data corruption in Persistent Store implementations
> 
>
> Key: IGNITE-3321
> URL: https://issues.apache.org/jira/browse/IGNITE-3321
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.6
> Environment: any
>Reporter: Alexandre Boudnik
>Assignee: Alexandre Boudnik
>Priority: Critical
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> When records from partitions on different nodes are committed, each node uses 
> its own SQL connection. It is possible that one of DML statements will fail 
> on one of the connections, while others have committed successfully.
> And we need to make a very hard decision:
> - If we ignore fail then we will lose some changes.
> - If we throw an exception we will make inconsistent changes.



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

[jira] [Closed] (IGNITE-1560) ClassNotFoundException on AWS

[Alexandre Boudnik (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Boudnik closed IGNITE-1560.
-

> ClassNotFoundException on AWS
> -
>
> Key: IGNITE-1560
> URL: https://issues.apache.org/jira/browse/IGNITE-1560
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
> Environment: AWS
>Reporter: Alexandre Boudnik
>Assignee: Nikolay Tikhonov
>Priority: Critical
>  Labels: maven
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Optional {{ignite-aws}} has outdated (2012) dependency:
> {code}
> 
>   com.amazonaws
>   aws-java-sdk
>   1.3.21.1
>   compile
> 
> {code}
> that depends on
> {code}
> 
> org.codehaus.jackson
> jackson-core-asl
> 1.8.9
> jar
> compile
> 
> 
> org.codehaus.jackson
> jackson-mapper-asl
> 1.8.9
> jar
> compile
> 
> {code}
> As results it produces {{ClassNotFoundException}} for 
> {{org.codehaus.jackson.JsonNode}} and 
> {{org.codehaus.jackson.map.ObjectMapper}} classes
> I would recommend to switch to newer version of {{aws-java-sdk}}, which is 
> has no external dependencies.



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

[jira] [Resolved] (IGNITE-1560) ClassNotFoundException on AWS

[Alexandre Boudnik (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Boudnik resolved IGNITE-1560.
---
Resolution: Fixed

as I know, it was resolved in 1.5

> ClassNotFoundException on AWS
> -
>
> Key: IGNITE-1560
> URL: https://issues.apache.org/jira/browse/IGNITE-1560
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
> Environment: AWS
>Reporter: Alexandre Boudnik
>Assignee: Nikolay Tikhonov
>Priority: Critical
>  Labels: maven
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Optional {{ignite-aws}} has outdated (2012) dependency:
> {code}
> 
>   com.amazonaws
>   aws-java-sdk
>   1.3.21.1
>   compile
> 
> {code}
> that depends on
> {code}
> 
> org.codehaus.jackson
> jackson-core-asl
> 1.8.9
> jar
> compile
> 
> 
> org.codehaus.jackson
> jackson-mapper-asl
> 1.8.9
> jar
> compile
> 
> {code}
> As results it produces {{ClassNotFoundException}} for 
> {{org.codehaus.jackson.JsonNode}} and 
> {{org.codehaus.jackson.map.ObjectMapper}} classes
> I would recommend to switch to newer version of {{aws-java-sdk}}, which is 
> has no external dependencies.



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

[jira] [Comment Edited] (IGNITE-2968) Near cache support in transactions deadlock detection

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384968#comment-15384968
 ] 

Andrey Gura edited comment on IGNITE-2968 at 7/19/16 10:19 PM:
---

Implemented for optimistic transactions (detection procedure should ignore 
local MVCC candidates with {{NEAR}} flag). All deadlock detection related tests 
are passed. Waiting for TC.

Also fixed IGNITE-2797 as part of this task because it was cause of failing 
tests.


was (Author: agura):
Also implemented for optimistic transactions. All deadlock detection related 
tests are passed. Waiting for TC.

> Near cache support in transactions deadlock detection
> -
>
> Key: IGNITE-2968
> URL: https://issues.apache.org/jira/browse/IGNITE-2968
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support transactions on near cache. Need implement 
> it.



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

[jira] [Commented] (IGNITE-2968) Near cache support in transactions deadlock detection

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384968#comment-15384968
 ] 

Andrey Gura commented on IGNITE-2968:
-

Also implemented for optimistic transactions. All deadlock detection related 
tests are passed. Waiting for TC.

> Near cache support in transactions deadlock detection
> -
>
> Key: IGNITE-2968
> URL: https://issues.apache.org/jira/browse/IGNITE-2968
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support transactions on near cache. Need implement 
> it.



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

[jira] [Commented] (IGNITE-3390) ODBC: Add system DSN support for Windows.

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384883#comment-15384883
 ] 

Igor Sapego commented on IGNITE-3390:
-

Implemented some basic classes to work with WinApi. I'm going to keep them 
simple as I only need single window for now.

> ODBC: Add system DSN support for Windows.
> -
>
> Key: IGNITE-3390
> URL: https://issues.apache.org/jira/browse/IGNITE-3390
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.7
>
>
> Need to add support for the DSN creation/modification in Windows. To do so we 
> will need to create some UI windows with matching fields.



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

[jira] [Commented] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384749#comment-15384749
 ] 

Denis Magda commented on IGNITE-3495:
-

[~agoncharuk], please provide your feedback on this topic.

[~v.pyatkov], please make sure to support the same for 
{{CacheMetrics.getAveragePutTime}} and {{CacheMetrics.getAverageRemoveTime}}.

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
> Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch, 
> example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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

[jira] [Comment Edited] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Vladislav Pyatkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384386#comment-15384386
 ] 

Vladislav Pyatkov edited comment on IGNITE-3495 at 7/19/16 3:44 PM:


Before create pull request I would appreciate if community group review my 
first patch (it must fix the test). [^IGNITE_3495.patch]


was (Author: v.pyatkov):
Before create pull request I would appreciate if community group review my 
first patch (it must fix the test).

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
> Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch, 
> example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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

[jira] [Updated] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Vladislav Pyatkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladislav Pyatkov updated IGNITE-3495:
--
Attachment: IGNITE_3495.patch

Before create pull request I would appreciate if community group review my 
first patch (it must fix the test).

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
> Attachments: ExampleNodeStartupClient.java, IGNITE_3495.patch, 
> example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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

[jira] [Commented] (IGNITE-3465) Java crash: problematic frame org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()

[Semen Boikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384319#comment-15384319
 ] 

Semen Boikov commented on IGNITE-3465:
--

Looks like crash happened at the moment when ignite tried to call 'toString' 
for non initialized BinaryObject (possible when object is in process of reading 
from socket). Added check in 'toString' to avoid crash. 

> Java crash: problematic frame 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()
> ---
>
> Key: IGNITE-3465
> URL: https://issues.apache.org/jira/browse/IGNITE-3465
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
> Attachments: hs_err_pid12976.log, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> During streaming load test some of JVMs crashed while logging info about 
> "Failed to wait for partition map exchange" problem
> {noformat}
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=61, 
> minorTopVer=0], node=4f7b195a-62e3-4c32-b496-4a98de50b277]. Dumping
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Ready 
> affinity version: AffinityTopologyVersion [topVer=60, minorTopVer=0]
> [01:05:24,107][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last exchange 
> future: GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> exchange futures:
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last 10 
> exchange futures (total: 48):
> [01:05:24,109][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=7291b03d-ce91
> [01:05:24,110][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=739ab624-7bce
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=93572383-07e8
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3c24caa1-d4b2
> [01:05:24,112][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=e762044c-8ccc
> [01:05:24,118][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=5ffbe144-f843
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=28199123-fa5b
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=14d27ae8-ee26
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fea5c90e-0467
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a5370f23-42bc
> [01:05:24,122][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> transactions:
> [01:05:24,767][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=fea5c90e-0467-462a-8755-928b539fb278, 
> rmtFutId=a52022ed551-938a204f-bf03-451b-8425-be7047673bf6, 
> nearXidVer=GridCacheVers
> [01:05:24,769][WARN 
> 

[jira] [Closed] (IGNITE-3465) Java crash: problematic frame org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov closed IGNITE-3465.

Assignee: (was: Semen Boikov)

> Java crash: problematic frame 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()
> ---
>
> Key: IGNITE-3465
> URL: https://issues.apache.org/jira/browse/IGNITE-3465
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ksenia Rybakova
> Attachments: hs_err_pid12976.log, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> During streaming load test some of JVMs crashed while logging info about 
> "Failed to wait for partition map exchange" problem
> {noformat}
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=61, 
> minorTopVer=0], node=4f7b195a-62e3-4c32-b496-4a98de50b277]. Dumping
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Ready 
> affinity version: AffinityTopologyVersion [topVer=60, minorTopVer=0]
> [01:05:24,107][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last exchange 
> future: GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> exchange futures:
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last 10 
> exchange futures (total: 48):
> [01:05:24,109][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=7291b03d-ce91
> [01:05:24,110][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=739ab624-7bce
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=93572383-07e8
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3c24caa1-d4b2
> [01:05:24,112][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=e762044c-8ccc
> [01:05:24,118][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=5ffbe144-f843
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=28199123-fa5b
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=14d27ae8-ee26
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fea5c90e-0467
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a5370f23-42bc
> [01:05:24,122][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> transactions:
> [01:05:24,767][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=fea5c90e-0467-462a-8755-928b539fb278, 
> rmtFutId=a52022ed551-938a204f-bf03-451b-8425-be7047673bf6, 
> nearXidVer=GridCacheVers
> [01:05:24,769][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=739ab624-7bce-4e4b-81cc-3696f65247bd, 
> rmtFutId=ddfe12ed551-15e1d48c-8146-44ac-8d7b-370ea34fa44b, 
> nearXidVer=GridCacheVers
> [01:05:24,771][WARN 
> 

[jira] [Resolved] (IGNITE-3465) Java crash: problematic frame org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov resolved IGNITE-3465.
--
Resolution: Fixed

> Java crash: problematic frame 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()
> ---
>
> Key: IGNITE-3465
> URL: https://issues.apache.org/jira/browse/IGNITE-3465
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
> Attachments: hs_err_pid12976.log, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> During streaming load test some of JVMs crashed while logging info about 
> "Failed to wait for partition map exchange" problem
> {noformat}
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=61, 
> minorTopVer=0], node=4f7b195a-62e3-4c32-b496-4a98de50b277]. Dumping
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Ready 
> affinity version: AffinityTopologyVersion [topVer=60, minorTopVer=0]
> [01:05:24,107][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last exchange 
> future: GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> exchange futures:
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last 10 
> exchange futures (total: 48):
> [01:05:24,109][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=7291b03d-ce91
> [01:05:24,110][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=739ab624-7bce
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=93572383-07e8
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3c24caa1-d4b2
> [01:05:24,112][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=e762044c-8ccc
> [01:05:24,118][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=5ffbe144-f843
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=28199123-fa5b
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=14d27ae8-ee26
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fea5c90e-0467
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a5370f23-42bc
> [01:05:24,122][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> transactions:
> [01:05:24,767][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=fea5c90e-0467-462a-8755-928b539fb278, 
> rmtFutId=a52022ed551-938a204f-bf03-451b-8425-be7047673bf6, 
> nearXidVer=GridCacheVers
> [01:05:24,769][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=739ab624-7bce-4e4b-81cc-3696f65247bd, 
> rmtFutId=ddfe12ed551-15e1d48c-8146-44ac-8d7b-370ea34fa44b, 
> nearXidVer=GridCacheVers
> [01:05:24,771][WARN 
> 

[jira] [Commented] (IGNITE-945) HTTP REST prepend/append commands failed

[Saikat Maitra (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384270#comment-15384270
 ] 

Saikat Maitra commented on IGNITE-945:
--

[~dmagda]

Thank you Denis !!!

Regards
Saikat

> HTTP REST prepend/append commands failed
> 
>
> Key: IGNITE-945
> URL: https://issues.apache.org/jira/browse/IGNITE-945
> Project: Ignite
>  Issue Type: Bug
>  Components: newbie
>Affects Versions: sprint-5
>Reporter: Sergey Kozlov
>Assignee: Saikat Maitra
>  Labels: newbie
> Fix For: 1.7
>
>
> Requests 
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=prepend=p
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=append=a
> returns same error:
> {noformat}
> {"error":"Failed to start transaction on non-transactional cache: 
> partitioned_cache","response":null,"sessionToken":"","successStatus":1}
> {noformat}
> Node output is following:
> {noformat}
> [14:01:32,555][SEVERE][ignite-#12%pub-null%][GridRestProcessor] Failed to 
> handle request: CACHE_PREPEND
> class org.apache.ignite.IgniteCheckedException: Failed to start transaction 
> on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6732)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to start 
> transaction on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.checkTransactional(IgniteTransactionsImpl.java:193)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.txStartEx(IgniteTransactionsImpl.java:121)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.txStartEx(GridCacheAdapter.java:3239)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.txStartEx(GridCacheProxyImpl.java:808)
>   at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$1.call(GridCacheCommandHandler.java:405)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6124)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:893)
>   ... 4 more
> {noformat}
> Is there a limitation for use non-transactional caches for prepend/append 
> commands?



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

[jira] [Commented] (IGNITE-637) Implement IgniteReentrantReadWriteLock data structure

[Krome Plasma (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384217#comment-15384217
 ] 

Krome Plasma commented on IGNITE-637:
-

Vladisav, you available on any chat (gitter maybe) ? I'd like to discuss about 
IRRWL and a small bug i found.

> Implement IgniteReentrantReadWriteLock data structure
> -
>
> Key: IGNITE-637
> URL: https://issues.apache.org/jira/browse/IGNITE-637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantReadWriteLock}} data structure in addition to 
> other data structures provided by Ignite. {{IgniteReentrantReadWriteLock}} 
> should have similar API to 
> {{java.util.concurrent.locks.ReentrantReadWriteLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> readers and writers and allow user threads to block whenever needed to wait 
> for a lock.



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

[jira] [Commented] (IGNITE-2649) Ignition.localIgnite() unreliable under Gateways and cause wrong components deserialization.

[Amit Shah (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384139#comment-15384139
 ] 

Amit Shah commented on IGNITE-2649:
---

I'm facing an issue where I get the exception mentioned in the bug description 
but the failure appears only in case when ignite instance is not defined in the 
context where it is used & a CacheFileLocalStore is used. In the below code the 
issue appears when ignite instance is defined as a instance variable. Would it 
appear when @IgniteInstanceResource is used? Can someone confirm if this is the 
same issue being track by this jira and explain the root cause behind this 
issue? 

The code I am referring to is
{code:java}
public class LocalStoreTest implements Serializable {
private Ignite ignite = IgniteConfigUtil.initializeIgniteInClientMode();

public void testLocalStoreGridGainExample() {
CacheConfiguration ccfg = new CacheConfiguration<>();
ccfg.setName("Cache 1");

ccfg.setCacheStoreFactory(
new Factory>() {
@SuppressWarnings("unchecked")
@Override
public CacheStore create() {
return new CacheFileLocalStore();
}
});

//try (Ignite ignite = IgniteConfigUtil.initializeIgniteInClientMode()) 
{
IgniteCache cache = ignite.getOrCreateCache(ccfg);

System.out.println("Putting values to cache...");

for (int i = 0; i < 20; i++)
cache.put(i, i);
//}

}
}
{code}


> Ignition.localIgnite() unreliable under Gateways and cause wrong components 
> deserialization.
> 
>
> Key: IGNITE-2649
> URL: https://issues.apache.org/jira/browse/IGNITE-2649
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Vladimir Ozerov
>Priority: Critical
>  Labels: 1.6, community
> Fix For: 1.7
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> We can get something like this:
> {noformat}
> java.lang.IllegalArgumentException: This method should be accessed under 
> org.apache.ignite.thread.IgniteThread
> at org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1252)
> at org.apache.ignite.Ignition.localIgnite(Ignition.java:531)
> at org.project.MyPojo.readResolve(MyPojo.java:123)
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:746)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1564)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1086)
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:827)
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:734)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1564)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:1908)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadMap(BinaryUtils.java:1892)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1595)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1644)
> at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
> at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:734)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1448)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:537)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:257)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:148)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:135)
> at 
> 

[jira] [Closed] (IGNITE-3511) .NET: Fix AffinityFunctionBase namespace and package description

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-3511.
---

> .NET: Fix AffinityFunctionBase namespace and package description
> 
>
> Key: IGNITE-3511
> URL: https://issues.apache.org/jira/browse/IGNITE-3511
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Created] (IGNITE-3511) .NET: Fix AffinityFunctionBase namespace and package description

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3511:
---

 Summary: .NET: Fix AffinityFunctionBase namespace and package 
description
 Key: IGNITE-3511
 URL: https://issues.apache.org/jira/browse/IGNITE-3511
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.7






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

[jira] [Closed] (IGNITE-3416) CPP: Review and optimize serialization and deserialization.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-3416.
---

> CPP: Review and optimize serialization and deserialization.
> ---
>
> Key: IGNITE-3416
> URL: https://issues.apache.org/jira/browse/IGNITE-3416
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> It seems like some operations can be optimized a lot, for example 
> {{BinaryReaderImpl::ReadTopObject()}} reads string from the 
> stream byte by byte, makeing 2 additional calls to {{EnsureEnoughData()}} and 
> {{Shift()}} for every byte.



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

[jira] [Closed] (IGNITE-3414) Hadoop: Optimize map-reduce job planning.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-3414.
---

> Hadoop: Optimize map-reduce job planning.
> -
>
> Key: IGNITE-3414
> URL: https://issues.apache.org/jira/browse/IGNITE-3414
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently Hadoop module has inefficient map-reduce planning engine. In 
> particular, it assigns tasks only to affinity nodes. It could lead to 
> situation when very huge tasks is processed by a single cluster node, while 
> other cluster nodes are idle. 
> We should implement configurable map-reduce planner which will be able to 
> utilize the whole cluster.



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

[jira] [Resolved] (IGNITE-3414) Hadoop: Optimize map-reduce job planning.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov resolved IGNITE-3414.
-
Resolution: Fixed

> Hadoop: Optimize map-reduce job planning.
> -
>
> Key: IGNITE-3414
> URL: https://issues.apache.org/jira/browse/IGNITE-3414
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently Hadoop module has inefficient map-reduce planning engine. In 
> particular, it assigns tasks only to affinity nodes. It could lead to 
> situation when very huge tasks is processed by a single cluster node, while 
> other cluster nodes are idle. 
> We should implement configurable map-reduce planner which will be able to 
> utilize the whole cluster.



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

[jira] [Created] (IGNITE-3510) .NET: Review namespace structure

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3510:
--

 Summary: .NET: Review namespace structure
 Key: IGNITE-3510
 URL: https://issues.apache.org/jira/browse/IGNITE-3510
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


Current issues:
* Impl namespace contains both public and internal types.
* Some classes (QueryBase, AffinityFunctionBase, etc) are not intended to be 
used directly, but they have to be public

Need to review framework design guidelines and see how well-known APIs (.NET, 
WPF, Entity Framework) handle such issues.



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

[jira] [Created] (IGNITE-3509) .NET: Add package-info descriptions to all namespaces

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3509:
--

 Summary: .NET: Add package-info descriptions to all namespaces
 Key: IGNITE-3509
 URL: https://issues.apache.org/jira/browse/IGNITE-3509
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.7


Add a unit test to check this



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

[jira] [Created] (IGNITE-3507) misspelling and broken URL on Ignite features page

[Sarychev Roman (JIRA)]

Sarychev Roman created IGNITE-3507:
--

 Summary: misspelling and broken URL on Ignite features page
 Key: IGNITE-3507
 URL: https://issues.apache.org/jira/browse/IGNITE-3507
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Sarychev Roman
Priority: Trivial


https://ignite.apache.org/features.html

1. "Memached Support"

should be MemCached Support

2. link to Semaphore (Docs for this feature) are broken - 404
https://apacheignite.readme.io/docs/distributed-semaphore




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

[jira] [Created] (IGNITE-3508) .NET: Make ICache implement IDictionary

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3508:
--

 Summary: .NET: Make ICache implement IDictionary
 Key: IGNITE-3508
 URL: https://issues.apache.org/jira/browse/IGNITE-3508
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


ICache is essentially a dictionary. Implementing IDictionary will provide 
a familiar interface to the users.

However, this may require us to remove ICacheEntry interface and switch to 
KeyValuePair, since this is what IDictionary operates on. KeyValuePair is also 
a struct, so this may improve performance in certain cases.



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

[jira] [Updated] (IGNITE-3506) .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3506:
---
Summary: .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class 
constants  (was: .NET: Fix ContinuousQuery class constants)

> .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants
> 
>
> Key: IGNITE-3506
> URL: https://issues.apache.org/jira/browse/IGNITE-3506
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: breaking-api
> Fix For: 2.0
>
>
> 1) Abbreviations should not be used
> 2) Constants in generic class are not good



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

[jira] [Created] (IGNITE-3506) .NET: Fix ContinuousQuery class constants

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3506:
--

 Summary: .NET: Fix ContinuousQuery class constants
 Key: IGNITE-3506
 URL: https://issues.apache.org/jira/browse/IGNITE-3506
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


1) Abbreviations should not be used
2) Constants in generic class are not good



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

[jira] [Updated] (IGNITE-3505) BinaryObject keys can't be reused because of partition caching.

[Alexei Scherbakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexei Scherbakov updated IGNITE-3505:
--
Description: 
BinaryObject can't be reused as key between caches because it's
actual implementation BinaryObjectImpl implements KeyCacheObject and
due to the fact caches partition, which is not recalculated later.

See 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition:

{code}
if (key instanceof KeyCacheObject && ((KeyCacheObject)key).partition() != -1)
return ((KeyCacheObject)key).partition();
{code}

The issue can be reproduced with the following code:

{code}
public static void main(String[] args) throws IgniteException {
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(new 
TcpDiscoveryVmIpFinder(true)));
Ignite ignite = Ignition.start(cfg);
CacheConfiguration cfg1 = new
CacheConfiguration<>("Cache 1");
cfg1.setCacheMode(CacheMode.PARTITIONED);
cfg1.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);

IgniteCache cache1 =
ignite.getOrCreateCache(cfg1).withKeepBinary();

CacheConfiguration cfg2 = new
CacheConfiguration<>("Cache 2");
cfg2.setCacheMode(CacheMode.REPLICATED);


cfg2.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
IgniteCache cache2 =
ignite.getOrCreateCache(cfg2);

BinaryObjectBuilder keyBuilder = ignite.binary().builder("keyType")
.setField("F1", "V1").hashCode("V1".hashCode());

BinaryObjectBuilder valBuilder = ignite.binary().builder("valueType")
.setField("F2", "V2")
.setField("F3", "V3");

BinaryObject key = keyBuilder.build();
BinaryObject val = valBuilder.build();

cache1.put(key, val);
cache2.put(key, val); // error

System.out.println(cache1.get(key)); // error
System.out.println(cache2.get(key)); 
}
{code}

Corresponding user list thread: 
http://apache-ignite-users.70518.x6.nabble.com/Adding-a-binary-object-to-two-caches-fails-with-FULL-SYNC-write-mode-configured-for-the-replicated-ce-tp6343p6366.html

  was:
BinaryObject can't be reused as key between caches because it's
actual implementation BinaryObjectImpl implements KeyCacheObject and
due to the fact caches partition, which is not recalculated later.

See 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition:

{code}
if (key instanceof KeyCacheObject && ((KeyCacheObject)key).partition() != -1)
return ((KeyCacheObject)key).partition();
{code}

The issue can be reproduced with the following code:

{code}
public static void main(String[] args) throws IgniteException {
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(new 
TcpDiscoveryVmIpFinder(true)));
Ignite ignite = Ignition.start(cfg);
CacheConfiguration cfg1 = new
CacheConfiguration<>("Cache 1");
cfg1.setCacheMode(CacheMode.PARTITIONED);
cfg1.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);

IgniteCache cache1 =
ignite.getOrCreateCache(cfg1).withKeepBinary();

CacheConfiguration cfg2 = new
CacheConfiguration<>("Cache 2");
cfg2.setCacheMode(CacheMode.REPLICATED);


cfg2.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
IgniteCache cache2 =
ignite.getOrCreateCache(cfg2);

BinaryObjectBuilder keyBuilder = ignite.binary().builder("keyType")
.setField("F1", "V1").hashCode("V1".hashCode());

BinaryObjectBuilder valBuilder = ignite.binary().builder("valueType")
.setField("F2", "V2")
.setField("F3", "V3");

BinaryObject key = keyBuilder.build();
BinaryObject val = valBuilder.build();

cache1.put(key, val);
cache2.put(key, val); // error

System.out.println(cache1.get(key)); // error
System.out.println(cache2.get(key)); 
}
{code}


> BinaryObject keys can't be reused because of partition caching.
> ---
>
> Key: IGNITE-3505
> URL: https://issues.apache.org/jira/browse/IGNITE-3505
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Denis Magda
> Fix For: 1.7
>
>
> BinaryObject can't be reused as key between caches because it's
> 

[jira] [Created] (IGNITE-3505) BinaryObject keys can't be reused because of partition caching.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-3505:
-

 Summary: BinaryObject keys can't be reused because of partition 
caching.
 Key: IGNITE-3505
 URL: https://issues.apache.org/jira/browse/IGNITE-3505
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.6
Reporter: Alexei Scherbakov
Assignee: Denis Magda
 Fix For: 1.7


BinaryObject can't be reused as key between caches because it's
actual implementation BinaryObjectImpl implements KeyCacheObject and
due to the fact caches partition, which is not recalculated later.

See 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition:

{code}
if (key instanceof KeyCacheObject && ((KeyCacheObject)key).partition() != -1)
return ((KeyCacheObject)key).partition();
{code}

The issue can be reproduced with the following code:

{code}
public static void main(String[] args) throws IgniteException {
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(new 
TcpDiscoveryVmIpFinder(true)));
Ignite ignite = Ignition.start(cfg);
CacheConfiguration cfg1 = new
CacheConfiguration<>("Cache 1");
cfg1.setCacheMode(CacheMode.PARTITIONED);
cfg1.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);

IgniteCache cache1 =
ignite.getOrCreateCache(cfg1).withKeepBinary();

CacheConfiguration cfg2 = new
CacheConfiguration<>("Cache 2");
cfg2.setCacheMode(CacheMode.REPLICATED);


cfg2.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
IgniteCache cache2 =
ignite.getOrCreateCache(cfg2);

BinaryObjectBuilder keyBuilder = ignite.binary().builder("keyType")
.setField("F1", "V1").hashCode("V1".hashCode());

BinaryObjectBuilder valBuilder = ignite.binary().builder("valueType")
.setField("F2", "V2")
.setField("F3", "V3");

BinaryObject key = keyBuilder.build();
BinaryObject val = valBuilder.build();

cache1.put(key, val);
cache2.put(key, val); // error

System.out.println(cache1.get(key)); // error
System.out.println(cache2.get(key)); 
}
{code}



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

[jira] [Created] (IGNITE-3504) .NET: Improve IBinaryObjectBuilder test coverage

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3504:
--

 Summary: .NET: Improve IBinaryObjectBuilder test coverage
 Key: IGNITE-3504
 URL: https://issues.apache.org/jira/browse/IGNITE-3504
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
 Fix For: 1.7


Most methods are not even used anywhere.



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

[jira] [Updated] (IGNITE-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3503:
---
Description: It does not make much sense and makes property names too long.

> .NET: Remove "Default" prefix from BinaryConfiguration properties
> -
>
> Key: IGNITE-3503
> URL: https://issues.apache.org/jira/browse/IGNITE-3503
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: breaking-api
> Fix For: 2.0
>
>
> It does not make much sense and makes property names too long.



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

[jira] [Created] (IGNITE-3503) .NET: Remove "Default" prefix from BinaryConfiguration properties

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3503:
--

 Summary: .NET: Remove "Default" prefix from BinaryConfiguration 
properties
 Key: IGNITE-3503
 URL: https://issues.apache.org/jira/browse/IGNITE-3503
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0






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

[jira] [Assigned] (IGNITE-3465) Java crash: problematic frame org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()

[Semen Boikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov reassigned IGNITE-3465:


Assignee: Semen Boikov  (was: Dmitry Karachentsev)

> Java crash: problematic frame 
> org.apache.ignite.internal.binary.BinaryObjectImpl.hashCode()
> ---
>
> Key: IGNITE-3465
> URL: https://issues.apache.org/jira/browse/IGNITE-3465
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
> Attachments: hs_err_pid12976.log, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> During streaming load test some of JVMs crashed while logging info about 
> "Failed to wait for partition map exchange" problem
> {noformat}
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Failed to 
> wait for partition map exchange [topVer=AffinityTopologyVersion [topVer=61, 
> minorTopVer=0], node=4f7b195a-62e3-4c32-b496-4a98de50b277]. Dumping
> [01:05:23,949][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Ready 
> affinity version: AffinityTopologyVersion [topVer=60, minorTopVer=0]
> [01:05:24,107][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last exchange 
> future: GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> exchange futures:
> [01:05:24,108][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Last 10 
> exchange futures (total: 48):
> [01:05:24,109][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=7291b03d-ce91
> [01:05:24,110][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=739ab624-7bce
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=93572383-07e8
> [01:05:24,111][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3c24caa1-d4b2
> [01:05:24,112][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=e762044c-8ccc
> [01:05:24,118][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=5ffbe144-f843
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=28199123-fa5b
> [01:05:24,119][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=14d27ae8-ee26
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=fea5c90e-0467
> [01:05:24,120][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a5370f23-42bc
> [01:05:24,122][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] Pending 
> transactions:
> [01:05:24,767][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=fea5c90e-0467-462a-8755-928b539fb278, 
> rmtFutId=a52022ed551-938a204f-bf03-451b-8425-be7047673bf6, 
> nearXidVer=GridCacheVers
> [01:05:24,769][WARN 
> ][exchange-worker-#96%null%][GridCachePartitionExchangeManager] >>> 
> GridDhtTxRemote [nearNodeId=739ab624-7bce-4e4b-81cc-3696f65247bd, 
> rmtFutId=ddfe12ed551-15e1d48c-8146-44ac-8d7b-370ea34fa44b, 
> 

[jira] [Commented] (IGNITE-637) Implement IgniteReentrantReadWriteLock data structure

[Krome Plasma (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383893#comment-15383893
 ] 

Krome Plasma commented on IGNITE-637:
-

Vladisav, because I have specific needs for RW locking I haven't tested much of 
ordinary IgniteLock.

> Implement IgniteReentrantReadWriteLock data structure
> -
>
> Key: IGNITE-637
> URL: https://issues.apache.org/jira/browse/IGNITE-637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantReadWriteLock}} data structure in addition to 
> other data structures provided by Ignite. {{IgniteReentrantReadWriteLock}} 
> should have similar API to 
> {{java.util.concurrent.locks.ReentrantReadWriteLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> readers and writers and allow user threads to block whenever needed to wait 
> for a lock.



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

[jira] [Resolved] (IGNITE-2527) IndexOutOfBoundsException in scheduler future

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda resolved IGNITE-2527.
-
Resolution: Fixed

> IndexOutOfBoundsException in scheduler future
> -
>
> Key: IGNITE-2527
> URL: https://issues.apache.org/jira/browse/IGNITE-2527
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Valentin Kulichenko
>Assignee: Milap Wadhwa
>Priority: Minor
> Fix For: 1.7
>
>
> Calling {{SchedulerFuture.nextExecutionTime()}} (and probably other methods) 
> on a completed future leads to this exception:
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
>   at 
> org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.nextExecutionTime(ScheduleFutureImpl.java:455)
> {noformat}
> In particular, this happens if {{nextExecutionTime()}} right after calling 
> {{IgniteScheduler.scheduleLocal()}} with an invalid pattern (see code example 
> below). The exception is lost in this case and is never printed out or thrown.
> {code}
> SchedulerFuture schedulerFuture = ignite.scheduler().scheduleLocal(() -> {}, 
> "{55} 53 3/5 * * *");
> long nextExecutionTime = schedulerFuture.nextExecutionTime();
> {code}



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

[jira] [Commented] (IGNITE-2527) IndexOutOfBoundsException in scheduler future

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383887#comment-15383887
 ] 

Denis Magda commented on IGNITE-2527:
-

[~milap.wadhwa], thanks a lot for the contribution!

I've reviewed, slightly modified and merged your changes. In general I think 
that it's better to return {{0}} rather than {{-1}} if 
{{schedulerFuture.nextExecutionTime()}} is empty just in order to be consistent 
with other time related methods of the scheduler.

> IndexOutOfBoundsException in scheduler future
> -
>
> Key: IGNITE-2527
> URL: https://issues.apache.org/jira/browse/IGNITE-2527
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Valentin Kulichenko
>Assignee: Milap Wadhwa
>Priority: Minor
> Fix For: 1.7
>
>
> Calling {{SchedulerFuture.nextExecutionTime()}} (and probably other methods) 
> on a completed future leads to this exception:
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
>   at 
> org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.nextExecutionTime(ScheduleFutureImpl.java:455)
> {noformat}
> In particular, this happens if {{nextExecutionTime()}} right after calling 
> {{IgniteScheduler.scheduleLocal()}} with an invalid pattern (see code example 
> below). The exception is lost in this case and is never printed out or thrown.
> {code}
> SchedulerFuture schedulerFuture = ignite.scheduler().scheduleLocal(() -> {}, 
> "{55} 53 3/5 * * *");
> long nextExecutionTime = schedulerFuture.nextExecutionTime();
> {code}



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

[jira] [Closed] (IGNITE-2527) IndexOutOfBoundsException in scheduler future

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda closed IGNITE-2527.
---

> IndexOutOfBoundsException in scheduler future
> -
>
> Key: IGNITE-2527
> URL: https://issues.apache.org/jira/browse/IGNITE-2527
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Valentin Kulichenko
>Assignee: Milap Wadhwa
>Priority: Minor
> Fix For: 1.7
>
>
> Calling {{SchedulerFuture.nextExecutionTime()}} (and probably other methods) 
> on a completed future leads to this exception:
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
>   at 
> org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.nextExecutionTime(ScheduleFutureImpl.java:455)
> {noformat}
> In particular, this happens if {{nextExecutionTime()}} right after calling 
> {{IgniteScheduler.scheduleLocal()}} with an invalid pattern (see code example 
> below). The exception is lost in this case and is never printed out or thrown.
> {code}
> SchedulerFuture schedulerFuture = ignite.scheduler().scheduleLocal(() -> {}, 
> "{55} 53 3/5 * * *");
> long nextExecutionTime = schedulerFuture.nextExecutionTime();
> {code}



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

[jira] [Resolved] (IGNITE-945) HTTP REST prepend/append commands failed

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda resolved IGNITE-945.

Resolution: Fixed

> HTTP REST prepend/append commands failed
> 
>
> Key: IGNITE-945
> URL: https://issues.apache.org/jira/browse/IGNITE-945
> Project: Ignite
>  Issue Type: Bug
>  Components: newbie
>Affects Versions: sprint-5
>Reporter: Sergey Kozlov
>Assignee: Saikat Maitra
>  Labels: newbie
> Fix For: 1.7
>
>
> Requests 
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=prepend=p
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=append=a
> returns same error:
> {noformat}
> {"error":"Failed to start transaction on non-transactional cache: 
> partitioned_cache","response":null,"sessionToken":"","successStatus":1}
> {noformat}
> Node output is following:
> {noformat}
> [14:01:32,555][SEVERE][ignite-#12%pub-null%][GridRestProcessor] Failed to 
> handle request: CACHE_PREPEND
> class org.apache.ignite.IgniteCheckedException: Failed to start transaction 
> on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6732)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to start 
> transaction on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.checkTransactional(IgniteTransactionsImpl.java:193)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.txStartEx(IgniteTransactionsImpl.java:121)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.txStartEx(GridCacheAdapter.java:3239)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.txStartEx(GridCacheProxyImpl.java:808)
>   at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$1.call(GridCacheCommandHandler.java:405)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6124)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:893)
>   ... 4 more
> {noformat}
> Is there a limitation for use non-transactional caches for prepend/append 
> commands?



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

[jira] [Commented] (IGNITE-945) HTTP REST prepend/append commands failed

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383851#comment-15383851
 ] 

Denis Magda commented on IGNITE-945:


[~samaitra], I've slightly improved your fix and merged the fix into the master.

Thanks again for the contribution!

> HTTP REST prepend/append commands failed
> 
>
> Key: IGNITE-945
> URL: https://issues.apache.org/jira/browse/IGNITE-945
> Project: Ignite
>  Issue Type: Bug
>  Components: newbie
>Affects Versions: sprint-5
>Reporter: Sergey Kozlov
>Assignee: Saikat Maitra
>  Labels: newbie
> Fix For: 1.7
>
>
> Requests 
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=prepend=p
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=append=a
> returns same error:
> {noformat}
> {"error":"Failed to start transaction on non-transactional cache: 
> partitioned_cache","response":null,"sessionToken":"","successStatus":1}
> {noformat}
> Node output is following:
> {noformat}
> [14:01:32,555][SEVERE][ignite-#12%pub-null%][GridRestProcessor] Failed to 
> handle request: CACHE_PREPEND
> class org.apache.ignite.IgniteCheckedException: Failed to start transaction 
> on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6732)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to start 
> transaction on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.checkTransactional(IgniteTransactionsImpl.java:193)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.txStartEx(IgniteTransactionsImpl.java:121)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.txStartEx(GridCacheAdapter.java:3239)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.txStartEx(GridCacheProxyImpl.java:808)
>   at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$1.call(GridCacheCommandHandler.java:405)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6124)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:893)
>   ... 4 more
> {noformat}
> Is there a limitation for use non-transactional caches for prepend/append 
> commands?



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

[jira] [Closed] (IGNITE-945) HTTP REST prepend/append commands failed

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda closed IGNITE-945.
--

> HTTP REST prepend/append commands failed
> 
>
> Key: IGNITE-945
> URL: https://issues.apache.org/jira/browse/IGNITE-945
> Project: Ignite
>  Issue Type: Bug
>  Components: newbie
>Affects Versions: sprint-5
>Reporter: Sergey Kozlov
>Assignee: Saikat Maitra
>  Labels: newbie
> Fix For: 1.7
>
>
> Requests 
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=prepend=p
> http://localhost:8080/ignite?cacheName=partitioned_cache=1=append=a
> returns same error:
> {noformat}
> {"error":"Failed to start transaction on non-transactional cache: 
> partitioned_cache","response":null,"sessionToken":"","successStatus":1}
> {noformat}
> Node output is following:
> {noformat}
> [14:01:32,555][SEVERE][ignite-#12%pub-null%][GridRestProcessor] Failed to 
> handle request: CACHE_PREPEND
> class org.apache.ignite.IgniteCheckedException: Failed to start transaction 
> on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6732)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to start 
> transaction on non-transactional cache: partitioned_cache
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.checkTransactional(IgniteTransactionsImpl.java:193)
>   at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTransactionsImpl.txStartEx(IgniteTransactionsImpl.java:121)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.txStartEx(GridCacheAdapter.java:3239)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.txStartEx(GridCacheProxyImpl.java:808)
>   at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$1.call(GridCacheCommandHandler.java:405)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6124)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:893)
>   ... 4 more
> {noformat}
> Is there a limitation for use non-transactional caches for prepend/append 
> commands?



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

[jira] [Updated] (IGNITE-3486) .NET: Improve documentation

[Pavel Tupitsyn (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-3486:
---
Summary: .NET: Improve documentation  (was: .Net: documentation improvement 
is needed)

> .NET: Improve documentation
> ---
>
> Key: IGNITE-3486
> URL: https://issues.apache.org/jira/browse/IGNITE-3486
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
>  Will document documentation related issues.
> Getting Started (https://apacheignite-net.readme.io/docs/getting-started-2)
> - document how to start with Apache.exe that is a part of release bundle.
> - {{By default Apache.Ignite.exe starts Ignite.NET node with the default 
> configuration: config/default-config.xml.}}. However, this doesn't look valid 
> statement. Tried to remove and corrupt it but the node was started all the 
> time.
> - there is no installation instructions that are part of 
> “platform\dotnet\README.txt”
> Configurations (https://apacheignite-net.readme.io/docs/configuration):
> - how to start with particular a particular configuration (app.config and 
> XML). No examples, not clear.
> - more info about app.config: how it maps to C# classes, how to specify type 
> names
> SQL QUERIES (https://apacheignite-net.readme.io/v1.5/docs/sql-queries):
> - cachetypemetadaa is used an example of configuration. {{QueryEntity}}'s 
> XML, App.config and source examples must be provided.
> - clarify keyType/keyTypeName confusion
> Troubleshooting (https://apacheignite-net.readme.io/docs/troubleshooting):
> - refer to the {{BinaryContfiguration}} from the interoperability section 
> (https://apacheignite-net.readme.io/docs/platform-interoperability#mixed-platform-clusters)
>  that must be set if there are Java node. Show the stack trace that usually 
> produced when {{BinaryConfiguration}} is wrong.
> Tuning:
> - Refer to Java readme tuning page and explain how to set JVM parameters from 
> .NET (app.config and C#).



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

[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383818#comment-15383818
 ] 

Denis Magda commented on IGNITE-3303:
-

[~avinogradov], please review the changes.

> Apache Flink Integration - Flink source to run a continuous query against one 
> or multiple caches
> 
>
> Key: IGNITE-3303
> URL: https://issues.apache.org/jira/browse/IGNITE-3303
> Project: Ignite
>  Issue Type: New Feature
>  Components: streaming
>Reporter: Saikat Maitra
>Assignee: Anton Vinogradov
>
> Apache Flink integration 
> +++ *Ignite as a bidirectional Connector* +++
> As a Flink source => run a continuous query against one or multiple
> caches [4].
> Related discussion : 
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html



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

[jira] [Commented] (IGNITE-637) Implement IgniteReentrantReadWriteLock data structure

[Vladisav Jelisavcic (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383820#comment-15383820
 ] 

Vladisav Jelisavcic commented on IGNITE-637:


Krome,

Of course, I agree, for read-write locks having a fair ordering option is 
mandatory. Have you tried using 
[IgniteLock|https://ignite.apache.org/releases/1.6.0/javadoc/org/apache/ignite/IgniteLock.html]
 in fair mode? 

> Implement IgniteReentrantReadWriteLock data structure
> -
>
> Key: IGNITE-637
> URL: https://issues.apache.org/jira/browse/IGNITE-637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantReadWriteLock}} data structure in addition to 
> other data structures provided by Ignite. {{IgniteReentrantReadWriteLock}} 
> should have similar API to 
> {{java.util.concurrent.locks.ReentrantReadWriteLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> readers and writers and allow user threads to block whenever needed to wait 
> for a lock.



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

[jira] [Updated] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-3303:

Assignee: Anton Vinogradov  (was: Saikat Maitra)

> Apache Flink Integration - Flink source to run a continuous query against one 
> or multiple caches
> 
>
> Key: IGNITE-3303
> URL: https://issues.apache.org/jira/browse/IGNITE-3303
> Project: Ignite
>  Issue Type: New Feature
>  Components: streaming
>Reporter: Saikat Maitra
>Assignee: Anton Vinogradov
>
> Apache Flink integration 
> +++ *Ignite as a bidirectional Connector* +++
> As a Flink source => run a continuous query against one or multiple
> caches [4].
> Related discussion : 
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html



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

[jira] [Commented] (IGNITE-3217) Text input in number field

[Vasiliy Sisko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383816#comment-15383816
 ] 

Vasiliy Sisko commented on IGNITE-3217:
---

# Dropdown with object selection should be disabled when empty.
# On quick change of valid -> invalid -> valid state field can have invalid 
presentation. F.e. Cluster -> General -> Local host
# Cluster -> Binary configuration -> Type configurations have empty labels. 
Also in some other tables. (F.e. failover configuration, cache -> store)
# Cluster -> Binary configuration -> Type configurations: configure first type 
with invalid fields, configure second type with valid fields, remove first 
type. second showed how first with red border on valid field.
# Cluster -> Connector configuration: disabled checkboxes change state on click 
or do hot have disabled state.
# Model -> General: create new model, input "Int" in Key type. Typeahead show 
wrong variants. Input "Integer" and clear field. Typeahead does not show 
variants.
# Chrome -> Cluster -> General: Input two letter in port number field, press 
section undo. Global undo and Save stay active.

> Text input in number field
> --
>
> Key: IGNITE-3217
> URL: https://issues.apache.org/jira/browse/IGNITE-3217
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.7
>
>
> Create new cluster and try to input text into number field (f.e. Cluster - 
> General - Port number):
> # Field is empty (Chrome) or show text with error message (Firefox or Chrome 
> for 'e' symbol),
> # field in model (backupItem) is not set,
> # Buttons "Save" and "Undo all" and "Undo" is available (For empty fields in 
> chrome),
> # On undo of section "Save" and "Undo all" still available.
> # Undo does not revert text in number fields.
> Also following scenario should be tested:
> # Remove all clusters.
> # Create new cluster. Save.
> # Change some field to "-1" (invalid). DO NOT Save.
> # Click "Add cluster" - new cluster created, but invalid field with "-1" is 
> not cleared.
> On cluster page in failover configuration:
> Configure custom failover configuration and stay SPI implementation field 
> empty.
> That configuration is saved without any errors.
> Also reproduced in cluster binary type configuration for type configuration 
> table.



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

[jira] [Updated] (IGNITE-3389) metadata result set throws NPE when closed

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-3389:

Assignee: Andrey Gura  (was: Alexandre Boudnik)

> metadata result set throws NPE when closed
> --
>
> Key: IGNITE-3389
> URL: https://issues.apache.org/jira/browse/IGNITE-3389
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, odbc, SQL
>Affects Versions: 1.6, 1.7
>Reporter: Alexandre Boudnik
>Assignee: Andrey Gura
>  Labels: easyfix
> Fix For: 1.7
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Need to handle when ResultSet has no cursor. It happened only with client 
> JDBC. This code throws NPE:
> {code}
> public void testMetadataResultSetClose() throws Exception {
> try (Connection conn = DriverManager.getConnection(BASE_URL)) {
> try (ResultSet tables = conn.getMetaData().getTables(null, null, 
> "%", null)) {
> int columnCount = tables.getMetaData().getColumnCount();
> while (tables.next())
> for (int i = 0; i < columnCount; i++)
> tables.getObject(i + 1);
> }
> }
> }
> {code}



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

[jira] [Comment Edited] (IGNITE-637) Implement IgniteReentrantReadWriteLock data structure

[Krome Plasma (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382969#comment-15382969
 ] 

Krome Plasma edited comment on IGNITE-637 at 7/19/16 8:29 AM:
--

If you ask me any lock related feature would be a nice addition to ignite, 
especially when there is a combination of read+write :)
Another important question for you Vladisave, would ReentrantReadWriteLock 
impementation include fair ordering option ? 
Especially if you have multiple write lockers on multiple nodes and don't want 
them to just wait forever for a write lock, 
I have such a case when i need to do a  non-transactional bulk load of cache 
with streaming, but this can happen on multiple
nodes. Tried doing it with semaphores with draining, but then two writers can 
start drain permits at same time and eventually
end up in dead lock between them.


was (Author: kromulan):
If you ask me any lock related feature would be a nice addition to ignite, 
especially when there is a combination of read+write :)
Another important question for you Vladisave, would ReentrantReadWriteLock 
impementation include fair ordering option ? 
Especially if you have multiple write lockers on on multiple nodes and don't 
want them to just wait forever for a write lock, 
I have such a case when i need to do a  non-transactional bulk load of cache 
with streaming, but this can happen on multiple
nodes. Tried doing it with semaphores with draining, but then two writers can 
start drain permits at same time and eventually
end up in dead lock between them.

> Implement IgniteReentrantReadWriteLock data structure
> -
>
> Key: IGNITE-637
> URL: https://issues.apache.org/jira/browse/IGNITE-637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantReadWriteLock}} data structure in addition to 
> other data structures provided by Ignite. {{IgniteReentrantReadWriteLock}} 
> should have similar API to 
> {{java.util.concurrent.locks.ReentrantReadWriteLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> readers and writers and allow user threads to block whenever needed to wait 
> for a lock.



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

[jira] [Commented] (IGNITE-3414) Hadoop: Optimize map-reduce job planning.

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383758#comment-15383758
 ] 

Vladimir Ozerov commented on IGNITE-3414:
-

1) Because we want to assign local reducers until some limit is reached, and 
only then switch to weight-based distribution. This way when there are only 
several reducers, they are likely to be assigned to nodes where some mappers 
are run. If we rely only on weights, the same behavior is only possible when 
local and remote reducer weights are different. And this will be bad for cases 
when there are lots reducers - the imbalance between local and remote nodes 
will grow linearly.
2) This is exactly how it works now. 
3) Too difficult for a very rare case when there are more than one node on a 
single machine.

> Hadoop: Optimize map-reduce job planning.
> -
>
> Key: IGNITE-3414
> URL: https://issues.apache.org/jira/browse/IGNITE-3414
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently Hadoop module has inefficient map-reduce planning engine. In 
> particular, it assigns tasks only to affinity nodes. It could lead to 
> situation when very huge tasks is processed by a single cluster node, while 
> other cluster nodes are idle. 
> We should implement configurable map-reduce planner which will be able to 
> utilize the whole cluster.



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

[jira] [Created] (IGNITE-3502) Hadoop randomwriter doesn't work in hadoop edition

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-3502:
-

 Summary: Hadoop randomwriter doesn't work in hadoop edition
 Key: IGNITE-3502
 URL: https://issues.apache.org/jira/browse/IGNITE-3502
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 1.6
 Environment: CentOS 7, Hadoop 2.7.2
Reporter: Sergey Kozlov


0. Install hadoop and set up HADOOP_HOME
1. Setup Ignite hadoop {{bin/setup-hadoop.sh}}
1. Start one node {{bin/ignite.sh -v -J-Xmx20g -J-Xms20g}}
2. Start randomwriter example (is tries to write 10GB for each node)
3. The example and server node hung.



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

[jira] [Closed] (IGNITE-2423) We should correctly handle a case when DB has several shemas with the tables with the same name

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov closed IGNITE-2423.
--
Assignee: (was: Pavel Konstantinov)

Successfully tested on staging.

> We should correctly handle a case when DB has several shemas with the tables 
> with the same name
> ---
>
> Key: IGNITE-2423
> URL: https://issues.apache.org/jira/browse/IGNITE-2423
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.7
>
>
> Currently in this case we generated several caches\models with the same name. 
> This is wrong.
> We could:
> 1) add schema name to generated cache\model
> 2) show error on Save 



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

[jira] [Assigned] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Vladislav Pyatkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladislav Pyatkov reassigned IGNITE-3495:
-

Assignee: Vladislav Pyatkov  (was: Andrey Velichko)

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
> Attachments: ExampleNodeStartupClient.java, example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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

[jira] [Commented] (IGNITE-3495) CacheMetrics.getAverage###Time is not calculated properly

[Vladislav Pyatkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383652#comment-15383652
 ] 

Vladislav Pyatkov commented on IGNITE-3495:
---

I will take it upon myself.

> CacheMetrics.getAverage###Time is not calculated properly
> -
>
> Key: IGNITE-3495
> URL: https://issues.apache.org/jira/browse/IGNITE-3495
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Andrey Velichko
> Attachments: ExampleNodeStartupClient.java, example-default.xml
>
>
> {{CacheMetrics.getAverageGetTime}}, {{CacheMetrics.getAveragePutTime}} and 
> {{CacheMetrics.getAverageRemoveTime}} are not calculated properly in the 
> following scenario:
> - start a server node;
> - start a client node that will perform gets and puts;
> - {{CacheMetrics.getAverage###Time}} will always be 0 for the server node's 
> cluster group.
> The issue happens because {{CacheMetricsImpl.add###TimeNanos}} method is not 
> called on the server side when a metric related event happens.
> In the attache you can find source that showcases the bug.
> - start basic {{ExampleNodeStartup}} using attached configuration 
> {{example-default.xml}} conjuration;
> - start {{ExampleNodeStartupClient}}. You will see that average metrics are 
> not incremented.



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