[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-967:
---
Labels: important  (was: )

> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> One of our users reported that he sees warnings in Tomcat's log when the 
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type 
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value 
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a 
> value of type [java.lang.Integer] (value [0]) but failed to remove it when 
> the web application was stopped. Threads are going to be renewed over time to 
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}. 
> While it's usually OK not to clean thread locals on standalone node, in app 
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites 
> that will check thread locals in test runner thread. If we have this check in 
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}} 
> variable. It would also be a good idea to check Tomcat's sources on how it's 
> done there.



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

[jira] [Updated] (IGNITE-2195) Accessing from IGFS to HDFS that is in kerberised environment

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2195:

Labels: important  (was: )

> Accessing from IGFS to HDFS that is in kerberised environment
> -
>
> Key: IGNITE-2195
> URL: https://issues.apache.org/jira/browse/IGNITE-2195
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop, IGFS
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Ivan Veselovsky
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> There is some issue in the current IGFS implementation that doesn't take into 
> account some Kerberos user related settings which leads to the exception 
> below when there is an attempt to work with Kerberised cluster
> {noformat}
> Connecting to HDFS with the following settings [uri=null, cfg=all-site.xml, 
> userName=null]
> log4j:WARN No appenders could be found for logger 
> (org.apache.hadoop.metrics2.lib.MutableMetricsFactory).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
> info.
> org.apache.hadoop.security.AccessControlException: SIMPLE authentication is 
> not enabled. Available:[TOKEN, KERBEROS]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at 
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at 
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
> at org.apache.hadoop.hdfs.DFSClient.listPaths(DFSClient.java:2096)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$DirListingIterator.(DistributedFileSystem.java:944)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$DirListingIterator.(DistributedFileSystem.java:927)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:872)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:868)
> at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at 
> org.apache.hadoop.hdfs.DistributedFileSystem.listLocatedStatus(DistributedFileSystem.java:868)
> at org.apache.hadoop.fs.FileSystem.listLocatedStatus(FileSystem.java:1694)
> at org.apache.hadoop.fs.FileSystem$6.(FileSystem.java:1786)
> at org.apache.hadoop.fs.FileSystem.listFiles(FileSystem.java:1783)
> at com.ig.HadoopFsIssue.main(HadoopFsIssue.java:35)
> Caused by: 
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
>  SIMPLE authentication is not enabled. Available:[TOKEN, KERBEROS]
> at org.apache.hadoop.ipc.Client.call(Client.java:1427)
> at org.apache.hadoop.ipc.Client.call(Client.java:1358)
> at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
> at com.sun.proxy.$Proxy7.getListing(Unknown Source)
> at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getListing(ClientNamenodeProtocolTranslatorPB.java:573)
> 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 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
> at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
> at com.sun.proxy.$Proxy8.getListing(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.listPaths(DFSClient.java:2094)
> {noformat}
> The issue is fixed in the following way. Need to revisit the fix and check 
> whether it can lead to some other consequences.
> {noformat}
> /**
> * @return {@link org.apache.hadoop.fs.FileSystem}  instance for this 
> secondary Fs.
> * @throws IOException
> */
> public FileSystem createFileSystem(String userName) throws IOException {
> userName = IgfsUtils.fixUserName(userName);
> UserGroupInformation.setConfiguration(cfg);
> UserGroupInformation ugi = UserGroupInformation.createProxyUser(userName, 
> UserGroupInformation.getCurrentUser());
> try {
> return ugi.doAs(new PrivilegedExceptionAction() {
> @Override
> public FileSystem run() throws Exception {
> return FileSystem.get(uri, cfg);
> }
> });
> } catch (InterruptedException e) 

[jira] [Updated] (IGNITE-2258) Hadoop: secondary file system is initialized on client even if there are no explicit PROXY paths.

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2258:

Labels: important  (was: )

> Hadoop: secondary file system is initialized on client even if there are no 
> explicit PROXY paths.
> -
>
> Key: IGNITE-2258
> URL: https://issues.apache.org/jira/browse/IGNITE-2258
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> *Problem*:
> In case at least one PROXY path exists, we intialize secondary file system on 
> the client (IgniteHadoopFileSystem). 
> We have 4 "default paths" which are always defined (see IgfsImpl) and one of 
> these paths is in PROXY mode.
> As a result, whenever secondary file system is defined, it will always be 
> intiialized on the client whether it is needed or not.
> *Proposed solutions*:
> a) Remove these default paths as they are of little use in real apps.
> b) Or make them optional through configuration parameter.



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

[jira] [Updated] (IGNITE-2267) CacheEvent serializes ClusterNodes that may lead to slow deserialization of event

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2267:

Description: 
When a CacheEvent is being sent to a remote node, that listens for the events, 
it serializes TcpDiscoveryNodes ('node' and 'eventNode' fields of CacheEvent).

During deserialization of the event on a remote side {{sockAddrrs}} field of 
TcpDiscoveryNode is deserialized this way
{{sockAddrs = U.toSocketAddresses(this, discPort);}}.

Such a call may lead to performance degradation if the event node and the node, 
that deserializes the event, are located in different networks.




  was:
When a CacheEvent is being sent to a remote node, that listens for the events, 
it serializes TcpDiscoveryNodes ('node' and 'eventNode' fields of CacheEvent).

During deserialization of the event on a remote side {{sockAddrrs}} field of 
TcpDiscoveryNode is deserialized this way
{{sockAddrs = U.toSocketAddresses(this, discPort);}}.

Such a call may lead to performance degradation of the event node and the node 
that deserializes the event are located in different networks.





> CacheEvent serializes ClusterNodes that may lead to slow deserialization of 
> event
> -
>
> Key: IGNITE-2267
> URL: https://issues.apache.org/jira/browse/IGNITE-2267
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> When a CacheEvent is being sent to a remote node, that listens for the 
> events, it serializes TcpDiscoveryNodes ('node' and 'eventNode' fields of 
> CacheEvent).
> During deserialization of the event on a remote side {{sockAddrrs}} field of 
> TcpDiscoveryNode is deserialized this way
> {{sockAddrs = U.toSocketAddresses(this, discPort);}}.
> Such a call may lead to performance degradation if the event node and the 
> node, that deserializes the event, are located in different networks.



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

[jira] [Created] (IGNITE-2267) CacheEvent serializes ClusterNodes that may lead to slow deserialization of event

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2267:
---

 Summary: CacheEvent serializes ClusterNodes that may lead to slow 
deserialization of event
 Key: IGNITE-2267
 URL: https://issues.apache.org/jira/browse/IGNITE-2267
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: ignite-1.4
Reporter: Denis Magda
Priority: Critical
 Fix For: 1.6


When a CacheEvent is being sent to a remote node, that listens for the events, 
it serializes TcpDiscoveryNodes ('node' and 'eventNode' fields of CacheEvent).

During deserialization of the event on a remote side {{sockAddrrs}} field of 
TcpDiscoveryNode is deserialized this way
{{sockAddrs = U.toSocketAddresses(this, discPort);}}.

Such a call may lead to performance degradation of the event node and the node 
that deserializes the event are located in different networks.






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

[jira] [Updated] (IGNITE-2267) CacheEvent serializes ClusterNodes that may lead to slow deserialization of event

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2267:

Labels: important  (was: )

> CacheEvent serializes ClusterNodes that may lead to slow deserialization of 
> event
> -
>
> Key: IGNITE-2267
> URL: https://issues.apache.org/jira/browse/IGNITE-2267
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> When a CacheEvent is being sent to a remote node, that listens for the 
> events, it serializes TcpDiscoveryNodes ('node' and 'eventNode' fields of 
> CacheEvent).
> During deserialization of the event on a remote side {{sockAddrrs}} field of 
> TcpDiscoveryNode is deserialized this way
> {{sockAddrs = U.toSocketAddresses(this, discPort);}}.
> Such a call may lead to performance degradation if the event node and the 
> node, that deserializes the event, are located in different networks.



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

[jira] [Updated] (IGNITE-2083) EntryProcessor is called twice on primary node in transactional cache

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2083:

Labels: important  (was: )

> EntryProcessor is called twice on primary node in transactional cache
> -
>
> Key: IGNITE-2083
> URL: https://issues.apache.org/jira/browse/IGNITE-2083
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
>  Labels: important
> Fix For: 1.5
>
>
> Issue is described in details here: 
> http://apache-ignite-developers.2346864.n4.nabble.com/EntryProcessor-invoked-twice-td5494.html
> Looks like that this can be optimized, at least for {{REPEATABLE_READ}} 
> transactions.



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

[jira] [Updated] (IGNITE-2079) GridCacheIoManager eats exception trail if it falls into the directed case

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2079:

Labels: important  (was: )

> GridCacheIoManager eats exception trail if it falls into the directed case
> --
>
> Key: IGNITE-2079
> URL: https://issues.apache.org/jira/browse/IGNITE-2079
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>  Labels: important
> Fix For: 1.6
>
>
> During a recent test I have run into an issue where a storage disabled client 
> of a Fabric that has services deployed for which the client does not have the 
> fabric in the class path failed with the following exception:
> com.workday.fabric.HelloWorldTest STANDARD_ERROR
> Nov 08, 2015 6:15:20 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to process message 
> [senderId=30775397-457a-400f-a6c9-077c9e762d61, messageType=class 
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> class org.apache.ignite.IgniteCheckedException: Failed to send response to 
> node. Unsupported direct type [message=GridCacheQueryResponse [finished=true, 
> reqId=5, err=null, fields=false, metadata=null]]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:546)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:272)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:77)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1078)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
>  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)
> This unfortunately gives me 0 information to work on to resolve the issue, as 
> the original unmarshalling exception (from the JdkMarshaller) was eaten as 
> this is the code for the default process failed message:
> default:
> throw new IgniteCheckedException("Failed to send response to node. 
> Unsupported direct type [message="
> + msg + "]");
> }
> you should also include the original stack from msg.getError() in the newly 
> thrown IgniteCheckedException



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

[jira] [Updated] (IGNITE-1553) Optimize transaction prepare step when store is enabled

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1553:

Labels: important  (was: )

