[jira] [Updated] (IGNITE-3220) I/O bottleneck on server/client cluster configuration

2016-11-15 Thread Alexei Scherbakov (JIRA)

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

Alexei Scherbakov updated IGNITE-3220:
--
Fix Version/s: (was: 1.8)
   2.0

> I/O bottleneck on server/client cluster configuration
> -
>
> Key: IGNITE-3220
> URL: https://issues.apache.org/jira/browse/IGNITE-3220
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Reporter: Alexei Scherbakov
>Assignee: Yakov Zhdanov
>Priority: Critical
>  Labels: performance
> Fix For: 2.0
>
>
> Steps to reproduce:
> # start 1 server and 1 client nodes in single JVM. Do cache.put(randomKey) 
> from 16 threads. Get N ops/sec.
> # start 1 server and 2 client nodes in single JVM. Do cache.put(randomKey) 
> from 16 threads picking up random client of 2. Get 2*N ops/sec.
> One of the possible reasons of this is the IO approach. Currently, all direct 
> marshallable messages are marshalled and unmarshalled in a single NIO thread 
> which is in charge for the connection this message goes to or comes from.
> Possible fix may be:
> # move direct marshalling from user & system threads to make it parallel
> ## after all user objects are marshalled, direct marshallable message should 
> be able to provide the size of the resulting message 
> ## communication should allocate rather big direct byte buffer per connection
> ## user or system thread that wants to send message should request a chunk 
> (256 or 512) for writing direct message to
> ## thread can request another chunk from communication (communication should 
> try allocating chunk next to already allocated), if chunk cannot be expanded 
> thread may allocate buffer locally and finish marshalling to it.
> ## set of buffers can be written to sock channel with 
> {{java.nio.channels.SocketChannel#write(java.nio.ByteBuffer[], int, int)}}
> ## amount of info written to the soket should be even to some value, e.g. 256 
> or 512 bytes. Free space should be sent as well.
> ## each chunk (i.e. 256 or 512 bytes) written to socket should have local 
> thread ID in the very beginning.
> # move direct UN-marshalling from NIO hreads to make it parallel
> ## data is read by chunks, first thread ID of the chunk should be analyzed 
> and chunk should be submitted to striped thread pool for unmarshalling
> ## after message is unmarshalled it gets processed in the way it is done now.
> NOTE: As a further idea we can try to do user object marshalling directly to 
> per-connection buffer and switch thread to process another message until 
> chunk is flushed (similar to job continuation approach).



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


[jira] [Updated] (IGNITE-3905) Optimize RendezvousAffinityFunction

2016-11-15 Thread Alexei Scherbakov (JIRA)

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

Alexei Scherbakov updated IGNITE-3905:
--
Fix Version/s: (was: 1.8)
   2.0

> Optimize RendezvousAffinityFunction
> ---
>
> Key: IGNITE-3905
> URL: https://issues.apache.org/jira/browse/IGNITE-3905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, community, general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 2.0
>
>
> Currently RendezvousAffinityFunction.assignPartition generates a lot of 
> garbage if called very often, on example in case of rebalancing a lot of 
> caches.
> This causes excessive pressure on GC, which is not always fast enough to 
> clear memory, producing long GC pauses leading to node segmentation.
> We should cache calculation of nodeHashBytes in node attribute or resort to 
> more efficient node hash calculation.



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


[jira] [Updated] (IGNITE-3714) Introduce new performance hint for default store-by-value caches behavior.

2016-11-15 Thread Alexei Scherbakov (JIRA)

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

Alexei Scherbakov updated IGNITE-3714:
--
Fix Version/s: (was: 1.8)
   2.0

> Introduce new performance hint for default store-by-value caches behavior.
> --
>
> Key: IGNITE-3714
> URL: https://issues.apache.org/jira/browse/IGNITE-3714
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, newbie
>Reporter: Alexei Scherbakov
> Fix For: 2.0
>
>
> Default store-by-value semantics of Ignite has bad impact on performance and 
> rarely needed.
> We must print the performance hint if some of the caches have copyOnRead 
> property set to true (default value).
> It must work both for static and dynamic caches.
> Corresponding thread on dev list: 
> http://apache-ignite-developers.2346864.n4.nabble.com/copyOnRead-performance-issues-td10762.html



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


[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

2016-11-15 Thread Dmitriy Govorukhin (JIRA)

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

Dmitriy Govorukhin updated IGNITE-1678:
---
Fix Version/s: (was: 1.8)
   2.0

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
> Fix For: 2.0
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



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


[jira] [Updated] (IGNITE-2654) Protocol optimization for GridNearLockRequest/Response

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-2654:

Fix Version/s: (was: 1.8)
   2.0

> Protocol optimization for GridNearLockRequest/Response
> --
>
> Key: IGNITE-2654
> URL: https://issues.apache.org/jira/browse/IGNITE-2654
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Ilya Lantukh
>  Labels: performance
> Fix For: 2.0
>
>
> Create new, more lightweight versions of GridNearLockRequest/Response:
> - Make miniId integer.
> - Store boolean flags in a single byte field.
> - Remove unused fields.



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


[jira] [Updated] (IGNITE-3727) Support local listeners async execution for IgniteMessage.send

2016-11-15 Thread Dmitriy Govorukhin (JIRA)

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

Dmitriy Govorukhin updated IGNITE-3727:
---
Fix Version/s: (was: 1.8)
   2.0

> Support local listeners async execution for IgniteMessage.send
> --
>
> Key: IGNITE-3727
> URL: https://issues.apache.org/jira/browse/IGNITE-3727
> Project: Ignite
>  Issue Type: Task
>  Components: messaging
>Affects Versions: 1.7
> Environment: windows 7
>Reporter: Yujue Li
>Assignee: Dmitriy Govorukhin
> Fix For: 2.0
>
>
> ignite.message() method not support async mode,withAsync() is invalid.



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


[jira] [Updated] (IGNITE-2539) NPE at RendezvousAffinityFunction

2016-11-15 Thread Dmitriy Govorukhin (JIRA)

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

Dmitriy Govorukhin updated IGNITE-2539:
---
Fix Version/s: (was: 1.8)
   2.0

> NPE at RendezvousAffinityFunction
> -
>
> Key: IGNITE-2539
> URL: https://issues.apache.org/jira/browse/IGNITE-2539
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ershov
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.0
>
> Attachments: ignite.log
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> RendezvousAffinityFunction#assignPartition throws NPE, probably due to 
> simultaneous topology change and  cache stop. We should write a test and fix 
> this.



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


[jira] [Updated] (IGNITE-2037) Update javadocs and documentation about LOCAL cache could be created on client node

2016-11-15 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov updated IGNITE-2037:
-
Fix Version/s: (was: 1.8)
   2.0

> Update javadocs and documentation about LOCAL cache could be created on 
> client node
> ---
>
> Key: IGNITE-2037
> URL: https://issues.apache.org/jira/browse/IGNITE-2037
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, newbie
>Affects Versions: ignite-1.4
>Reporter: Alexey Kuznetsov
>Assignee: kcheng.mvp
>Priority: Trivial
>  Labels: newbie
> Fix For: 2.0
>
>
> Code that show local cache on client node:
> {code}
> public class LocalCacheOnClient {
> public static void main(String[] args) throws IgniteException {
> IgniteConfiguration cfgSrv = new IgniteConfiguration();
> cfgSrv.setGridName("srv");
> Ignite n1 = Ignition.start(cfgSrv);
> IgniteConfiguration cfgClm = new IgniteConfiguration();
> cfgClm.setGridName("cln");
> cfgClm.setClientMode(true);
> Ignite n2 = Ignition.start(cfgClm);
> CacheConfiguration ccfg = new 
> CacheConfiguration<>("local");
> ccfg.setCacheMode(CacheMode.LOCAL);
> IgniteCache c = n2.getOrCreateCache(ccfg);
> c.put(1, 100);
> n1.close(); // stop server node
> c.put(2, 200); // local cache works fine.
> System.out.println(c.get(1));
> System.out.println(c.get(2));
> }
> }
> {code}



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


[jira] [Assigned] (IGNITE-3443) Implement collecting what SQL statements executed on cluster and their metrics.

2016-11-15 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov reassigned IGNITE-3443:


Assignee: Alexey Kuznetsov  (was: Semen Boikov)

> Implement collecting what SQL statements executed on cluster and their 
> metrics.
> ---
>
> Key: IGNITE-3443
> URL: https://issues.apache.org/jira/browse/IGNITE-3443
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
>
> We could collect last 1000 (maybe configurable) sql statements with per  
> statement statistics: count, min time, max time, avg time,
> May be execution plan (explain) ?
> ---
> Proposed API changes:
> So, I introduced interface org.apache.ignite.cache.query.QueryDetailsMetrics 
> with metrics:
> {code}
> /**
>  * Query metrics aggregated by query type and its textual representation.
>  */
> public interface QueryDetailsMetrics {
> /**
>  * @return Query type.
>  */
> public String getQueryType();
> /**
>  * @return Textual representation of query.
>  */
> public String getQuery();
> /**
>  * @return Cache where query was executed.
>  */
> public String getCache();
> /**
>  * Gets total number execution of query.
>  *
>  * @return Number of executions.
>  */
> public int getExecutions();
> /**
>  * Gets number of completed execution of query.
>  *
>  * @return Number of completed executions.
>  */
> public int getCompletions();
> /**
>  * Gets number of times a query execution failed.
>  *
>  * @return Number of times a query execution failed.
>  */
> public int getFailures();
> /**
>  * Gets minimum execution time of query.
>  *
>  * @return Minimum execution time of query.
>  */
> public long getMinimumTime();
> /**
>  * Gets maximum execution time of query.
>  *
>  * @return Maximum execution time of query.
>  */
> public long getMaximumTime();
> /**
>  * Gets average execution time of query.
>  *
>  * @return Average execution time of query.
>  */
> public double getAverageTime();
> /**
>  * Gets total time of all query executions.
>  *
>  * @return Total time of all query executions.
>  */
> public long getTotalTime();
> /**
>  * Gets latest query start time.
>  *
>  * @return Latest time query was stared.
>  */
> public long getLastStartTime();
> }
> {code}
> And added method on org.apache.ignite.IgniteCache:
> {code}
> /**
>  * Gets query metrics details.
>  *
>  * @return Metrics.
>  */
> public Collection queryMetricsHistory();
> {code}
> And also I added new property on 
> org.apache.ignite.configuration.CacheConfiguration:
> {code}
> /**
>  * Gets size of queries metrics history that will be stored in memory for 
> monitoring purposes.
>  * If {@code 0} then history will not be collected.
>  * Note, Larger number may lead to higher memory consumption.
>  *
>  * @return Maximum number of query metrics that will be stored in memory.
>  */
> public int getQueryMetricsHistorySize() {
> return qryMetricsHistSz;
> }
> /**
>  * Sets size of queries metrics history that will be stored in memory for 
> monitoring purposes.
>  *
>  * @param qryMetricsHistSz Maximum number of latest queries metrics that will 
> be stored in memory.
>  * @return {@code this} for chaining.
>  */
> public CacheConfiguration setQueryMetricsHistorySize(int 
> qryMetricsHistSz) {
> this.qryMetricsHistSz = qryMetricsHistSz;
> return this;
> }
> {code}



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


[jira] [Updated] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4018:

Affects Version/s: 1.7

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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


[jira] [Updated] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4018:

Component/s: (was: cache)
 SQL

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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


[jira] [Updated] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4018:

Affects Version/s: (was: 1.7)

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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


[jira] [Updated] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4018:

Fix Version/s: 1.8

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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


[jira] [Updated] (IGNITE-4169) Data streamer mode for DML

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4169:

Fix Version/s: 1.8

> Data streamer mode for DML
> --
>
> Key: IGNITE-4169
> URL: https://issues.apache.org/jira/browse/IGNITE-4169
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> SQL INSERT and MERGE are supposed to support data streamer mode which should 
> be turned on by JDBC connection string param.
> Note: particular details of usage means and implementation of this mode, as 
> well as urgency of this feature are yet to be discussed.



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


[jira] [Updated] (IGNITE-2294) Implement SQL DML (insert, update, delete) clauses.

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-2294:

Fix Version/s: (was: 2.0)
   1.8

> Implement SQL DML (insert, update, delete) clauses.
> ---
>
> Key: IGNITE-2294
> URL: https://issues.apache.org/jira/browse/IGNITE-2294
> Project: Ignite
>  Issue Type: Wish
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 1.8
>
>
> We need to add parsing for all the listed SQL commands and translate them 
> into respective cache operations (putIfAbstent, put, remove).



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


[jira] [Updated] (IGNITE-3919) Let JDBC driver have H2's metadata for PreparedStatements

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3919:

Fix Version/s: (was: 2.0)
   1.8

> Let JDBC driver have H2's metadata for PreparedStatements
> -
>
> Key: IGNITE-3919
> URL: https://issues.apache.org/jira/browse/IGNITE-3919
> Project: Ignite
>  Issue Type: Sub-task
>  Components: jdbc-driver
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> Subj. - needed for IGNITE-3910. Will do it in DML branch.



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


[jira] [Updated] (IGNITE-4112) Client is stopped if communication to servers is lost during (re)connect routine.

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4112:

Fix Version/s: (was: 1.8)
   2.0

> Client is stopped if communication to servers is lost during (re)connect 
> routine.
> -
>
> Key: IGNITE-4112
> URL: https://issues.apache.org/jira/browse/IGNITE-4112
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Consider the following situation for the client which is currently 
> disconnected:
> 1) Link to servers is restored;
> 2) Clients connects successfully;
> 3) Link is broken again after some time.
> Result: client is disconnected.
> But!
> 1) Link to servers is restored;
> 2) Clients is re-connecting;
> 3) Link is broken again before reconnect is finished.
> Result: client might be stopped (for new client it will exit from 
> {{Ignition.start}} routine with exception).
> Apparently, we need to make (re)connect routine "atomic" with respect to 
> concurrent network events. That is, we either reconnect all components 
> successfully, or client is forcefully moved to disconnected state again. 



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


