[jira] [Commented] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Igor Rudyak (JIRA)]

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

Igor Rudyak commented on IGNITE-3293:
-

I also added README.txt

> AWS bootstrap scripts patch for Ignite-Cassandra 
> -
>
> Key: IGNITE-3293
> URL: https://issues.apache.org/jira/browse/IGNITE-3293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Igor Rudyak
>Assignee: Nikolay Tikhonov
>
> New version of AWS bootstrap script having:
> 1) Gaglia monitoring
> 2) Allows to manually trigger tests execution multiple times on the same 
> ifstastructure



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

[jira] [Closed] (IGNITE-3097) .NET: Improve reflective serialization performance

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn closed IGNITE-3097.
--

> .NET: Improve reflective serialization performance
> --
>
> Key: IGNITE-3097
> URL: https://issues.apache.org/jira/browse/IGNITE-3097
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> * Do not share single BinaryReflectiveSerializer between types. Use a 
> separate instance for each type. This will eliminate descriptor dictionary 
> lookup and simplify the code.
> * Use generic Read/Write methods in serializer to avoid casting and boxing. 
> Maintain compatibility with existing IBinarySerializer interface by wrapping 
> user-defined serializers.
> * Serializer should be responsible for creating new instance, not reader, to 
> allow optimizations for certain types.
> * Remove IBinarizable check from reflective serializer



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

[jira] [Commented] (IGNITE-3097) .NET: Improve reflective serialization performance

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3097:


Github user asfgit closed the pull request at:

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


> .NET: Improve reflective serialization performance
> --
>
> Key: IGNITE-3097
> URL: https://issues.apache.org/jira/browse/IGNITE-3097
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> * Do not share single BinaryReflectiveSerializer between types. Use a 
> separate instance for each type. This will eliminate descriptor dictionary 
> lookup and simplify the code.
> * Use generic Read/Write methods in serializer to avoid casting and boxing. 
> Maintain compatibility with existing IBinarySerializer interface by wrapping 
> user-defined serializers.
> * Serializer should be responsible for creating new instance, not reader, to 
> allow optimizations for certain types.
> * Remove IBinarizable check from reflective serializer



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

[jira] [Closed] (IGNITE-2877) .NET: Compile and cache delegates for service method invocation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn closed IGNITE-2877.
--

> .NET: Compile and cache delegates for service method invocation
> ---
>
> Key: IGNITE-2877
> URL: https://issues.apache.org/jira/browse/IGNITE-2877
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 1.7
>
>
> See ServiceProxyInvoker: MethodBase.Invoke is used to invoke service methods, 
> which is not efficient (reflection).
> Instead, we can compile and cache delegates per [svcType, methodName, 
> argCount] to eliminate overhead (see DelegateConverter).



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

[jira] [Commented] (IGNITE-2877) .NET: Compile and cache delegates for service method invocation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2877:


Github user asfgit closed the pull request at:

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


> .NET: Compile and cache delegates for service method invocation
> ---
>
> Key: IGNITE-2877
> URL: https://issues.apache.org/jira/browse/IGNITE-2877
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.7
>
>
> See ServiceProxyInvoker: MethodBase.Invoke is used to invoke service methods, 
> which is not efficient (reflection).
> Instead, we can compile and cache delegates per [svcType, methodName, 
> argCount] to eliminate overhead (see DelegateConverter).



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

[jira] [Closed] (IGNITE-2379) .NET: ASP.NET Output Cache provider

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn closed IGNITE-2379.
--