> Optimize transaction prepare step when store is enabled
> ---
>
> Key: IGNITE-1553
> URL: https://issues.apache.org/jira/browse/IGNITE-1553
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>  Labels: important
>
> Currently entries are enlisted in a database transaction after grid 
> transaction is in PREPARED state. We can do this in parallel in the following 
> fashion (pseudo-code):
> {code}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
> db.commit();
> 
> tx.commit();
> }
> catch (Exception e) {
> tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for 
> transactions when write-through is enabled.



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

[jira] [Updated] (IGNITE-1864) Cannot configure jndiNames for CacheJndiTmLookup

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1864:

Labels: important  (was: )

> Cannot configure jndiNames for CacheJndiTmLookup 
> -
>
> Key: IGNITE-1864
> URL: https://issues.apache.org/jira/browse/IGNITE-1864
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Yakov Zhdanov
>Assignee: Artem Shutak
>Priority: Critical
>  Labels: important
> Fix For: 1.5
>
>
> Since user have an ability to configure only lookup class name via 
> org.apache.ignite.configuration.TransactionConfiguration#getTxManagerLookupClassName,
>  he lacks ability to properly configure all of its properties.
> This seems to be a general problem for this approach



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

[jira] [Updated] (IGNITE-2249) Services are sometimes deserialized on client

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2249:

Labels: important  (was: )

> Services are sometimes deserialized on client
> -
>
> Key: IGNITE-2249
> URL: https://issues.apache.org/jira/browse/IGNITE-2249
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>




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

[jira] [Updated] (IGNITE-2212) Transactional put triggers several deserializations on server of there are recordable events

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2212:

Labels: important  (was: )

> Transactional put triggers several deserializations on server of there are 
> recordable events
> 
>
> Key: IGNITE-2212
> URL: https://issues.apache.org/jira/browse/IGNITE-2212
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Alexey Goncharuk
>  Labels: important
> Fix For: 1.6
>
> Attachments: TxTest.java
>
>
> Test attached.



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

[jira] [Commented] (IGNITE-2154) .NET: doxygen docs generation must be included into Maven build process.

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-2154:
--

Anton,
I've added notes on how to skip .NET docs generation when no doxygen is 
installed.

> .NET: doxygen docs generation must be included into Maven build process.
> 
>
> Key: IGNITE-2154
> URL: https://issues.apache.org/jira/browse/IGNITE-2154
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>




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

[jira] [Resolved] (IGNITE-2217) Add BinaryConfiguration support to cluster screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko resolved IGNITE-2217.
---
Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

Implemented binary configuration in cluster configuration.

> Add BinaryConfiguration support to cluster screen
> -
>
> Key: IGNITE-2217
> URL: https://issues.apache.org/jira/browse/IGNITE-2217
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>




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

[jira] [Resolved] (IGNITE-2135) ClassNotFoundException for CacheContinuousQueryExample

[Saikat Maitra (JIRA)]

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

Saikat Maitra resolved IGNITE-2135.
---
Resolution: Fixed

> ClassNotFoundException for CacheContinuousQueryExample
> --
>
> Key: IGNITE-2135
> URL: https://issues.apache.org/jira/browse/IGNITE-2135
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Sergey Kozlov
>Assignee: Saikat Maitra
>Priority: Critical
> Fix For: 1.6
>
>
> 1. Start 3 nodes with examples/config/example-ignite.xml
> 2. Run CacheContinuousQueryExample in IDEA
> 3. The example fails:
> {noformat}
> >>> Cache continuous query example started.
> [14:15:07] Ignite node stopped OK [uptime=00:00:00:898]
> Exception in thread "main" javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Query execution failed: 
> GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, 
> filter=org.apache.ignite.examples.datagrid.CacheContinuousQueryExample$1@6b6b1935,
>  part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter [minTime=0, 
> maxTime=0, sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], 
> pageSize=1024, timeout=0, keepAll=true, incBackups=false, dedup=false, 
> prj=null, keepPortable=false, subjId=2908e088-371e-4528-9141-52efb5ef42d6, 
> taskHash=0], rdc=null, trans=null]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1634)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy$5.onHasNext(IgniteCacheProxy.java:528)
>   at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
>   at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
>   at 
> org.apache.ignite.examples.datagrid.CacheContinuousQueryExample.main(CacheContinuousQueryExample.java:92)
>   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.IgniteCheckedException: Query execution 
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, 
> clsName=null, clause=null, 
> filter=org.apache.ignite.examples.datagrid.CacheContinuousQueryExample$1@6b6b1935,
>  part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter [minTime=0, 
> maxTime=0, sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], 
> pageSize=1024, timeout=0, keepAll=true, incBackups=false, dedup=false, 
> prj=null, keepPortable=false, subjId=2908e088-371e-4528-9141-52efb5ef42d6, 
> taskHash=0], rdc=null, trans=null]
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:325)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
>   ... 9 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter 
> [type=SCAN, clsName=null, clause=null, 
> filter=org.apache.ignite.examples.datagrid.CacheContinuousQueryExample$1@6b6b1935,
>  part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter [minTime=0, 
> maxTime=0, sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], 
> pageSize=1024, timeout=0, keepAll=true, incBackups=false, dedup=false, 
> prj=null, keepPortable=false, subjId=2908e088-371e-4528-9141-52efb5ef42d6, 
> taskHash=0], rdc=null, trans=null], 
> nodeId=a17e9748-7771-441c-a594-122c598b7b8e]
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:390)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:395)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:60)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$1.apply(GridCacheDistributedQueryManager.java:90)
>   at 

[jira] [Commented] (IGNITE-2135) ClassNotFoundException for CacheContinuousQueryExample

[Saikat Maitra (JIRA)]

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

Saikat Maitra commented on IGNITE-2135:
---

Yes , verified and it is not reproducible now.

> ClassNotFoundException for CacheContinuousQueryExample
> --
>
> Key: IGNITE-2135
> URL: https://issues.apache.org/jira/browse/IGNITE-2135
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Sergey Kozlov
>Assignee: Saikat Maitra
>Priority: Critical
> Fix For: 1.6
>
>
> 1. Start 3 nodes with examples/config/example-ignite.xml
> 2. Run CacheContinuousQueryExample in IDEA
> 3. The example fails:
> {noformat}
> >>> Cache continuous query example started.
> [14:15:07] Ignite node stopped OK [uptime=00:00:00:898]
> Exception in thread "main" javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Query execution failed: 
> GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, clsName=null, 
> clause=null, 
> filter=org.apache.ignite.examples.datagrid.CacheContinuousQueryExample$1@6b6b1935,
>  part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter [minTime=0, 
> maxTime=0, sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], 
> pageSize=1024, timeout=0, keepAll=true, incBackups=false, dedup=false, 
> prj=null, keepPortable=false, subjId=2908e088-371e-4528-9141-52efb5ef42d6, 
> taskHash=0], rdc=null, trans=null]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1634)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy$5.onHasNext(IgniteCacheProxy.java:528)
>   at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
>   at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
>   at 
> org.apache.ignite.examples.datagrid.CacheContinuousQueryExample.main(CacheContinuousQueryExample.java:92)
>   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.IgniteCheckedException: Query execution 
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN, 
> clsName=null, clause=null, 
> filter=org.apache.ignite.examples.datagrid.CacheContinuousQueryExample$1@6b6b1935,
>  part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter [minTime=0, 
> maxTime=0, sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], 
> pageSize=1024, timeout=0, keepAll=true, incBackups=false, dedup=false, 
> prj=null, keepPortable=false, subjId=2908e088-371e-4528-9141-52efb5ef42d6, 
> taskHash=0], rdc=null, trans=null]
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:325)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
>   ... 9 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter 
> [type=SCAN, clsName=null, clause=null, 
> filter=org.apache.ignite.examples.datagrid.CacheContinuousQueryExample$1@6b6b1935,
>  part=null, incMeta=false, metrics=GridCacheQueryMetricsAdapter [minTime=0, 
> maxTime=0, sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], 
> pageSize=1024, timeout=0, keepAll=true, incBackups=false, dedup=false, 
> prj=null, keepPortable=false, subjId=2908e088-371e-4528-9141-52efb5ef42d6, 
> taskHash=0], rdc=null, trans=null], 
> nodeId=a17e9748-7771-441c-a594-122c598b7b8e]
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.onPage(GridCacheQueryFutureAdapter.java:390)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryResponse(GridCacheDistributedQueryManager.java:395)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.access$000(GridCacheDistributedQueryManager.java:60)
>   at 
> 

[jira] [Comment Edited] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-1371 at 12/25/15 7:12 AM:


Igor,

Valentin Kulichenko and I reviewed your code and we have following points:

1) First of all please merge with latest master or ignite-1.5. In ignite-1.5 we 
introduced BinaryMarshaller that should be properly handled in store.
2) Please add more javadocs for Cassandra specific code (for example keyspace, 
tblOptions, keyspaceOptions) what for we need them, may be give a link to 
Cassandra docs.
3) KeyValuePersistenceSettings.keyspaceOptions - please describe why such 
default options were selected? And please move defaults to constant 
DFLT_propper_name.
4) CassandraCacheStoreFactory.persistenceSettings lets make these settings not 
transient, but serializable and also move all settings classes from util 
package to same package as store.
5) Also let's refactor persistence settings to be serializable and more simple 
(take a look at JdbsType of CacheJdbcPojoStorefactory) to be just a description 
of metadata. Move all serialization logic inside store.
6) Also persistence settings hierarchy looks a bit over engineered a lot of 
classes: KeyValuePersistenceSettings, KeyPersistenceSettings, 
ValuePersistenceSettings, PojoField, PojoKeyField, PojoValueField ... why we 
need such many classes? Is this cassandra specific? Why we need indexes in 
PojoValueField? Also may be we could rename classes to be looks like same 
classes in JdbcPojoStore? KeyValuePersistenceSettings -> CassandraTypes. 
KeyPersistenceSettings -> CassandraKeyType, and so on
7) What for we need PersistenceStrategy? now in Ignite-1.5 we have Binary 
marshaller as default marshaller and this marshaller already serialize objects 
as bytes, assuming this I think we could drop Serializers that were introduces 
(Java and Kryo).
8) Also what is the difference between PRIMITIVE and POJO modes in 
PersistenceStrategy?


was (Author: kuaw26):
Igor,

Valentin Kulichenko reviewed your code and we have following points:

1) First of all please merge with latest master or ignite-1.5. In ignite-1.5 we 
introduced BinaryMarshaller that should be properly handled in store.
2) Please add more javadocs for Cassandra specific code (for example keyspace, 
tblOptions, keyspaceOptions) what for we need them, may be give a link to 
Cassandra docs.
3) KeyValuePersistenceSettings.keyspaceOptions - please describe why such 
default options were selected? And please move defaults to constant 
DFLT_propper_name.
4) CassandraCacheStoreFactory.persistenceSettings lets make these settings not 
transient, but serializable and also move all settings classes from util 
package to same package as store.
5) Also let's refactor persistence settings to be serializable and more simple 
(take a look at JdbsType of CacheJdbcPojoStorefactory) to be just a description 
of metadata. Move all serialization logic inside store.
6) Also persistence settings hierarchy looks a bit over engineered a lot of 
classes: KeyValuePersistenceSettings, KeyPersistenceSettings, 
ValuePersistenceSettings, PojoField, PojoKeyField, PojoValueField ... why we 
need such many classes? Is this cassandra specific? Why we need indexes in 
PojoValueField? Also may be we could rename classes to be looks like same 
classes in JdbcPojoStore? KeyValuePersistenceSettings -> CassandraTypes. 
KeyPersistenceSettings -> CassandraKeyType, and so on
7) What for we need PersistenceStrategy? now in Ignite-1.5 we have Binary 
marshaller as default marshaller and this marshaller already serialize objects 
as bytes, assuming this I think we could drop Serializers that were introduces 
(Java and Kryo).
8) Also what is the difference between PRIMITIVE and POJO modes in 
PersistenceStrategy?

> Key-Value store (like Cassandra) as CacheStore
> --
>
> Key: IGNITE-1371
> URL: https://issues.apache.org/jira/browse/IGNITE-1371
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexandre Boudnik
>Assignee: Igor Rudyak
> Attachments: master_02b59e4_ignite-1371.patch
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> It will provide ability to map particular cache holding POJOs to Cassandra 
> table. Later it would be generalized to support eventually any any Key-Value 
> store.



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

[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-1371:
--

Igor,

Valentin Kulichenko reviewed your code and we have following points:

1) First of all please merge with latest master or ignite-1.5. In ignite-1.5 we 
introduced BinaryMarshaller that should be properly handled in store.
2) Please add more javadocs for Cassandra specific code (for example keyspace, 
tblOptions, keyspaceOptions) what for we need them, may be give a link to 
Cassandra docs.
3) KeyValuePersistenceSettings.keyspaceOptions - please describe why such 
default options were selected? And please move defaults to constant 
DFLT_propper_name.
4) CassandraCacheStoreFactory.persistenceSettings lets make these settings not 
transient, but serializable and also move all settings classes from util 
package to same package as store.
5) Also let's refactor persistence settings to be serializable and more simple 
(take a look at JdbsType of CacheJdbcPojoStorefactory) to be just a description 
of metadata. Move all serialization logic inside store.
6) Also persistence settings hierarchy looks a bit over engineered a lot of 
classes: KeyValuePersistenceSettings, KeyPersistenceSettings, 
ValuePersistenceSettings, PojoField, PojoKeyField, PojoValueField ... why we 
need such many classes? Is this cassandra specific? Why we need indexes in 
PojoValueField? Also may be we could rename classes to be looks like same 
classes in JdbcPojoStore? KeyValuePersistenceSettings -> CassandraTypes. 
KeyPersistenceSettings -> CassandraKeyType, and so on
7) What for we need PersistenceStrategy? now in Ignite-1.5 we have Binary 
marshaller as default marshaller and this marshaller already serialize objects 
as bytes, assuming this I think we could drop Serializers that were introduces 
(Java and Kryo).
8) Also what is the difference between PRIMITIVE and POJO modes in 
PersistenceStrategy?

> Key-Value store (like Cassandra) as CacheStore
> --
>
> Key: IGNITE-1371
> URL: https://issues.apache.org/jira/browse/IGNITE-1371
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexandre Boudnik
>Assignee: Igor Rudyak
> Attachments: master_02b59e4_ignite-1371.patch
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> It will provide ability to map particular cache holding POJOs to Cassandra 
> table. Later it would be generalized to support eventually any any Key-Value 
> store.



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