[jira] [Updated] (IGNITE-4092) Implement prototype for thread-per-partition approach.

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4092:

Fix Version/s: (was: 1.8)
   2.0

> Implement prototype for thread-per-partition approach.
> --
>
> Key: IGNITE-4092
> URL: https://issues.apache.org/jira/browse/IGNITE-4092
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
>  Labels: performance
> Fix For: 2.0
>
>
> Rationale:
> - Decrease contention on thread-pool blocking queue head/tail;
> - Minimize amount of thread parks/unparks;
> - Decrease overhead on partition RW locking.
> Implementation:
> - Implemented striped thread pool;
> - Every thread has separate non-blocking queue;
> - Blocking back-off strategy if queue is empty.



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


[jira] [Updated] (IGNITE-4015) Continuous query events could be lost on backup node when primary leaves (transactional cache).

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4015:

Fix Version/s: (was: 1.8)
   2.0

> Continuous query events could be lost on backup node when primary leaves 
> (transactional cache).
> ---
>
> Key: IGNITE-4015
> URL: https://issues.apache.org/jira/browse/IGNITE-4015
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>  Labels: transactions
> Fix For: 2.0
>
>
> Consider the following scenario:
> 1) One stable node in topology;
> 2) PARTITIONED, TRANSACTIONAL cache with 1 backup;
> 3) Continuous query is set on the cache;
> 4) Put some data to cache.
> If another node joins the cluster, it will handle some updates.
> But when it leaves the topology during put transaction, transaction rolled 
> back with retry and events are lost.
> Reproducer can be found in 
> org.apache.ignite.loadtests.continuous.CacheContinuousQueryFailoverTxPrimaryWriteOrderLoadTest



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


[jira] [Updated] (IGNITE-1494) Get return nulls for some cache configurations

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-1494:

Fix Version/s: (was: 1.8)
   2.0

> Get return nulls for some cache configurations
> --
>
> Key: IGNITE-1494
> URL: https://issues.apache.org/jira/browse/IGNITE-1494
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
> Fix For: 2.0
>
> Attachments: CacheTestExample.java, grid_config_01.client.xml, 
> grid_config_01.xml
>
>
> 1. Copy grid_config_01.xml and grid_config_01.client.xml in examples/config 
> directory (it contains 25 FULL_SYNCed cache configurations)
> 2. Copy CacheTestExample in org.apache.ignite.examples.datagrid package
> 3. Start two nodes by bin/ignite.sh examples/config/grid_config_01.xml
> 4. Build and run CacheTestExample (it makes put/get/remove operations for 100 
> keys) a few times (w/o stopping server nodes)
> 5. The normal output should be following:
> {noformat}
> [12:12:02] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [12:12:02] 
> [12:12:02] Ignite node started OK (id=3f1ea113)
> [12:12:02] Topology snapshot [ver=5, servers=2, clients=1, CPUs=8, heap=3.8GB]
> >>>cache_0001
> Put 100 -> put1_
> Get 100
> RemoveAll 100
> Put 1..50 -> put2_ 
> Remove 30.40
> RemoveAll 21..50
> PutAll 21..100 -> putall_
> Get 1..20
> Get 21..100
> >>>cache_0002
> Put 100 -> put1_
> Get 100
> RemoveAll 100
> Put 1..50 -> put2_ 
> Remove 30.40
> RemoveAll 21..50
> PutAll 21..100 -> putall_
> Get 1..20
> Get 21..100
> >>>cache_0003
> Put 100 -> put1_
> Get 100
> RemoveAll 100
> Put 1..50 -> put2_ 
> Remove 30.40
> RemoveAll 21..50
> PutAll 21..100 -> putall_
> Get 1..20
> Get 21..100
> ...
> {noformat}
> But for some caches I got:
> {noformat}
> >>>cache_0011
> Put 100 -> put1_
> Get 100
> RemoveAll 100
> Put 1..50 -> put2_ 
> Remove 30.40
> RemoveAll 21..50
> PutAll 21..100 -> putall_
> Get 1..20
> Wrong value found [key=1, val=null]
> Wrong value found [key=2, val=null]
> Wrong value found [key=3, val=null]
> Wrong value found [key=4, val=null]
> Get 21..100
> ...
> {noformat}



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


[jira] [Updated] (IGNITE-3117) Weblogic manual tests for HttpSession caching.

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3117:

Fix Version/s: (was: 1.8)
   2.0

> Weblogic manual tests for HttpSession caching.
> --
>
> Key: IGNITE-3117
> URL: https://issues.apache.org/jira/browse/IGNITE-3117
> Project: Ignite
>  Issue Type: Test
>  Components: websession
>Affects Versions: 1.6
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Minor
>  Labels: patch, test
> Fix For: 2.0
>
> Attachments: IGNITE_3117_servlet_tests.patch
>
>
> Simple tests that allow deploy and check that HttpSession is cached properly 
> in grid.



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


[jira] [Commented] (IGNITE-3066) Set of Redis commands that can be easily implemented via existing REST commands

2016-11-15 Thread Roman Shtykh (JIRA)

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

Roman Shtykh commented on IGNITE-3066:
--

1) One addition. I chose to call REST commands as I understood from the 
comments from Yakov (see IGNITE-2788) I have to do this way. I might 
misunderstood though. Do you think we should use cache API directly for all 
commands? If you have a better idea, please advise.
Anyway, it's a rather big refactoring that can be done as a next step.

> Set of Redis commands that can be easily implemented via existing REST 
> commands
> ---
>
> Key: IGNITE-3066
> URL: https://issues.apache.org/jira/browse/IGNITE-3066
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> As the 1st iteration of IGNITE-2788 the following commands can be implemented 
> via existing REST commands,
> GET
> MGET
> SET
> MSET
> INCR
> DECR
> INCRBY
> DECRBY
> APPEND
> STRLEN
> GETSET
> SETRANGE
> GETRANGE
> DEL
> EXISTS
> DBSIZE
> http://redis.io/commands



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


[jira] [Commented] (IGNITE-4148) Web console: adding a first item in CheckpointSPI takes a long time under Firefox

2016-11-15 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov commented on IGNITE-4148:


For now adding a first item in CheckpointSPI is fast.

> Web console: adding a first item in CheckpointSPI takes a long time under 
> Firefox
> -
>
> Key: IGNITE-4148
> URL: https://issues.apache.org/jira/browse/IGNITE-4148
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> 1) I've noticed adding a first item in CheckpointSPI list takes a long time 
> in Firefox.
> We need to investigate and fix the reason.
> 2) Hide not mandatory fields under the 'show advanced' panel



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


[jira] [Closed] (IGNITE-4148) Web console: adding a first item in CheckpointSPI takes a long time under Firefox

2016-11-15 Thread Pavel Konstantinov (JIRA)

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

Pavel Konstantinov closed IGNITE-4148.
--
Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: adding a first item in CheckpointSPI takes a long time under 
> Firefox
> -
>
> Key: IGNITE-4148
> URL: https://issues.apache.org/jira/browse/IGNITE-4148
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> 1) I've noticed adding a first item in CheckpointSPI list takes a long time 
> in Firefox.
> We need to investigate and fix the reason.
> 2) Hide not mandatory fields under the 'show advanced' panel



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


[jira] [Commented] (IGNITE-3066) Set of Redis commands that can be easily implemented via existing REST commands

2016-11-15 Thread Roman Shtykh (JIRA)

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

Roman Shtykh commented on IGNITE-3066:
--

Andrey, I enforced operations on strings.

> Set of Redis commands that can be easily implemented via existing REST 
> commands
> ---
>
> Key: IGNITE-3066
> URL: https://issues.apache.org/jira/browse/IGNITE-3066
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> As the 1st iteration of IGNITE-2788 the following commands can be implemented 
> via existing REST commands,
> GET
> MGET
> SET
> MSET
> INCR
> DECR
> INCRBY
> DECRBY
> APPEND
> STRLEN
> GETSET
> SETRANGE
> GETRANGE
> DEL
> EXISTS
> DBSIZE
> http://redis.io/commands



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


[jira] [Commented] (IGNITE-1943) ignitevisorcmd: wrong behavior for "mclear" command

2016-11-15 Thread Andrey Novikov (JIRA)

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

Andrey Novikov commented on IGNITE-1943:


Hi Saikat,

I think will be better execute mcompact manually by user. Visor cmd can be used 
in batch mode where user scripts can't expect this behavior.