> .NET: ASP.NET Output Cache provider
> ---
>
> Key: IGNITE-2379
> URL: https://issues.apache.org/jira/browse/IGNITE-2379
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Implement System.Web.Caching.OutputCacheProvider 
> (https://msdn.microsoft.com/en-us/library/system.web.caching.outputcacheprovider(v=vs.110).aspx)



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

[jira] [Commented] (IGNITE-2379) .NET: ASP.NET Output Cache provider

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2379:


Github user asfgit closed the pull request at:

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


> .NET: ASP.NET Output Cache provider
> ---
>
> Key: IGNITE-2379
> URL: https://issues.apache.org/jira/browse/IGNITE-2379
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Implement System.Web.Caching.OutputCacheProvider 
> (https://msdn.microsoft.com/en-us/library/system.web.caching.outputcacheprovider(v=vs.110).aspx)



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

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

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-2969:
-

{{GridDhtTxPrepareFuture}} also changed accordingly to review comments.

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



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

[jira] [Assigned] (IGNITE-1018) Node local map is not available when LifecycleEventType.BEFORE_NODE_START is processed in lifecycle bean

[Andrey Velichko (JIRA)]

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

Andrey Velichko reassigned IGNITE-1018:
---

Assignee: Andrey Velichko

> Node local map is not available when LifecycleEventType.BEFORE_NODE_START is 
> processed in lifecycle bean
> 
>
> Key: IGNITE-1018
> URL: https://issues.apache.org/jira/browse/IGNITE-1018
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Andrey Velichko
>  Labels: Usability, newbie
>
> Currently {{IgniteCluster.nodeLocalMap()}} method is guarded by gateway like 
> all others. But this is just a local concurrent map which is already 
> available at the moment LifecycleEventType.BEFORE_NODE_START is processed, so 
> I think it will be good to make it available in lifecycle bean.
> This can be useful if user needs to initialize some resources and put them to 
> node local map before node is started.



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

[jira] [Assigned] (IGNITE-2379) .NET: ASP.NET Output Cache provider

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-2379:
--

Assignee: Pavel Tupitsyn  (was: Vladimir Ozerov)

> .NET: ASP.NET Output Cache provider
> ---
>
> Key: IGNITE-2379
> URL: https://issues.apache.org/jira/browse/IGNITE-2379
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Implement System.Web.Caching.OutputCacheProvider 
> (https://msdn.microsoft.com/en-us/library/system.web.caching.outputcacheprovider(v=vs.110).aspx)



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

[jira] [Commented] (IGNITE-3233) need to optimize injections

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-3233:
-

Thanks Semen. Yep, done.

> need to optimize injections
> ---
>
> Key: IGNITE-3233
> URL: https://issues.apache.org/jira/browse/IGNITE-3233
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Alexander Paschenko
>  Labels: community, performance
> Fix For: 1.7
>
>
> {noformat}
> I want to check how this closure performs vs empty one:
> ignite.compute().affinityCall(xx, xx, new IgniteCallable() {
> @IgniteInstanceResource
> Ignite ignite;
> 
> @SpringApplicationContextResource
> ApplicationContext ctx;
> 
> Object bean1;
> Object bean2;
> 
> 
> @Override public Object call() throws Exception {
> bean1 = ctx.getBean(bean1class);
> bean2 = ctx.getBean(bean2class);
> 
> return null;
> }
> });
> {noformat}
> Closure above is 3 times slower than Noop closure. Injections should be 
> optimized.
> I see the following options:
> # Annotations
> ## Introduce SpringAware annotation and annotate each object that will need 
> injection including SPI and internal stuff
> ## Support Spring Autowire annotation.
> ## I am not sure about the approach. We can use ApplicationContext.autowire() 
> or generate and compile code that will do injections.
> # Interfaces
> ## IgniteAware
> ## Spring ApplicationContext aware
> ## ...
> Implementor should suggest and back solution with microbenchmarks.



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

[jira] [Created] (IGNITE-3337) REST HTTP: metadata command returns all caches even if cache name is passed to request

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-3337:
-

 Summary: REST HTTP: metadata command returns all caches even if 
cache name is passed to request
 Key: IGNITE-3337
 URL: https://issues.apache.org/jira/browse/IGNITE-3337
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Kozlov


Request: 
{{http://localhost:8080/ignite?cmd=metadata=replicated_cache}}

Reply:
{noformat}
{
  "error": "",
  "response": [
{
  "cacheName": "partitioned_cache",
  "fields": {},
  "indexes": {},
  "keyClasses": {},
  "types": [],
  "valClasses": {}
},
{
  "cacheName": "replicated_cache",
  "fields": {},
  "indexes": {},
  "keyClasses": {},
  "types": [],
  "valClasses": {}
}
  ],
  "sessionToken": "",
  "successStatus": 0
}
{noformat}




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

[jira] [Updated] (IGNITE-3337) REST HTTP: metadata command returns all caches even if a cache name is passed to request

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-3337:
--
Summary: REST HTTP: metadata command returns all caches even if a cache 
name is passed to request  (was: REST HTTP: metadata command returns all caches 
even if cache name is passed to request)

> REST HTTP: metadata command returns all caches even if a cache name is passed 
> to request
> 
>
> Key: IGNITE-3337
> URL: https://issues.apache.org/jira/browse/IGNITE-3337
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kozlov
>
> Request: 
> {{http://localhost:8080/ignite?cmd=metadata=replicated_cache}}
> Reply:
> {noformat}
> {
>   "error": "",
>   "response": [
> {
>   "cacheName": "partitioned_cache",
>   "fields": {},
>   "indexes": {},
>   "keyClasses": {},
>   "types": [],
>   "valClasses": {}
> },
> {
>   "cacheName": "replicated_cache",
>   "fields": {},
>   "indexes": {},
>   "keyClasses": {},
>   "types": [],
>   "valClasses": {}
> }
>   ],
>   "sessionToken": "",
>   "successStatus": 0
> }
> {noformat}



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

[jira] [Comment Edited] (IGNITE-3184) Hadoop: HADOOP_HOME should not be required if all other environment variables are set.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-3184 at 6/17/16 1:38 PM:
--

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

tested both on Linux & Windows.


was (Author: iveselovskiy):
https://github.com/apache/ignite/pull/810

(Windows scripts not tested yet.)

> Hadoop: HADOOP_HOME should not be required if all other environment variables 
> are set.
> --
>
> Key: IGNITE-3184
> URL: https://issues.apache.org/jira/browse/IGNITE-3184
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> *Problem*
> Ignite internals require three pieces to create correct Hadoop classpath:
> 1) Path to common JARs;
> 2) Path to HDFS JARs;
> 3) Path map-reduce JARs.
> These three paths could be set with environment variables HADOOP_COMMON_HOME, 
> HADOOP_HDFS_HOME and HADOOP_MAPRED_HOME respectively. 
> When all of them are set, HADOOP_HOME is no longer needed, but we will throw 
> an exception in this case. We should not do that.
> *Solution*
> Throw exception only in case we cannot resolve any of these paths.



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

[jira] [Closed] (IGNITE-3107) Help for tasks/events should be rephrased

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov closed IGNITE-3107.
-

> Help for tasks/events should be rephrased
> -
>
> Key: IGNITE-3107
> URL: https://issues.apache.org/jira/browse/IGNITE-3107
> Project: Ignite
>  Issue Type: Bug
>  Components: visor
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Trivial
> Fix For: 1.6
>
>
> {noformat}
>  |   | of Event Storage SPI that is responsible for temporary storage of 
> generated   |
>  |   | events on each node can also affect the functionality of this 
> command.|
>  |   |
>|
> -|   | By default - all events are enabled and Ignite stores last 10,000 
> local   |
> +|   | By default - all events are disabled and Ignite stores last 10,000 
> local  |
>  |   | events on each node. Both of these defaults can be changed in 
> configuration.  |
>  
> +---+{noformat}



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

[jira] [Updated] (IGNITE-3300) ArrayIndexOutOfBoundsException: -1 during capitalization benchmark running

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-3300:

Priority: Blocker  (was: Major)

> ArrayIndexOutOfBoundsException: -1 during capitalization benchmark running
> --
>
> Key: IGNITE-3300
> URL: https://issues.apache.org/jira/browse/IGNITE-3300
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Priority: Blocker
>
> Test config:
> 1 client, 16 servers
> warmup 60
> duration 1h
> preload 5M
> operations: capitalization benchmark
> backups count 1
> After ~30 min after start the following errors occur at the driver:
> {noformat}
> [08:42:51,367][ERROR][sys-#5%null%][GridTaskWorker] Failed to obtain remote 
> job result policy for result from ComputeTask.result(..) method (will fail 
> the whole task): GridJobResultImpl [job=C4V2 
> [r=o.a.i.yardstick.cache.load.IgniteCapitalizationBenchmark$ScanQueryBroadcastClosure@41013d64],
>  sib=GridJobSiblingImpl 
> [sesId=bfb21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> nodeId=79226bcc-651f-4af7-8d39-fd4019b7708c, isJobDone=false], 
> jobCtx=GridJobContextImpl 
> [jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, timeoutObj=null, 
> attrs={}], node=TcpDiscoveryNode [id=79226bcc-651f-4af7-8d39-fd4019b7708c, 
> addrs=[10.20.0.216, 127.0.0.1], sockAddrs=[fosters-216/10.20.0.216:47501, 
> /10.20.0.216:47501, /127.0.0.1:47501], discPort=47501, order=5, intOrder=5, 
> lastExchangeTime=1465485122287, loc=false, ver=1.7.0#20160603-sha1:82573436, 
> isClient=false], ex=class o.a.i.compute.ComputeUserUndeclaredException: 
> Failed to execute job due to unexpected runtime exception 
> [jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.yardstick.cache.load.IgniteCapitalizationBenchmark$ScanQueryBroadcastClosure,
>  dep=LocalDeployment [super=GridDeployment [ts=1465485111989, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@6da264f1, 
> clsLdrId=cee28b53551-79226bcc-651f-4af7-8d39-fd4019b7708c, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.yardstick.cache.load.IgniteCapitalizationBenchmark$ScanQueryBroadcastClosure,
>  sesId=bfb21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> startTime=1465486810898, endTime=9223372036854775807, 
> taskNodeId=a8d91d06-89bd-41a5-8b4f-6a02416dfc63, 
> clsLdr=sun.misc.Launcher$AppClassLoader@6da264f1, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, 
> subjId=a8d91d06-89bd-41a5-8b4f-6a02416dfc63, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1465486811180, 
> endTime=0, ignoreInterrupts=false, state=INIT]]], 
> jobId=51c21563551-a8d91d06-89bd-41a5-8b4f-6a02416dfc63]], hasRes=true, 
> isCancelled=false, isOccupied=true]
> class org.apache.ignite.IgniteException: Remote job threw user exception 
> (override or implement ComputeTask.result(..) method if you would like to 
> have automatic failover for this exception).
> at 
> org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:101)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker$3.apply(GridTaskWorker.java:912)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker$3.apply(GridTaskWorker.java:905)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6491)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:905)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:801)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:995)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1220)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at 

