[jira] [Created] (IGNITE-3276) Develop Cloudera Service Descriptor for PnP integration with Cloudera Manager.

2016-06-08 Thread Nikita Ivanov (JIRA) 
Nikita Ivanov created IGNITE-3276:
-

 Summary: Develop Cloudera Service Descriptor for PnP integration 
with Cloudera Manager.
 Key: IGNITE-3276
 URL: https://issues.apache.org/jira/browse/IGNITE-3276
 Project: Ignite
  Issue Type: New Feature
  Components: hadoop
Affects Versions: 1.6
Reporter: Nikita Ivanov


Several people expressed an idea of PnP integration with Cloudera via CSR: 
https://blog.cloudera.com/blog/2014/04/how-to-extend-cloudera-manager-with-custom-service-descriptors/

Sounds like a great feature when running within Cloudera YARN.



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

[jira] [Commented] (IGNITE-3238) Javadoc Warning due to cassandra libs usage

2016-06-08 Thread Igor Rudyak (JIRA) 

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

Igor Rudyak commented on IGNITE-3238:
-

That's ok. This branch also includes bugfixes to AWS bootstrap scripts which 
were not included into 1.6 release

> Javadoc Warning due to cassandra libs usage
> ---
>
> Key: IGNITE-3238
> URL: https://issues.apache.org/jira/browse/IGNITE-3238
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Anton Vinogradov
>Assignee: Igor Rudyak
>Priority: Critical
> Fix For: 1.7
>
>
> I found following at Ignite 1.6 build log:
> {code} [WARNING] Javadoc Warnings
>  [WARNING] warning: 
> /home/teamcity/.m2/repository/org/apache/cassandra/cassandra-all/3.3/cassandra-all-3.3.jar(org/apache/cassandra/service/CassandraDaemon.class):
>  major version 52 is newer than 51, the highest major version supported by 
> this compiler.
>  [WARNING] It is recommended that the compiler be upgraded.{code} 
> seems this warning related to 
> https://issues.apache.org/jira/browse/IGNITE-1371. 
> Command to gain this is:
> {code} mvn clean package -DskipTests{code} 
> also you can use this TeamCity task: 
> http://149.202.210.143:8111/viewType.html?buildTypeId=IgniteTests_RatJavadoc
> Need to fix it without using JDK 8.



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

[jira] [Comment Edited] (IGNITE-3275) .NET: Enable REST HTTP in .NET nodes

2016-06-08 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn edited comment on IGNITE-3275 at 6/8/16 7:21 PM:


I imagine that main use case is connecting to a node from a pure .NET code via 
HTTP.
If we publish REST jars in a separate NuGet package, there is no space concern.