> ignitevisorcmd: wrong behavior for "mclear" command
> ---
>
> Key: IGNITE-1943
> URL: https://issues.apache.org/jira/browse/IGNITE-1943
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vasilisa  Sidorova
>Assignee: Saikat Maitra
> Fix For: 1.8
>
>
> -
> DESCRIPTION
> -
> "mclear" should clears all Visor console variables before they will be 
> updated during next run of the corresponding command. It OK for all type of 
> shortcut (@cX, @tX, @aX, @eX) exept shortcut for node-id variables. After 
> "mclear" @nX are disappear from any statistics 
> -
> STEPS FOR REPRODUCE
> -
> # Start cluster
> # Start visorcmd ([IGNITE_HOME]/bin/ignitevisorcmd.sh)
> # Connect to the started cluster (visor> open)
> # Execute any tasks in it (for example, run any example from EventsExample, 
> DeploymentExample, ComputeContinuousMapperExample, ComputeTaskMapExample, 
> ComputeTaskSplitExample) 
> # Create several alerts (visor> alert)
> # Run visor "mclear" command
> # Run visor "node" command
> -
> ACTUAL RESULT
> -
> There isn't @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +==+
> | # |   Node ID8(@), IP   | Up Time  | CPUs | CPU Load | Free Heap |
> +==+
> | 0 | 6B3E4033, 127.0.0.1 | 00:38:41 | 8| 0.20 %   | 97.00 %   |
> | 1 | 0A0D6989, 127.0.0.1 | 00:38:22 | 8| 0.17 %   | 97.00 %   |
> | 2 | 0941E33F, 127.0.0.1 | 00:35:46 | 8| 0.23 %   | 97.00 %   |
> +--+
> {noformat}
> -
> EXPECTED RESULT
> -
> There is @nX values in the first table's column:
> {noformat}
> visor> node
> Select node from:
> +===+
> | # | Node ID8(@), IP  | Up Time  | CPUs | CPU Load | Free Heap |
> +===+
> | 0 | 6B3E4033(@n0), 127.0.0.1 | 00:38:13 | 8| 0.23 %   | 97.00 %   |
> | 1 | 0A0D6989(@n1), 127.0.0.1 | 00:37:54 | 8| 0.27 %   | 97.00 %   |
> | 2 | 0941E33F(@n2), 127.0.0.1 | 00:35:18 | 8| 0.20 %   | 97.00 %   |
> +---+
> {noformat}
> "mclear" should get effect only for "mget @nX" command (with result "Missing 
> variable with name: '@nX'") and @nX variables  should get new values after 
> "node" (or "tasks") command execution. Like in case for all others @ 
> variables (@cX, @tX, @aX, @eX) 



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


[jira] [Closed] (IGNITE-4198) Ignite Kafka sink connector should have an option to transform Kafka values

2016-11-15 Thread Roman Shtykh (JIRA)

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

Roman Shtykh closed IGNITE-4198.


> Ignite Kafka sink connector should have an option to transform Kafka values
> ---
>
> Key: IGNITE-4198
> URL: https://issues.apache.org/jira/browse/IGNITE-4198
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: community, streaming
> Fix For: 1.8
>
>
> Currently the connector takes a Kafka key and uses it as an Ignite key. 
> However, Kafka keys can be null, and users may want to specify an Ignite key 
> from the value object.
> Instead of creating a new transformer interface, I think we can use 
> {{StreamMultipleTupleExtractor}} whenever its implementation is specified by 
> the user in connector config file.
> http://apache-ignite-users.70518.x6.nabble.com/Kafka-Failed-to-stream-a-record-with-null-key-td8731.html



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


[jira] [Updated] (IGNITE-4199) Functionality to extract keys from values when sinking data from kafka topics

2016-11-15 Thread Roman Shtykh (JIRA)

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

Roman Shtykh updated IGNITE-4199:
-
Fix Version/s: (was: 1.7)
   1.8

> Functionality to extract keys from values when sinking data from kafka topics
> -
>
> Key: IGNITE-4199
> URL: https://issues.apache.org/jira/browse/IGNITE-4199
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
> Environment: linux, centos 7
>Reporter: austin solomon
>Assignee: Roman Shtykh
>Priority: Blocker
>  Labels: performance
> Fix For: 1.8
>
>
> I have a use case where I am reading a text file using kafka's  
> FileStreamSource connector and sinking the data to Ignite's cache.
> I got an error while doing this
> Error: ERROR Failed to stream a record with null key!
> (org.apache.ignite.stream.kafka.connect.IgniteSinkTask:96)
> When I printed the streamed record i got the following result : key=null
> SinkRecord{kafkaOffset=2, timestampType=CreateTime} 
> ConnectRecord{topic='ignitetest', kafkaPartition=2, key=null, value=k1,v1, 
> timestamp=1478690650016}
> I wish to have a functionality to extracting keys from values or any work 
> around.



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


[jira] [Closed] (IGNITE-4199) Functionality to extract keys from values when sinking data from kafka topics

2016-11-15 Thread Roman Shtykh (JIRA)

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

Roman Shtykh closed IGNITE-4199.


Implemented in IGNITE-4198.

> Functionality to extract keys from values when sinking data from kafka topics
> -
>
> Key: IGNITE-4199
> URL: https://issues.apache.org/jira/browse/IGNITE-4199
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
> Environment: linux, centos 7
>Reporter: austin solomon
>Assignee: Roman Shtykh
>Priority: Blocker
>  Labels: performance
> Fix For: 1.7
>
>
> I have a use case where I am reading a text file using kafka's  
> FileStreamSource connector and sinking the data to Ignite's cache.
> I got an error while doing this
> Error: ERROR Failed to stream a record with null key!
> (org.apache.ignite.stream.kafka.connect.IgniteSinkTask:96)
> When I printed the streamed record i got the following result : key=null
> SinkRecord{kafkaOffset=2, timestampType=CreateTime} 
> ConnectRecord{topic='ignitetest', kafkaPartition=2, key=null, value=k1,v1, 
> timestamp=1478690650016}
> I wish to have a functionality to extracting keys from values or any work 
> around.



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


[jira] [Commented] (IGNITE-4198) Ignite Kafka sink connector should have an option to transform Kafka values

2016-11-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4198:


Github user asfgit closed the pull request at:

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


> Ignite Kafka sink connector should have an option to transform Kafka values
> ---
>
> Key: IGNITE-4198
> URL: https://issues.apache.org/jira/browse/IGNITE-4198
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: community, streaming
> Fix For: 1.8
>
>
> Currently the connector takes a Kafka key and uses it as an Ignite key. 
> However, Kafka keys can be null, and users may want to specify an Ignite key 
> from the value object.
> Instead of creating a new transformer interface, I think we can use 
> {{StreamMultipleTupleExtractor}} whenever its implementation is specified by 
> the user in connector config file.
> http://apache-ignite-users.70518.x6.nabble.com/Kafka-Failed-to-stream-a-record-with-null-key-td8731.html



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


[jira] [Updated] (IGNITE-4230) Create documentation for the integration with Tableau

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4230:

Description: 
Let's create a simple documentation that will show how to connect from Tableau 
to Ignite and what steps have to be performed to fulfill this.

The documentation has to be placed under "Integrations" section on readme.io. 
The section is missing for now but will be introduced soon. Under this section 
we will have documentation for Zeppelin, Memcached, Mybatis, etc.

Refer to this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html

  was:
Let's create a simple documentation that will show how to connect from Tableau 
to Ignite and what steps have to be performed to fulfil this.

Refer to this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html


> Create documentation for the integration with Tableau
> -
>
> Key: IGNITE-4230
> URL: https://issues.apache.org/jira/browse/IGNITE-4230
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Fix For: 2.0
>
>
> Let's create a simple documentation that will show how to connect from 
> Tableau to Ignite and what steps have to be performed to fulfill this.
> The documentation has to be placed under "Integrations" section on readme.io. 
> The section is missing for now but will be introduced soon. Under this 
> section we will have documentation for Zeppelin, Memcached, Mybatis, etc.
> Refer to this discussion for more details:
> http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html



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


[jira] [Created] (IGNITE-4230) Create documentation for the integration with Tableau

2016-11-15 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-4230:
---

 Summary: Create documentation for the integration with Tableau
 Key: IGNITE-4230
 URL: https://issues.apache.org/jira/browse/IGNITE-4230
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Igor Sapego
 Fix For: 2.0


Let's create a simple documentation that will show how to connect from Tableau 
to Ignite and what steps have to be performed to fulfil this.

Refer to this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Connecting-to-Ignite-from-Tableau-td12065.html



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


[jira] [Commented] (IGNITE-1192) Provide integration with Spring Data

2016-11-15 Thread Sury Sinha (JIRA)

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

Sury Sinha commented on IGNITE-1192:


[~EdShangGG] , I was interested in integrating Ignite caching with Spring Data 
, Looks like there is some progress on this based on last commit from you . Can 
you please point me :
a) any sample code for Spring Data and Ignite integration
b) version of Ignite which needs to be used  

> Provide integration with Spring Data
> 
>
> Key: IGNITE-1192
> URL: https://issues.apache.org/jira/browse/IGNITE-1192
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Minor
>  Labels: Newbie
> Fix For: 2.0
>
>
> Spring Data docs:
> * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/
> * http://docs.spring.io/spring-data/data-commons/docs/current/api/



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


[jira] [Commented] (IGNITE-4116) .NET: documentation and example for client reconnect feature

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4116:
-

Pavel, "reconnect" is not used as a noun. This is a verb only. Prachi, please 
pay attention to this as well.