[jira] [Resolved] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-3335.
-
Resolution: Fixed

> IGFS: Route client requests only to metadata affinity nodes. 
> -
>
> Key: IGNITE-3335
> URL: https://issues.apache.org/jira/browse/IGNITE-3335
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Closed] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3335.
---

> IGFS: Route client requests only to metadata affinity nodes. 
> -
>
> Key: IGNITE-3335
> URL: https://issues.apache.org/jira/browse/IGNITE-3335
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Created] (IGNITE-3336) Improve Ignite troubleshooting logging

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-3336:


 Summary: Improve Ignite troubleshooting logging
 Key: IGNITE-3336
 URL: https://issues.apache.org/jira/browse/IGNITE-3336
 Project: Ignite
  Issue Type: Task
  Components: general
Reporter: Semen Boikov
Assignee: Semen Boikov


Currently there is method IgniteKernal.dumpDebugInfo which dumps important 
troubleshooting information. Currently Ignite dumps this information when 
partition exchange process hangs. In addition need add some background logic 
which will check that there are no hanging operations (tx, atomic updates) and 
dump debug info if there are any.

In addition need improve debug logging for cache operations: e.g. if I know id 
of hanging tx it should be possible to grep logs by this id and find out all 
steps of tx execution, maybe need add several levels of details for tx 
execution to avoid too much logging.



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