However, I did not know that REST API in Java is nearly deprecated, where does 
it say that? visorcmd uses REST, as I understand 
(http://apache-ignite-users.70518.x6.nabble.com/Is-it-possible-to-disable-TcpRestProtocol-td5461.html).


was (Author: ptupitsyn):
I imagine that main use case is connecting to a node from a pure .NET code via 
HTTP.
If we publish REST jars in a separate NuGet package, there is no space concern.

However, I did not know that REST API in Java is nearly deprecated, where does 
it say that?

> .NET: Enable REST HTTP in .NET nodes
> 
>
> Key: IGNITE-3275
> URL: https://issues.apache.org/jira/browse/IGNITE-3275
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
> Fix For: 1.7
>
>
> * Include REST HTTP jars in NuGet (either in core, or in a separate package). 
> Keep in mind NuGet size limitation
> * Add required options to IgniteConfiguration to enable/disable REST



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

[jira] [Commented] (IGNITE-3275) .NET: Enable REST HTTP in .NET nodes

2016-06-08 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn commented on IGNITE-3275:


I imagine that main use case is connecting to a node from a pure .NET code via 
HTTP.
If we publish REST jars in a separate NuGet package, there is no space concern.

However, I did not know that REST API in Java is nearly deprecated, where does 
it say that?

> .NET: Enable REST HTTP in .NET nodes
> 
>
> Key: IGNITE-3275
> URL: https://issues.apache.org/jira/browse/IGNITE-3275
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
> Fix For: 1.7
>
>
> * Include REST HTTP jars in NuGet (either in core, or in a separate package). 
> Keep in mind NuGet size limitation
> * Add required options to IgniteConfiguration to enable/disable REST



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

[jira] [Commented] (IGNITE-3275) .NET: Enable REST HTTP in .NET nodes

2016-06-08 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov commented on IGNITE-3275:
-

I hardly can imagine why .NET users may want it. REST API is in either 
deprecated or _nearly_ deprecated state in Java. I do not remember a single 
user who needed it. 
Provided that we are limited in space in NuGet packages, I would rather keep 
free space for something more useful.

> .NET: Enable REST HTTP in .NET nodes
> 
>
> Key: IGNITE-3275
> URL: https://issues.apache.org/jira/browse/IGNITE-3275
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
> Fix For: 1.7
>
>
> * Include REST HTTP jars in NuGet (either in core, or in a separate package). 
> Keep in mind NuGet size limitation
> * Add required options to IgniteConfiguration to enable/disable REST



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

[jira] [Commented] (IGNITE-2680) Terminating running SQL queries

2016-06-08 Thread Alexei Scherbakov (JIRA) 

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

Alexei Scherbakov commented on IGNITE-2680:
---

Working on the test with the failing initiator node.

> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
>  Labels: important
>
> If to start a long running SQL query over a huge cache will millions of 
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed 
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related 
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;



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

[jira] [Commented] (IGNITE-3152) Client node's addresses are registered in IP finder

2016-06-08 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov commented on IGNITE-3152:
--

node.isClient() checks that clientRouterNodeId != null
Which should means this client node not in forceServerMode, correct?

So, !node.isClient() will exclude only client nodes at clietn mode.

> Client node's addresses are registered in IP finder
> ---
>
> Key: IGNITE-3152
> URL: https://issues.apache.org/jira/browse/IGNITE-3152
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>  Labels: important
> Fix For: 1.7
>
> Attachments: Test.java
>
>
> Currently client node register its addresses in IP finder and never 
> deregisters them. Also looks like coordinator address is also not removed.
> The simple test that shows this behavior is attached.



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

[jira] [Comment Edited] (IGNITE-1629) .Net: Introduce native logging facility.

2016-06-08 Thread Pavel Tupitsyn (JIRA) 

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

Pavel Tupitsyn edited comment on IGNITE-1629 at 6/8/16 4:06 PM:


Considerations:
* We need a single common point of logging in .NET and Java, so that events 
from both platforms are visible in .NET.
* Implement IgnitePlatformLogger which delegates to .NET
* Do not depend on any library in Core. Provide an ILogger facade similar to 
IgniteLogger in Java
* Provide a default ConsoleLogger in .NET. using native .NET console will fix 
the issue with log not being shown in R# test runner, LINQPad output and other 
places.
* Provide optional integrations with NLog and Log4Net (separate tickets)
* Include ignite-log4j in NuGet package so that native logging can be 
configured via config/ignite-log4j.xml file (see IgnitionEx logic). What is 
ignite-log4j2?


was (Author: ptupitsyn):
Considerations:
* We need a single common point of logging in .NET and Java, so that events 
from both platforms are visible on both platforms
* Implement IgnitePlatformLogger which delegates to .NET
* Do not depend on any library in Core. Provide an ILogger facade similar to 
IgniteLogger in Java
* Provide optional integrations with NLog and Log4Net (separate tickets)
* Include ignite-log4j in NuGet package so that native logging can be 
configured via config/ignite-log4j.xml file (see IgnitionEx logic). What is 
ignite-log4j2?

> .Net: Introduce native logging facility.
> 
>
> Key: IGNITE-1629
> URL: https://issues.apache.org/jira/browse/IGNITE-1629
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
>
> This is pretty serious usability issue. Currently Ignite produces logs using 
> Java "log4j" library. While naural for Java environment, this is somewhat 
> alien for Windows users. 
> We need to investigate ability to hack into normal .Net logging frameworks. 
> This include both native Windows APIs (e.g. events), and widely-used .Net 
> loggers.



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

[jira] [Commented] (IGNITE-1629) .Net: Introduce native logging facility.

2016-06-08 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IGNITE-1629:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1629 .Net: Introduce native logging facility.



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

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

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

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


commit 649203a12a6e92732381aa726e091befb9a3ad79
Author: Pavel Tupitsyn 
Date:   2016-06-07T14:47:33Z

IGNITE-1629 .Net: Introduce native logging facility.

commit a882f23a6d292eb4881642e10d02358752a0fcdc
Author: Pavel Tupitsyn 
Date:   2016-06-07T15:20:31Z

wip

commit 0d1545cfe30c9227e2a445b0453481fedab59f11
Author: Pavel Tupitsyn 
Date:   2016-06-07T16:07:44Z

wip

commit 68448e5c0c23e040fe5a751d3946aaf83e73e055
Author: Pavel Tupitsyn 
Date:   2016-06-07T16:15:28Z

wip C#

commit 99c3be4f38e2b9f9010dc2ff3dd22aeeefc51b9a
Author: Pavel Tupitsyn 
Date:   2016-06-07T16:29:24Z

wip

commit 246779d721816299c8ced48cb34b25d4593905ad
Author: Pavel Tupitsyn 
Date:   2016-06-07T16:34:37Z

wip

commit 20d37ca0c91030539dc9083d299b507d854d84c0
Author: Pavel Tupitsyn 
Date:   2016-06-07T16:55:40Z

wip

commit 54f6b8b313cd4b0cc6296194aed437a513b0be99
Author: Pavel Tupitsyn 
Date:   2016-06-08T09:53:47Z

wip

commit 6470b49c361c2c0d35bf1b5566971154442c0e7a
Author: Pavel Tupitsyn 
Date:   2016-06-08T09:57:03Z

wip

commit 81a83121f19701a32506e75fb8a790a7315173f2
Author: Pavel Tupitsyn 
Date:   2016-06-08T10:05:53Z

wip

commit 7aac8f6376a9914447b00db9fda14bc3d4c3ea2f
Author: Pavel Tupitsyn 
Date:   2016-06-08T10:41:34Z

wip

commit cc5d487ae81646e5afddf10e622b1864568fab79
Author: Pavel Tupitsyn 
Date:   2016-06-08T11:00:11Z

wip

commit 7445d83c266ea29e1441ffc34f98e4266980dfa2
Author: Pavel Tupitsyn 
Date:   2016-06-08T11:46:44Z

wip

commit f508bf55008296bfe7d3b204b3f4e3274d0a6eea
Author: Pavel Tupitsyn 
Date:   2016-06-08T11:49:27Z

wip

commit 1cddb1a4ef65852d49930990652c5484679577e7
Author: Pavel Tupitsyn 
Date:   2016-06-08T11:53:59Z

wip

commit 13d73e281ff92aba9e46de6b96f18d824070a197
Author: Pavel Tupitsyn 
Date:   2016-06-08T11:56:26Z

wip

commit dba27541301016ccbf6445b3813217cbde3ef64c
Author: Pavel Tupitsyn 
Date:   2016-06-08T11:57:46Z

wip

commit b5761a5578c703c60f2066b8d5459ec83dda91cd
Author: Pavel Tupitsyn 
Date:   2016-06-08T12:19:05Z

ConsoleLogger implemented

commit bbda4ef50b1696670f26373dca9b40818d6e0ad8
Author: Pavel Tupitsyn 
Date:   2016-06-08T12:24:41Z

wip

commit 2d56c88ee4389dee9728ef2b8afa1bd9ee9750c6
Author: Pavel Tupitsyn 
Date:   2016-06-08T12:28:51Z

wip

commit 1ee78904004909b080648a5a979d3dae4b080511
Author: Pavel Tupitsyn 
Date:   2016-06-08T12:33:48Z

wip

commit e04b3564e200dff9176b43fb765143faa1fa2ae8
Author: Pavel Tupitsyn 
Date:   2016-06-08T12:34:33Z

wip

commit 789560702f56c0e121d2ab7751d5600f34a49109
Author: Pavel Tupitsyn 
Date:   2016-06-08T12:52:22Z

wip

commit 3ec2688ec609c6be06cdbc77cdc58a623da1600f
Author: Pavel Tupitsyn 
Date:   2016-06-08T13:21:58Z

wip callbacks

commit 8ac78e202f07d466dada70274a8c968c7cea0ae7
Author: Pavel Tupitsyn 
Date:   2016-06-08T13:23:46Z

wip callbacks

commit 1345aa93542c01dec123e2faaa520ec82e153089
Author: Pavel Tupitsyn 
Date:   2016-06-08T13:36:52Z

Java callbacks done

commit 50323054e129985f697d1661fec3e701459895ab
Author: Pavel Tupitsyn 
Date:   2016-06-08T14:07:10Z

wip

commit ec21d607ffa78a1c958f2593a0c77e22911950d7
Author: Pavel Tupitsyn 
Date:   2016-06-08T14:07:53Z

Callback in Java done

commit 713dd4c2f25d075754dd268b53c9f33125c44c45
Author: Pavel Tupitsyn 
Date:   2016-06-08T14:15:23Z

Fix jbool result

commit 2022532ee36e6fe88d2aa642369b9674fe7f99d9
Author: Pavel Tupitsyn 
Date:   2016-06-08T14:19:28Z

fix

[jira] [Commented] (IGNITE-114) Value is not loaded from store for invoke in transactional cache

2016-06-08 Thread Semen Boikov (JIRA) 

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

Semen Boikov commented on IGNITE-114:
-

In TRANSACTIONAL cache backups can not read value for invoke from store during 
commit (since they can read already updated value). Instead I added read from 
store when backups receive 'prepare' message from primary, at this moment lock 
is already held, so nobody should change value this read is safe.

> Value is not loaded from store for invoke in transactional cache
> 
>
> Key: IGNITE-114
> URL: https://issues.apache.org/jira/browse/IGNITE-114
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-1
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>  Labels: Muted_test
> Fix For: 1.7
>
>
> Added test IgniteCacheInvokeReadThroughTest. Value is not in cache but exists 
> in store, when invoke EntryProcessor is executed on backup it gets null value 
> instead of value loaded from store.



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

[jira] [Commented] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder

2016-06-08 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov commented on IGNITE-3216:
--

I replaced usage of F.viewSetReadOnly(...) by 
Collections.unmodifiableCollection(...)
Will check TeamCity.

> Need to deduplicate addresses registered in the IP finder
> -
>
> Key: IGNITE-3216
> URL: https://issues.apache.org/jira/browse/IGNITE-3216
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> {{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with 
> duplicated addresses in some cases (e.g., if one of hostnames is provided as 
> an IP). We should deduplicate the list before returning it (most likely we 
> should simply use {{Set}} instead).



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

[jira] [Commented] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections

2016-06-08 Thread Valentin Kulichenko (JIRA) 

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

Valentin Kulichenko commented on IGNITE-3153:
-

Anton,

I was under impression that {{onSpiContextDestroyed}} can be called on client 
disconnect. If this is not true, I think you're right. But the usage of 
{{initGuard}} should be revisited in any case.

> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP 
> finder is used. Most likely this is caused by the fact that {{initGuard}} is 
> flipped back to {{false}} when the context is destroyed and new curator 
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
> {noformat}
> 2016-05-16 12:00:59,096 5786  ERROR 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught 
> during grid runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-reconnector-#5%Default%] 
> java.lang.IllegalStateException: Cannot be started more than once
> at 
> org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
> ...
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}



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

[jira] [Commented] (IGNITE-3226) Load test: iteration over cache partitions using scan queries and performing transactions

2016-06-08 Thread Ksenia Rybakova (JIRA) 

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

Ksenia Rybakova commented on IGNITE-3226:
-

One more useful thing whould be logging percentage of preloading done. For 
instance: "Preloading: 200 of 1000 entries loaded" or "Preloading... 20%" or 
something like that.

> Load test: iteration over cache partitions using scan queries and performing 
> transactions
> -
>
> Key: IGNITE-3226
> URL: https://issues.apache.org/jira/browse/IGNITE-3226
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Vladislav Pyatkov
> Fix For: 1.7
>
>
> The following load test has to be added:
> - two caches are created (Persons and Deposit). Deposits are collocated by 
> Person;
> - Persons and Deposits are constructed with {{BinaryObjectBuilder}} and in 
> fact there won't be real classes for these data models;
> - data is preloaded with data streamers into the server nodes;
> - compute jobs are sent to the nodes that hold a particular partition;
> - the logic of the job iterates over a partition of Persons cache using 
> ScanQuery (local);
> - for every returned Person we should execute a local SQL query getting all 
> Person's deposits;
> - for every returned deposits we have to perform a pessimistic 
> repeatable-read transaction that will increase a deposit amount on some value.
> As an example you can refer to 
> https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/datagrid/query/ScanQueryExample.java



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

[jira] [Commented] (IGNITE-3152) Client node's addresses are registered in IP finder

2016-06-08 Thread Valentin Kulichenko (JIRA) 

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

Valentin Kulichenko commented on IGNITE-3152:
-

Anton,

Client node can work in forced server mode. I think we should register 
addresses in this case.

See {{TcpDiscoveryIpFinderAdapter.discoveryClientMode()}} and its usages on how 
this can be properly checked.

> Client node's addresses are registered in IP finder
> ---
>
> Key: IGNITE-3152
> URL: https://issues.apache.org/jira/browse/IGNITE-3152
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>  Labels: important
> Fix For: 1.7
>
> Attachments: Test.java
>
>
> Currently client node register its addresses in IP finder and never 
> deregisters them. Also looks like coordinator address is also not removed.
> The simple test that shows this behavior is attached.



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

[jira] [Commented] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder

2016-06-08 Thread Valentin Kulichenko (JIRA) 

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

Valentin Kulichenko commented on IGNITE-3216:
-

Anton,

Why do we need the {{F.viewSetReadOnly}} call there? Can we avoid it? I would 
prefer to remove usages of {{F.}} where possible.

> Need to deduplicate addresses registered in the IP finder
> -
>
> Key: IGNITE-3216
> URL: https://issues.apache.org/jira/browse/IGNITE-3216
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> {{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with 
> duplicated addresses in some cases (e.g., if one of hostnames is provided as 
> an IP). We should deduplicate the list before returning it (most likely we 
> should simply use {{Set}} instead).



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

[jira] [Created] (IGNITE-3275) .NET: Enable REST HTTP in .NET nodes

2016-06-08 Thread Pavel Tupitsyn (JIRA) 
Pavel Tupitsyn created IGNITE-3275:
--

 Summary: .NET: Enable REST HTTP in .NET nodes
 Key: IGNITE-3275
 URL: https://issues.apache.org/jira/browse/IGNITE-3275
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
 Fix For: 1.7


* Include REST HTTP jars in NuGet (either in core, or in a separate package). 
Keep in mind NuGet size limitation
* Add required options to IgniteConfiguration to enable/disable REST



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

[jira] [Commented] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections

2016-06-08 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov commented on IGNITE-3153:
--

I wonder how can happen context destroy and then reconnect, except race at node 
stop.
Seems that correct solution is to remove 
if (!initGuard.compareAndSet(true, false))
return;
at onSpiContextDestroyed
This will fix problem, I think.

> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP 
> finder is used. Most likely this is caused by the fact that {{initGuard}} is 
> flipped back to {{false}} when the context is destroyed and new curator 
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
> {noformat}
> 2016-05-16 12:00:59,096 5786  ERROR 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught 
> during grid runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-reconnector-#5%Default%] 
> java.lang.IllegalStateException: Cannot be started more than once
> at 
> org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
> ...
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}



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

[jira] [Comment Edited] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections

2016-06-08 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov edited comment on IGNITE-3153 at 6/8/16 1:21 PM:
--

I wonder how can happen context destroy and then reconnect, except race at node 
stop.
Seems that correct solution is to remove 
if (!initGuard.compareAndSet(true, false))
return;
at onSpiContextDestroyed
This will fix the problem, I think.


was (Author: avinogradov):
I wonder how can happen context destroy and then reconnect, except race at node 
stop.
Seems that correct solution is to remove 
if (!initGuard.compareAndSet(true, false))
return;
at onSpiContextDestroyed
This will fix problem, I think.

> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP 
> finder is used. Most likely this is caused by the fact that {{initGuard}} is 
> flipped back to {{false}} when the context is destroyed and new curator 
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
> {noformat}
> 2016-05-16 12:00:59,096 5786  ERROR 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught 
> during grid runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-reconnector-#5%Default%] 
> java.lang.IllegalStateException: Cannot be started more than once
> at 
> org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
> ...
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}



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

[jira] [Comment Edited] (IGNITE-2969) Optimistic transactions support in deadlock detection

2016-06-08 Thread Andrey Gura (JIRA) 

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

Andrey Gura edited comment on IGNITE-2969 at 6/8/16 1:08 PM:
-

Rerun benchmarks more accurate. Results below:

{noformat}
 With detection   
Without detection

tx-put-1-backup   19,608.72   19,854.48
tx-put-offheap-1-backup   18,480.55   17,938.68
tx-put-offheap-val-1-backup   20,423.42   19,936.32
tx-put-get-1-backup   18,250.85   18,526.29
tx-put-get-offheap16,033.24   16,433.10
tx-put-get-offheap-val-1-backup   18,069.81   18,502.69
{noformat}

So I can conclude that additional synchronization doesn't affect performance.


was (Author: agura):
Rerun benchmarks more accurate. Results below:

{noformat}
 With detection   
Without detection

tx-put-1-backup   19,608.72   19,854.48
tx-put-offheap-1-backup   18,480.55   17,938.68
tx-put-offheap-val-1-backup   20,423.42   19,936.32
tx-put-get-1-backup   18,250.85  18,526.29
tx-put-get-offheap16,033.24  16,433.10
tx-put-get-offheap-val-1-backup   18,069.81  18,502.69
{noformat}

So I can conclude that additional synchronization doesn't affect performance.

> Optimistic transactions support in deadlock detection
> -
>
> Key: IGNITE-2969
> URL: https://issues.apache.org/jira/browse/IGNITE-2969
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support optimistic transactions now. It should be 
> implemented.



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

[jira] [Commented] (IGNITE-2969) Optimistic transactions support in deadlock detection

2016-06-08 Thread Andrey Gura (JIRA) 

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

Andrey Gura commented on IGNITE-2969:
-

In {{GridNearOptimisticTxPrepareFuture}} some code blocks are synchronized now. 
Цe just wanted to make sure that there is no any contention on thi synchronized 
blocks that can affect performance.

> Optimistic transactions support in deadlock detection
> -
>
> Key: IGNITE-2969
> URL: https://issues.apache.org/jira/browse/IGNITE-2969
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support optimistic transactions now. It should be 
> implemented.



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

[jira] [Comment Edited] (IGNITE-2969) Optimistic transactions support in deadlock detection

2016-06-08 Thread Andrey Gura (JIRA) 

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

Andrey Gura edited comment on IGNITE-2969 at 6/8/16 1:08 PM:
-

Rerun benchmarks more accurate. Results below:

{noformat}
 With detection   
Without detection

tx-put-1-backup   19,608.72   19,854.48
tx-put-offheap-1-backup   18,480.55   17,938.68
tx-put-offheap-val-1-backup   20,423.42   19,936.32
tx-put-get-1-backup   18,250.85  18,526.29
tx-put-get-offheap16,033.24  16,433.10
tx-put-get-offheap-val-1-backup   18,069.81  18,502.69
{noformat}

So I can conclude that additional synchronization doesn't affect performance.


was (Author: agura):
Rerun benchmarks more accurate. Results below:

{noformat}
 With detection   
Without detection

tx-put-1-backup   19,608.72   19,854.48
tx-put-offheap-1-backup  18,480.55   17,938.68
tx-put-offheap-val-1-backup20,423.42   19,936.32
tx-put-get-1-backup 18,250.85  18,526.29
tx-put-get-offheap16,033.24  16,433.10
tx-put-get-offheap-val-1-backup  18,069.81  18,502.69
{noformat}

So I can conclude that additional synchronization doesn't affect performance.

> Optimistic transactions support in deadlock detection
> -
>
> Key: IGNITE-2969
> URL: https://issues.apache.org/jira/browse/IGNITE-2969
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support optimistic transactions now. It should be 
> implemented.



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

[jira] [Assigned] (IGNITE-3261) AffinityKey is not stored in the metadata cache

2016-06-08 Thread Semen Boikov (JIRA) 

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

Semen Boikov reassigned IGNITE-3261:


Assignee: Semen Boikov

> AffinityKey is not stored in the metadata cache
> ---
>
> Key: IGNITE-3261
> URL: https://issues.apache.org/jira/browse/IGNITE-3261
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Critical
>  Labels: community, important
> Fix For: 1.7
>
> Attachments: Ignite-MarshallBenchmark.zip
>
>
> Presently we don't register predefined and system classes in metadata cache 
> which can lead to significant performance drops when these types used as keys.
> As an example we have {{AffinityKey}} class. It's not registered in the 
> metadata cache and as a result client nodes don't update their 
> {{CacheObjectBinaryProcessorImpl.clientMetaDataCache}}. After that when a 
> client node needs to get {{AffinityKey}} metadata using 
> {{CacheObjectBinaryProcessorImpl.metadata(typeId)}} it will always call 
> metadata cache and this is a bottleneck. The drop can be significant because 
> this method is called from methods like 
> {{GridAffinityProcessor.mapKeyToPrimaryAndBackups}}.
> In attach you can find a simple benchmark that shows how slower a result if 
> AffinityKey is used.
> As a solution we can register {{AffinityKey}} and other system and predefined 
> classes (?) in the metadata cache.



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

[jira] [Commented] (IGNITE-3221) Bad ip used , when fixed ip in hostname

2016-06-08 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IGNITE-3221:


GitHub user sebadiaz opened a pull request:

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

[IGNITE-3221] Bad ip used , when fixed ip in hostname

The target is to set the ip written in a string format instead to call the 
DNS to resolve it. 

DNS could not be well working in some case and the IP is the more clear 
connection that we can make

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

$ git pull https://github.com/sebadiaz/ignite master

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

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


commit 266a2dd9725eaa5251a6fce876745ee4080b3dfb
Author: Sebastien Diaz 
Date:   2016-06-08T11:36:47Z

IGNITE-3221 check IP and convert it

commit 26443bf41e4a8acb031054c5c295be22b6921102
Author: Sebastien Diaz 
Date:   2016-06-08T11:37:50Z

IGNITE-3221 check IP and convert it

commit f3bdc95f8a507d26e6b7ca598a609f77f9609fba
Author: Sebastien Diaz 
Date:   2016-06-08T11:39:51Z

IGNITE-3221 check IP and convert it

commit 0d1091e9ad7b8cee9f1078171a6e8362d8731f1f
Author: Sebastien Diaz 
Date:   2016-06-08T11:42:49Z

IGNITE-3221 check IP and convert it

commit 9f357d020e64b7374d47593bc35dc57d685f87f1
Author: Sebastien Diaz 
Date:   2016-06-08T11:43:54Z

IGNITE-3221 check IP and convert it




> Bad ip used , when fixed ip in hostname
> ---
>
> Key: IGNITE-3221
> URL: https://issues.apache.org/jira/browse/IGNITE-3221
> Project: Ignite
>  Issue Type: Bug
>Reporter: sebastien diaz
>Assignee: Denis Magda
>  Labels: community
>
> Hello
> My machine have certainly a bad dns resolve issue (docker+swarm,network and 
> compose)  but I fix the ip directly at the place of the hostname.
> Unfortunately TcpDiscoveryNode mark a different socker ip
> Example host=40.1.0.23 -> socketAddress=104.239.213.7 :
> TcpDiscoveryNode [id=54b73d98-e702-4660-957a-61d065003078, addrs=[40.1.0.23], 
> sockAddrs=[44de9a1e9afe/104.239.213.7:47500, /40.1.0.23:47500]
> The code apparently in casuse should be :
> public static InetAddress resolveLocalHost(@Nullable String hostName) throws 
> IOException {
> return F.isEmpty(hostName) ?
> // Should default to InetAddress#anyLocalAddress which is 
> package-private.
> new InetSocketAddress(0).getAddress() :
> InetAddress.getByName(hostName);
> }
> In my issue it will preferable to not use the function
> InetAddress.getByName 
> but to use something as 
> InetAddress.getByAddress(ipAddr);
> thanks



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

[jira] [Resolved] (IGNITE-3264) IGFS: Refactor and simplify output streams.

2016-06-08 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov resolved IGNITE-3264.
-
Resolution: Fixed

> IGFS: Refactor and simplify output streams.
> ---
>
> Key: IGNITE-3264
> URL: https://issues.apache.org/jira/browse/IGNITE-3264
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently our IGFS output streams are overly complex and has 3-level 
> hierarchy. There are no reasons for this.
> We should make it flat and simple.



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

[jira] [Updated] (IGNITE-3264) IGFS: Refactor and simplify output streams.

2016-06-08 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov updated IGNITE-3264:

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

> IGFS: Refactor and simplify output streams.
> ---
>
> Key: IGNITE-3264
> URL: https://issues.apache.org/jira/browse/IGNITE-3264
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently our IGFS output streams are overly complex and has 3-level 
> hierarchy. There are no reasons for this.
> We should make it flat and simple.



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

[jira] [Closed] (IGNITE-3274) Hadoop: NPE when mappings are not set in BasicUserNameMapper.

2016-06-08 Thread Vladimir Ozerov (JIRA) 

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

Vladimir Ozerov closed IGNITE-3274.
---

> Hadoop: NPE when mappings are not set in BasicUserNameMapper.
> -
>
> Key: IGNITE-3274
> URL: https://issues.apache.org/jira/browse/IGNITE-3274
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> We simply forgot null check there.



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

[jira] [Created] (IGNITE-3274) Hadoop: NPE when mappings are not set in BasicUserNameMapper.

2016-06-08 Thread Vladimir Ozerov (JIRA) 
Vladimir Ozerov created IGNITE-3274:
---

 Summary: Hadoop: NPE when mappings are not set in 
BasicUserNameMapper.
 Key: IGNITE-3274
 URL: https://issues.apache.org/jira/browse/IGNITE-3274
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.7


We simply forgot null check there.



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

[jira] [Updated] (IGNITE-3273) SQL query parse error on map query side

2016-06-08 Thread Alexei Scherbakov (JIRA) 

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

Alexei Scherbakov updated IGNITE-3273:
--
Description: 
Distributed SQL query cannot be parsed on map side if it contains left join.
The same local query works without any error.
Replacing left join with inner join removes the error.
See the attachment for the reproducer.

{noformat}
[10:40:58,850][ERROR][main][GridMapQueryExecutor] Failed to execute local 
query: GridQueryRequest [reqId=1, pageSize=1024, space=P, 
qrys=[GridCacheSqlQuery [qry=SELECT
PERSON._KEY __C0,
PERSON._VAL __C1,
PERSON.NAME __C2,
PERSON.ID __C3,
PERSON.DEPID __C4,
DEP._KEY __C5,
DEP._VAL __C6,
DEP.NAME __C7,
DEP.ID __C8,
DEP.ORGID __C9,
ORG._KEY __C10,
ORG._VAL __C11,
ORG.NAME __C12,
ORG.ID __C13
FROM P.PERSON 
 INNER JOIN D.DEPARTMENT DEP 
 LEFT OUTER JOIN O.ORG ORG 
 ON ORG.ID = DEP.ORGID
WHERE DEP.ID = P.PERSON.DEPID, params=[], paramIdxs=[], paramsSize=0, 
cols={__C0=GridSqlType [type=4, scale=0, precision=10, displaySize=11, 
sql=INTEGER], __C1=GridSqlType [type=19, scale=0, precision=2147483647, 
displaySize=2147483647, sql=OTHER], __C2=GridSqlType [type=13, scale=0, 
precision=2147483647, displaySize=2147483647, sql=VARCHAR], __C3=GridSqlType 
[type=4, scale=0, precision=10, displaySize=11, sql=INTEGER], __C4=GridSqlType 
[type=4, scale=0, precision=10, displaySize=11, sql=INTEGER], __C5=GridSqlType 
[type=4, scale=0, precision=10, displaySize=11, sql=INTEGER], __C6=GridSqlType 
[type=19, scale=0, precision=2147483647, displaySize=2147483647, sql=OTHER], 
__C7=GridSqlType [type=13, scale=0, precision=2147483647, 
displaySize=2147483647, sql=VARCHAR], __C8=GridSqlType [type=4, scale=0, 
precision=10, displaySize=11, sql=INTEGER], __C9=GridSqlType [type=4, scale=0, 
precision=10, displaySize=11, sql=INTEGER], __C10=GridSqlType [type=4, scale=0, 
precision=10, displaySize=11, sql=INTEGER], __C11=GridSqlType [type=19, 
scale=0, precision=2147483647, displaySize=2147483647, sql=OTHER], 
__C12=GridSqlType [type=13, scale=0, precision=2147483647, 
displaySize=2147483647, sql=VARCHAR], __C13=GridSqlType [type=4, scale=0, 
precision=10, displaySize=11, sql=INTEGER]}, alias=null]], 
topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], extraSpaces=[D, O], 
parts=null]
class org.apache.ignite.IgniteCheckedException: Failed to parse SQL query: 
SELECT
PERSON._KEY __C0,
PERSON._VAL __C1,
PERSON.NAME __C2,
PERSON.ID __C3,
PERSON.DEPID __C4,
DEP._KEY __C5,
DEP._VAL __C6,
DEP.NAME __C7,
DEP.ID __C8,
DEP.ORGID __C9,
ORG._KEY __C10,
ORG._VAL __C11,
ORG.NAME __C12,
ORG.ID __C13
FROM P.PERSON 
 INNER JOIN D.DEPARTMENT DEP 
 LEFT OUTER JOIN O.ORG ORG 
 ON ORG.ID = DEP.ORGID
WHERE DEP.ID = P.PERSON.DEPID
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:828)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:870)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:454)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:184)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1065)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:572)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$2.iterator(IgniteH2Indexing.java:971)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:61)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:73)
at 
org.apache.ignite.internal.processors.cache.distributed.replicated.Example2.main(Example2.java:40)
Caused by: org.h2.jdbc.JdbcSQLException: Column "DEP.ORGID" not found; SQL 
statement:
SELECT
PERSON._KEY __C0,
PERSON._VAL __C1,
PERSON.NAME __C2,
PERSON.ID __C3,
PERSON.DEPID __C4,
DEP._KEY __C5,
DEP._VAL __C6,
DEP.NAME __C7,
DEP.ID __C8,
DEP.ORGID __C9,
ORG._KEY __C10,
ORG._VAL __C11,
ORG.NAME __C12,
ORG.ID __C13
FROM P.PERSON 
 INNER JOIN D.DEPARTMENT DEP 
 LEFT OUTER JOIN O.ORG ORG 
 ON ORG.ID = DEP.ORGID