> .NET: documentation and example for client reconnect feature
> 
>
> Key: IGNITE-4116
> URL: https://issues.apache.org/jira/browse/IGNITE-4116
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 1.7
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 1.8
>
> Attachments: Screen Shot 2016-10-31 at 8.53.01 AM.png
>
>
> Presently the documentation and example about the client reconnect feature is 
> missing on .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> (https://apacheignite.readme.io/docs/clients-vs-servers#client-reconnect)
> - The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/ClientReconnectExample.cs



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


[jira] [Updated] (IGNITE-4137) .NET: add example for Atomic Types

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4137:

Assignee: Pavel Tupitsyn  (was: Denis Magda)

> .NET: add example for Atomic Types
> --
>
> Key: IGNITE-4137
> URL: https://issues.apache.org/jira/browse/IGNITE-4137
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Add the example that will showcase the usage of all Atomic Types that are 
> presently supported in .NET.



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


[jira] [Commented] (IGNITE-4137) .NET: add example for Atomic Types

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4137:
-

Pavel,

I've left minor comments in GitHub. Didn't manage to do this in Code Review due 
to missing permissions.

As for AtomicLong and AtomicSequence example, you can make a difference by at 
least changing the value of {{atomicSequenceReserveSize}} in 
{{AtomicConfiguration}} and explaining why this may be needed.  

> .NET: add example for Atomic Types
> --
>
> Key: IGNITE-4137
> URL: https://issues.apache.org/jira/browse/IGNITE-4137
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.8
>
>
> Add the example that will showcase the usage of all Atomic Types that are 
> presently supported in .NET.



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


[jira] [Updated] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-3921:

Assignee: Prachi Garg  (was: Denis Magda)

> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Prachi Garg
>  Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we 
> need to document it for our users.



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


[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-3921:
-

Igor, awesome!

I've polished a bit the documentation. [~pgarg] would you mind reviewing this 
small section?
https://apacheignite.readme.io/v1.7/docs/connection-string-and-dsn#configuring-dsn

After you finalize the review please re-assign the ticket back on me. I'll go 
through the whole documentation setting up everything on my side from scratch.

> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Denis Magda
>  Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we 
> need to document it for our users.



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


[jira] [Updated] (IGNITE-4019) ODBC and DML: Document the usage on Apache Readme.io

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4019:

Assignee: Prachi Garg  (was: Denis Magda)

> ODBC and DML: Document the usage on Apache Readme.io
> 
>
> Key: IGNITE-4019
> URL: https://issues.apache.org/jira/browse/IGNITE-4019
> Project: Ignite
>  Issue Type: Task
>  Components: cache, odbc
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 1.8
>
>
> Create "a new page" under ODBC section [1] on readme.io naming "DML Support" 
> and put the following content:
> - basic description on DML support by our ODBC driver. There should be a 
> reference to IGNITE-4018 that will contain overall information on DML.
> - list every supported command (INSERT, MERGE, UPDATE, DELETE) providing a 
> small code snippet examples. The examples can be taken from the example that 
> will be enhanced as a part of IGNITE-4016
> [1] https://apacheignite.readme.io/docs/odbc-driver



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


[jira] [Commented] (IGNITE-4019) ODBC and DML: Document the usage on Apache Readme.io

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4019:
-

Igor, thanks. I've looked over the documentation and improved it a bit. 
[~pgarg], please do the final review of this page
http://apacheignite.gridgain.org/v1.7/docs/querying-and-modifying-data

> ODBC and DML: Document the usage on Apache Readme.io
> 
>
> Key: IGNITE-4019
> URL: https://issues.apache.org/jira/browse/IGNITE-4019
> Project: Ignite
>  Issue Type: Task
>  Components: cache, odbc
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 1.8
>
>
> Create "a new page" under ODBC section [1] on readme.io naming "DML Support" 
> and put the following content:
> - basic description on DML support by our ODBC driver. There should be a 
> reference to IGNITE-4018 that will contain overall information on DML.
> - list every supported command (INSERT, MERGE, UPDATE, DELETE) providing a 
> small code snippet examples. The examples can be taken from the example that 
> will be enhanced as a part of IGNITE-4016
> [1] https://apacheignite.readme.io/docs/odbc-driver



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


[jira] [Commented] (IGNITE-4103) IgniteDataStreamer doesn't throw exception if cache is destroyed

2016-11-15 Thread Saikat Maitra (JIRA)

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

Saikat Maitra commented on IGNITE-4103:
---

[~avinogradov]

Hi Anton,

I verified that in DataStreamProcessor #localUpdate() the check is present for 
cache but it is not present in IgniteCacheObjectProcessorImpl #partition() 
method.

Can you please rethrow the IgniteCheckedException in the above partition() 
method. 

Regards,
Saikat

> IgniteDataStreamer doesn't throw exception if cache is destroyed
> 
>
> Key: IGNITE-4103
> URL: https://issues.apache.org/jira/browse/IGNITE-4103
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
> Fix For: 1.8
>
> Attachments: StreamerTest.java
>
>
> Test reproducing the issue is attached.
> When a streamer streams the data and someone concurrently destroys the cache, 
> {{addData}} doesn't throw an exception. Code continues to work and a lot of 
> messages like this appear in the log:
> {noformat}
> [12:20:38,451][ERROR][main][CacheObjectBinaryProcessorImpl] Failed to get 
> partition
> {noformat}
> The problematic code is in {{IgniteCacheObjectProcessorImpl.partition(...)}} 
> method:
> {code}
> try {
> return cctx != null ?
> cctx.affinity().partition(obj, false) :
> ctx.kernalContext().affinity().partition0(ctx.cacheName(), obj, null);
> }
> catch (IgniteCheckedException e) {
> U.error(log, "Failed to get partition");
> return  -1;
> }
> {code}
> There are two issues here:
> # Exception is completely ignored, it's not even printed out in {{U.error}}.
> # The exception should be actually rethrown so that streamer can stop adding 
> data.



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


[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache

2016-11-15 Thread Sergey Chugunov (JIRA)

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

Sergey Chugunov commented on IGNITE-4157:
-

Refactored IgnitePluginProcessor and ClusterProcessor to use new discovery 
sharing solution.

> Use discovery custom messages instead of marshaller and system cache
> 
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



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


[jira] [Commented] (IGNITE-4184) Document how ODBC drivers works with the cluster

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4184:
-

Igor,

Thanks, I've slightly modified the documentation [1].

However, what's about this point  from the description - "Details on how ODBC 
connection works on C++ side and how you can alter specific parameters using 
Configuration object"? If someone adjusts settings on Java side using 
OdbcDriver configuration then we may need to update some setting on C++ side 
over Connector object. Is this so? If yes we should add a relevant 
documentation to C++ part of the doc.

[1] 
http://apacheignite.gridgain.org/v1.7/docs/getting-started-18#cluster-configuration

> Document how ODBC drivers works with the cluster
> 
>
> Key: IGNITE-4184
> URL: https://issues.apache.org/jira/browse/IGNITE-4184
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.0
>
>
> There are no any details on how ODBC driver connects to the cluster and sends 
> queries to it for the execution. 
> Let's make our documentation more technical by adding the following blocks to 
> this page [1]:
> - ODBC Driver necessity and usage on Java side
> - ODBC Configuration parameter
> - Details on how ODBC connection works on C++ side and how you can alter 
> specific parameters using Configuration object
> [1] https://apacheignite.readme.io/docs/odbc-driver



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


[jira] [Updated] (IGNITE-4184) Document how ODBC drivers works with the cluster

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4184:

Assignee: Igor Sapego  (was: Denis Magda)

> Document how ODBC drivers works with the cluster
> 
>
> Key: IGNITE-4184
> URL: https://issues.apache.org/jira/browse/IGNITE-4184
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Igor Sapego
> Fix For: 2.0
>
>
> There are no any details on how ODBC driver connects to the cluster and sends 
> queries to it for the execution. 
> Let's make our documentation more technical by adding the following blocks to 
> this page [1]:
> - ODBC Driver necessity and usage on Java side
> - ODBC Configuration parameter
> - Details on how ODBC connection works on C++ side and how you can alter 
> specific parameters using Configuration object
> [1] https://apacheignite.readme.io/docs/odbc-driver



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


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

2016-11-15 Thread Saikat Maitra (JIRA)

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

Saikat Maitra edited comment on IGNITE-3303 at 11/15/16 6:41 PM:
-

[~avinogradov]

Hi Anton,

Thank you for your feedback.

1.  I have investigated the issue further with static stopped variable and 
noticed that the exit condition was not correctly defined for the tests. I have 
fixed it and updated the PR.

2. parallelism is set to 1 so that multiple threads do not receive and process 
same events. The parallelism may not be useful for the tests but will be useful 
when join, map and reduce are used over data streams. 


3. team city report 
http://ci.ignite.apache.org/viewLog.html?buildId=358872=IgniteTests_IgniteStreamers=buildResultsDiv

Regards,
Saikat



was (Author: samaitra):
[~avinogradov]

Hi Anton,

Thank you for your feedback.

1.  I have investigated the issue further with static stopped variable and 
noticed that the exit condition was not correctly defined for the tests. I have 
fixed it and updated the PR.

2. parallelism is set to 1 so that multiple threads do not receive and process 
same events. There is no data filtering, partitioning during receiving events 
so with parallelism count more than 1, all the threads will start processing 
the events and the following test assert fails.
{noformat} assertEquals(eventList, resultList) {noformat}

The parallelism may not be useful for the tests but will be useful in cluster 
env when join, map and reduce are used over data streams. 


3. team city report 
http://ci.ignite.apache.org/viewLog.html?buildId=358872=IgniteTests_IgniteStreamers=buildResultsDiv

Regards,
Saikat


> 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: Saikat Maitra
> Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, 
> testFlinkIgniteSourceWithLargeBatch.log, win7.PNG
>
>
> 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-4138) .NET: document additional parameters usage in Apache.Ignite.exe.config

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4138:
-

Ok, let's close the ticket if everything is ready from all the parties.

> .NET: document additional parameters usage in Apache.Ignite.exe.config
> --
>
> Key: IGNITE-4138
> URL: https://issues.apache.org/jira/browse/IGNITE-4138
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> There is no any information available on how to change the config and set the 
> assembly path directly in {{Apache.Ignite.exe.config}} file.
> At the level of {{Apache.Ignite.exe.config}} please do the following:
> - Document Ignite.ConfigFileName parameter.
> - Document Ignite.Assembly parameter.
> Also add this information to readme.io configuration page
> https://apacheignite-net.readme.io/docs/configuration



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


[jira] [Updated] (IGNITE-4138) .NET: document additional parameters usage in Apache.Ignite.exe.config

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4138:

Assignee: Pavel Tupitsyn  (was: Denis Magda)

> .NET: document additional parameters usage in Apache.Ignite.exe.config
> --
>
> Key: IGNITE-4138
> URL: https://issues.apache.org/jira/browse/IGNITE-4138
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> There is no any information available on how to change the config and set the 
> assembly path directly in {{Apache.Ignite.exe.config}} file.
> At the level of {{Apache.Ignite.exe.config}} please do the following:
> - Document Ignite.ConfigFileName parameter.
> - Document Ignite.Assembly parameter.
> Also add this information to readme.io configuration page
> https://apacheignite-net.readme.io/docs/configuration



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


[jira] [Updated] (IGNITE-4125) .NET: documentation and example for off-heap and swap tieres

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda updated IGNITE-4125:

Assignee: Pavel Tupitsyn  (was: Denis Magda)

> .NET: documentation and example for off-heap and swap  tieres
> -
>
> Key: IGNITE-4125
> URL: https://issues.apache.org/jira/browse/IGNITE-4125
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Presently the documentation and example about the off-heap and swap tieres 
> are missing on .NET side. Let's fill this gap.
> Documentation can be taken from Java side 
> https://apacheignite.readme.io/docs/off-heap-memory
> The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/MultiTieredCacheExample.cs



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


[jira] [Commented] (IGNITE-4125) .NET: documentation and example for off-heap and swap tieres

2016-11-15 Thread Denis Magda (JIRA)

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

Denis Magda commented on IGNITE-4125:
-

Vovan, Pavel,

In my practice, there is at least one use case when the swap space is used in 
production. The use case is to avoid out of memory issues or the whole cluster 
shut down if there is not enough RAM for the whole data set. It can take time 
while IT guys detect that there is almost no RAM is left and will take time to 
scale out the cluster by adding new machines. While the cluster will be being 
scaled out the data that is no longer fit in memory will be moved to swap, at 
least temporarily which will preserve cluster's stability.

So I would add the swap space to this example and, apparently, add some notes 
about the applicability of the swap. 

> .NET: documentation and example for off-heap and swap  tieres
> -
>
> Key: IGNITE-4125
> URL: https://issues.apache.org/jira/browse/IGNITE-4125
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.8
>
>
> Presently the documentation and example about the off-heap and swap tieres 
> are missing on .NET side. Let's fill this gap.
> Documentation can be taken from Java side 
> https://apacheignite.readme.io/docs/off-heap-memory
> The example that can be (should be) added to the distribution is the 
> following 
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/MultiTieredCacheExample.cs



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


[jira] [Updated] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4018:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-2294

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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


[jira] [Updated] (IGNITE-4017) DML: Add Java Example

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-4017:

Issue Type: Sub-task  (was: Task)
Parent: IGNITE-2294

> DML: Add Java Example
> -
>
> Key: IGNITE-4017
> URL: https://issues.apache.org/jira/browse/IGNITE-4017
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to improve existed or add additional examples.
> We need to add {{CacheDmlExample}} doing the following with DML's *GridGain 
> Java API*:
> - fill up a cache using INSERT commands.
> - execute SELECT statements. There are should be queries with joins.
> - perform cache update using UPDATE and MERGE statements.
> - execute SELECT statements. There are should be queries with joins.
> - remove a part of the data from cache using DELETE command.
> execute SELECTs again.



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


[jira] [Assigned] (IGNITE-4138) .NET: document additional parameters usage in Apache.Ignite.exe.config

2016-11-15 Thread Prachi Garg (JIRA)

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

Prachi Garg reassigned IGNITE-4138:
---

Assignee: Denis Magda  (was: Prachi Garg)

> .NET: document additional parameters usage in Apache.Ignite.exe.config
> --
>
> Key: IGNITE-4138
> URL: https://issues.apache.org/jira/browse/IGNITE-4138
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 1.8
>
>
> There is no any information available on how to change the config and set the 
> assembly path directly in {{Apache.Ignite.exe.config}} file.
> At the level of {{Apache.Ignite.exe.config}} please do the following:
> - Document Ignite.ConfigFileName parameter.
> - Document Ignite.Assembly parameter.
> Also add this information to readme.io configuration page
> https://apacheignite-net.readme.io/docs/configuration



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


[jira] [Commented] (IGNITE-4138) .NET: document additional parameters usage in Apache.Ignite.exe.config

2016-11-15 Thread Prachi Garg (JIRA)

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

Prachi Garg commented on IGNITE-4138:
-

changed to 'via', and fixed other minor issues.

> .NET: document additional parameters usage in Apache.Ignite.exe.config
> --
>
> Key: IGNITE-4138
> URL: https://issues.apache.org/jira/browse/IGNITE-4138
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 1.8
>
>
> There is no any information available on how to change the config and set the 
> assembly path directly in {{Apache.Ignite.exe.config}} file.
> At the level of {{Apache.Ignite.exe.config}} please do the following:
> - Document Ignite.ConfigFileName parameter.
> - Document Ignite.Assembly parameter.
> Also add this information to readme.io configuration page
> https://apacheignite-net.readme.io/docs/configuration



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


[jira] [Commented] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

2016-11-15 Thread Andrew Mashenkov (JIRA)

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

Andrew Mashenkov commented on IGNITE-4106:
--

We need to split GridH2TreeIndex into segments, to each thread can work with 
its own segment. 

GridH2Tree.doFind method is feasible candidate. Partition filter that was saved 
in GridH2QueryContext is accessed in doFind method. We can add additional 
context property to transfer some "segment index" instead of using partition 
filter. This will reduce message size and simplify code, due to we shouldn't be 
bothered with distributing partitions among the threads in 
GridReduceQueryExecutor. 


> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



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


[jira] [Commented] (IGNITE-4227) ODBC: Implement SQLError function

2016-11-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4227:


GitHub user isapego opened a pull request:

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

IGNITE-4227: Implemented SQLError.



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

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

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

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


commit 7290d88e14a15a3d030b7381dbd0a3f14cb65a12
Author: Pavel Tupitsyn 
Date:   2016-10-18T14:17:17Z

IGNITE-4030 Streamline PlatformTarget operation methods

This closes #1167

commit 66c76d1f30f024b58db8cab07ba9e7d429f596f8
Author: tledkov-gridgain 
Date:   2016-10-18T15:45:06Z

IGNITE-2355 Fixed the test HadoopClientProtocolMultipleServersSelfTest. 
Clear connection poll after the test, cosmetic.

commit f37fbcab1ae2c7553696e96b7a9c3194a570d7af
Author: isapego 
Date:   2016-10-19T10:06:42Z

IGNITE-3705: Fixed compiliation warnings. This closes #1169.

commit 7ed2bb7e341701d052220a36a2b2f8f0a46fd644
Author: AMRepo 
Date:   2016-10-19T15:33:59Z

IGNITE-3448 Support SQL queries with distinct aggregates added. This closes 
#3448.

commit 551a4dfae6169a07a5e28f9b266f90311f3216b7
Author: tledkov-gridgain 
Date:   2016-10-21T10:25:57Z

IGNITE-2355 Fixed the test HadoopClientProtocolMultipleServersSelfTest. 
Clear connection poll before and after  the test

commit ec12a9db2265180f96be72e2217e60ced856164e
Author: vozerov-gridgain 
Date:   2016-10-24T14:52:36Z

Minor fix for flags passed to GridCacheMapEntry.initialValue from data 
streamer isolated updater.

commit 44740465677c39068dc813dabd464e60f09e5f49
Author: tledkov-gridgain 
Date:   2016-10-26T13:00:11Z

IGNITE-4062: fix BinaryObject.equals: compare only bytes containing the 
fields' data (without header and footer). This closes  #1182.

commit 9ddb8be1243df8e489f7ebc716d315415775439a
Author: Dmitriy Govorukhin 
Date:   2016-10-27T14:52:22Z

IGNITE-2079 GridCacheIoManager eats exception trail if it falls into the 
directed case
merger from ignite-2079-2

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/GridCacheQueryMetricsAdapter.java

commit 6f160728c544d252f77bdb85c0ff2857559707a3
Author: Valentin Kulichenko 
Date:   2016-10-28T23:18:14Z

IGNITE-4110 - Fixed BUFFER_UNDERFLOW and BUFFER_OVERFLOW handling in 
BlockingSslHandler

commit 6b78ad0cbbcf286cb083136c49cebd5dd85de58c
Author: sboikov 
Date:   2016-10-31T07:35:44Z

TcoDiscovery: reduced amount of debug logging (heartbeat/connection check 
messages are logged trace level).

commit 175da6b7e394dd76c27d5155ff98a5b2ef03bb9d
Author: tledkov-gridgain 
Date:   2016-11-07T06:16:58Z

IGNITE-3432:  check data/meta cache names are different for different IGFS 
instances. This closes #1201

commit 40ef2f5ae42826fe8fd077e3013e8f55c8512bdd
Author: Dmitriy Govorukhin 
Date:   2016-11-07T09:09:41Z

ignite-4178 support permission builder

commit fc7ce5a4d72145f2e8a86debeda264ef0a5b37e3
Author: isapego 
Date:   2016-11-07T10:26:05Z

IGNITE-4090: Added flags so stdint and limits can be used in C++.

commit a98804a249496ba9bafbc96daa7aaf25b3d36724
Author: Igor Sapego 
Date:   2016-11-07T11:00:00Z

IGNITE-4113: Added tests. Added Statement::Set/GetAttribute.

commit 950bad474ef29f9b808e74034c49a69d57eb2740
Author: dkarachentsev 
Date:   2016-11-08T11:03:34Z

GG-11655 - Restore service compatibility with releases before 1.5.30.

commit 3d19bfc2b66574e3945ce17c7a4dfe77d0070b8d
Author: dkarachentsev 
Date:   2016-11-08T11:04:36Z

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

commit e821dc0083003bc81058b1cb223d8a8a2ee44daf
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:09:21Z

IGNITE-2079 (revert commit) GridCacheIoManager eats exception trail if it 
falls into the directed case

commit c2c82ca44befe4570325dd6cf2ba885e0d90596c
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:10:10Z

Merge remote-tracking branch 'professional/ignite-1.6.11' into ignite-1.6.11

commit 865bbcf0f41a0c4944e0928f1758d43a0eae82c5
Author: Dmitriy Govorukhin 

[jira] [Comment Edited] (IGNITE-4129) .NET: add documentation and example for near cache

2016-11-15 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn edited comment on IGNITE-4129 at 11/15/16 4:01 PM:
--

Near cache can be probed via CachePeekMode.Near


was (Author: ptupitsyn):
Looks like there is no way to know how near cache is used (no metrics for 
this), should we still provide this example? It does not demonstrate anything 
useful.

> .NET: add documentation and example for near cache
> --
>
> Key: IGNITE-4129
> URL: https://issues.apache.org/jira/browse/IGNITE-4129
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Presently the documentation and example about the near caching are missing on 
> .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> https://apacheignite.readme.io/docs/near-caches
> - This example should be used as a reference
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/NearCacheExample.cs
> However, we have to improve it by showing that the near cache is really used 
> (metrics or event listeners or something else)



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


[jira] [Updated] (IGNITE-3288) Load test benchmark: log current number of operations over caches on demand

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-3288:

Fix Version/s: (was: 1.8)
   1.9

> Load test benchmark: log current number of operations over caches on demand
> ---
>
> Key: IGNITE-3288
> URL: https://issues.apache.org/jira/browse/IGNITE-3288
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
> Fix For: 1.9
>
>
> Currently statistics on operations done over each cache is logged only at the 
> end of the test. It whould be really helpful to have an ability to log such 
> statistics on demand during the test (for instance, sending some signal) or 
> over some configured interval (introduce new option).



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


[jira] [Commented] (IGNITE-4129) .NET: add documentation and example for near cache

2016-11-15 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-4129:


Looks like there is no way to know how near cache is used (no metrics for 
this), should we still provide this example? It does not demonstrate anything 
useful.

> .NET: add documentation and example for near cache
> --
>
> Key: IGNITE-4129
> URL: https://issues.apache.org/jira/browse/IGNITE-4129
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Presently the documentation and example about the near caching are missing on 
> .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> https://apacheignite.readme.io/docs/near-caches
> - This example should be used as a reference
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/NearCacheExample.cs
> However, we have to improve it by showing that the near cache is really used 
> (metrics or event listeners or something else)



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


[jira] [Assigned] (IGNITE-4129) .NET: add documentation and example for near cache

2016-11-15 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn reassigned IGNITE-4129:
--

Assignee: Pavel Tupitsyn

> .NET: add documentation and example for near cache
> --
>
> Key: IGNITE-4129
> URL: https://issues.apache.org/jira/browse/IGNITE-4129
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Presently the documentation and example about the near caching are missing on 
> .NET side. Let's fill this gap.
> - Documentation can be taken from Java side 
> https://apacheignite.readme.io/docs/near-caches
> - This example should be used as a reference
> https://github.com/gridgain/apache-ignite/blob/ignite-net-advanced-examples/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Advanced/NearCacheExample.cs
> However, we have to improve it by showing that the near cache is really used 
> (metrics or event listeners or something else)



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


[jira] [Updated] (IGNITE-3338) BinaryObjectException: Failed to get field because type ID of passed object differs from type ID this BinaryField belongs to - during load test with eviction configured

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-3338:

Fix Version/s: (was: 1.8)
   1.9

> BinaryObjectException: Failed to get field because type ID of passed object 
> differs from type ID this BinaryField belongs to -  during load test with 
> eviction configured
> -
>
> Key: IGNITE-3338
> URL: https://issues.apache.org/jira/browse/IGNITE-3338
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Ksenia Rybakova
> Fix For: 1.9
>
>
> The following exceptions occur during load test with eviction configured:
> {noformat}
> ERROR: The benchmark of random operation failed.
> Type '--help' for usage.
> Finishing main test [ts=1466178657166, date=Fri Jun 17 08:50:57 PDT 2016]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
> (retry update if possible).: [26, 1872066, 1945790, 2405741, 3845651, 
> 4830233, 7284502, 8555643]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1467)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1972)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.removeAll(IgniteCacheProxy.java:1416)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.doRemoveAll(IgniteCacheRandomOperationBenchmark.java:809)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeRandomOperation(IgniteCacheRandomOperationBenchmark.java:551)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeOutOfTx(IgniteCacheRandomOperationBenchmark.java:509)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.test(IgniteCacheRandomOperationBenchmark.java:156)
> at 
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:176)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [26, 1872066, 
> 1945790, 2405741, 3845651, 4830233, 7284502, 8555643]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onResult(GridNearAtomicUpdateFuture.java:311)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:2958)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$700(GridDhtAtomicCache.java:129)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:266)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:264)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ... 1 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys on primary node.
> at 
> 