[jira] [Created] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3335:
---

 Summary: IGFS: Route client requests only to metadata affinity 
nodes. 
 Key: IGNITE-3335
 URL: https://issues.apache.org/jira/browse/IGNITE-3335
 Project: Ignite
  Issue Type: Sub-task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.7






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

[jira] [Resolved] (IGNITE-3334) TcpDiscoveryZookeeperIpFinder uses INFO logging without isInfoEnabled() check

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko resolved IGNITE-3334.
-
Resolution: Fixed

Fixed in master.

> TcpDiscoveryZookeeperIpFinder uses INFO logging without isInfoEnabled() check
> -
>
> Key: IGNITE-3334
> URL: https://issues.apache.org/jira/browse/IGNITE-3334
> Project: Ignite
>  Issue Type: Bug
>  Components: ignite-zookeeper
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> This leads to the warnings in case INFO is disabled:
> {noformat}
> [org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder]
>  Logging at INFO level without checking if INFO level is enabled
> {noformat}



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

[jira] [Closed] (IGNITE-3239) "Failed to write class name to file xxxxx.classname" error when several clients and server are running at one host

[Andrey Gura (JIRA)]

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

Andrey Gura closed IGNITE-3239.
---

> "Failed to write class name to file x.classname" error when several 
> clients and server are running at one host
> --
>
> Key: IGNITE-3239
> URL: https://issues.apache.org/jira/browse/IGNITE-3239
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Andrey Gura
>Priority: Minor
>
> During load test with 4 clients and 1 server per host (total 4 servers) the 
> following errors occur on server and client sides:
> {noformat}
> [06:02:28,418][ERROR][marshaller-cache-#96%null%][MarshallerContextImpl] 
> Failed to write class name to file [id=1023271795, 
> clsName=o.a.i.yardstick.cache.load.model.key.Identifier, 
> file=/home/gridgain/krybakova/opts-set-b-0-m-client-rev-3c3ed056-date-0206-060158/yardstick/work/marshaller/1023271795.classname]
> java.io.IOException: Resource deadlock avoided
> at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1052)
> at 
> org.apache.ignite.internal.MarshallerContextImpl$ContinuousQueryListener.onUpdated(MarshallerContextImpl.java:236)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:769)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2167)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2250)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1644)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1484)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2945)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:129)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:260)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:258)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-2969:

Comment: was deleted

(was: Merged into master branch.)

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



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

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

[Andrey Gura (JIRA)]

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

Andrey Gura reopened IGNITE-2969:
-

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



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

[jira] [Created] (IGNITE-3334) TcpDiscoveryZookeeperIpFinder uses INFO logging without isInfoEnabled() check

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-3334:
---

 Summary: TcpDiscoveryZookeeperIpFinder uses INFO logging without 
isInfoEnabled() check
 Key: IGNITE-3334
 URL: https://issues.apache.org/jira/browse/IGNITE-3334
 Project: Ignite
  Issue Type: Bug
  Components: ignite-zookeeper
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 1.7


This leads to the warnings in case INFO is disabled:
{noformat}
[org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder] 
Logging at INFO level without checking if INFO level is enabled
{noformat}



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

[jira] [Commented] (IGNITE-3212) Servers get stuck with the warning "Failed to wait for initial partition map exchange" during falover test

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3212:
--