[jira] [Comment Edited] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-1371 at 12/25/15 7:13 AM:


Igor,

Valentin Kulichenko and I reviewed your code and we have following points:

# First of all please merge with latest master or ignite-1.5. In ignite-1.5 we 
introduced BinaryMarshaller that should be properly handled in store.
# Please add more javadocs for Cassandra specific code (for example keyspace, 
tblOptions, keyspaceOptions) what for we need them, may be give a link to 
Cassandra docs.
# KeyValuePersistenceSettings.keyspaceOptions - please describe why such 
default options were selected? And please move defaults to constant 
DFLT_propper_name.
# CassandraCacheStoreFactory.persistenceSettings lets make these settings not 
transient, but serializable and also move all settings classes from util 
package to same package as store.
# Also let's refactor persistence settings to be serializable and more simple 
(take a look at JdbsType of CacheJdbcPojoStorefactory) to be just a description 
of metadata. Move all serialization logic inside store.
# Also persistence settings hierarchy looks a bit over engineered a lot of 
classes: KeyValuePersistenceSettings, KeyPersistenceSettings, 
ValuePersistenceSettings, PojoField, PojoKeyField, PojoValueField ... why we 
need such many classes? Is this cassandra specific? Why we need indexes in 
PojoValueField? Also may be we could rename classes to be looks like same 
classes in JdbcPojoStore? KeyValuePersistenceSettings -> CassandraTypes. 
KeyPersistenceSettings -> CassandraKeyType, and so on
# What for we need PersistenceStrategy? now in Ignite-1.5 we have Binary 
marshaller as default marshaller and this marshaller already serialize objects 
as bytes, assuming this I think we could drop Serializers that were introduces 
(Java and Kryo).
# Also what is the difference between PRIMITIVE and POJO modes in 
PersistenceStrategy?


was (Author: kuaw26):
Igor,

Valentin Kulichenko and I reviewed your code and we have following points:

1) First of all please merge with latest master or ignite-1.5. In ignite-1.5 we 
introduced BinaryMarshaller that should be properly handled in store.
2) Please add more javadocs for Cassandra specific code (for example keyspace, 
tblOptions, keyspaceOptions) what for we need them, may be give a link to 
Cassandra docs.
3) KeyValuePersistenceSettings.keyspaceOptions - please describe why such 
default options were selected? And please move defaults to constant 
DFLT_propper_name.
4) CassandraCacheStoreFactory.persistenceSettings lets make these settings not 
transient, but serializable and also move all settings classes from util 
package to same package as store.
5) Also let's refactor persistence settings to be serializable and more simple 
(take a look at JdbsType of CacheJdbcPojoStorefactory) to be just a description 
of metadata. Move all serialization logic inside store.
6) Also persistence settings hierarchy looks a bit over engineered a lot of 
classes: KeyValuePersistenceSettings, KeyPersistenceSettings, 
ValuePersistenceSettings, PojoField, PojoKeyField, PojoValueField ... why we 
need such many classes? Is this cassandra specific? Why we need indexes in 
PojoValueField? Also may be we could rename classes to be looks like same 
classes in JdbcPojoStore? KeyValuePersistenceSettings -> CassandraTypes. 
KeyPersistenceSettings -> CassandraKeyType, and so on
7) What for we need PersistenceStrategy? now in Ignite-1.5 we have Binary 
marshaller as default marshaller and this marshaller already serialize objects 
as bytes, assuming this I think we could drop Serializers that were introduces 
(Java and Kryo).
8) Also what is the difference between PRIMITIVE and POJO modes in 
PersistenceStrategy?

> Key-Value store (like Cassandra) as CacheStore
> --
>
> Key: IGNITE-1371
> URL: https://issues.apache.org/jira/browse/IGNITE-1371
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexandre Boudnik
>Assignee: Igor Rudyak
> Attachments: master_02b59e4_ignite-1371.patch
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> It will provide ability to map particular cache holding POJOs to Cassandra 
> table. Later it would be generalized to support eventually any any Key-Value 
> store.



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

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 9:58 PM:
---

{{GridUnsafeMap}} is fixed. But the following tests fail under Solaris:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OptimizedObjectStreamSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridEmbeddedFutureSelfTest}}
  * {{SocketStreamerSelfTest}}
  * {{GridCacheAbstractReduceFieldsQuerySelfTest.testIncludeBackups}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

Failures don't related with JVM crash. Need to investigate.


was (Author: agura):
`GridUnsafeMap` is fixed. But the following tests fail under Solaris:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OptimizedObjectStreamSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridEmbeddedFutureSelfTest}}
  * {{SocketStreamerSelfTest}}
  * {{GridCacheAbstractReduceFieldsQuerySelfTest.testIncludeBackups}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

Failures don't related with JVM crash. Need to investigate.

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j  
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j  org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j  
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j  

[jira] [Resolved] (IGNITE-2257) Incorrect deserialization of BinaryContext.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-2257.
-
Resolution: Fixed

> Incorrect deserialization of BinaryContext.
> ---
>
> Key: IGNITE-2257
> URL: https://issues.apache.org/jira/browse/IGNITE-2257
> Project: Ignite
>  Issue Type: Bug
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> 1) Initially BinaryContext was deserialized using grid name. This is 
> incorrect, because on the other side grid name might be different.
> {code}IgniteKernal g = IgnitionEx.gridx(gridName);{code}
> 2) Now it is deserialized using TLS grid name which depends on IgniteThread. 
> This is incorrect either because deserialization code might be invoked in 
> user thread.
> IgniteKernal g = IgnitionEx.localIgnite();
> Proposed fix: set TLS BinaryContext inside GridBinaryMarshaller when 
> deserialzation starts, and reset it afterwards.



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

[jira] [Closed] (IGNITE-2257) Incorrect deserialization of BinaryContext.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2257.
---

> Incorrect deserialization of BinaryContext.
> ---
>
> Key: IGNITE-2257
> URL: https://issues.apache.org/jira/browse/IGNITE-2257
> Project: Ignite
>  Issue Type: Bug
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> 1) Initially BinaryContext was deserialized using grid name. This is 
> incorrect, because on the other side grid name might be different.
> {code}IgniteKernal g = IgnitionEx.gridx(gridName);{code}
> 2) Now it is deserialized using TLS grid name which depends on IgniteThread. 
> This is incorrect either because deserialization code might be invoked in 
> user thread.
> IgniteKernal g = IgnitionEx.localIgnite();
> Proposed fix: set TLS BinaryContext inside GridBinaryMarshaller when 
> deserialzation starts, and reset it afterwards.



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

[jira] [Updated] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2004:

Labels: important  (was: )

> Asynchronous execution of ContinuousQuery's remote filter
> -
>
> Key: IGNITE-2004
> URL: https://issues.apache.org/jira/browse/IGNITE-2004
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
>  Labels: important
> Fix For: 1.6
>
>
> Presently remote filters are executed synchronously an entry update. This 
> leads to the limitation when it's disallowed to perform cache related 
> operation in a filter body.
> It's required to add the ability to execute remote filters asynchronously. 
> This will let to execute any kind of operations including cache operations 
> directly in the filter body.
> The solution must be fault-tolerant. At least once execution of a filter in 
> case of a failure works fine. 



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

[jira] [Updated] (IGNITE-1403) forOldest() cluster group returns predicate that is not updated when topology changes

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1403:

Labels: important  (was: )

> forOldest() cluster group returns predicate that is not updated when topology 
> changes
> -
>
> Key: IGNITE-1403
> URL: https://issues.apache.org/jira/browse/IGNITE-1403
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>  Labels: important
>
> {{AgeClusterGroup}} that implements {{forOldest()}} and {{forYoungest}} 
> cluster groups is dynamically updated when topology changes. But the 
> predicate that can be acquired from this group via {{predicate()}} method is 
> static, which is incorrect.



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

[jira] [Updated] (IGNITE-1523) Need to always serialize user objects with configured marshaller

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1523:

Labels: important user-request  (was: user-request)

> Need to always serialize user objects with configured marshaller
> 
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
>  Labels: important, user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all 
> objects.



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

[jira] [Updated] (IGNITE-1186) Filter is sent instead of factory when continuous query is created

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1186:

Labels: important  (was: )

> Filter is sent instead of factory when continuous query is created
> --
>
> Key: IGNITE-1186
> URL: https://issues.apache.org/jira/browse/IGNITE-1186
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> {{CacheContinuousQueryHandler}}, which is sent to remote nodes on query 
> creation always contains {{CacheEntryEventSerializableFilter}}. This is OK 
> for our {{ContinuousQuery}} API, because it doesn't work with factories, but 
> not OK for JCache entry listener API. {{CacheEntryListenerConfiguration}} 
> contains factory and it's assumed that the filter is created on remote node 
> and is never sent through network. But we require the filter to be 
> {{Serializable}}.
> We need to always send factory instead of the filter. In case of 
> {{ContinuousQuery}} API we can use singleton factory that will wrap the 
> instance that already exist.



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

[jira] [Updated] (IGNITE-1979) Support case insensitive nonquoted cache names in SQL queries

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1979:

Labels: important  (was: )

> Support case insensitive nonquoted cache names in SQL queries
> -
>
> Key: IGNITE-1979
> URL: https://issues.apache.org/jira/browse/IGNITE-1979
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
>
> According to SQL ANSI-99 standard the schema name (corresponds to a cache 
> name in Ignite) is case insensitive.
> However Ignite has the requirement to put a cache name into the quotation 
> marks. This violates the standard.
> The main reasons of that is because a cache name in Ignite is case sensitive 
> and can contain all kind of symbols that are not supported by underlying H2 
> engine.
> Proposed to introduce a new configuration property to {{CacheConfiguration}} 
> that will let the end user use a cache name in case insensitive manner 
> without quoted identifiers in SQL queries.



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

[jira] [Updated] (IGNITE-426) Make sure continuous queries notifications are not missed in case primary node fails

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-426:
---
Labels: important  (was: )

> Make sure continuous queries notifications are not missed in case primary 
> node fails
> 
>
> Key: IGNITE-426
> URL: https://issues.apache.org/jira/browse/IGNITE-426
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Tikhonov
>Priority: Critical
>  Labels: important
> Fix For: 1.5
>
>
> * Maintain updates queue on backup node(s) in addition to primary node.
> * If primary node crushes, this queue is flushed to listening clients.
> * To avoid notification duplicates we will have a per-partition update 
> counter. Once an entry in some partition is updated, counter for this 
> partition is incremented on both primary and backups. The value of this 
> counter is also sent along with the update to the client, which also 
> maintains the copy of this mapping. If at some moment it receives an update 
> with the counter less than in its local map, this update is a duplicate and 
> can be discarded.
> * To cleanup the backup queue we will use communication acks. When batch 
> receival is acked by the client, we will send special ack message to backup 
> nodes that will remove items that are not longer needed. This message has to 
> contain partition to latest update counter map.



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

[jira] [Updated] (IGNITE-2213) Handle duplicate field names in BinaryMarshaller.

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2213:

Labels: important  (was: )

> Handle duplicate field names in BinaryMarshaller.
> -
>
> Key: IGNITE-2213
> URL: https://issues.apache.org/jira/browse/IGNITE-2213
> Project: Ignite
>  Issue Type: Bug
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
>  Labels: important
> Fix For: 1.5
>
>
> Consider the following scenario:
> {code}
> class A {
> int field;
> }
> class B : class A {
> int field;
> }
> {code}
> In this case BinaryMarshaller will throw an exception about duplicate field 
> names. And there is no sensible workaround for user. 
> We can add some prefix/suffix to comflicting fields. E.g. A.field will be 
> written as "field", B.field will be written as "field_B".



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

[jira] [Updated] (IGNITE-2266) Several examples fail with Optimized marshaller

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-2266:
--
Fix Version/s: (was: 1.5)
   1.6