[jira] [Updated] (IGNITE-3292) Yardstick: add logging of preloading progress

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-3292:

Fix Version/s: (was: 1.8)
   1.9

> Yardstick: add logging of preloading progress
> -
>
> Key: IGNITE-3292
> URL: https://issues.apache.org/jira/browse/IGNITE-3292
> Project: Ignite
>  Issue Type: Wish
>  Components: yardstick
>Reporter: Ksenia Rybakova
> Fix For: 1.9
>
>
> Please, add logging of preloading progress. This is really useful when we 
> load a lot of entries or they are large. 
> For instance: "Preloading: 200 of 1000 loaded".
> Also adding an option that controls frequency of such output makes sense. For 
> instance, this might be a step (number of entries loaded) - if entries are 
> large, we set small step, if entries are integers,  the step will be large.



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


[jira] [Updated] (IGNITE-3358) Yardstick: log exception that causes driver shutdown

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-3358:

Fix Version/s: (was: 1.8)
   1.9

> Yardstick: log exception that causes driver shutdown
> 
>
> Key: IGNITE-3358
> URL: https://issues.apache.org/jira/browse/IGNITE-3358
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ksenia Rybakova
>Priority: Critical
> Fix For: 1.9
>
>
> Some times driver stops during load test with the errors like:
> {noformat}
> ERROR: The benchmark of random operation failed.
> Type '--help' for usage.
> Finishing main test [ts=1466613716339, date=Wed Jun 22 09:41:56 PDT 2016]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> {noformat}
> But there is no info which exactly exception caused this error. If we have 
> many exceptions in the log it's impossible to identify the root cause.
> Please, add stack trace of the exception to the error.



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


[jira] [Updated] (IGNITE-3401) "Remote node ID is not as expected" errors at driver during load test

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-3401:

Fix Version/s: (was: 1.8)
   1.9