Issues with GridCacheTxRecoveryFuture.onNodeLeft are fixed (commit #4e82af8), 
also verified that iteration over 'IgniteTxManager.completedVersHashMap' is not 
an issue.

> Servers get stuck with the warning "Failed to wait for initial partition map 
> exchange" during falover test
> --
>
> Key: IGNITE-3212
> URL: https://issues.apache.org/jira/browse/IGNITE-3212
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Assignee: Semen Boikov
> Fix For: 1.7
>
>
> Servers being restarted during failover test get stuck after some time with 
> the warning "Failed to wait for initial partition map exchange". 
> {noformat}
> [08:44:41,303][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager] 
> Added new node to topology: TcpDiscoveryNode 
> [id=db557f04-43b7-4e28-ae0d-d4dcf4139c89, addrs=
> [10.20.0.222, 127.0.0.1], sockAddrs=[fosters-222/10.20.0.222:47503, 
> /10.20.0.222:47503, /127.0.0.1:47503], discPort=47503, order=44, intOrder=32, 
> lastExchangeTime=1464
> 363880917, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:44:41,304][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager] 
> Topology snapshot [ver=44, servers=19, clients=1, CPUs=64, heap=160.0GB]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager] 
> Added new node to topology: TcpDiscoveryNode 
> [id=6fae61a7-c1c1-40e5-8ad0-8bf5d6c86eb7, addrs=
> [10.20.0.223, 127.0.0.1], sockAddrs=[fosters-223/10.20.0.223:47503, 
> /10.20.0.223:47503, /127.0.0.1:47503], discPort=47503, order=45, intOrder=33, 
> lastExchangeTime=1464
> 363910999, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager] 
> Topology snapshot [ver=45, servers=20, clients=1, CPUs=64, heap=170.0GB]
> [08:45:19,942][INFO ][ignite-update-notifier-timer][GridUpdateNotifier] 
> Update status is not available.
> [08:46:20,370][WARN ][main][GridCachePartitionExchangeManager] Failed to wait 
> for initial partition map exchange. Possible reasons are:
>   ^-- Transactions in deadlock.
>   ^-- Long running transactions (ignore if this is the case).
>   ^-- Unreleased explicit locks.
> [08:48:30,375][WARN ][main][GridCachePartitionExchangeManager] Still waiting 
> for initial partition map exchange ...
> {noformat}
> "Failed to wait for partition release future" warnings are on other nodes.
> {noformat}
> [08:09:45,822][WARN 
> ][exchange-worker-#82%null%][GridDhtPartitionsExchangeFuture] Failed to wait 
> for partition release future [topVer=AffinityTopologyVersion [topVer=29, 
> minorTopVer=0], node=cab5d0e0-7365-4774-8f99-d9f131c5d896]. Dumping pending 
> objects that might be the cause:
> [08:09:45,822][WARN 
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Ready 
> affinity version: AffinityTopologyVersion [topVer=28, minorTopVer=1]
> [08:09:45,826][WARN 
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Last exchange 
> future: GridDhtPartitionsExchangeFuture ...
> {noformat}
> Load config:
> - 1 client, 20 servers (5 servers per 1 host)
> - warmup 60
> - duration 66h
> - preload 5M
> - key range 10M
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL 
> PUT_IF_ABSENT REPLACE
> - backups count 3
> - 3 servers restart every 15 min with 30 sec step, pause between stop and 
> start 5min



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

[jira] [Assigned] (IGNITE-3309) Web console: incorrect validator

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3309:


Assignee: Alexey Kuznetsov  (was: Dmitriyff)

> Web console: incorrect validator
> 
>
> Key: IGNITE-3309
> URL: https://issues.apache.org/jira/browse/IGNITE-3309
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Attachments: ig-3309.png
>
>
> # Clusters -> Communication -> Unacknowledged messages
> # set value = 1
> # Save - error message appear but the fields is not with a red frame
> Also please verify the tooltip for this field



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

[jira] [Commented] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-3215:
-

Merged to master.

> IgniteRDD should be able to work with BinaryObjects
> ---
>
> Key: IGNITE-3215
> URL: https://issues.apache.org/jira/browse/IGNITE-3215
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to 
> {{IgniteCache}}. If set, functions used in methods like {{foreachPartition}} 
> will work with {{BinaryObject}} instances instead of deserialized objects. 
> Currently if such methods are used, classes are required to be deployed on 
> executors' classpath.



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

[jira] [Closed] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-3215.
---

> IgniteRDD should be able to work with BinaryObjects
> ---
>
> Key: IGNITE-3215
> URL: https://issues.apache.org/jira/browse/IGNITE-3215
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to 
> {{IgniteCache}}. If set, functions used in methods like {{foreachPartition}} 
> will work with {{BinaryObject}} instances instead of deserialized objects. 
> Currently if such methods are used, classes are required to be deployed on 
> executors' classpath.



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

[jira] [Commented] (IGNITE-3239) "Failed to write class name to file xxxxx.classname" error when several clients and server are running at one host

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3239:
--

Looks good, just change ThreadLocalRandom8 to 
java.util.concurrent.ThreadLocalRandom.

> "Failed to write class name to file x.classname" error when several 
> clients and server are running at one host
> --
>
> Key: IGNITE-3239
> URL: https://issues.apache.org/jira/browse/IGNITE-3239
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Andrey Gura
>Priority: Minor
>
> During load test with 4 clients and 1 server per host (total 4 servers) the 
> following errors occur on server and client sides:
> {noformat}
> [06:02:28,418][ERROR][marshaller-cache-#96%null%][MarshallerContextImpl] 
> Failed to write class name to file [id=1023271795, 
> clsName=o.a.i.yardstick.cache.load.model.key.Identifier, 
> file=/home/gridgain/krybakova/opts-set-b-0-m-client-rev-3c3ed056-date-0206-060158/yardstick/work/marshaller/1023271795.classname]
> java.io.IOException: Resource deadlock avoided
> at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1052)
> at 
> org.apache.ignite.internal.MarshallerContextImpl$ContinuousQueryListener.onUpdated(MarshallerContextImpl.java:236)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:769)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2167)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2250)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1644)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1484)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2945)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:129)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:260)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:258)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}

[jira] [Commented] (IGNITE-3320) .NET: Configure AffinityFunction without Spring

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3320:


Github user asfgit closed the pull request at:

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


> .NET: Configure AffinityFunction without Spring
> ---
>
> Key: IGNITE-3320
> URL: https://issues.apache.org/jira/browse/IGNITE-3320
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Allow choosing predefined RendezvousAffinityFunction and FairAffinityFunction



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

[jira] [Resolved] (IGNITE-3320) .NET: Configure AffinityFunction without Spring

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-3320.

Resolution: Done