WHERE DEP.ID = P.PERSON.DEPID [42122-175]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:332)
at org.h2.message.DbException.get(DbException.java:172)
at org.h2.message.DbException.get(DbException.java:149)
at 
org.h2.expression.ExpressionColumn.optimize(ExpressionColumn.java:144)
at org.h2.expression.Comparison.optimize(Comparison.java:179)
at org.h2.command.dml.Select.setEvaluatableRecursive(Select.java:958)
at org.h2.command.dml.Select.preparePlan(Select.java:937)
at

[jira] [Comment Edited] (IGNITE-3238) Javadoc Warning due to cassandra libs usage

2016-06-08 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov edited comment on IGNITE-3238 at 6/8/16 6:58 AM:
--

Igor, I've created pull request from you branch to apache ignite master and see 
a lot of changes, is it ok?
PR: https://github.com/apache/ignite/pull/783/files


was (Author: avinogradov):
Igor, I've created pull request from you branch to apache ignite master and see 
a lot of changes, is it ok?

> Javadoc Warning due to cassandra libs usage
> ---
>
> Key: IGNITE-3238
> URL: https://issues.apache.org/jira/browse/IGNITE-3238
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Anton Vinogradov
>Assignee: Igor Rudyak
>Priority: Critical
> Fix For: 1.7
>
>
> I found following at Ignite 1.6 build log:
> {code} [WARNING] Javadoc Warnings
>  [WARNING] warning: 
> /home/teamcity/.m2/repository/org/apache/cassandra/cassandra-all/3.3/cassandra-all-3.3.jar(org/apache/cassandra/service/CassandraDaemon.class):
>  major version 52 is newer than 51, the highest major version supported by 
> this compiler.
>  [WARNING] It is recommended that the compiler be upgraded.{code} 
> seems this warning related to 
> https://issues.apache.org/jira/browse/IGNITE-1371. 
> Command to gain this is:
> {code} mvn clean package -DskipTests{code} 
> also you can use this TeamCity task: 
> http://149.202.210.143:8111/viewType.html?buildTypeId=IgniteTests_RatJavadoc
> Need to fix it without using JDK 8.



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