> "Remote node ID is not as expected" errors at driver during load test
> -
>
> Key: IGNITE-3401
> URL: https://issues.apache.org/jira/browse/IGNITE-3401
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Ksenia Rybakova
> Fix For: 1.9
>
>
> A lot of errors at some drivers after several minutes after grid is up during 
> load test:
> {noformat}
> [14:33:42] (err) Failed to execute compound future reducer: Compound future 
> listener []class org.apache.ignite.IgniteCheckedException: Failed to send 
> message (node may have left the grid or TCP connection cannot be established 
> due to fir
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1193)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1378)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1173)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:756)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:568)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:604)
> at 
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark$1.run(IgniteCacheRandomOperationBenchmark.java:383)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
> message to remote node: TcpDiscoveryNode 
> [id=11da20f5-87c5-4321-8163-ffef85f2d54c, addrs=[10.20.0.215, 127.0.0.1], 
> sockAddrs=[/127.0.0.1:47503, fosters-215/10.20.0
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1986)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1926)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1124)
> ... 7 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect 
> to node (is node still alive?). Make sure that each GridComputeTask and 
> GridCacheTransaction has a timeout set in order to prevent parties from 
> waiting forever
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2489)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2130)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2024)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1960)
> ... 9 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> connect to address: fosters-215/10.20.0.215:47103
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> read remote node recovery handshake (connection closed).
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2699)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> connect to address: /127.0.0.1:47103
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Remote 
> node ID is not as expected [expected=11da20f5-87c5-4321-8163-ffef85f2d54c, 
> rcvd=03bc7d54-4fec-481d-af24-6f5408b32fe2]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2604)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> {noformat}
> Tested version: 1.5.27
> Load config:
> - 7 hosts with 4 servers and 3 drivers each (28 servers and 21 

[jira] [Updated] (IGNITE-4094) .NET: NPE at org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.execute while running ServicesExample

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-4094:

Fix Version/s: (was: 1.8)
   1.9

> .NET: NPE at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.execute
>  while running ServicesExample
> --
>
> Key: IGNITE-4094
> URL: https://issues.apache.org/jira/browse/IGNITE-4094
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
> Environment: version 1.6.10
>Reporter: Ksenia Rybakova
>  Labels: .NET
> Fix For: 1.9
>
>
> 1) Build examples according to 
> %IGNITE_HOME%\platforms\dotnet\examples\README.txt
> 2) Run 4 standalone Apache Ignite.NET nodes as it is described in 
> ServicesExample.cs
> 3) Run ServicesExample
> NPE occured at one of the nodes. Also it's strange that 
> initialized->started->cancelled happened twice.
> {noformat}
> [15:03:08] Topology snapshot [ver=41, servers=5, clients=0, CPUs=4, 
> heap=18.0GB]
> Service initialized: service
> Service started: service
> Service cancelled: service
> Service initialized: service
> Service cancelled: service
> [15:03:11,062][SEVERE][ignite-#374%null%][GridServiceProcessor] Service 
> execution stopped with error [name=service, 
> execId=e27cefac-31a8-46b7-bee9-b56d060d77b3]
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.execute(PlatformAbstractService.java:119)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$2.run(GridServiceProcessor.java:1101)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> [15:03:11] Topology snapshot [ver=42, servers=4, clients=0, CPUs=4, 
> heap=14.0GB]
> {noformat}
> The 2nd node has two "initialized->started->cancelled" as well
> {noformat}
> [15:03:08] Topology snapshot [ver=41, servers=5, clients=0, CPUs=4, 
> heap=18.0GB]
> Service initialized: service
> Service started: service
> Service cancelled: service
> Service initialized: service
> Service started: service
> Service cancelled: service
> [15:03:11] Topology snapshot [ver=42, servers=4, clients=0, CPUs=4, 
> heap=14.0GB]
> {noformat}
> The 3rd and 4th nodes are ok:
> {noformat}
> [15:03:08] Topology snapshot [ver=41, servers=5, clients=0, CPUs=4, 
> heap=18.0GB]
> Service initialized: service
> Service started: service
> Service cancelled: service
> [15:03:11] Topology snapshot [ver=42, servers=4, clients=0, CPUs=4, 
> heap=14.0GB]
> {noformat}



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


[jira] [Created] (IGNITE-4229) Loading configuration from XML into Console for further editing

2016-11-15 Thread Alexander (JIRA)
Alexander created IGNITE-4229:
-

 Summary: Loading configuration from XML into Console for further 
editing
 Key: IGNITE-4229
 URL: https://issues.apache.org/jira/browse/IGNITE-4229
 Project: Ignite
  Issue Type: Wish
Reporter: Alexander
Assignee: Alexey Kuznetsov
Priority: Minor


It would be great to have ability of loading an external XML into Console as 
the initial configuration and then get editing.

At this point it's only allowed to create a configuration from scratch and then 
export to the XML.



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


[jira] [Updated] (IGNITE-4214) "Failed to wait for partition map exchange" warnings during different load tests

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-4214:

Fix Version/s: (was: 1.9)

> "Failed to wait for partition map exchange" warnings during different load 
> tests
> 
>
> Key: IGNITE-4214
> URL: https://issues.apache.org/jira/browse/IGNITE-4214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Attachments: IGNITE-4214.logs.zip, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> "Failed to wait for partition map exchange" warnings appears during different 
> load tests. Grid doesn't hang though and operations are performed 
> successfully.
> Example of load test config:
> - Benchmark: CacheRandomOperation
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 12
>  Corresponding Yardstick configs and property file are attached.
> Some logs with the error are attached. Complete logs will be provided by 
> request.



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


[jira] [Created] (IGNITE-4228) Missing documentation on CacheJdbcPojoStore

2016-11-15 Thread Alexander (JIRA)
Alexander created IGNITE-4228:
-

 Summary: Missing documentation on CacheJdbcPojoStore
 Key: IGNITE-4228
 URL: https://issues.apache.org/jira/browse/IGNITE-4228
 Project: Ignite
  Issue Type: Wish
  Components: documentation
Affects Versions: 1.7
Reporter: Alexander
Assignee: Alexey Kuznetsov
Priority: Minor


Missing documentation on CacheJdbcPojoStore class in Javadoc.

Especially on the method loadCache() - what kind of the optional arguments is 
supported?



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


[jira] [Updated] (IGNITE-3558) Affinity task hangs when Collision SPI produces a lot of job rejections & Failover SPI produces many attempts

2016-11-15 Thread Taras Ledkov (JIRA)

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

Taras Ledkov updated IGNITE-3558:
-
Fix Version/s: (was: 1.8)
   2.0

> Affinity task hangs when Collision SPI produces a lot of job rejections & 
> Failover SPI produces many attempts
> -
>
> Key: IGNITE-3558
> URL: https://issues.apache.org/jira/browse/IGNITE-3558
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> The test to reproduce:
> IgniteCacheLockPartitionOnAffinityRunWithCollisionSpiTest#testJobFinishing
> *Root cause*
> GridJobExecuteResponse isn't set from target node because there is a 
> confusion with GridJobWorker instances in the CollisionContext.
> *Suggestion*
> The method GridJobProcessor.CollisionJobContext.cancel()
> use passiveJobs.remove(jobWorker.getJobId(), jobWorker). 
> *passiveJobs* is a ConcurrentHashMap and GridJobWorker.equals() implements as 
> a equation of jobId.
> So, when two thread try to cancel the two workers with *the same jobIds* we 
> have the case:
> - thread0 remove jobWorker0 & cancel jobWorker0.
> - thread0 put jobWorker1 (because jobWorker0 already removed);
> - thread1: (has a copy of jobWorker0) and try to cancel it.
> - thread1: remove jobWorker1 instead of jobWorker0 (because jobId is used to 
> identify);
> - thread1: doesn't send ExecuteResponse because jobWorker0 has been canceled.
> *Proposal*
> Try to use system default equals for the GridJobWorker



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


[jira] [Updated] (IGNITE-2097) Splitting Query example

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov updated IGNITE-2097:
--
Fix Version/s: (was: 1.8)
   2.0

> Splitting Query example
> ---
>
> Key: IGNITE-2097
> URL: https://issues.apache.org/jira/browse/IGNITE-2097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4, 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
>
> CacheQueryExample is overloaded by query features. What's about to introduce 
> a new package e.g. called {{org.apache.ignite.examples.query}} and split 
> {{org.apache.ignite.examples.datagrid.CacheQueryExample}} into separate 
> examples like: 
> QueryScanExample 
> QueryJoinExample 
> QueryTextExample 
> QueryAggregationExample 
> QueryFieldsExample 
> QueryFieldsJoinExample 
> And add new ones:
> QueryCrossCacheExample 
> QueryExplainExample 
> upd YZ: I think this should be done in separate package 
> {{org.apache.ignite.examples.datagrid.query}}



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


[jira] [Updated] (IGNITE-2085) Yardstick: introduce json/xml support

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov updated IGNITE-2085:
--
Fix Version/s: (was: 1.8)
   2.0

> Yardstick: introduce json/xml support
> -
>
> Key: IGNITE-2085
> URL: https://issues.apache.org/jira/browse/IGNITE-2085
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4, 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
>
> Now yardstick produces a few csv files with probes: 
> ThroughtputLatencyProbe.csv, DStatProbe.csv, PercentileProbe.csv. 
> But such formats are simple ones and don't allow to make deep analyzing.
> Thus I suggest the following approach:
>  - introduce json or xml support for probes
>  - the data collected over different csv files should be combined in one 
> json/xml file
>  - all data related for run conditions (like benchmark options, hosts, 
> date/time, ignite revision etc) shoud be added to this json/xml file



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


[jira] [Commented] (IGNITE-4137) .NET: add example for Atomic Types

2016-11-15 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn commented on IGNITE-4137:


AtomicLong, AtomicSequence and AtomicReference examples added, similar to 
examples in Java.

However, AtomicLong and AtomicSequence examples are identical. Any ideas how to 
make them better?

> .NET: add example for Atomic Types
> --
>
> Key: IGNITE-4137
> URL: https://issues.apache.org/jira/browse/IGNITE-4137
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Add the example that will showcase the usage of all Atomic Types that are 
> presently supported in .NET.



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


[jira] [Resolved] (IGNITE-1889) FIFO eviction for atomic cache after removeAll

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov resolved IGNITE-1889.
---
   Resolution: Fixed
Fix Version/s: (was: 1.8)
   2.0

> FIFO eviction for atomic cache after removeAll
> --
>
> Key: IGNITE-1889
> URL: https://issues.apache.org/jira/browse/IGNITE-1889
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
>
> 1. Start 2 data nodes with following config
> {code:title=config.xml|borderStyle=solid}
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy">
> 
> 
> 
> 
> 
> 
> {code}
> 2. Start client and make following operations for cache_0001
> 2.1. put 100 entries
> 2.2. removeAll 
> 2.3. put 60 entries
> 2.4. get 60 entries (same keys from previous step)
> 2.5. got 40 entries only



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


[jira] [Updated] (IGNITE-4214) "Failed to wait for partition map exchange" warnings during different load tests

2016-11-15 Thread Ksenia Rybakova (JIRA)

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

Ksenia Rybakova updated IGNITE-4214:

Fix Version/s: 1.9

> "Failed to wait for partition map exchange" warnings during different load 
> tests
> 
>
> Key: IGNITE-4214
> URL: https://issues.apache.org/jira/browse/IGNITE-4214
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
> Fix For: 1.9
>
> Attachments: IGNITE-4214.logs.zip, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> "Failed to wait for partition map exchange" warnings appears during different 
> load tests. Grid doesn't hang though and operations are performed 
> successfully.
> Example of load test config:
> - Benchmark: CacheRandomOperation
> - Operations: put, put_all, get, get_all, invoke, invoke_all, remove, 
> remove_all, put_if_absent, replace
> - Heap: 8Gb for servers, 4Gb for clients
> - 5 clients, 20 servers
> - Number of caches: 12
> - Types of caches (atomicity mode): different (atomic, transactional)
> - Types of caches (tiered storage mode): different (onheap without eviction, 
> onheap with eviction, offheap_tired, offheap_values)
> - Types of caches (indexing): different (with and without indexes)
> - Types of caches (cache mode): different (partitioned, replicated)
> - Backups count: 12
>  Corresponding Yardstick configs and property file are attached.
> Some logs with the error are attached. Complete logs will be provided by 
> request.



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


[jira] [Closed] (IGNITE-4107) Sporadic NPE for ServiceExample

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov closed IGNITE-4107.
-

> Sporadic NPE for ServiceExample 
> 
>
> Key: IGNITE-4107
> URL: https://issues.apache.org/jira/browse/IGNITE-4107
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
>
> Sometimes executing {{ServiceExample}} with 3 nodes throws NPE on a server 
> node:
> {noformat}
> [13:38:31,381][INFO][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=870f84bb-8952-4e25-9bcc-84d0b5b8e47b]
> [13:38:31,382][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=8de084c0-609c-4a93-b8de-284337210774]
> [13:38:31,420][INFO][sys-#26%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [13:38:31,422][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=e75c3ce9-e396-49ec-b729-00ee6f0e587d]
> [13:38:31,441][INFO][disco-event-worker-#20%null%][GridDiscoveryManager] Node 
> left topology: TcpDiscoveryNode [id=609ab107-9786-419d-95aa-a3da52305531, 
> addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 172.25.2.127, 
> 2001:0:9d38:6abd:c8d:2f03:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6abd:c8d:2f03:3c6f:269:0, /0:0:0:0:0:0:0:1:0, 
> /127.0.0.1:0, work-pc/172.25.2.127:0], discPort=0, order=4, intOrder=4, 
> lastExchangeTime=1477305509885, loc=false, ver=1.6.10#20161020-sha1:30cb02de, 
> isClient=true]
> [13:38:31,442][INFO][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=5, servers=3, clients=0, CPUs=8, heap=3.0GB]
> [13:38:31,469][INFO][sys-#27%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [13:38:31,471][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=a4c5be10-f0d0-4c62-a870-c1e3af4669c9]
> [13:38:31,473][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=5, minorTopVer=0], evt=NODE_LEFT, 
> node=609ab107-9786-419d-95aa-a3da52305531]
> [13:38:31,495][INFO][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [13:38:31,496][SEVERE][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=5, 
> minorTopVer=1], nodeId=a4c5be10, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> [13:38:31,500][SEVERE][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Failed to wait for completion of partition map exchange (preloading will not 
> start): GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryCustomEvent [customMsg=null, 
> affTopVer=AffinityTopologyVersion [topVer=5, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a4c5be10-f0d0-4c62-a870-c1e3af4669c9, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.2.127, 2001:0:9d38:6abd:c8d:2f03:3c6f:269], 
> sockAddrs=[work-pc/172.25.2.127:47501, /127.0.0.1:47501, 
> /0:0:0:0:0:0:0:1:47501, /2001:0:9d38:6abd:c8d:2f03:3c6f:269:47501], 
> discPort=47501, order=2, intOrder=2, lastExchangeTime=1477305488276, 
> loc=false, ver=1.6.10#20161020-sha1:30cb02de, isClient=false], topVer=5, 
> nodeId8=8de084c0, msg=null, type=DISCOVERY_CUSTOM_EVT, 
> 

[jira] [Closed] (IGNITE-2168) Examples should destroy created caches: SpringBeanExample fails after CacheBinaryAutoStoreExample

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov closed IGNITE-2168.
-

> Examples should destroy created caches: SpringBeanExample fails after 
> CacheBinaryAutoStoreExample
> -
>
> Key: IGNITE-2168
> URL: https://issues.apache.org/jira/browse/IGNITE-2168
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Vladimir Ershov
> Fix For: 1.8
>
>
> 1. Start remote node with examples/config/example-ignite.xml
> 2. Run DbH2ServerStartup
> 3. Run CacheBinaryAutoStoreExample ()
> 4. Run SpringBeanExample and get the following exception: 
> {noformat}
> >>> Spring bean example started.
> log4j:WARN No appenders could be found for logger 
> (org.springframework.core.env.StandardEnvironment).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> [14:22:00]__   
> [14:22:00]   /  _/ ___/ |/ /  _/_  __/ __/ 
> [14:22:00]  _/ // (7 7// /  / / / _/   
> [14:22:00] /___/\___/_/|_/___/ /_/ /___/  
> [14:22:00] 
> [14:22:00] ver. 1.5.0-b2#20151215-sha1:0c550aaa
> [14:22:00] 2015 Copyright(C) Apache Software Foundation
> [14:22:00] 
> [14:22:00] Ignite documentation: http://ignite.apache.org
> [14:22:00] 
> [14:22:00] Quiet mode.
> [14:22:00]   ^-- Logging to file 
> 'C:\Work\apache-ignite-fabric-1.5.0-b2-bin\work\log\ignite-0b6a932b.log'
> [14:22:00]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
> "-v" to ignite.{sh|bat}
> [14:22:00] 
> [14:22:00] OS: Windows 7 6.1 amd64
> [14:22:00] VM information: Java(TM) SE Runtime Environment 1.7.0_80-b15 
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 24.80-b11
> [14:22:00] Initial heap size is 254MB (should be no less than 512MB, use 
> -Xms512m -Xmx512m).
> [14:22:01] Configured plugins:
> [14:22:01]   ^-- None
> [14:22:01] 
> [14:22:02] Security status [authentication=off, tls/ssl=off]
> [14:22:03,911][ERROR][main][IgniteKernal] Got exception while starting (will 
> rollback startup routine).
> class org.apache.ignite.IgniteException: Failed to load bean in application 
> context [beanName=h2-example-db, 
> igniteConfig=org.springframework.context.support.ClassPathXmlApplicationContext@7a64f150:
>  startup date [Tue Dec 15 14:21:59 MSK 2015]; root of context hierarchy]
>   at 
> org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:168)
>   at 
> org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:96)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1243)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:774)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:945)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1659)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1518)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:974)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:534)
>   at org.apache.ignite.IgniteSpring.start(IgniteSpring.java:66)
>   at 
> org.apache.ignite.IgniteSpringBean.afterPropertiesSet(IgniteSpringBean.java:128)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1627)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1564)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:540)
>   at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302)
>   at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:229)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:298)
>   at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
>   at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:725)
>   

[jira] [Updated] (IGNITE-2256) Stopped cache with enabled metrics causes java.lang.IllegalArgumentException

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov updated IGNITE-2256:
--
Fix Version/s: (was: 1.8)
   2.0

> Stopped cache with enabled metrics causes java.lang.IllegalArgumentException
> 
>
> Key: IGNITE-2256
> URL: https://issues.apache.org/jira/browse/IGNITE-2256
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, UI
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
>
> Sometimes stop of a cache with enabled metrics causes 
> java.lang.IllegalArgumentException
> {noformat}
> [01:56:25,226][SEVERE][mgmt-#59%null%][GridJobWorker] Failed to execute job 
> due to unexpected runtime exception 
> [jobId=704ce01d151-07c43726-096b-4931-94b4-8e744c2330d3, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.v.cache.VisorCacheMetricsCollectorTask, dep=LocalDeployment 
> [super=GridDeployment [ts=1450911364031, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, 
> clsLdrId=fb37e01d151-07c43726-096b-4931-94b4-8e744c2330d3, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.v.cache.VisorCacheMetricsCollectorTask, 
> sesId=504ce01d151-23bcc212-8c7d-4aeb-b7ec-1959089e5376, 
> startTime=1450911385197, endTime=9223372036854775807, 
> taskNodeId=23bcc212-8c7d-4aeb-b7ec-1959089e5376, 
> clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=23bcc212-8c7d-4aeb-b7ec-1959089e5376, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1450911385217, 
> endTime=0, ignoreInterrupts=false, lsnr=null, state=INIT]]], 
> jobId=704ce01d151-07c43726-096b-4931-94b4-8e744c2330d3]]
> java.lang.IllegalArgumentException: Cache is not configured: 
> replicated_cache_for_clear_and_stop
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3135)
> at 
> org.apache.ignite.internal.visor.cache.VisorCacheMetrics.from(VisorCacheMetrics.java:178)
> at 
> org.apache.ignite.internal.visor.cache.VisorCacheMetricsCollectorTask$VisorCacheMetricsCollectorJob.run(VisorCacheMetricsCollectorTask.java:117)
> at 
> org.apache.ignite.internal.visor.cache.VisorCacheMetricsCollectorTask$VisorCacheMetricsCollectorJob.run(VisorCacheMetricsCollectorTask.java:78)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6397)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:503)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:456)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> {noformat}



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