> .NET: Configure AffinityFunction without Spring
> ---
>
> Key: IGNITE-3320
> URL: https://issues.apache.org/jira/browse/IGNITE-3320
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Allow choosing predefined RendezvousAffinityFunction and FairAffinityFunction



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

[jira] [Resolved] (IGNITE-3332) IGFS: Use task for file unlock routine on client nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-3332.
-
Resolution: Fixed

> IGFS: Use task for file unlock routine on client nodes.
> ---
>
> Key: IGNITE-3332
> URL: https://issues.apache.org/jira/browse/IGNITE-3332
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Resolved] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-3331.
-
Resolution: Fixed

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Closed] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3331.
---

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Updated] (IGNITE-2852) Support of Comparable interface for BinaryObject

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2852:

Assignee: Andrey Velichko

> Support of Comparable interface for BinaryObject
> 
>
> Key: IGNITE-2852
> URL: https://issues.apache.org/jira/browse/IGNITE-2852
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Andrey Velichko
> Fix For: 1.7
>
>
> When trying to convert {{TreeMap}} into binary object using {{toBinary}} 
> method, the following exception fails:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> java.lang.Comparable
>   at java.util.TreeMap.compare(TreeMap.java:1188)
>   at java.util.TreeMap.put(TreeMap.java:531)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:495)
>   at 
> org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.toBinary(IgniteBinaryImpl.java:67)
>   at TreeMapTest.main(TreeMapTest.java:15)
>   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:144)
> {noformat}
> This happens because maps are not wrapped into binary objects, therefore we 
> create another {{TreeMap}} and put {{BinaryObject}} instances, which are not 
> {{Comparable}}.



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

[jira] [Updated] (IGNITE-2852) Support of Comparable interface for BinaryObject

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2852:

Summary: Support of Comparable interface for BinaryObject  (was: TreeMap 
can't be converted to portable)

> Support of Comparable interface for BinaryObject
> 
>
> Key: IGNITE-2852
> URL: https://issues.apache.org/jira/browse/IGNITE-2852
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
>
> When trying to convert {{TreeMap}} into binary object using {{toBinary}} 
> method, the following exception fails:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to 
> java.lang.Comparable
>   at java.util.TreeMap.compare(TreeMap.java:1188)
>   at java.util.TreeMap.put(TreeMap.java:531)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:495)
>   at 
> org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.toBinary(IgniteBinaryImpl.java:67)
>   at TreeMapTest.main(TreeMapTest.java:15)
>   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:144)
> {noformat}
> This happens because maps are not wrapped into binary objects, therefore we 
> create another {{TreeMap}} and put {{BinaryObject}} instances, which are not 
> {{Comparable}}.



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

[jira] [Commented] (IGNITE-3320) .NET: Configure AffinityFunction without Spring

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3320:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3320 .NET: Configure AffinityFunction without Spring



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

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

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

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


commit 1185239cbdec2f3254c870a276538af5470b
Author: Pavel Tupitsyn 
Date:   2016-06-15T16:17:00Z

Interfaces added

commit 83ee6f587b28677803a1284fcf84a6bfbd385290
Author: Pavel Tupitsyn 
Date:   2016-06-15T16:23:51Z

wip

commit a9d836bc6799473ce4b23697c49b7c3f37a2996a
Author: Pavel Tupitsyn 
Date:   2016-06-15T16:45:23Z

wip base class

commit 7e2bb0038d43219b9d95aceceb4c81c236809822
Author: Pavel Tupitsyn 
Date:   2016-06-15T17:06:42Z

wip

commit 5d207a7c59578988226bd5ed641ccab3f5842d49
Author: Pavel Tupitsyn 
Date:   2016-06-16T11:08:40Z

wip

commit 7a32eb1782bfa50b6fba6ac5e8bb75ad10c02f45
Author: Pavel Tupitsyn 
Date:   2016-06-17T08:38:52Z

Read/write

commit cba8189eac39119023ce91284f152a60f145effb
Author: Pavel Tupitsyn 
Date:   2016-06-17T09:37:02Z

Read/write in Java

commit 8bc769e7d63fd3474b6db77545edc2dbcda4f978
Author: Pavel Tupitsyn 
Date:   2016-06-17T09:48:01Z

wip test

commit 3a26291d446a6153233c26c67ee7483c452767a8
Author: Pavel Tupitsyn 
Date:   2016-06-17T09:48:38Z

цшз

commit e58a1689bdae6e3ce9b1741491fe530a7d481c3f
Author: Pavel Tupitsyn 
Date:   2016-06-17T10:24:55Z

tests wip

commit ead0124750561a6964bcb9d5fa87ccefbe785a19
Author: Pavel Tupitsyn 
Date:   2016-06-17T10:28:05Z

wip

commit 6af813491138a6edf45cf1621d5bcd90007bbc0a
Author: Pavel Tupitsyn 
Date:   2016-06-17T10:31:30Z

wip

commit 81eb143b6040a52fe4473d086d6f50deb446d3d2
Author: Pavel Tupitsyn 
Date:   2016-06-17T10:32:39Z

update schema




> .NET: Configure AffinityFunction without Spring
> ---
>
> Key: IGNITE-3320
> URL: https://issues.apache.org/jira/browse/IGNITE-3320
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Allow choosing predefined RendezvousAffinityFunction and FairAffinityFunction



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