> Several examples fail with Optimized marshaller
> ---
>
> Key: IGNITE-2266
> URL: https://issues.apache.org/jira/browse/IGNITE-2266
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: Apache Ignite 1.5.0.final build #128 
>Reporter: Vasilisa  Sidorova
> Fix For: 1.6
>
>
> -
> DESCRIPTION
> -
> CacheQueryExample and StreamVisitorExample fail if it's running with 
> Optimized marshaller (instead deafult Binary marshaller)
> -
> STEPS FOR REPRODUCE
> -
> # Build examples in IDE
> # Add property Into example-ignite.xml:
> {noformat}
> 
>  class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> 
> 
> 
> 
> 
> {noformat}
> # Run CacheQueryExample
> -
> ACTUAL RESULT
> -
> Example fails with exception:
> {noformat}
> [15:41:02,466][ERROR][sys-#31%null%][GridCacheDistributedQueryManager] 
>  Failed to run query [qry=GridCacheQueryInfo 
> [loc=false, trans=null, rdc=null, qry=GridCacheQueryAdapter [type=SCAN, 
> clsName=null, clause=null, 
> filter=o.a.i.examples.datagrid.CacheQueryExample$1@136abff1, part=null, 
> incMeta=false, metrics=null, pageSize=1024, timeout=0, keepAll=false, 
> incBackups=false, dedup=false, prj=null, keepBinary=true, 
> subjId=d4d84708-9109-4706-8454-5cbae2fff7bb, taskHash=0], locFut=null, 
> sndId=d4d84708-9109-4706-8454-5cbae2fff7bb, reqId=28, incMeta=false, 
> all=false], node=d4d84708-9109-4706-8454-5cbae2fff7bb]
> class org.apache.ignite.IgniteCheckedException: 
> org.apache.ignite.cache.affinity.AffinityKey cannot be cast to 
> org.apache.ignite.binary.BinaryObject
>   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7005)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:166)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$CachedResult.iterator(GridCacheQueryManager.java:2825)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1390)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:227)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$7.call(GridCacheDistributedQueryManager.java:764)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6397)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:929)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   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)
> Caused by: java.lang.ClassCastException: 
> org.apache.ignite.cache.affinity.AffinityKey cannot be cast to 
> org.apache.ignite.binary.BinaryObject
>   at 
> org.apache.ignite.examples.datagrid.CacheQueryExample$1.apply(CacheQueryExample.java:133)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.checkPredicate(GridCacheQueryManager.java:963)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.advance(GridCacheQueryManager.java:929)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.(GridCacheQueryManager.java:874)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.scanIterator(GridCacheQueryManager.java:829)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.executeQuery(GridCacheQueryManager.java:593)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.queryResult(GridCacheQueryManager.java:1687)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.queryResult(GridCacheQueryManager.java:1654)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1385)
>   ... 8 more
> 

[jira] [Closed] (IGNITE-2252) Add support for cache sql schema in REST topology command

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov closed IGNITE-2252.
-

> Add support for cache sql schema in REST topology command
> -
>
> Key: IGNITE-2252
> URL: https://issues.apache.org/jira/browse/IGNITE-2252
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kozlov
>Priority: Blocker
> Fix For: 1.5
>
>




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

[jira] [Comment Edited] (IGNITE-2265) Replace Atomic* variables with field updaters.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-2265 at 12/24/15 9:11 PM:
---

Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspots revealed by profiler. Some atomics are 
located inside our cache futures which are created on virually any cache 
operation. And in a simple benchmark with distributed cache GET, these Atomics* 
are responsible for 2-3% of all heap allocations  We can easily get rid of 
these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.


was (Author: vozerov):
Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspot which were revealed by profiler. Some 
atomics are located inside our cache futures which are created on virually any 
cache operation. And in a simple benchmark with distributed cache GET, these 
Atomics* are responsible for 2-3% of all heap allocations  We can easily get 
rid of these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.

> Replace Atomic* variables with field updaters.
> --
>
> Key: IGNITE-2265
> URL: https://issues.apache.org/jira/browse/IGNITE-2265
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Field updaters must be used instaed of the following classes:
> 1) AtomicInteger
> 2) AtomicLong
> 3) AtomicReference
> 4) If AtomicBoolean is met in some hot spaces, it must be replaced with (int 
> + updater) pair. 



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

[jira] [Comment Edited] (IGNITE-2265) Replace Atomic* variables with field updaters.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-2265 at 12/24/15 9:10 PM:
---

Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspot which were revealed by profiler. Some 
atomics are located inside our cache futures which are created on virually any 
cache operation. And in a simple benchmark with distributed cache GET, these 
Atomics* are responsible for 2-3% of all heap allocations  We can easily get 
rid of these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.


was (Author: vozerov):
Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to improve overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspot which were revealed by profiler. Some 
atomics are located inside our cache futures which are created on virually any 
cache operation. And in a simple benchmark with distributed cache GET, these 
Atomics* are responsible for 2-3% of all heap allocations  We can easily get 
rid of these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.

> Replace Atomic* variables with field updaters.
> --
>
> Key: IGNITE-2265
> URL: https://issues.apache.org/jira/browse/IGNITE-2265
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Field updaters must be used instaed of the following classes:
> 1) AtomicInteger
> 2) AtomicLong
> 3) AtomicReference
> 4) If AtomicBoolean is met in some hot spaces, it must be replaced with (int 
> + updater) pair. 



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

[jira] [Comment Edited] (IGNITE-2265) Replace Atomic* variables with field updaters.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-2265 at 12/24/15 9:11 PM:
---

Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspots revealed by profiler. Some atomics are 
located inside our cache futures which are created on virually any cache 
operation. And in a simple benchmark with distributed cache GET, these Atomics* 
are responsible for 2-3% of all heap allocations  We can easily get rid of 
these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtasks to the parent ticket IGNITE-2232.


was (Author: vozerov):
Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspots revealed by profiler. Some atomics are 
located inside our cache futures which are created on virually any cache 
operation. And in a simple benchmark with distributed cache GET, these Atomics* 
are responsible for 2-3% of all heap allocations  We can easily get rid of 
these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.

> Replace Atomic* variables with field updaters.
> --
>
> Key: IGNITE-2265
> URL: https://issues.apache.org/jira/browse/IGNITE-2265
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Field updaters must be used instaed of the following classes:
> 1) AtomicInteger
> 2) AtomicLong
> 3) AtomicReference
> 4) If AtomicBoolean is met in some hot spaces, it must be replaced with (int 
> + updater) pair. 



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

[jira] [Assigned] (IGNITE-2259) We need to support 'sqlSchema' property on SQL page

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-2259:
--

Assignee: Andrey Novikov

> We need to support 'sqlSchema' property on SQL page
> ---
>
> Key: IGNITE-2259
> URL: https://issues.apache.org/jira/browse/IGNITE-2259
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: 1.6
>
>




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

[jira] [Commented] (IGNITE-2265) Replace Atomic* variables with field updaters.

[Andrey Kornev (JIRA)]

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

Andrey Kornev commented on IGNITE-2265:
---

Vladimir,

Just out of curiosity (and for educational purposes) could you please provide 
some example(s) which demonstrate the benefit of such refactoring?

Thanks
Andrey

> Replace Atomic* variables with field updaters.
> --
>
> Key: IGNITE-2265
> URL: https://issues.apache.org/jira/browse/IGNITE-2265
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Field updaters must be used instaed of the following classes:
> 1) AtomicInteger
> 2) AtomicLong
> 3) AtomicReference
> 4) If AtomicBoolean is met in some hot spaces, it must be replaced with (int 
> + updater) pair. 



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

[jira] [Updated] (IGNITE-1626) .Net: Create NuGet package.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1626:
---
Description: 
*Overview*
To boost usage of the product we need to distribute it using NuGet, which is 
tightly integrated with Visual Studio.
To achieve this several technical, infrastructure and marketing tasks must be 
completed.

*Technical tasks*
- Apache Ignite.NET heavily depends on relative positions of compiled Java 
classes. We must be able to apply different classpath search strategies 
depending on packaging. This includes normal search in exploded build 
directory, search in NuGet package, search in local Maven repo.
- We need a way to select classpath search strategy. E.g. we can add special 
marker resource to NuGet package so that DLL understands that it is 
NuGet-based. More investigation here is reuqired.
- Minimal set of required JARs should be defined. Currently we have over >100Mb 
of Java libraries shipped with Ignite build. NuGet has limitation of 30Mb per 
package. Only vital subset of JARs should be shipped.
- Resulting package should be tested automatically on TC

*Infrastructure tasks*
- INFRA team must be asked about a place where NuGet package could be stored. 
- Separate build plan should be created, producing NuGet artifacts.

*Marketing tasks*
- We need to produce clean, selling and intriguing header and description for 
our package and attach logo.

  was:
*Overview*
To boost usage of the product we need to distribute it using NuGet, which is 
tightly integrated with Visual Studio.
To achieve this several technical, infrastructure and marketing tasks must be 
completed.

*Technical tasks*
- Apache Ignite.NET heavily depends on relative positions of compiled Java 
classes. We must be able to apply different classpath search strategies 
depending on packaging. This includes normal search in exploded build 
directory, search in NuGet package, search in local Maven repo.
- We need a way to select classpath search strategy. E.g. we can add special 
marker resource to NuGet package so that DLL understands that it is 
NuGet-based. More investigation here is reuqired.
- Minimal set of required JARs should be defined. Currently we have over >100Mb 
of Java libraries shipped with Ignite build. NuGet have limitation of 30Mb per 
package. Only vital subset of JARs should be shipped.

*Infrastructure tasks*
- INFRA team must be asked about a place where NuGet package could be stored. 
- Separate build plan should be created, producing NuGet artifacts.

*Marketing tasks*
- We need to produce clean, selling and intriguing header and description for 
our package and attach logo.


> .Net: Create NuGet package.
> ---
>
> Key: IGNITE-1626
> URL: https://issues.apache.org/jira/browse/IGNITE-1626
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> *Overview*
> To boost usage of the product we need to distribute it using NuGet, which is 
> tightly integrated with Visual Studio.
> To achieve this several technical, infrastructure and marketing tasks must be 
> completed.
> *Technical tasks*
> - Apache Ignite.NET heavily depends on relative positions of compiled Java 
> classes. We must be able to apply different classpath search strategies 
> depending on packaging. This includes normal search in exploded build 
> directory, search in NuGet package, search in local Maven repo.
> - We need a way to select classpath search strategy. E.g. we can add special 
> marker resource to NuGet package so that DLL understands that it is 
> NuGet-based. More investigation here is reuqired.
> - Minimal set of required JARs should be defined. Currently we have over 
> >100Mb of Java libraries shipped with Ignite build. NuGet has limitation of 
> 30Mb per package. Only vital subset of JARs should be shipped.
> - Resulting package should be tested automatically on TC
> *Infrastructure tasks*
> - INFRA team must be asked about a place where NuGet package could be stored. 
> - Separate build plan should be created, producing NuGet artifacts.
> *Marketing tasks*
> - We need to produce clean, selling and intriguing header and description for 
> our package and attach logo.



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

[jira] [Resolved] (IGNITE-2183) Broken UI after killing web agent

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2183.
--
Resolution: Cannot Reproduce
  Assignee: Pavel Konstantinov

Failed to reproduce with latest staging.
Could you retest one more time?

> Broken UI after killing web agent
> -
>
> Key: IGNITE-2183
> URL: https://issues.apache.org/jira/browse/IGNITE-2183
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
> Attachments: ig-2183.png
>
>
> Some time after I'm killing web agent I'm getting a broken UI (please see 
> attachment)



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

[jira] [Updated] (IGNITE-2257) Incorrect deserialization of BinaryContext.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2257:

Description: 
1) Initially BinaryContext was deserialized using grid name. This is incorrect, 
because on the other side grid name might be different.
{code}IgniteKernal g = IgnitionEx.gridx(gridName);{code}

2) Now it is deserialized using TLS grid name which depends on IgniteThread. 
This is incorrect either because deserialization code might be invoked in user 
thread.
IgniteKernal g = IgnitionEx.localIgnite();

Proposed fix: set TLS BinaryContext inside GridBinaryMarshaller when 
deserialzation starts, and reset it afterwards.


  was:
1) Initially BinaryContext was deserialized using grid name: 
{code}IgniteKernal g = IgnitionEx.gridx(gridName);