[jira] [Commented] (IGNITE-3238) Javadoc Warning due to cassandra libs usage

2016-06-08 Thread Anton Vinogradov (JIRA) 

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

Anton Vinogradov commented on IGNITE-3238:
--

Igor, I've created pull request from you branch to apache ignite master and see 
a lot of changes, is it ok?

> Javadoc Warning due to cassandra libs usage
> ---
>
> Key: IGNITE-3238
> URL: https://issues.apache.org/jira/browse/IGNITE-3238
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Anton Vinogradov
>Assignee: Igor Rudyak
>Priority: Critical
> Fix For: 1.7
>
>
> I found following at Ignite 1.6 build log:
> {code} [WARNING] Javadoc Warnings
>  [WARNING] warning: 
> /home/teamcity/.m2/repository/org/apache/cassandra/cassandra-all/3.3/cassandra-all-3.3.jar(org/apache/cassandra/service/CassandraDaemon.class):
>  major version 52 is newer than 51, the highest major version supported by 
> this compiler.
>  [WARNING] It is recommended that the compiler be upgraded.{code} 
> seems this warning related to 
> https://issues.apache.org/jira/browse/IGNITE-1371. 
> Command to gain this is:
> {code} mvn clean package -DskipTests{code} 
> also you can use this TeamCity task: 
> http://149.202.210.143:8111/viewType.html?buildTypeId=IgniteTests_RatJavadoc
> Need to fix it without using JDK 8.



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