[jira] [Commented] (IGNITE-1018) Node local map is not available when LifecycleEventType.BEFORE_NODE_START is processed in lifecycle bean

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1018:


GitHub user AndreyVel opened a pull request:

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

IGNITE-1018

Node local map is not available when LifecycleEventType.BEFORE_NODE_START 
is processed in lifecycle bean

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

$ git pull https://github.com/AndreyVel/ignite ignite-1018

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

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


commit a56c8b3140bf9af7f562f4cec879278e4fa0e699
Author: AndreyVel 
Date:   2016-06-17T09:54:00Z

IGNITE-1018

Node local map is not available when LifecycleEventType.BEFORE_NODE_START 
is processed in lifecycle bean




> Node local map is not available when LifecycleEventType.BEFORE_NODE_START is 
> processed in lifecycle bean
> 
>
> Key: IGNITE-1018
> URL: https://issues.apache.org/jira/browse/IGNITE-1018
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>  Labels: Usability, newbie
>
> Currently {{IgniteCluster.nodeLocalMap()}} method is guarded by gateway like 
> all others. But this is just a local concurrent map which is already 
> available at the moment LifecycleEventType.BEFORE_NODE_START is processed, so 
> I think it will be good to make it available in lifecycle bean.
> This can be useful if user needs to initialize some resources and put them to 
> node local map before node is started.



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

[jira] [Commented] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-3293:
--

Igor,

AWS scripts looks good for me. Now we try to deploy the framework on AWS. I'll 
post the result here.

> AWS bootstrap scripts patch for Ignite-Cassandra 
> -
>
> Key: IGNITE-3293
> URL: https://issues.apache.org/jira/browse/IGNITE-3293
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Igor Rudyak
>Assignee: Nikolay Tikhonov
>
> New version of AWS bootstrap script having:
> 1) Gaglia monitoring
> 2) Allows to manually trigger tests execution multiple times on the same 
> ifstastructure



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

[jira] [Created] (IGNITE-3333) IGFS: Allow for ATOMIC data cache.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-:
---

 Summary: IGFS: Allow for ATOMIC data cache.
 Key: IGNITE-
 URL: https://issues.apache.org/jira/browse/IGNITE-
 Project: Ignite
  Issue Type: Task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.7


Currently data cache must be transactional. It means that some updates even on 
single key will require 2PC. Instead, it makes sense to try change update logic 
to work always on single keys. In this case we will be able to switch to ATOMIC 
cache, what could improve performance dramatically.



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

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

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-3226.
-
Resolution: Won't Fix

Not relevant for Apache Ignite.

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



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

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

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-3226.
---

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



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

[jira] [Updated] (IGNITE-3332) IGFS: Use task for file unlock routine on client nodes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3332:

Summary: IGFS: Use task for file unlock routine on client nodes.  (was: 
IGFS: Use task file for unlock routine on client nodes.)

> IGFS: Use task for file unlock routine on client nodes.
> ---
>
> Key: IGNITE-3332
> URL: https://issues.apache.org/jira/browse/IGNITE-3332
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Created] (IGNITE-3332) IGFS: Use task file for unlock routine on client nodes.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3332:
---

 Summary: IGFS: Use task file for unlock routine on client nodes.
 Key: IGNITE-3332
 URL: https://issues.apache.org/jira/browse/IGNITE-3332
 Project: Ignite
  Issue Type: Sub-task
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.7






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

[jira] [Updated] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3331:

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

> IGFS: Route client tasks to primary node when metadata co-location is enabled.
> --
>
> Key: IGNITE-3331
> URL: https://issues.apache.org/jira/browse/IGNITE-3331
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Currently we route IGFS client tasks to random metadata data node. When 
> co-location is enabled, it makes sense to requests which are going to change 
> metadata directly to primary node. 



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

[jira] [Created] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3331:
---

 Summary: IGFS: Route client tasks to primary node when metadata 
co-location is enabled.
 Key: IGNITE-3331
 URL: https://issues.apache.org/jira/browse/IGNITE-3331
 Project: Ignite
  Issue Type: Bug
  Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.7


Currently we route IGFS client tasks to random metadata data node. When 
co-location is enabled, it makes sense to requests which are going to change 
metadata directly to primary node. 



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

[jira] [Updated] (IGNITE-3295) IGFS: Introduce file ID cache (HashMap) to minimize cache calls.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3295:

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

> IGFS: Introduce file ID cache (HashMap) to minimize cache calls.
> 
>
> Key: IGNITE-3295
> URL: https://issues.apache.org/jira/browse/IGNITE-3295
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Closed] (IGNITE-3295) IGFS: Introduce file ID cache (HashMap) to minimize cache calls.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3295.
---

> IGFS: Introduce file ID cache (HashMap) to minimize cache calls.
> 
>
> Key: IGNITE-3295
> URL: https://issues.apache.org/jira/browse/IGNITE-3295
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Resolved] (IGNITE-3295) IGFS: Introduce file ID cache (HashMap) to minimize cache calls.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-3295.
-
Resolution: Won't Fix

> IGFS: Introduce file ID cache (HashMap) to minimize cache calls.
> 
>
> Key: IGNITE-3295
> URL: https://issues.apache.org/jira/browse/IGNITE-3295
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>




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