> Incorrect deserialization of BinaryContext.
> ---
>
> Key: IGNITE-2257
> URL: https://issues.apache.org/jira/browse/IGNITE-2257
> Project: Ignite
>  Issue Type: Bug
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> 1) Initially BinaryContext was deserialized using grid name. This is 
> incorrect, because on the other side grid name might be different.
> {code}IgniteKernal g = IgnitionEx.gridx(gridName);{code}
> 2) Now it is deserialized using TLS grid name which depends on IgniteThread. 
> This is incorrect either because deserialization code might be invoked in 
> user thread.
> IgniteKernal g = IgnitionEx.localIgnite();
> Proposed fix: set TLS BinaryContext inside GridBinaryMarshaller when 
> deserialzation starts, and reset it afterwards.



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

[jira] [Resolved] (IGNITE-2075) We must deny access to admin page to unauthorized users

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2075.
--
Resolution: Cannot Reproduce
  Assignee: Pavel Konstantinov

Failed to reproduce with incognito page in browser.

> We must deny access to admin page to unauthorized users
> ---
>
> Key: IGNITE-2075
> URL: https://issues.apache.org/jira/browse/IGNITE-2075
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> Currently user may open this page using direct link and see table header



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

[jira] [Updated] (IGNITE-2255) IgniteMqttStreamerTest.testConnectionStatusWithBrokerDisconnection fails

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-2255:
-
Assignee: Yakov Zhdanov

> IgniteMqttStreamerTest.testConnectionStatusWithBrokerDisconnection fails
> 
>
> Key: IGNITE-2255
> URL: https://issues.apache.org/jira/browse/IGNITE-2255
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Reporter: Semen Boikov
>Assignee: Yakov Zhdanov
>
> Test IgniteMqttStreamerTest.testConnectionStatusWithBrokerDisconnection fails 
> sometimes on TC. Also was able to reproduce locally.
> Sometimes fails assert 'assertTrue(streamer.isConnected());',
> Also locally got hang at test stop:
> {noformat}
> "main" prio=6 tid=0x01fca800 nid=0xd6c in Object.wait() 
> [0x0238e000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0x0007d75bedb0> (a java.lang.Object)
>   at java.lang.Object.wait(Object.java:503)
>   at 
> org.eclipse.paho.client.mqttv3.internal.Token.waitForResponse(Token.java:141)
>   - locked <0x0007d75bedb0> (a java.lang.Object)
>   at 
> org.eclipse.paho.client.mqttv3.internal.Token.waitForCompletion(Token.java:108)
>   at 
> org.eclipse.paho.client.mqttv3.MqttToken.waitForCompletion(MqttToken.java:63)
>   at 
> org.eclipse.paho.client.mqttv3.MqttClient.disconnect(MqttClient.java:254)
>   at 
> org.apache.ignite.stream.mqtt.MqttStreamer.stop(MqttStreamer.java:280)
>   at 
> org.apache.ignite.stream.mqtt.IgniteMqttStreamerTest.afterTest(IgniteMqttStreamerTest.java:159)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1362)
>   at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:391)
> {noformat}



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

[jira] [Created] (IGNITE-2257) Incorrect deserialization of BinaryContext.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2257:
---

 Summary: Incorrect deserialization of BinaryContext.
 Key: IGNITE-2257
 URL: https://issues.apache.org/jira/browse/IGNITE-2257
 Project: Ignite
  Issue Type: Bug
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Blocker
 Fix For: 1.5


1) Initially BinaryContext was deserialized using grid name: 
{code}IgniteKernal g = IgnitionEx.gridx(gridName);



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

[jira] [Closed] (IGNITE-1979) Support case insensitive nonquoted cache names in SQL queries

[Pavel Konstantinov (JIRA)]

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

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

Tested. Closed.

> Support case insensitive nonquoted cache names in SQL queries
> -
>
> Key: IGNITE-1979
> URL: https://issues.apache.org/jira/browse/IGNITE-1979
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 1.6
>
>
> According to SQL ANSI-99 standard the schema name (corresponds to a cache 
> name in Ignite) is case insensitive.
> However Ignite has the requirement to put a cache name into the quotation 
> marks. This violates the standard.
> The main reasons of that is because a cache name in Ignite is case sensitive 
> and can contain all kind of symbols that are not supported by underlying H2 
> engine.
> Proposed to introduce a new configuration property to {{CacheConfiguration}} 
> that will let the end user use a cache name in case insensitive manner 
> without quoted identifiers in SQL queries.



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

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 4:35 PM:
---

The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

{{SocketStreamerSelfTest}} failures aren't related with changes. It's probably 
environment problem:

{noformat}
{noformat}


was (Author: agura):
The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j  
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j  org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j  
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/
> 

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 4:37 PM:
---

The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

{{SocketStreamerSelfTest}} failures aren't related with changes. It's probably 
environment problem:

{noformat}
[08:35:02,751][INFO ][main][root] >>> Starting test: 
testDelimiterBasedCustomConverter <<<
class org.apache.ignite.IgniteCheckedException: Failed to initialize NIO 
selector.
at 
org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:648)
at 
org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:280)
at 
org.apache.ignite.internal.util.nio.GridNioServer.(GridNioServer.java:86)
at 
org.apache.ignite.internal.util.nio.GridNioServer$Builder.build(GridNioServer.java:2249)
at 
org.apache.ignite.stream.socket.SocketStreamer.start(SocketStreamer.java:183)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.test(SocketStreamerSelfTest.java:335)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.testDelimiterBasedCustomConverter(SocketStreamerSelfTest.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1699)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:116)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1637)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at 
org.apache.ignite.internal.util.nio.GridNioServer.createSelector(GridNioServer.java:632)
... 15 more

{noformat}


was (Author: agura):
The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

{{SocketStreamerSelfTest}} failures aren't related with changes. It's probably 
environment problem:

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.stream.socket.SocketStreamer.stop(SocketStreamer.java:207)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.test(SocketStreamerSelfTest.java:358)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.testDelimiterBasedCustomConverter(SocketStreamerSelfTest.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1699)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:116)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1637)
at 

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 4:36 PM:
---

The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

{{SocketStreamerSelfTest}} failures aren't related with changes. It's probably 
environment problem:

{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.stream.socket.SocketStreamer.stop(SocketStreamer.java:207)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.test(SocketStreamerSelfTest.java:358)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.testDelimiterBasedCustomConverter(SocketStreamerSelfTest.java:246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1699)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:116)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1637)
at java.lang.Thread.run(Thread.java:745)
[08:08:47,752][INFO ][main][root] >>> Stopping test: 
testDelimiterBasedCustomConverter in 78 ms <<<
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.81 sec <<< 
FAILURE! - in org.apache.ignite.stream.socket.SocketStreamerSelfTest
testDelimiterBasedCustomConverter(org.apache.ignite.stream.socket.SocketStreamerSelfTest)
  Time elapsed: 11.557 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.apache.ignite.stream.socket.SocketStreamer.stop(SocketStreamer.java:207)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.test(SocketStreamerSelfTest.java:358)
at 
org.apache.ignite.stream.socket.SocketStreamerSelfTest.testDelimiterBasedCustomConverter(SocketStreamerSelfTest.java:246)

{noformat}


was (Author: agura):
The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

{{SocketStreamerSelfTest}} failures aren't related with changes. It's probably 
environment problem:

{noformat}
{noformat}

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  

[jira] [Comment Edited] (IGNITE-1626) .Net: Create NuGet package.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-1626 at 12/24/15 4:43 PM:
--

Need to investigate how staging works in NuGet:
* There is a staging.nuget.org which is simply a mirror of nuget.org
* There is a pre-release mechanism: adding any kind of text after a dash '-' in 
[AssemblyInformationalVersion] will make such package pre-release, so it does 
not show up by default


was (Author: ptupitsyn):
Need to investigate how staging works in NuGet.

> .Net: Create NuGet package.
> ---
>
> Key: IGNITE-1626
> URL: https://issues.apache.org/jira/browse/IGNITE-1626
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> *Overview*
> To boost usage of the product we need to distribute it using NuGet, which is 
> tightly integrated with Visual Studio.
> To achieve this several technical, infrastructure and marketing tasks must be 
> completed.
> *Technical tasks*
> - Apache Ignite.NET heavily depends on relative positions of compiled Java 
> classes. We must be able to apply different classpath search strategies 
> depending on packaging. This includes normal search in exploded build 
> directory, search in NuGet package, search in local Maven repo.
> - We need a way to select classpath search strategy. E.g. we can add special 
> marker resource to NuGet package so that DLL understands that it is 
> NuGet-based. More investigation here is reuqired.
> - Minimal set of required JARs should be defined. Currently we have over 
> >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of 
> 30Mb per package. Only vital subset of JARs should be shipped.
> *Infrastructure tasks*
> - INFRA team must be asked about a place where NuGet package could be stored. 
> - Separate build plan should be created, producing NuGet artifacts.
> *Marketing tasks*
> - We need to produce clean, selling and intriguing header and description for 
> our package and attach logo.



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

[jira] [Updated] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2218:

Fix Version/s: 1.6

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> 

[jira] [Updated] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2218:

Component/s: hadoop

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

To the contrast, System.load() or System.loadLibrary() are called only form one 
place in Hadoop - NativeCodeLoader.

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

Location of native code library: 
https://github.com/apache/hadoop/tree/master/hadoop-common-project/hadoop-common/src/main/native

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> 

[jira] [Updated] (IGNITE-2260) Attempted to trust a non-string value in a content requiring a string: Context: html

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2260:
---
Attachment: ig-2260.png

> Attempted to trust a non-string value in a content requiring a string: 
> Context: html
> 
>
> Key: IGNITE-2260
> URL: https://issues.apache.org/jira/browse/IGNITE-2260
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
> Attachments: ig-2260.png
>
>
> Tried to load metadata from IBM DB2 (please see attachment for connection 
> params)
> {code}
> 18:20:09.734 "Error: [$sce:itype] Attempted to trust a non-string value in a 
> content requiring a string: Context: html
> http://errors.angularjs.org/1.4.8/$sce/itype?p0=html
> minErr/<@https://staging-console.gridgain.com/app.min.js:82686:18
> trustAs@https://staging-console.gridgain.com/app.min.js:90624:1
> @https://staging-console.gridgain.com/app.min.js:90708:22
> ModalFactory/<@https://staging-console.gridgain.com/app.min.js:56609:30
> forEach@https://staging-console.gridgain.com/app.min.js:82747:17
> ModalFactory@https://staging-console.gridgain.com/app.min.js:56607:13
> AlertFactory@https://staging-console.gridgain.com/app.min.js:57963:22
> showError@https://staging-console.gridgain.com/common-module.js:153:24
> _loadSchemas/<@https://staging-console.gridgain.com/all.js:2615:25
> $http/promise.error/<@https://staging-console.gridgain.com/app.min.js:86948:19
> processQueue@https://staging-console.gridgain.com/app.min.js:89708:34
> scheduleProcessQueue/<@https://staging-console.gridgain.com/app.min.js:89725:13
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90276:22
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90188:21
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90307:19
> done@https://staging-console.gridgain.com/app.min.js:87074:19
> completeRequest@https://staging-console.gridgain.com/app.min.js:87180:13
> requestLoaded@https://staging-console.gridgain.com/app.min.js:87145:15
> "1 app.min.js:87868:24
> consoleLog/<() app.min.js:87868
> $ExceptionHandlerProvider/this.$get processQueue() app.min.js:89716
> scheduleProcessQueue/<() app.min.js:89725
> $RootScopeProvider/this.$get $RootScopeProvider/this.$get $RootScopeProvider/this.$get done() app.min.js:87074
> completeRequest() app.min.js:87180
> requestLoaded() app.min.js:87145
> {code}



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

[jira] [Closed] (IGNITE-2174) Error with overwrite dialog on loading metadata from DB

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> Error with overwrite dialog on loading metadata from DB
> ---
>
> Key: IGNITE-2174
> URL: https://issues.apache.org/jira/browse/IGNITE-2174
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> To reproduce just try to load the same metadata twice.
> UI just hang, but should show confirm override dialog instead.



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

[jira] [Resolved] (IGNITE-647) org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-647.
-
Resolution: Fixed

Fixed in ignite-1.5 (commit 383f317).