[jira] [Resolved] (IGNITE-4107) Sporadic NPE for ServiceExample

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov resolved IGNITE-4107.
---
Resolution: Cannot Reproduce

> Sporadic NPE for ServiceExample 
> 
>
> Key: IGNITE-4107
> URL: https://issues.apache.org/jira/browse/IGNITE-4107
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
>
> Sometimes executing {{ServiceExample}} with 3 nodes throws NPE on a server 
> node:
> {noformat}
> [13:38:31,381][INFO][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=870f84bb-8952-4e25-9bcc-84d0b5b8e47b]
> [13:38:31,382][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=8de084c0-609c-4a93-b8de-284337210774]
> [13:38:31,420][INFO][sys-#26%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [13:38:31,422][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=e75c3ce9-e396-49ec-b729-00ee6f0e587d]
> [13:38:31,441][INFO][disco-event-worker-#20%null%][GridDiscoveryManager] Node 
> left topology: TcpDiscoveryNode [id=609ab107-9786-419d-95aa-a3da52305531, 
> addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 172.25.2.127, 
> 2001:0:9d38:6abd:c8d:2f03:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6abd:c8d:2f03:3c6f:269:0, /0:0:0:0:0:0:0:1:0, 
> /127.0.0.1:0, work-pc/172.25.2.127:0], discPort=0, order=4, intOrder=4, 
> lastExchangeTime=1477305509885, loc=false, ver=1.6.10#20161020-sha1:30cb02de, 
> isClient=true]
> [13:38:31,442][INFO][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=5, servers=3, clients=0, CPUs=8, heap=3.0GB]
> [13:38:31,469][INFO][sys-#27%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [13:38:31,471][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=4, minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=a4c5be10-f0d0-4c62-a870-c1e3af4669c9]
> [13:38:31,473][INFO][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
> [topVer=5, minorTopVer=0], evt=NODE_LEFT, 
> node=609ab107-9786-419d-95aa-a3da52305531]
> [13:38:31,495][INFO][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [13:38:31,496][SEVERE][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=5, 
> minorTopVer=1], nodeId=a4c5be10, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> [13:38:31,500][SEVERE][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
>  Failed to wait for completion of partition map exchange (preloading will not 
> start): GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false, 
> reassign=false, discoEvt=DiscoveryCustomEvent [customMsg=null, 
> affTopVer=AffinityTopologyVersion [topVer=5, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=a4c5be10-f0d0-4c62-a870-c1e3af4669c9, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.2.127, 2001:0:9d38:6abd:c8d:2f03:3c6f:269], 
> sockAddrs=[work-pc/172.25.2.127:47501, /127.0.0.1:47501, 
> /0:0:0:0:0:0:0:1:47501, /2001:0:9d38:6abd:c8d:2f03:3c6f:269:47501], 
> discPort=47501, order=2, intOrder=2, lastExchangeTime=1477305488276, 
> loc=false, ver=1.6.10#20161020-sha1:30cb02de, isClient=false], topVer=5, 
> nodeId8=8de084c0, msg=null, 

[jira] [Updated] (IGNITE-2084) Yardstick: benchmark-run-all.sh script should able to deploy and grab logs for distributed environment

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov updated IGNITE-2084:
--
Fix Version/s: (was: 1.8)
   2.0

> Yardstick: benchmark-run-all.sh script should able to deploy and grab logs 
> for distributed environment
> --
>
> Key: IGNITE-2084
> URL: https://issues.apache.org/jira/browse/IGNITE-2084
> Project: Ignite
>  Issue Type: Task
>Affects Versions: ignite-1.4, 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
> Fix For: 2.0
>
>
> One of important disadvantages for yardstick framework that it requires to be 
> copied on all hosts where server nodes will run and then server/gc logs can 
> be found on these hosts only .
> But the script bin/benchmark-run-all.sh takes the configuration file where 
> server hosts already defined (config/*.properties). Thus is it possible to 
> add a first step for deploying yardstick on server hosts and then grab logs 
> and copy into local yardstick directory.
> It will significantly reduce time to run benchmarks and get the results 
> faster.



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


[jira] [Resolved] (IGNITE-1883) Test path to swap files of a cache during cache creating

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov resolved IGNITE-1883.
---
Resolution: Cannot Reproduce

> Test path to swap files of a cache during cache creating
> 
>
> Key: IGNITE-1883
> URL: https://issues.apache.org/jira/browse/IGNITE-1883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
>Priority: Minor
> Fix For: 1.8
>
>
> Long name of cache (and long path to IGNITE home) may be a reason of 
> following failures if cache configured with swap:
> {noformat}
> Exception in thread "main" 
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
> (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1615)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1750)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1024)
>   at 
> org.apache.ignite.examples.datagrid.CachePutGetExample.putGet(CachePutGetExample.java:72)
>   at 
> org.apache.ignite.examples.datagrid.CachePutGetExample.main(CachePutGetExample.java:51)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.addFailedKeys(GridNearAtomicUpdateFuture.java:1186)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.onResult(GridNearAtomicUpdateFuture.java:657)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onResult(GridNearAtomicUpdateFuture.java:351)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:2458)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:123)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:253)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:251)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:540)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:273)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:197)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:76)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:159)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
>   Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys on primary node.
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:348)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1180)
>   at 
> 

[jira] [Closed] (IGNITE-1883) Test path to swap files of a cache during cache creating

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov closed IGNITE-1883.
-

> Test path to swap files of a cache during cache creating
> 
>
> Key: IGNITE-1883
> URL: https://issues.apache.org/jira/browse/IGNITE-1883
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
>Priority: Minor
> Fix For: 1.8
>
>
> Long name of cache (and long path to IGNITE home) may be a reason of 
> following failures if cache configured with swap:
> {noformat}
> Exception in thread "main" 
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
> (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1615)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1750)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1024)
>   at 
> org.apache.ignite.examples.datagrid.CachePutGetExample.putGet(CachePutGetExample.java:72)
>   at 
> org.apache.ignite.examples.datagrid.CachePutGetExample.main(CachePutGetExample.java:51)
>   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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [1]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.addFailedKeys(GridNearAtomicUpdateFuture.java:1186)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.onResult(GridNearAtomicUpdateFuture.java:657)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onResult(GridNearAtomicUpdateFuture.java:351)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:2458)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:123)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:253)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:251)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:540)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:273)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:197)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:76)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:159)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
>   Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys on primary node.
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:348)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1180)
>   at 
> 

[jira] [Updated] (IGNITE-2356) IGFS client should be able to failover in case of server crash.

2016-11-15 Thread Taras Ledkov (JIRA)

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

Taras Ledkov updated IGNITE-2356:
-
Fix Version/s: (was: 1.8)
   1.9

> IGFS client should be able to failover in case of server crash.
> ---
>
> Key: IGNITE-2356
> URL: https://issues.apache.org/jira/browse/IGNITE-2356
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.9
>
>
> IGFS client (IgniteHadoopFileSystem) communicates IGFS over endpoint - either 
> TCP or shmem.
> Only single endpoint can be specified. As such, should the server went down, 
> IgntieHadoopFileSystem (either new or existing) is no longer operational. 
> We need to let user specify several endpoints and failover/balance between 
> them.
> Look at Hadoop HA first to get an ideas on how to configure multiple 
> addresses.



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


[jira] [Updated] (IGNITE-1772) java.io.StreamCorruptedException with invalid type code

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov updated IGNITE-1772:
--
Fix Version/s: (was: 1.8)
   2.0

> java.io.StreamCorruptedException with invalid type code
> ---
>
> Key: IGNITE-1772
> URL: https://issues.apache.org/jira/browse/IGNITE-1772
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
> Environment: Windows, Oracle JDK 1.8_60
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
>Priority: Minor
> Fix For: 2.0
>
>
> 1. Open examples project in IDEA
> 2. Build/compile project
> 3. Run ExampeNodeStartup
> 4. Run CacheAsyncApiExample, ComputeTaskMapExample a few times in random 
> order until getting following exception:
> {noformat}
> [15:06:40,961][ERROR][tcp-disco-sock-reader-#10%null][TcpDiscoverySpi] Failed 
> to read message 
> [sock=Socket[addr=/0:0:0:0:0:0:0:1,port=50106,localport=47501], 
> locNodeId=1276ca1d-80f6-4481-9245-9aa28a916d68, 
> rmtNodeId=f9f29bed-e8d7-433a-baa7-62628077d781]
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object 
> with given class loader: sun.misc.Launcher$AppClassLoader@27716f4
>   at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:105)
>   at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.body(ServerImpl.java:4785)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.StreamCorruptedException: invalid type code: 69
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1379)
>   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
>   at java.util.ArrayDeque.readObject(ArrayDeque.java:888)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
>   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1900)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
>   at 
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
>   at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
>   at 
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
>   at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
>   at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
>   at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:102)
>   ... 2 more
> {noformat}



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


[jira] [Closed] (IGNITE-1742) Update notifier doesn't work

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov closed IGNITE-1742.
-

> Update notifier doesn't work
> 
>
> Key: IGNITE-1742
> URL: https://issues.apache.org/jira/browse/IGNITE-1742
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
>
> I've tested a couple internet connections over different ISPs and alays got 
> following:
> {noformat}
> [16:03:15,071][INFO][main][GridDiscoveryManager] Topology snapshot [ver=1, 
> servers=1, clients=0, CPU
> s=8, heap=1.0GB]
> [16:04:15,075][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f70d129a, name=null]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=8]
> ^-- CPU [cur=0%, avg=0.12%, GC=0%]
> ^-- Heap [used=63MB, free=93.58%, comm=982MB]
> ^-- Public thread pool [active=0, idle=16, qSize=0]
> ^-- System thread pool [active=0, idle=16, qSize=0]
> ^-- Outbound messages queue [size=0]
> [16:04:15,365][INFO][ignite-update-notifier-timer][GridUpdateNotifier] Update 
> status is not available.
> {noformat}



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


[jira] [Resolved] (IGNITE-1742) Update notifier doesn't work

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov resolved IGNITE-1742.
---
Resolution: Cannot Reproduce

> Update notifier doesn't work
> 
>
> Key: IGNITE-1742
> URL: https://issues.apache.org/jira/browse/IGNITE-1742
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
>
> I've tested a couple internet connections over different ISPs and alays got 
> following:
> {noformat}
> [16:03:15,071][INFO][main][GridDiscoveryManager] Topology snapshot [ver=1, 
> servers=1, clients=0, CPU
> s=8, heap=1.0GB]
> [16:04:15,075][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f70d129a, name=null]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=8]
> ^-- CPU [cur=0%, avg=0.12%, GC=0%]
> ^-- Heap [used=63MB, free=93.58%, comm=982MB]
> ^-- Public thread pool [active=0, idle=16, qSize=0]
> ^-- System thread pool [active=0, idle=16, qSize=0]
> ^-- Outbound messages queue [size=0]
> [16:04:15,365][INFO][ignite-update-notifier-timer][GridUpdateNotifier] Update 
> status is not available.
> {noformat}



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


[jira] [Resolved] (IGNITE-1579) Build examples failed from binary fabric package

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov resolved IGNITE-1579.
---
Resolution: Cannot Reproduce

> Build examples failed from binary fabric package
> 
>
> Key: IGNITE-1579
> URL: https://issues.apache.org/jira/browse/IGNITE-1579
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
>
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building ignite-examples 1.4.0
> [INFO] 
> 
> [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is 
> missing, no dependency information available
> [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is missing, 
> no dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.404 s
> [INFO] Finished at: 2015-09-30T09:06:08+03:00
> [INFO] Final Memory: 7M/245M
> {noformat}



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


[jira] [Updated] (IGNITE-3376) IGFS: Allow direct PROXY mode invocations.

2016-11-15 Thread Taras Ledkov (JIRA)

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

Taras Ledkov updated IGNITE-3376:
-
Fix Version/s: (was: 1.8)
   1.9

> IGFS: Allow direct PROXY mode invocations.
> --
>
> Key: IGNITE-3376
> URL: https://issues.apache.org/jira/browse/IGNITE-3376
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Critical
>  Labels: roadmap
> Fix For: 1.9
>
>
> Currently we do not have special handling for PROXY mode. So we will either 
> hit AssertionError during dev, or will go to incorrect code path in 
> productions systems.
> We need to fix that - PROXY mode should be handled correctly.



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


[jira] [Closed] (IGNITE-1579) Build examples failed from binary fabric package

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov closed IGNITE-1579.
-

> Build examples failed from binary fabric package
> 
>
> Key: IGNITE-1579
> URL: https://issues.apache.org/jira/browse/IGNITE-1579
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
>
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building ignite-examples 1.4.0
> [INFO] 
> 
> [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is 
> missing, no dependency information available
> [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is missing, 
> no dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.404 s
> [INFO] Finished at: 2015-09-30T09:06:08+03:00
> [INFO] Final Memory: 7M/245M
> {noformat}



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


[jira] [Updated] (IGNITE-4063) BinaryType.fieldNames() should return names in consistent order

2016-11-15 Thread Taras Ledkov (JIRA)

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

Taras Ledkov updated IGNITE-4063:
-
Fix Version/s: (was: 1.8)
   1.9

> BinaryType.fieldNames() should return names in consistent order
> ---
>
> Key: IGNITE-4063
> URL: https://issues.apache.org/jira/browse/IGNITE-4063
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 1.9
>
>
> In some cases it can be useful to get the field names from metadata in the 
> order fields were written when the metadata was created (i.e. object was 
> serialized for the first time). For example, this can be used to recreate the 
> object using builder preserving the consistent field ordering, so that 
> {{BinaryObject.equals()}} method works properly.
> Basically, we just need to replace {{HashMap}} with {{LinkedHashMap}} in the 
> {{BinaryType}} implementation.



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


[jira] [Updated] (IGNITE-4181) The several runs of ServicesExample causes NPE

2016-11-15 Thread Sergey Kozlov (JIRA)

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

Sergey Kozlov updated IGNITE-4181:
--
Fix Version/s: (was: 1.8)
   2.0

> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6, 1.7
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
> Fix For: 2.0
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache: 
> myNodeSingletonService
> [15:37:20,033][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [15:37:20,046][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Node left topology: TcpDiscoveryNode 
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, 
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, 
> intOrder=7, lastExchangeTime=1478522239236, loc=false, 
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [15:37:20,066][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> [15:37:20,142][ERROR][exchange-worker-#23%null%][GridCachePartitionExchangeManager]
> 

[jira] [Updated] (IGNITE-3961) IGFS: Support direct PROXY mode invocation in method: affinity

2016-11-15 Thread Taras Ledkov (JIRA)

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

Taras Ledkov updated IGNITE-3961:
-
Fix Version/s: (was: 1.8)
   1.9

> IGFS: Support direct PROXY mode invocation in method: affinity
> --
>
> Key: IGNITE-3961
> URL: https://issues.apache.org/jira/browse/IGNITE-3961
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.9
>
>
> See 
> {{org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.getFileBlockLocations}}
>  for reference.



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


[jira] [Commented] (IGNITE-4137) .NET: add example for Atomic Types

2016-11-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4137:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4137 .NET: Atomic examples added



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

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

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

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






> .NET: add example for Atomic Types
> --
>
> Key: IGNITE-4137
> URL: https://issues.apache.org/jira/browse/IGNITE-4137
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Fix For: 1.8
>
>
> Add the example that will showcase the usage of all Atomic Types that are 
> presently supported in .NET.



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


[jira] [Commented] (IGNITE-2523) Introduce "single put" NEAR update request.

2016-11-15 Thread Konstantin Dudkov (JIRA)

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

Konstantin Dudkov commented on IGNITE-2523:
---

Semen,

* I tried to get rid of using keys() method, now I revert this code back.
* We use it as a common interface for GridNearAtomic*UpdateRequest. It's not 
possible to use interface, because it must extend abstract class 
GridCacheMessage. Now I remove unused GridNearAtomicUpdateRequest interface and 
move all method signatures to abstract class to make code more clear.
* I'm trying to investigate this point, but that (and others) test runs locally 
pretty good - can it be a problem in TC?

> Introduce "single put" NEAR update request.
> ---
>
> Key: IGNITE-2523
> URL: https://issues.apache.org/jira/browse/IGNITE-2523
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
>  Labels: performance
> Fix For: 1.8
>
>
> Essentially, in this case we could get rid of all collections and garbage 
> inside GridNearAtomicUpdateRequest/GridDhtAtomicUpdateRequest.
> This should drastically decrease message size and improve performance.



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


[jira] [Updated] (IGNITE-1192) Provide integration with Spring Data

2016-11-15 Thread Eduard Shangareev (JIRA)

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

Eduard Shangareev updated IGNITE-1192:
--
Fix Version/s: (was: 1.8)
   2.0

> Provide integration with Spring Data
> 
>
> Key: IGNITE-1192
> URL: https://issues.apache.org/jira/browse/IGNITE-1192
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Eduard Shangareev
>Priority: Minor
>  Labels: Newbie
> Fix For: 2.0
>
>
> Spring Data docs:
> * http://docs.spring.io/spring-data/data-commons/docs/current/reference/html/
> * http://docs.spring.io/spring-data/data-commons/docs/current/api/



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


[jira] [Updated] (IGNITE-2731) Cache and cluster metrics documentation on readme.io

2016-11-15 Thread Sergej Sidorov (JIRA)

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

Sergej Sidorov updated IGNITE-2731:
---
Fix Version/s: (was: 1.8)
   1.9

> Cache and cluster metrics documentation on readme.io
> 
>
> Key: IGNITE-2731
> URL: https://issues.apache.org/jira/browse/IGNITE-2731
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Sergej Sidorov
> Fix For: 1.9
>
>
> Cache and cluster metrics related topic is becoming hot on the user list.
> 1) 
> http://apache-ignite-users.70518.x6.nabble.com/Monitoring-Cache-Data-counters-Cache-Data-Size-td3203.html#a3211
> 2) 
> http://apache-ignite-users.70518.x6.nabble.com/Is-there-a-way-to-get-cache-metrics-for-all-the-nodes-in-cluster-combined-td2674.html
> 3) 
> http://apache-ignite-users.70518.x6.nabble.com/Metrics-for-backup-caches-td2689.html#a2692
> The time to add the documentation to the readme.io has come.



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


[jira] [Commented] (IGNITE-4175) SQL: JdbcResultSet class wasNull() method should return true on NULL fields

2016-11-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4175:


Github user AMashenkov closed the pull request at:

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


> SQL: JdbcResultSet class wasNull() method should return true on NULL fields
> ---
>
> Key: IGNITE-4175
> URL: https://issues.apache.org/jira/browse/IGNITE-4175
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: newbie
> Fix For: 1.8
>
>
> For now wasNull() method can return false for NULL field in case of field 
> typed as String.
> Startpoints are org.apache.ignite.internal.jdbc.JdbcResultSet class
> and org.apache.ignite.internal.jdbc2.JdbcResultSet class



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


[jira] [Commented] (IGNITE-4175) SQL: JdbcResultSet class wasNull() method should return true on NULL fields

2016-11-15 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-4175:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4175: SQL: JdbcResultSet class wasNull() method should return true 
on NULL fields 



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

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

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

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


commit 9aea27a6d0f772b0b74d2e5779b3a0fbd45b85a2
Author: Andrey V. Mashenkov 
Date:   2016-11-03T19:10:41Z

Trivial fix.

JdbcResultSet.wasNull() method should return null on column NULL value.

commit 10b1b0abf9e83fc65b421dd91ef66889af8d3282
Author: Andrey V. Mashenkov 
Date:   2016-11-10T11:30:51Z

Minors




> SQL: JdbcResultSet class wasNull() method should return true on NULL fields
> ---
>
> Key: IGNITE-4175
> URL: https://issues.apache.org/jira/browse/IGNITE-4175
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: newbie
> Fix For: 1.8
>
>
> For now wasNull() method can return false for NULL field in case of field 
> typed as String.
> Startpoints are org.apache.ignite.internal.jdbc.JdbcResultSet class
> and org.apache.ignite.internal.jdbc2.JdbcResultSet class



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


[jira] [Commented] (IGNITE-4198) Ignite Kafka sink connector should have an option to transform Kafka values

2016-11-15 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-4198:
-

Hi Roman,

My last comment is that we'd better to align property name with variable name: 
instead of {{entryTransformerCls}} I would name it {{singleTupleExtractorCls}}. 
The rest looks good to me. As per extractor interface I do not know the context 
well. Personally I'd prefer to have separate interfaces. Because otherwise it 
is not clear which method to invoke - {{single}} or {{multiple}}? So to support 
two methods in the same interface we probably will have to add even more 
methods, like {{isSingle}}. But again, I do not know Kafka good enough to judge 
on the matter, this is just my thoughts. May be I am missing something.

Vladimir.

> Ignite Kafka sink connector should have an option to transform Kafka values
> ---
>
> Key: IGNITE-4198
> URL: https://issues.apache.org/jira/browse/IGNITE-4198
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>  Labels: community, streaming
> Fix For: 1.8
>
>
> Currently the connector takes a Kafka key and uses it as an Ignite key. 
> However, Kafka keys can be null, and users may want to specify an Ignite key 
> from the value object.
> Instead of creating a new transformer interface, I think we can use 
> {{StreamMultipleTupleExtractor}} whenever its implementation is specified by 
> the user in connector config file.
> http://apache-ignite-users.70518.x6.nabble.com/Kafka-Failed-to-stream-a-record-with-null-key-td8731.html



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


[jira] [Updated] (IGNITE-3748) Data rebalancing of large cache can hang out.

2016-11-15 Thread Anton Vinogradov (JIRA)

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

Anton Vinogradov updated IGNITE-3748:
-
Fix Version/s: 1.8

> Data rebalancing of large cache can hang out.
> -
>
> Key: IGNITE-3748
> URL: https://issues.apache.org/jira/browse/IGNITE-3748
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Anton Vinogradov
> Fix For: 1.8
>
> Attachments: Apache.config.xml, default-config.xml, logs.zip, 
> thread_dump.zip
>
>
> After the node (_CO3SCH050520537_) disconnect from cluster and starts again, 
> rebalacing partitions of cache works, until node will faill by timeout.
> In the log of node which joining:
> {noformat}
> [2016.08.17 03:28:52,754 PDT][INFO 
> ][sys-#122%null%][GridDhtPartitionDemander]  Completed 
> (final) rebalancing [cache=cache_raw_gbievent, 
> fromNode=14666739-08e3-4188-ace7-9e47940bed70, 
> topology=AffinityTopologyVersion [topVer=205, minorTopVer=0], time=336336 ms]
> {noformat}
> In other server nodes:
> {noformat}
> [2016.08.17 03:29:04,413 PDT][WARN 
> ][exchange-worker-#176%null%][GridDhtPartitionsExchangeFuture] Failed to wait 
> for partition release future [topVer=AffinityTopologyVersion [topVer=205, 
> minorTopVer=1], node=14666739-08e3-4188-ace7-9e47940bed70].
> {noformat}
> See [the thread for details | 
> http://apache-ignite-users.70518.x6.nabble.com/Failed-to-wait-for-initial-partition-map-exchange-tt6252.html#a7171]



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


[jira] [Commented] (IGNITE-4225) DataStreamer can hang on changing topology

2016-11-15 Thread Anton Vinogradov (JIRA)

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

Anton Vinogradov commented on IGNITE-4225:
--

Fixed by replacing 

{noformat}
AffinityTopologyVersion topVer = cctx.isLocal() ?
cctx.affinity().affinityTopologyVersion() :
cctx.topology().topologyVersion();
{noformat}

with 
{noformat}
AffinityTopologyVersion topVer = cctx.isLocal() ?
cctx.affinity().affinityTopologyVersion() :
cctx.shared().exchange().readyAffinityVersion();
{noformat}

To be checked at TeamCity

> DataStreamer can hang on changing topology
> --
>
> Key: IGNITE-4225
> URL: https://issues.apache.org/jira/browse/IGNITE-4225
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.8
>
>
> Hang reason:
> Exchange cannot happen because some datastreamer futures not finished 
> {noformat}
> Pending data streamer futures:
> [12:17:28,427][WARN 
> ][exchange-worker-#106%distributed.CacheLoadingConcurrentGridStartSelfTest2%][GridCachePartitionExchangeManager]
>  >>> DataStreamerFuture [topVer=AffinityTopologyVersion [topVer=5, 
> minorTopVer=0], super=GridFutureAdapter [resFlag=0, res=null, 
> startTime=1479201428401, endTime=0, ignoreInterrupts=false, state=INIT]]
> {noformat}
> Reason of notfinished futures:
> {noformat}
> - parking to wait for  <0x000792e050b0> (a 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:160)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:538)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:449)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:402)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodes(GridCacheAffinityManager.java:259)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:295)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:286)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:310)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:1948)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:370)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1080)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:708)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:101)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:671)
>   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)
> {noformat}
> Possible solution:
> Need to use topology instead of affinity to detect is node primary
> {noformat}
> boolean primary = 

[jira] [Created] (IGNITE-4227) ODBC: Implement SQLError function

2016-11-15 Thread Igor Sapego (JIRA)
Igor Sapego created IGNITE-4227:
---

 Summary: ODBC: Implement SQLError function
 Key: IGNITE-4227
 URL: https://issues.apache.org/jira/browse/IGNITE-4227
 Project: Ignite
  Issue Type: Task
  Components: odbc
Affects Versions: 1.7
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.8


Some driver managers use this function even though {{SQLGetDiagRec}} was called.



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


  1   2   >