[jira] [Assigned] (IGNITE-1088) [Multi jvm] Full api test which test store.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-1088:
---

Assignee: Alexander Paschenko

> [Multi jvm] Full api test which test store.
> ---
>
> Key: IGNITE-1088
> URL: https://issues.apache.org/jira/browse/IGNITE-1088
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Alexander Paschenko
>  Labels: Muted_test
>
> Next tests use a store which actually is {{ConcurrentMap}}. Need to use some 
> place for storage which will be available from several jvms (file, db or 
> etc.).
> testRemoveAllSkipStore
> testWithSkipStore 
> testWithSkipStoreRemoveAll
> testWriteThroughTx
> See also all tests which use {{putToStore}} method.



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

[jira] [Closed] (IGNITE-3038) Optimize internally used ContinuousQueries

[Semen Boikov (JIRA)]

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

Semen Boikov closed IGNITE-3038.

Assignee: (was: Semen Boikov)

> Optimize internally used ContinuousQueries
> --
>
> Key: IGNITE-3038
> URL: https://issues.apache.org/jira/browse/IGNITE-3038
> Project: Ignite
>  Issue Type: Bug
>Reporter: Semen Boikov
>Priority: Critical
> Fix For: 1.7
>
>
> There are several issues:
> - even if for server nodes queries are local they still send custom discovery 
> messages (probably this should be fixed not only for internal queries)
> - ideally client nodes also should not send discovery messages since queries 
> are always started, so they can be statically configured
> - GridServiceProcessor starts two queries, looks like only one can be used
> - marshaller cache query is started before 
> GridCachePartitionExchangeManager.onKernalStart, this can slowdown exchange 
> process (not an issue is previous items are fixed)



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

[jira] [Resolved] (IGNITE-3038) Optimize internally used ContinuousQueries

[Semen Boikov (JIRA)]

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

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

Implemented optimizations to do not send unnecessary discovery messages to 
start internal continuous queries (commits #dc71125, #e5fcebb).

> Optimize internally used ContinuousQueries
> --
>
> Key: IGNITE-3038
> URL: https://issues.apache.org/jira/browse/IGNITE-3038
> Project: Ignite
>  Issue Type: Bug
>Reporter: Semen Boikov
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.7
>
>
> There are several issues:
> - even if for server nodes queries are local they still send custom discovery 
> messages (probably this should be fixed not only for internal queries)
> - ideally client nodes also should not send discovery messages since queries 
> are always started, so they can be statically configured
> - GridServiceProcessor starts two queries, looks like only one can be used
> - marshaller cache query is started before 
> GridCachePartitionExchangeManager.onKernalStart, this can slowdown exchange 
> process (not an issue is previous items are fixed)



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

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

[Semen Boikov (JIRA)]

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

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

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



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

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

[Semen Boikov (JIRA)]

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

Semen Boikov closed IGNITE-3261.

Assignee: (was: Semen Boikov)

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



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

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

[Semen Boikov (JIRA)]

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

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

Fixed in master (commit #150b5c9).

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



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

[jira] [Assigned] (IGNITE-3233) need to optimize injections

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-3233:


Assignee: Alexander Paschenko  (was: Semen Boikov)

Thanks Alexander, change looks good. I'm just curious what happens if there are 
two beans of the same class in spring context, could you please add such test?

> need to optimize injections
> ---
>
> Key: IGNITE-3233
> URL: https://issues.apache.org/jira/browse/IGNITE-3233
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>Assignee: Alexander Paschenko
>  Labels: community, performance
> Fix For: 1.7
>
>
> {noformat}
> I want to check how this closure performs vs empty one:
> ignite.compute().affinityCall(xx, xx, new IgniteCallable() {
> @IgniteInstanceResource
> Ignite ignite;
> 
> @SpringApplicationContextResource
> ApplicationContext ctx;
> 
> Object bean1;
> Object bean2;
> 
> 
> @Override public Object call() throws Exception {
> bean1 = ctx.getBean(bean1class);
> bean2 = ctx.getBean(bean2class);
> 
> return null;
> }
> });
> {noformat}
> Closure above is 3 times slower than Noop closure. Injections should be 
> optimized.
> I see the following options:
> # Annotations
> ## Introduce SpringAware annotation and annotate each object that will need 
> injection including SPI and internal stuff
> ## Support Spring Autowire annotation.
> ## I am not sure about the approach. We can use ApplicationContext.autowire() 
> or generate and compile code that will do injections.
> # Interfaces
> ## IgniteAware
> ## Spring ApplicationContext aware
> ## ...
> Implementor should suggest and back solution with microbenchmarks.



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

[jira] [Updated] (IGNITE-3328) .NET: Support user-defined AffinityFunction

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3328:
---
Description: 
Allow custom AffinityFunction implementation in .NET
Make sure it can be set in XML config.

  was:Allow custom AffinityFunction implementation in .NET


> .NET: Support user-defined AffinityFunction
> ---
>
> Key: IGNITE-3328
> URL: https://issues.apache.org/jira/browse/IGNITE-3328
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.7
>
>
> Allow custom AffinityFunction implementation in .NET
> Make sure it can be set in XML config.



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