> org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs
> --
>
> Key: IGNITE-647
> URL: https://issues.apache.org/jira/browse/IGNITE-647
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
>Priority: Blocker
>  Labels: Muted_test
> Fix For: 1.5
>
> Attachments: FairAffinityDynamicCacheSelfTest.testStartStopCache.txt, 
> threaddump.txt
>
>
> 1-2 runs out of ~10 local runs hanged for me



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

[jira] [Closed] (IGNITE-647) org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs

[Semen Boikov (JIRA)]

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

Semen Boikov closed IGNITE-647.
---
Assignee: (was: Semen Boikov)

> org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs
> --
>
> Key: IGNITE-647
> URL: https://issues.apache.org/jira/browse/IGNITE-647
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Priority: Blocker
>  Labels: Muted_test
> Fix For: 1.5
>
> Attachments: FairAffinityDynamicCacheSelfTest.testStartStopCache.txt, 
> threaddump.txt
>
>
> 1-2 runs out of ~10 local runs hanged for me



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

[jira] [Updated] (IGNITE-647) org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-647:

Fix Version/s: 1.5

> org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs
> --
>
> Key: IGNITE-647
> URL: https://issues.apache.org/jira/browse/IGNITE-647
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Assignee: Semen Boikov
>Priority: Blocker
>  Labels: Muted_test
> Fix For: 1.5
>
> Attachments: FairAffinityDynamicCacheSelfTest.testStartStopCache.txt, 
> threaddump.txt
>
>
> 1-2 runs out of ~10 local runs hanged for me



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

[jira] [Closed] (IGNITE-2227) Please add support of cache sql Schema on web console

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Please add support of cache sql Schema on web console
> -
>
> Key: IGNITE-2227
> URL: https://issues.apache.org/jira/browse/IGNITE-2227
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> https://issues.apache.org/jira/browse/IGNITE-1979



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

[jira] [Assigned] (IGNITE-1514) Platform .Net: Implement IIgnite.DestroyCache

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-1514:
--

Assignee: Pavel Tupitsyn

> Platform .Net: Implement IIgnite.DestroyCache
> -
>
> Key: IGNITE-1514
> URL: https://issues.apache.org/jira/browse/IGNITE-1514
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>
> Add and implement IIgnite.DestroyCache.



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

[jira] [Commented] (IGNITE-2252) Add support for cache sql schema in REST topology command

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2252:


Github user asfgit closed the pull request at:

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


> Add support for cache sql schema in REST topology command
> -
>
> Key: IGNITE-2252
> URL: https://issues.apache.org/jira/browse/IGNITE-2252
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kozlov
>Priority: Blocker
> Fix For: 1.5
>
>




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

[jira] [Commented] (IGNITE-2209) Some query tests fail with ClassCastException when BinaryMarshaller is enabled.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2209:


Github user asfgit closed the pull request at:

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


> Some query tests fail with ClassCastException when BinaryMarshaller is 
> enabled.
> ---
>
> Key: IGNITE-2209
> URL: https://issues.apache.org/jira/browse/IGNITE-2209
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 1.5
>
>
> *Problem*
> Sample stack trace:
> {code}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValue
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap(IgniteCacheAbstractQuerySelfTest.java:574)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1699)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:116)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1637)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> *Steps to reproduce*
> 1) Set BinaryMarshaller
> 2) Run IgniteCacheLocalQuerySelfTest
> 3) Observe failures due to class-cast in the following tests:
> - testArray
> - testObjectQueryWithSwap
> - testComplexType
> *Reason*
> Unknown; looks like we do not unwrap binary objects in some cases.



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

[jira] [Commented] (IGNITE-2200) CacheQueryExample failes after CacheClientBinaryQueryExample and vice versa

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2200:


Github user asfgit closed the pull request at:

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


> CacheQueryExample failes after CacheClientBinaryQueryExample and vice versa
> ---
>
> Key: IGNITE-2200
> URL: https://issues.apache.org/jira/browse/IGNITE-2200
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Blocker
> Fix For: 1.5
>
>
> 1. Start remote node with config examples/config/example-ignite.xml
> 2. Run CacheClientBinaryQueryExample. It passed
> 3. Run CacheQueryExample. It failes:
> {noformat}
> >>> Cache query example started.
> Exception in thread "main" javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Type ID collision detected 
> [id=1178922291, clsName1=org.apache.ignite.examples.model.Organization, 
> clsName2=org.apache.ignite.examples.model.binary.Organization]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1618)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1806)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1078)
>   at 
> org.apache.ignite.examples.datagrid.CacheQueryExample.initialize(CacheQueryExample.java:276)
>   at 
> org.apache.ignite.examples.datagrid.CacheQueryExample.main(CacheQueryExample.java:97)
>   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:134)
> Caused by: class org.apache.ignite.IgniteCheckedException: Type ID collision 
> detected [id=1178922291, 
> clsName1=org.apache.ignite.examples.model.Organization, 
> clsName2=org.apache.ignite.examples.model.binary.Organization]
>   at 
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:116)
>   at 
> org.apache.ignite.internal.MarshallerContextAdapter.registerClass(MarshallerContextAdapter.java:157)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:576)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:555)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:457)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:145)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:132)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:225)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:438)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:777)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:724)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1798)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.mapSingleUpdate(GridNearAtomicUpdateFuture.java:1137)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:868)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:418)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:284)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$18.apply(GridDhtAtomicCache.java:924)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$18.apply(GridDhtAtomicCache.java:922)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:699)
>   at 
> 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

Library to intercept native calls: https://code.google.com/p/native-intercept/

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

Some info on native methods instrumentation: 
http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/Instrumentation.html#setNativeMethodPrefix-java.lang.instrument.ClassFileTransformer-java.lang.String-

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> 

[jira] [Updated] (IGNITE-2183) Broken UI after killing web agent

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2183:
---
Fix Version/s: (was: 1.6)
   1.7

> Broken UI after killing web agent
> -
>
> Key: IGNITE-2183
> URL: https://issues.apache.org/jira/browse/IGNITE-2183
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.7
>
> Attachments: ig-2183.png
>
>
> Some time after I'm killing web agent I'm getting a broken UI (please see 
> attachment)



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

[jira] [Reopened] (IGNITE-2183) Broken UI after killing web agent

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reopened IGNITE-2183:


> Broken UI after killing web agent
> -
>
> Key: IGNITE-2183
> URL: https://issues.apache.org/jira/browse/IGNITE-2183
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.7
>
> Attachments: ig-2183.png
>
>
> Some time after I'm killing web agent I'm getting a broken UI (please see 
> attachment)



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

[jira] [Commented] (IGNITE-2183) Broken UI after killing web agent

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-2183:


Need more time to investigation

> Broken UI after killing web agent
> -
>
> Key: IGNITE-2183
> URL: https://issues.apache.org/jira/browse/IGNITE-2183
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.7
>
> Attachments: ig-2183.png
>
>
> Some time after I'm killing web agent I'm getting a broken UI (please see 
> attachment)



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

[jira] [Created] (IGNITE-2259) We need to support 'sqlSchema' property on SQL page

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2259:
--

 Summary: We need to support 'sqlSchema' property on SQL page
 Key: IGNITE-2259
 URL: https://issues.apache.org/jira/browse/IGNITE-2259
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov






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

[jira] [Updated] (IGNITE-2262) Add collecting of BinaryConfiguration to Visor collector tasks.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2262:
-
Description: And add display of collected infor in Visor console.

> Add collecting of BinaryConfiguration to Visor collector tasks.
> ---
>
> Key: IGNITE-2262
> URL: https://issues.apache.org/jira/browse/IGNITE-2262
> Project: Ignite
>  Issue Type: Task
>  Components: UI
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
> Fix For: 1.6
>
>
> And add display of collected infor in Visor console.



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

[jira] [Closed] (IGNITE-2250) Client section on Summary contains ServerConfigurationFactory java class

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> Client section on Summary contains ServerConfigurationFactory java class
> 
>
> Key: IGNITE-2250
> URL: https://issues.apache.org/jira/browse/IGNITE-2250
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> Should contain ClientConfigurationFactory



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

[jira] [Closed] (IGNITE-2075) We must deny access to admin page to unauthorized users

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> We must deny access to admin page to unauthorized users
> ---
>
> Key: IGNITE-2075
> URL: https://issues.apache.org/jira/browse/IGNITE-2075
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> Currently user may open this page using direct link and see table header



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

[jira] [Updated] (IGNITE-2252) Add support for cache sql schema in REST topology command

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-2252:
---
Assignee: Sergey Kozlov  (was: Semen Boikov)

> Add support for cache sql schema in REST topology command
> -
>
> Key: IGNITE-2252
> URL: https://issues.apache.org/jira/browse/IGNITE-2252
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kozlov
>Priority: Blocker
> Fix For: 1.5
>
>




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

[jira] [Comment Edited] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-2218 at 12/24/15 11:02 AM:


This appears to be a very generic problem - none native methods can be used 
from our HadoopClassLoader. 
Here some explanation from a veeery old Sun ticket: 
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4225434

Affected Hadoop classes:
{code}
org.apache.hadoop.crypto.OpensslCipher
org.apache.hadoop.crypto.random.OpensslSecureRandom

org.apache.hadoop.io.compress.bzip2.Bzip2Compressor
org.apache.hadoop.io.compress.bzip2.Bzip2Decompressor
org.apache.hadoop.io.compress.lz4.Lz4Compressor
org.apache.hadoop.io.compress.lz4.Lz4Decompressor
org.apache.hadoop.io.compress.snappy.SnappyCompressor
org.apache.hadoop.io.compress.snappy.SnappyDecompressor
org.apache.hadoop.io.compress.zlib.ZlibCompressor
org.apache.hadoop.io.compress.zlib.ZlibDecompressor

org.apache.hadoop.io.nativeio.NativeIO
org.apache.hadoop.io.nativeio.SharedFileDescriptorFactory

org.apache.hadoop.net.unix.DomainSocket
org.apache.hadoop.net.unix.DomainSocketWatcher

org.apache.hadoop.security.JniBasedUnixGroupsMapping
org.apache.hadoop.security.JniBasedUnixGroupsNetgroupMapping

org.apache.hadoop.util.NativeCodeLoader
org.apache.hadoop.util.NativeCrc32
{code}

Some of then have fallback Java code, some don't.


was (Author: vozerov):
This appears to be a very generic problem - none native methods can be used 
from our HadoopClassLoader. 
Here some explanation from a veeery old Sun ticket: 
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4225434

Affected Hadoop classes:
{code}
org.apache.hadoop.crypto.OpensslCipher
org.apache.hadoop.crypto.random.OpensslSecureRandom

org.apache.hadoop.io.compress.bzip2.Bzip2Compressor
org.apache.hadoop.io.compress.bzip2.Bzip2Decompressor
org.apache.hadoop.io.compress.lz4.Lz4Compressor
org.apache.hadoop.io.compress.lz4.Lz4Decompressor
org.apache.hadoop.io.compress.snappy.SnappyCompressor
org.apache.hadoop.io.compress.snappy.SnappyDecompressor
org.apache.hadoop.io.compress.zlib.ZlibCompressor
org.apache.hadoop.io.compress.zlib.ZlibDecompressor

org.apache.hadoop.io.nativeio.NativeIO
org.apache.hadoop.io.nativeio.SharedFileDescriptorFactory

org.apache.hadoop.net.unix.DomainSocket
org.apache.hadoop.net.unix.DomainSocketWatcher

org.apache.hadoop.security.JniBasedUnixGroupsMapping
org.apache.hadoop.security.JniBasedUnixGroupsNetgroupMapping

org.apache.hadoop.util.NativeCodeLoader
org.apache.hadoop.util.NativeCrc32
{code}

Some of then has fallback Java code, some don't.

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

This appears to be a very generic problem - none native methods can be used 
from our HadoopClassLoader. 
Here some explanation from a veeery old Sun ticket: 
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4225434

Affected Hadoop classes:
{code}
org.apache.hadoop.crypto.OpensslCipher
org.apache.hadoop.crypto.random.OpensslSecureRandom

org.apache.hadoop.io.compress.bzip2.Bzip2Compressor
org.apache.hadoop.io.compress.bzip2.Bzip2Decompressor
org.apache.hadoop.io.compress.lz4.Lz4Compressor
org.apache.hadoop.io.compress.lz4.Lz4Decompressor
org.apache.hadoop.io.compress.snappy.SnappyCompressor
org.apache.hadoop.io.compress.snappy.SnappyDecompressor
org.apache.hadoop.io.compress.zlib.ZlibCompressor
org.apache.hadoop.io.compress.zlib.ZlibDecompressor

org.apache.hadoop.io.nativeio.NativeIO
org.apache.hadoop.io.nativeio.SharedFileDescriptorFactory

org.apache.hadoop.net.unix.DomainSocket
org.apache.hadoop.net.unix.DomainSocketWatcher

org.apache.hadoop.security.JniBasedUnixGroupsMapping
org.apache.hadoop.security.JniBasedUnixGroupsNetgroupMapping

org.apache.hadoop.util.NativeCodeLoader
org.apache.hadoop.util.NativeCrc32
{code}

Some of then has fallback Java code, some don't.

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

One alternate idea: 
1) Always delegate to NativeCodeLoader in parent classloader to ensure that 
library is loaded only once (we already did that).
2) To ensure linkage:
- Implement our own JNI library with the same methods, which will delegate to 
already loaded DLL.
- Load this library using parent classloader.
- When one of the affected classes are loaded by HadoopClassLoader, go to JNI 
and call "registerNatives" from there which will link methods of our classes to 
Hadoop library.

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> 

[jira] [Commented] (IGNITE-2218) Ignite nodes cannot run Hadoop native code (e.g. snappy)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2218:
-

Resurrection of external execution might also do the trick, but as I remember 
it contained some other serious architecture flaws which prevented us from 
making it operational again.

> Ignite nodes cannot run Hadoop native code (e.g. snappy)
> 
>
> Key: IGNITE-2218
> URL: https://issues.apache.org/jira/browse/IGNITE-2218
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Blocker
> Fix For: 1.6
>
>
> Mapreduce tasks fail with the following exception:
> {code}
> class org.apache.ignite.IgniteCheckedException: class 
> org.apache.ignite.IgniteCheckedException: native snappy library not 
> available: this version of libhadoop was built without snappy support.
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:105)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2Task.run(HadoopV2Task.java:54)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:249)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.runAsJobOwner(HadoopV2TaskContext.java:548)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call(HadoopRunnableTask.java:46)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopExecutorService$2.body(HadoopExecutorService.java:186)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: native snappy library not available: 
> this version of libhadoop was built without snappy support.
> at 
> org.apache.hadoop.io.compress.SnappyCodec.checkNativeCodeLoaded(SnappyCodec.java:65)
> at 
> org.apache.hadoop.io.compress.SnappyCodec.getDecompressorType(SnappyCodec.java:193)
> at org.apache.hadoop.io.compress.CodecPool.getDecompressor(CodecPool.java:178)
> at 
> org.apache.hadoop.mapreduce.lib.input.LineRecordReader.initialize(LineRecordReader.java:90)
> at 
> com.splunk.mr.input.SplunkLineRecordReader.vixInitialize(SplunkLineRecordReader.java:17)
> at 
> com.splunk.mr.input.BaseSplunkRecordReader.initialize(BaseSplunkRecordReader.java:95)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:66)
> at 
> com.splunk.mr.JobSubmitterInputFormat.createRecordReader(JobSubmitterInputFormat.java:21)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2MapTask.run0(HadoopV2MapTask.java:74)
> ... 16 more
> at 
> org.apache.ignite.internal.processors.hadoop.HadoopUtils.transformException(HadoopUtils.java:290)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext.run(HadoopV2TaskContext.java:255)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.runTask(HadoopRunnableTask.java:201)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask.call0(HadoopRunnableTask.java:144)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:116)
> at 
> org.apache.ignite.internal.processors.hadoop.taskexecutor.HadoopRunnableTask$1.call(HadoopRunnableTask.java:114)
> at 
> org.apache.ignite.internal.processors.hadoop.v2.HadoopV2TaskContext$1.run(HadoopV2TaskContext.java:550)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> 

[jira] [Updated] (IGNITE-2260) Attempted to trust a non-string value in a content requiring a string: Context: html

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2260:
---
Description: 
Tried to load metadata from IBM DB2 (please see attachment for connection 
params)
{code}
18:20:09.734 "Error: [$sce:itype] Attempted to trust a non-string value in a 
content requiring a string: Context: html
http://errors.angularjs.org/1.4.8/$sce/itype?p0=html
minErr/<@https://staging-console.gridgain.com/app.min.js:82686:18
trustAs@https://staging-console.gridgain.com/app.min.js:90624:1
@https://staging-console.gridgain.com/app.min.js:90708:22
ModalFactory/<@https://staging-console.gridgain.com/app.min.js:56609:30
forEach@https://staging-console.gridgain.com/app.min.js:82747:17
ModalFactory@https://staging-console.gridgain.com/app.min.js:56607:13
AlertFactory@https://staging-console.gridgain.com/app.min.js:57963:22
showError@https://staging-console.gridgain.com/common-module.js:153:24
_loadSchemas/<@https://staging-console.gridgain.com/all.js:2615:25
$http/promise.error/<@https://staging-console.gridgain.com/app.min.js:86948:19
processQueue@https://staging-console.gridgain.com/app.min.js:89708:34
scheduleProcessQueue/<@https://staging-console.gridgain.com/app.min.js:89725:13
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90276:22
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90188:21
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90307:19
done@https://staging-console.gridgain.com/app.min.js:87074:19
completeRequest@https://staging-console.gridgain.com/app.min.js:87180:13
requestLoaded@https://staging-console.gridgain.com/app.min.js:87145:15
"1 app.min.js:87868:24
consoleLog/<() app.min.js:87868
$ExceptionHandlerProvider/this.$gethttp://errors.angularjs.org/1.4.8/$sce/itype?p0=html
minErr/<@https://staging-console.gridgain.com/app.min.js:82686:18
trustAs@https://staging-console.gridgain.com/app.min.js:90624:1
@https://staging-console.gridgain.com/app.min.js:90708:22
ModalFactory/<@https://staging-console.gridgain.com/app.min.js:56609:30
forEach@https://staging-console.gridgain.com/app.min.js:82747:17
ModalFactory@https://staging-console.gridgain.com/app.min.js:56607:13
AlertFactory@https://staging-console.gridgain.com/app.min.js:57963:22
showError@https://staging-console.gridgain.com/common-module.js:153:24
_loadSchemas/<@https://staging-console.gridgain.com/all.js:2615:25
$http/promise.error/<@https://staging-console.gridgain.com/app.min.js:86948:19
processQueue@https://staging-console.gridgain.com/app.min.js:89708:34
scheduleProcessQueue/<@https://staging-console.gridgain.com/app.min.js:89725:13
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90276:22
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90188:21
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90307:19
done@https://staging-console.gridgain.com/app.min.js:87074:19
completeRequest@https://staging-console.gridgain.com/app.min.js:87180:13
requestLoaded@https://staging-console.gridgain.com/app.min.js:87145:15
"1 app.min.js:87868:24
consoleLog/<() app.min.js:87868
$ExceptionHandlerProvider/this.$get Attempted to trust a non-string value in a content requiring a string: 
> Context: html
> 
>
> Key: IGNITE-2260
> URL: https://issues.apache.org/jira/browse/IGNITE-2260
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> Tried to load metadata from IBM DB2 (please see attachment for connection 
> params)
> {code}
> 18:20:09.734 "Error: [$sce:itype] Attempted to trust a non-string value in a 
> content requiring a string: Context: html
> http://errors.angularjs.org/1.4.8/$sce/itype?p0=html
> minErr/<@https://staging-console.gridgain.com/app.min.js:82686:18
> trustAs@https://staging-console.gridgain.com/app.min.js:90624:1
> @https://staging-console.gridgain.com/app.min.js:90708:22
> ModalFactory/<@https://staging-console.gridgain.com/app.min.js:56609:30
> forEach@https://staging-console.gridgain.com/app.min.js:82747:17
> ModalFactory@https://staging-console.gridgain.com/app.min.js:56607:13
> AlertFactory@https://staging-console.gridgain.com/app.min.js:57963:22
> showError@https://staging-console.gridgain.com/common-module.js:153:24
> _loadSchemas/<@https://staging-console.gridgain.com/all.js:2615:25
> $http/promise.error/<@https://staging-console.gridgain.com/app.min.js:86948:19
> processQueue@https://staging-console.gridgain.com/app.min.js:89708:34
> scheduleProcessQueue/<@https://staging-console.gridgain.com/app.min.js:89725:13
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90276:22
> 

[jira] [Commented] (IGNITE-2154) .NET: doxygen docs generation must be included into Maven build process.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-2154:
--

Roman, 
can I ask you to make suggestion to this page, with changes you described?

> .NET: doxygen docs generation must be included into Maven build process.
> 
>
> Key: IGNITE-2154
> URL: https://issues.apache.org/jira/browse/IGNITE-2154
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>




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

[jira] [Created] (IGNITE-2261) .Net: Connector configuration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2261:
--

 Summary: .Net: Connector configuration
 Key: IGNITE-2261
 URL: https://issues.apache.org/jira/browse/IGNITE-2261
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.6


Implement IgniteConfiguration.ConnectorConfiguration in code.
Add IgniteConfiguration.LocalHost property.



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

[jira] [Created] (IGNITE-2262) Add collecting of BinaryConfiguration to Visor collector tasks.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-2262:


 Summary: Add collecting of BinaryConfiguration to Visor collector 
tasks.
 Key: IGNITE-2262
 URL: https://issues.apache.org/jira/browse/IGNITE-2262
 Project: Ignite
  Issue Type: Task
  Components: UI
Affects Versions: 1.5
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
Priority: Trivial
 Fix For: 1.6






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

[jira] [Commented] (IGNITE-647) org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-647:
-

Found that one race still exists if cache with fair affinity is statically 
configured and multiple nodes start concurrently. If oldest node did not start 
cache yet inside onKernalStart, but next node already started exchange then 
GridDhtAffinityAssignmentRequest  is lost.

> org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs
> --
>
> Key: IGNITE-647
> URL: https://issues.apache.org/jira/browse/IGNITE-647
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Priority: Blocker
>  Labels: Muted_test
> Fix For: 1.6
>
> Attachments: FairAffinityDynamicCacheSelfTest.testStartStopCache.txt, 
> threaddump.txt
>
>
> 1-2 runs out of ~10 local runs hanged for me



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

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

[Vladimir Ershov (JIRA)]

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

Vladimir Ershov resolved IGNITE-2168.
-
Resolution: Fixed

> 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
>Reporter: Sergey Kozlov
>Assignee: Vladimir Ershov
> Fix For: 1.6
>
>
> 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 
> 

[jira] [Closed] (IGNITE-2261) .Net: Localhost configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn closed IGNITE-2261.
--

> .Net: Localhost configuration
> -
>
> Key: IGNITE-2261
> URL: https://issues.apache.org/jira/browse/IGNITE-2261
> Project: Ignite
>  Issue Type: Sub-task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Add IgniteConfiguration.LocalHost property.



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

[jira] [Updated] (IGNITE-647) org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-647:

Fix Version/s: (was: 1.5)
   1.6

> org.apache.ignite.IgniteCacheAffinitySelfTest.testAffinity() hangs
> --
>
> Key: IGNITE-647
> URL: https://issues.apache.org/jira/browse/IGNITE-647
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Priority: Blocker
>  Labels: Muted_test
> Fix For: 1.6
>
> Attachments: FairAffinityDynamicCacheSelfTest.testStartStopCache.txt, 
> threaddump.txt
>
>
> 1-2 runs out of ~10 local runs hanged for me



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

[jira] [Commented] (IGNITE-1514) Platform .Net: Implement IIgnite.DestroyCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1514:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1514 Platform .Net: Implement IIgnite.DestroyCache



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

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

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

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


commit bc2a95b9a2ee9308eec12344cb3f2ee9e4bcec67
Author: Pavel Tupitsyn 
Date:   2015-12-24T11:20:20Z

IGNITE-1514 Platform .Net: Implement IIgnite.DestroyCache

commit c7bc0fb45c70ddca4e4ddae6dc1cc23f5a77be9b
Author: Pavel Tupitsyn 
Date:   2015-12-24T11:59:47Z

CPP interop done

commit 68ce8c06c8ac2cc08661f64890b390081d659a4c
Author: Pavel Tupitsyn 
Date:   2015-12-24T12:01:37Z

Java done

commit 0ed1e49cb9a740310b6122c961d3e4d9d3483eba
Author: Pavel Tupitsyn 
Date:   2015-12-24T13:06:24Z

Test added

commit 6f09f9d91fa8bfc2b38805715b75ba9e3e20ab9b
Author: Pavel Tupitsyn 
Date:   2015-12-24T13:07:06Z

Fix cpp exports

commit 33117d6a9bcafff7ec1e784381510afbd3cb5fba
Author: Pavel Tupitsyn 
Date:   2015-12-24T13:08:47Z

test fixed




> Platform .Net: Implement IIgnite.DestroyCache
> -
>
> Key: IGNITE-1514
> URL: https://issues.apache.org/jira/browse/IGNITE-1514
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>
> Add and implement IIgnite.DestroyCache.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2168:


Github user asfgit closed the pull request at:

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


> 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
>Reporter: Sergey Kozlov
>Assignee: Vladimir Ershov
> Fix For: 1.6
>
>
> 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 
> 

[jira] [Updated] (IGNITE-2261) .Net: Localhost configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2261:
---
Description: Add IgniteConfiguration.LocalHost property.  (was: Implement 
IgniteConfiguration.ConnectorConfiguration in code.
Add IgniteConfiguration.LocalHost property.)

> .Net: Localhost configuration
> -
>
> Key: IGNITE-2261
> URL: https://issues.apache.org/jira/browse/IGNITE-2261
> Project: Ignite
>  Issue Type: Sub-task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Add IgniteConfiguration.LocalHost property.



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

[jira] [Updated] (IGNITE-2261) .Net: Localhost configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2261:
---
Summary: .Net: Localhost configuration  (was: .Net: Connector configuration)

> .Net: Localhost configuration
> -
>
> Key: IGNITE-2261
> URL: https://issues.apache.org/jira/browse/IGNITE-2261
> Project: Ignite
>  Issue Type: Sub-task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Implement IgniteConfiguration.ConnectorConfiguration in code.
> Add IgniteConfiguration.LocalHost property.



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

[jira] [Resolved] (IGNITE-2261) .Net: Localhost configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-2261.

Resolution: Done

> .Net: Localhost configuration
> -
>
> Key: IGNITE-2261
> URL: https://issues.apache.org/jira/browse/IGNITE-2261
> Project: Ignite
>  Issue Type: Sub-task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Add IgniteConfiguration.LocalHost property.



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

[jira] [Updated] (IGNITE-1957) .Net: Collections, dictionaries, object arrays and tuples must use handles.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1957:
---
Summary: .Net: Collections, dictionaries, object arrays and tuples must use 
handles.  (was: .NET: Collections, dictionaries, object arrays and tuples must 
use handles.)

> .Net: Collections, dictionaries, object arrays and tuples must use handles.
> ---
>
> Key: IGNITE-1957
> URL: https://issues.apache.org/jira/browse/IGNITE-1957
> Project: Ignite
>  Issue Type: Bug
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> We must track handles for the following cases:
> - Collections
> - Dictionaries
> - Entries
> - Object arrays
> Reason: they may have cyclic deps on other collections what will lead to 
> infinite loops.
> This change must be tested thoroughly:
> 1) Can we get such field which is handle?
> 2) Can we resolve infinite loops with collections/maps/arrays?
> 3) Are they referential equal after deserialization?



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

[jira] [Assigned] (IGNITE-1419) .Net: Add optional "raw" flag to portable type descriptor.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-1419:
--

Assignee: Pavel Tupitsyn

> .Net: Add optional "raw" flag to portable type descriptor.
> --
>
> Key: IGNITE-1419
> URL: https://issues.apache.org/jira/browse/IGNITE-1419
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>
> By default we write .Net objects with field names included. But in some cases 
> it is not needed. E.g. when objects are not going to be used in queries.
> Removing field names will speed up serialization/deserialization. We can add 
> optional "raw" flag to portable type descriptor to control this behavior.



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

[jira] [Updated] (IGNITE-2228) .Net: Ensure async Task can be cancelled.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2228:
---
Summary: .Net: Ensure async Task can be cancelled.  (was: .NET: Ensure 
async Task can be cancelled.)

> .Net: Ensure async Task can be cancelled.
> -
>
> Key: IGNITE-2228
> URL: https://issues.apache.org/jira/browse/IGNITE-2228
> Project: Ignite
>  Issue Type: Bug
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> Java has IgniteFuture.cancel() method. Depending on the context, it perofrms 
> different things. From no-op to task/closure cancellation. 
> We need to ensure that TPL infrastructure in .NET is able to propagate 
> cancellation to Java future.



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

[jira] [Updated] (IGNITE-1514) .Net: Implement IIgnite.DestroyCache

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1514:
---
Summary: .Net: Implement IIgnite.DestroyCache  (was: Platform .Net: 
Implement IIgnite.DestroyCache)

> .Net: Implement IIgnite.DestroyCache
> 
>
> Key: IGNITE-1514
> URL: https://issues.apache.org/jira/browse/IGNITE-1514
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>
> Add and implement IIgnite.DestroyCache.



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

[jira] [Assigned] (IGNITE-1626) .Net: Create NuGet package.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-1626:
--

Assignee: Pavel Tupitsyn  (was: Vladimir Ozerov)

> .Net: Create NuGet package.
> ---
>
> Key: IGNITE-1626
> URL: https://issues.apache.org/jira/browse/IGNITE-1626
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.5
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> *Overview*
> To boost usage of the product we need to distribute it using NuGet, which is 
> tightly integrated with Visual Studio.
> To achieve this several technical, infrastructure and marketing tasks must be 
> completed.
> *Technical tasks*
> - Apache Ignite.NET heavily depends on relative positions of compiled Java 
> classes. We must be able to apply different classpath search strategies 
> depending on packaging. This includes normal search in exploded build 
> directory, search in NuGet package, search in local Maven repo.
> - We need a way to select classpath search strategy. E.g. we can add special 
> marker resource to NuGet package so that DLL understands that it is 
> NuGet-based. More investigation here is reuqired.
> - Minimal set of required JARs should be defined. Currently we have over 
> >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of 
> 30Mb per package. Only vital subset of JARs should be shipped.
> *Infrastructure tasks*
> - INFRA team must be asked about a place where NuGet package could be stored. 
> - Separate build plan should be created, producing NuGet artifacts.
> *Marketing tasks*
> - We need to produce clean, selling and intriguing header and description for 
> our package and attach logo.



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

[jira] [Created] (IGNITE-2263) Get rif of wrapping views where possible.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2263:
---

 Summary: Get rif of wrapping views where possible.
 Key: IGNITE-2263
 URL: https://issues.apache.org/jira/browse/IGNITE-2263
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


We have about ~50-100 usages of things like F.view or F.viewReadOnly. In lots 
cases it is not necessary, adds garbage, but doesn't add any value. 
Need to revisit these places.



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

[jira] [Commented] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-2080:
-

The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j  
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j  org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j  
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/
> cache/distributed/dht/atomic/GridNearAtomicUpdateRequest;Lorg/apache/ignite/internal/util/typedef/CI2;)V+1023
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/c
> ache/distributed/dht/atomic/GridNearAtomicUpdateRequest;Lorg/apache/ignite/internal/util/typedef/CI2;)V+33
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/cache/
> distributed/dht/atomic/GridNearAtomicUpdateRequest;)V+28
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1200(Lorg/apache/ignite/internal/processors/cache/distributed/dh
> t/atomic/GridNearAtomicUpdateFuture;Ljava/util/UUID;Lorg/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateRequest;)V+3

[jira] [Created] (IGNITE-2264) Optimize GridDistributedTxMapping.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2264:
---

 Summary: Optimize GridDistributedTxMapping.
 Key: IGNITE-2264
 URL: https://issues.apache.org/jira/browse/IGNITE-2264
 Project: Ignite
  Issue Type: Sub-task
  Components: cache
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


This class has two methods: reads() and writes(). Together they return the 
whole set of entries. 
The problem is that each call creates collection wrapper over entries + 1 
additional iterator per each traverse over collection. This seen as a garbage 
"hotspot" in flight recorder.

Actually there is no need for these methods. Instead, we can pass entries 
collection directly and filter entries manually.



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

[jira] [Created] (IGNITE-2265) Replace Atomic* variables with field updaters.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2265:
---

 Summary: Replace Atomic* variables with field updaters.
 Key: IGNITE-2265
 URL: https://issues.apache.org/jira/browse/IGNITE-2265
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6


Field updaters must be used instaed of the following classes:
1) AtomicInteger
2) AtomicLong
3) AtomicReference
4) If AtomicBoolean is met in some hot spaces, it must be replaced with (int + 
updater) pair. 



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

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 3:16 PM:
---

`GridUnsafeMap` is fixed. But the following tests fail under Solaris:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OptimizedObjectStreamSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridEmbeddedFutureSelfTest}}
  * {{SocketStreamerSelfTest}}
  * {{GridCacheAbstractReduceFieldsQuerySelfTest.testIncludeBackups}}
  * {{GridCacheSwapScanQuerySelfTest}}

Failures don't related with JVM crash. Need to investigate.


was (Author: agura):
`GridUnsafeMap` is fixed. But the following tests fail under Solaris:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OptimizedObjectStreamSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridEmbeddedFutureSelfTest}}
  * {{SocketStreamerSelfTest}}
  * {{GridCacheAbstractReduceFieldsQuerySelfTest.testIncludeBackups}}
  * {{GridCacheSwapScanQuerySelfTest}}

Failures don't related with JVM crash. Need to investigate.

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j  
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j  org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j  
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j  
> 

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 3:17 PM:
---

The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}


was (Author: agura):
The problem with endianness found in `GridUnsafeMemory.compare` method. Fixed. 
The following test are passed now:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridCacheSwapScanQuerySelfTest}}

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j  
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j  org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j  
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/
> cache/distributed/dht/atomic/GridNearAtomicUpdateRequest;Lorg/apache/ignite/internal/util/typedef/CI2;)V+1023
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/c
> 

[jira] [Comment Edited] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-2080 at 12/24/15 3:19 PM:
---

`GridUnsafeMap` is fixed. But the following tests fail under Solaris:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OptimizedObjectStreamSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridEmbeddedFutureSelfTest}}
  * {{SocketStreamerSelfTest}}
  * {{GridCacheAbstractReduceFieldsQuerySelfTest.testIncludeBackups}}
  * {{GridCacheSwapScanQuerySelfTest}}
  * {{GridCacheValueBytesPreloadingSelfTest}}

Failures don't related with JVM crash. Need to investigate.


was (Author: agura):
`GridUnsafeMap` is fixed. But the following tests fail under Solaris:

  * {{GridCacheMemoryModeBinarySelfTest.testOffheapSwap}}
  * {{GridCacheMemoryModeBinarySelfTest.testTiered}}
  * {{GridCacheP2PUndeploySelfTest.testOffHeapP2PReplicated}} and other offheap 
related tests
  * {{GridUnsafeMemorySelfTest}}
  * {{GridUnsafeMapSelfTest}}
  * {{GridCacheMemoryModeSelfTest}}
  * {{GridUnsafePartitionedMapSelfTest}}
  * {{OptimizedObjectStreamSelfTest}}
  * {{OffHeapTieredTransactionSelfTest}}
  * {{GridEmbeddedFutureSelfTest}}
  * {{SocketStreamerSelfTest}}
  * {{GridCacheAbstractReduceFieldsQuerySelfTest.testIncludeBackups}}
  * {{GridCacheSwapScanQuerySelfTest}}

Failures don't related with JVM crash. Need to investigate.

> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]  
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties, 
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode 
> solaris-sparc )
> # Problematic frame:
> # V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700],  sp=0xfff0f6ffd1f0,  free 
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> V  [libjvm.so+0xc7c438]  Unsafe_SetInt+0x14c
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j  sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j  
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j  
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j  org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j  
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j  
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j  
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j  
>