[jira] [Commented] (IGNITE-2555) Include offheap usage in metrics report

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2555:


GitHub user ruskim opened a pull request:

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

IGNITE-2555 fix

 Added offheap usage (used/free/committed) to local node reports.

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

$ git pull https://github.com/ruskim/ignite IGNITE-2555

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

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


commit db1417f98133d35e10ae4acd20428b51e2b1
Author: ruskim 
Date:   2016-02-09T18:06:32Z

fix IGNITE-2555




> Include offheap usage in metrics report
> ---
>
> Key: IGNITE-2555
> URL: https://issues.apache.org/jira/browse/IGNITE-2555
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Priority: Minor
>  Labels: newbie
>
> The local node prints out the set of key parameters in its log (or console). 
> It makes sense to add offheap usage (used/free/committed) to that report.
> {noformat}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=41b12e0f, name=null]
> ^-- H/N/C [hosts=1, nodes=14, CPUs=8]
> ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%]
> ^-- Heap [used=1364MB, free=27,44%, comm=1881MB]
> ^-- Public thread pool [active=0, idle=16, qSize=0]
> ^-- System thread pool [active=1, idle=15, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}



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

[jira] [Updated] (IGNITE-169) [Failed test] GridSessionCheckpointSelfTest fails

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-169:
---
Description: 
{{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
time.

The problem is that test-runner thread invokes {{ignite.compute()}} in async 
mode and when all jobs are mapped it invokes {{processDelayedResponses}} 
method. At this moment is possible that all responses are received but sys pool 
threads don't invoke {{reduce}} method. test-runner thread polls delayed 
responses from queue and invoke {{reduce}}. So test-runner thread "steals" 
reduce job that is waitiong on latch that should be counted down by the same 
thread.

Just run test N times in a loop in order to reproduce it.

{noformat}
[19:04:17,405][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
clsLdr=IsolatedClassLoader{roleName='test'}, 
clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, loc=true, 
sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
 pendingUndeploy=false, undeployed=false, usage=0], 
taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
 sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
startTime=1454958227376, endTime=9223372036854775807, 
taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
failSpi=null, loadSpi=null, usage=0, fullSup=true, 
subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
[orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:666)
at 
org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest.checkCheckpoints(GridSessionCheckpointAbstractSelfTest.java:145)
at 
org.apache.ignite.session.GridSessionCheckpointSelfTest.testSharedFsCheckpoint(GridSessionCheckpointSelfTest.java:48)
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:1723)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
at java.lang.Thread.run(Thread.java:745)
{noformat}

  was:
{{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
time.

Just run test N times in a loop in order to reproduce it.

{noformat}
[19:04:17,405][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
clsLdr=IsolatedClassLoader{roleName='test'}, 
clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, loc=true, 
sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
 pendingUndeploy=false, undeployed=false, usage=0], 
taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
 sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
startTime=1454958227376, endTime=9223372036854775807, 
taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
failSpi=null, loadSpi=null, usage=0, fullSup=true, 
subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
[orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
at 

[jira] [Commented] (IGNITE-169) [Failed test] GridSessionCheckpointSelfTest fails

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-169:


I see two options for fix this:

# We can fix test. Communication SPI should be replaced. It should cacth job 
requests (e.g. first one), get task session, invoke saveCheckpoint and count 
latch down.
# From my point of view isn't good idea try to process delayed results from 
caller thread (especially in case of async compute facade). So I suggest remove 
this bahavior (remove {{processDelayedResponses}} method).

Thoughts?

> [Failed test] GridSessionCheckpointSelfTest fails
> -
>
> Key: IGNITE-169
> URL: https://issues.apache.org/jira/browse/IGNITE-169
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Irina Vasilinets
> Fix For: 1.6
>
>
> {{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
> time.
> The problem is that test-runner thread invokes {{ignite.compute()}} in async 
> mode and when all jobs are mapped it invokes {{processDelayedResponses}} 
> method. At this moment is possible that all responses are received but sys 
> pool threads don't invoke {{reduce}} method. test-runner thread polls delayed 
> responses from queue and invoke {{reduce}}. So test-runner thread "steals" 
> reduce job that is waitiong on latch that should be counted down by the same 
> thread.
> Just run test N times in a loop in order to reproduce it.
> {noformat}
> [19:04:17,405][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
> closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
> dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
> clsLdr=IsolatedClassLoader{roleName='test'}, 
> clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  pendingUndeploy=false, undeployed=false, usage=0], 
> taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
> startTime=1454958227376, endTime=9223372036854775807, 
> taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
> clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=0, fullSup=true, 
> subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
> endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:666)
> at 
> org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest.checkCheckpoints(GridSessionCheckpointAbstractSelfTest.java:145)
> at 
> org.apache.ignite.session.GridSessionCheckpointSelfTest.testSharedFsCheckpoint(GridSessionCheckpointSelfTest.java:48)
> 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:1723)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Resolved] (IGNITE-2595) Allow to save cache with store settings and no one model linked to cache

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko resolved IGNITE-2595.
---
Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Validation removed

> Allow to save cache with store settings and no one model linked to cache
> 
>
> Key: IGNITE-2595
> URL: https://issues.apache.org/jira/browse/IGNITE-2595
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> Currently we disallow to user to save cache if it has store setting but has 
> no one model assigned to it. This case is correct and we need to allow to 
> save cache.



--
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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-1403:

Assignee: Anton Vinogradov

> 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: Anton Vinogradov
>  Labels: important
> Fix For: 1.6
>
>
> {{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-1403) forOldest() cluster group returns predicate that is not updated when topology changes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-1403:

Fix Version/s: 1.6

> 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: Anton Vinogradov
>  Labels: important
> Fix For: 1.6
>
>
> {{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] [Resolved] (IGNITE-2520) Error on 'revert to your identity'

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-2520.

Resolution: Cannot Reproduce
  Assignee: Pavel Konstantinov  (was: Andrey Novikov)

Pavel, please try to reproduce

> Error on 'revert to your identity'
> --
>
> Key: IGNITE-2520
> URL: https://issues.apache.org/jira/browse/IGNITE-2520
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> # open Admin panel
> # become any other user
> # revert to your identity
> {code}
> 17:48:42.194 Error: $scope.profileForm is undefined
> $scope.saveBtnTipText@https://staging-console.gridgain.com/all.js:4182:13
> anonymous/fn@https://staging-console.gridgain.com/app.min.js line 93295 > 
> Function:2:230
> expressionInputWatch@https://staging-console.gridgain.com/app.min.js:94152:37
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94832:40
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94938:19
> timeout/timeoutId<@https://staging-console.gridgain.com/app.min.js:95506:17
> completeOutstandingRequest@https://staging-console.gridgain.com/app.min.js:89723:13
> Browser/self.defer/timeoutId<@https://staging-console.gridgain.com/app.min.js:89852:13
> 1 app.min.js:92501:24
> consoleLog/<() app.min.js:92501
> $ExceptionHandlerProvider/this.$get $RootScopeProvider/this.$get $RootScopeProvider/this.$get timeout/timeoutId<() app.min.js:95506
> completeOutstandingRequest() app.min.js:89723
> Browser/self.defer/timeoutId<() app.min.js:89852
> {code}



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

[jira] [Assigned] (IGNITE-1563) .Net: Implement "atomic" data structures.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-1563:
--

Assignee: Vladimir Ozerov  (was: Pavel Tupitsyn)

> .Net: Implement "atomic" data structures.
> -
>
> Key: IGNITE-1563
> URL: https://issues.apache.org/jira/browse/IGNITE-1563
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> This includes:
> atomicSequence;
> atomicStamped;
> atomicReference



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

[jira] [Closed] (IGNITE-2253) Refactoring fields on cluster page

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Refactoring fields on cluster page
> --
>
> Key: IGNITE-2253
> URL: https://issues.apache.org/jira/browse/IGNITE-2253
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriyff
> Fix For: 1.6
>
>




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

[jira] [Commented] (IGNITE-2380) .NET: Ignite configuration in app.config and web.config

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2380:


1, 4) Fixed
2) It accepts strings because everything in XML is string. It accepts both ints 
and event type names, see IgniteConfigurationSerializerTest:92.
3) 

> .NET: Ignite configuration in app.config and web.config
> ---
>
> Key: IGNITE-2380
> URL: https://issues.apache.org/jira/browse/IGNITE-2380
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> * Define custom ConfigurationSection for IgniteConfiguration (see 
> https://msdn.microsoft.com/en-us/library/2tw134k3.aspx)
> * Extend Ignition class to be able to start Ignite from app.config / 
> web.config configuration
> * Make sure to include xml schema



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

[jira] [Closed] (IGNITE-2520) Error on 'revert to your identity'

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Error on 'revert to your identity'
> --
>
> Key: IGNITE-2520
> URL: https://issues.apache.org/jira/browse/IGNITE-2520
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> # open Admin panel
> # become any other user
> # revert to your identity
> {code}
> 17:48:42.194 Error: $scope.profileForm is undefined
> $scope.saveBtnTipText@https://staging-console.gridgain.com/all.js:4182:13
> anonymous/fn@https://staging-console.gridgain.com/app.min.js line 93295 > 
> Function:2:230
> expressionInputWatch@https://staging-console.gridgain.com/app.min.js:94152:37
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94832:40
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94938:19
> timeout/timeoutId<@https://staging-console.gridgain.com/app.min.js:95506:17
> completeOutstandingRequest@https://staging-console.gridgain.com/app.min.js:89723:13
> Browser/self.defer/timeoutId<@https://staging-console.gridgain.com/app.min.js:89852:13
> 1 app.min.js:92501:24
> consoleLog/<() app.min.js:92501
> $ExceptionHandlerProvider/this.$get $RootScopeProvider/this.$get $RootScopeProvider/this.$get timeout/timeoutId<() app.min.js:95506
> completeOutstandingRequest() app.min.js:89723
> Browser/self.defer/timeoutId<() app.min.js:89852
> {code}



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

[jira] [Updated] (IGNITE-2430) BinaryObject: Inconsistent field type name is returned for Collections

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2430:

Assignee: Vladimir Ozerov

> BinaryObject: Inconsistent field type name is returned for Collections
> --
>
> Key: IGNITE-2430
> URL: https://issues.apache.org/jira/browse/IGNITE-2430
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 1.6
>
>
> Run this code below and you will see that different field type name is 
> returned for objects of the same type. There is a bug in 
> {{BinaryObjectBuilderImpl.serializeTo}} method.
> {noformat}
> BinaryObjectBuilder root = ignite.binary().builder("some_objects");
> root.setField("bi", new BigInteger(String.valueOf(Long.MAX_VALUE) + 
> "1"), BigInteger.class);
> root.setField("bd", new BigDecimal(String.valueOf(Long.MAX_VALUE) + 
> "1.1"), BigDecimal.class);
> List list = new ArrayList<>();
> list.add(Integer.MAX_VALUE);
> root.setField("l", list); //<- here: Collection
> root.setField("al", Arrays.asList(Integer.MAX_VALUE)); //<- 
> here: Object
> BinaryObject binaryObject = root.build();
> System.out.println(binaryObject.type().fieldTypeName("l"));
> System.out.println(binaryObject.type().fieldTypeName("al"));
> {noformat}



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

[jira] [Commented] (IGNITE-2509) Broken eviction and metrics for OFFHEAP_VALUES cache mode

[Vladimir Ershov (JIRA)]

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

Vladimir Ershov commented on IGNITE-2509:
-

Denis,
Thanks for checking! Could you please take a look at the test 
GridCacheOffHeapValuesEvictionSelfTest that was added for preventing such cases 
and advise about conf permutation for reproduction?

> Broken eviction and metrics for OFFHEAP_VALUES cache mode
> -
>
> Key: IGNITE-2509
> URL: https://issues.apache.org/jira/browse/IGNITE-2509
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: EvictionBug.java, eviction_fix.patch
>
>
> In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
> values size wrongly which leads to the fact that data is evicted only when 
> either the limit on number of entries is reached or size of keys is bigger 
> than max allowed size.
> To reproduce set the following cache configuration
> {noformat}
> FifoEvictionPolicy plc = new FifoEvictionPolicy();
> plc.setMaxMemorySize(2 * 1024 * 1024);
> cacheCfg.setEvictionPolicy(plc);
> cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
> cacheCfg.setSwapEnabled(true);
> {noformat}
> Test that reproduces the issue is attached.
> Also attached a patch that fixes the issue. However we should validate that 
> the fix is full and add additional tests to the test suites.
> Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
> this cache mode. Has to be fixed as well.



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

[jira] [Updated] (IGNITE-2587) Unexpected exception during cache update

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-2587:
-
Priority: Blocker  (was: Critical)

> Unexpected exception during cache update
> 
>
> Key: IGNITE-2587
> URL: https://issues.apache.org/jira/browse/IGNITE-2587
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
> Environment: Windows 10, Oracle JDK 1.7.0_80-b15
>Reporter: Sergey Kozlov
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: client_output.txt, ignite-33cb560a.0.log, 
> ignite-5e9294d1.0.log, server_output.txt
>
>
> 1. Start server node
> 2. Start client node (see the code in IGNITE-2586)
> 3. Server node failed:
> {noformat}
> [16:05:03,866][SEVERE][sys-#17%null%][GridDhtAtomicCache] 
>  Unexpected exception during cache update
> java.lang.UnsupportedOperationException
>   at 
> org.apache.ignite.internal.binary.BinaryObjectOffheapImpl.finishUnmarshal(BinaryObjectOffheapImpl.java:363)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:243)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2070)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1407)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1282)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2692)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:128)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:257)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:255)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:821)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:784)
>   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] [Updated] (IGNITE-2598) Enum arguments in SQL queries are not considered with BinaryMarshaller

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2598:

Attachment: ExampleNodeStartup.java

> Enum arguments in SQL queries are not considered with BinaryMarshaller
> --
>
> Key: IGNITE-2598
> URL: https://issues.apache.org/jira/browse/IGNITE-2598
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
> Attachments: ExampleNodeStartup.java
>
>
> Queries like the one below doesn't work with {{Enum}} returning a wrong 
> result when binary marshaller is used.
> {noformat}
> SqlQuery query = new SqlQuery(Event.class, "type = 
> ?");
> query.setArgs(EventType.EventA);
> {noformat}
> The same query works perfectly fine if optimized marshaller is enabled 
> instead.
> Attached the test that reproduces the issue.



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

[jira] [Comment Edited] (IGNITE-2380) .NET: Ignite configuration in app.config and web.config

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-2380 at 2/9/16 9:29 AM:


1, 3, 4) Fixed
2) It accepts strings because everything in XML is string. It accepts both ints 
and event type names, see IgniteConfigurationSerializerTest:92.


was (Author: ptupitsyn):
1, 4) Fixed
2) It accepts strings because everything in XML is string. It accepts both ints 
and event type names, see IgniteConfigurationSerializerTest:92.
3) 

> .NET: Ignite configuration in app.config and web.config
> ---
>
> Key: IGNITE-2380
> URL: https://issues.apache.org/jira/browse/IGNITE-2380
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> * Define custom ConfigurationSection for IgniteConfiguration (see 
> https://msdn.microsoft.com/en-us/library/2tw134k3.aspx)
> * Extend Ignition class to be able to start Ignite from app.config / 
> web.config configuration
> * Make sure to include xml schema



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

[jira] [Closed] (IGNITE-2457) Implement Getting started dialog

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Implement Getting started dialog
> 
>
> Key: IGNITE-2457
> URL: https://issues.apache.org/jira/browse/IGNITE-2457
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
> Fix For: 1.6
>
>
> Implement dialog to show features of Console on first input into system.



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

[jira] [Assigned] (IGNITE-2364) Error on Cancel in 'Discard changes' confirmation

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-2364:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

If this failed only under FF lets close this issue.

> Error on Cancel in 'Discard changes' confirmation
> -
>
> Key: IGNITE-2364
> URL: https://issues.apache.org/jira/browse/IGNITE-2364
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> 1) add new cache
> 2) set name, do not save
> 3) click 'Add cache' - confirmation appears
> 4) click Cancel
> {code}
> 17:33:45.760 "Error: [$rootScope:inprog] $apply already in progress
> http://errors.angularjs.org/1.4.8/$rootScope/inprog?p0=%24apply
> minErr/<@https://staging-console.gridgain.com/app.min.js:82926:18
> beginPhase@https://staging-console.gridgain.com/app.min.js:90679:1
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90415:15
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90547:19
> timeout/timeoutId<@https://staging-console.gridgain.com/app.min.js:91115:17
> completeOutstandingRequest@https://staging-console.gridgain.com/app.min.js:85333:13
> Browser/self.defer/timeoutId<@https://staging-console.gridgain.com/app.min.js:85462:13
> .confirmUnsavedChanges@https://staging-console.gridgain.com/common-module.js:878:25
> $scope.selectItem@https://staging-console.gridgain.com/all.js:550:1
> $scope.createItem@https://staging-console.gridgain.com/all.js:578:21
> anonymous/fn@https://staging-console.gridgain.com/app.min.js line 88902 > 
> Function:2:218
> ngEventHandler/https://staging-console.gridgain.com/app.min.js:92593:21
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90516:22
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90539:26
> ngEventHandler/<@https://staging-console.gridgain.com/app.min.js:92598:21
> jQuery.event.dispatch@https://staging-console.gridgain.com/app.min.js:122683:25
> jQuery.event.add/elemData.handle@https://staging-console.gridgain.com/app.min.js:122554:91
> "1 app.min.js:88108:24
> consoleLog/<() app.min.js:88108
> $ExceptionHandlerProvider/this.$get $RootScopeProvider/this.$get timeout/timeoutId<() app.min.js:91115
> completeOutstandingRequest() app.min.js:85333
> Browser/self.defer/timeoutId<() app.min.js:85462
> .confirmUnsavedChanges() common-module.js:878
> $scope.selectItem() all.js:550
> $scope.createItem() all.js:578
> anonymous/fn() app.min.js line 88902 > Function:2
> ngEventHandler/ $RootScopeProvider/this.$get $RootScopeProvider/this.$get ngEventHandler/<() app.min.js:92598
> jQuery.event.dispatch() app.min.js:122683
> jQuery.event.add/elemData.handle() app.min.js:122554
> {code}



--
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:

Assignee: Semen Boikov

> 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
>Assignee: Semen Boikov
>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-2310) Add lock/unlock partition operations on IgniteCache

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2310:

Assignee: Semen Boikov

> Add lock/unlock partition operations on IgniteCache
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.6
>
>
> Need to add public API methods that will allow to lock and unlock partitions. 
> This may be useful to avoid data movements when using {{affinityRun}} during 
> topology changes.



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

[jira] [Commented] (IGNITE-2509) Broken eviction and metrics for OFFHEAP_VALUES cache mode

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2509:
-

Vladimir,

Please refer to the attached EvictionBug.java. If I start the app using the 
following cfg {{offHeapValues(cacheCfg);}} then I see that the offheap 
allocated size is 0
{{onHeap=5,offEnt = 0, offAlloc = 0, swap = 3567, cache_size = 3572}}


> Broken eviction and metrics for OFFHEAP_VALUES cache mode
> -
>
> Key: IGNITE-2509
> URL: https://issues.apache.org/jira/browse/IGNITE-2509
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: EvictionBug.java, eviction_fix.patch
>
>
> In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
> values size wrongly which leads to the fact that data is evicted only when 
> either the limit on number of entries is reached or size of keys is bigger 
> than max allowed size.
> To reproduce set the following cache configuration
> {noformat}
> FifoEvictionPolicy plc = new FifoEvictionPolicy();
> plc.setMaxMemorySize(2 * 1024 * 1024);
> cacheCfg.setEvictionPolicy(plc);
> cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
> cacheCfg.setSwapEnabled(true);
> {noformat}
> Test that reproduces the issue is attached.
> Also attached a patch that fixes the issue. However we should validate that 
> the fix is full and add additional tests to the test suites.
> Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
> this cache mode. Has to be fixed as well.



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

[jira] [Closed] (IGNITE-2596) The downloaded project zip-file has no compression

[Pavel Konstantinov (JIRA)]

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

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

Tested

> The downloaded project zip-file has no compression
> --
>
> Key: IGNITE-2596
> URL: https://issues.apache.org/jira/browse/IGNITE-2596
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> I've noticed that our downloaded zip-file has no compression
> Please verify the options.



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

[jira] [Created] (IGNITE-2597) rework transport layer to websocket

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-2597:
-

 Summary: rework transport layer to websocket
 Key: IGNITE-2597
 URL: https://issues.apache.org/jira/browse/IGNITE-2597
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitriyff






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

[jira] [Assigned] (IGNITE-2597) rework transport layer to websocket

[Dmitriyff (JIRA)]

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

Dmitriyff reassigned IGNITE-2597:
-

Assignee: Dmitriyff

> rework transport layer to websocket
> ---
>
> Key: IGNITE-2597
> URL: https://issues.apache.org/jira/browse/IGNITE-2597
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Dmitriyff
>Assignee: Dmitriyff
> Fix For: 1.6
>
>




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

[jira] [Closed] (IGNITE-2351) Rework metadata creation

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-2351.

Assignee: (was: Alexey Kuznetsov)

> Rework metadata creation
> 
>
> Key: IGNITE-2351
> URL: https://issues.apache.org/jira/browse/IGNITE-2351
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.5.0.final
>Reporter: Alexey Kuznetsov
> Fix For: 1.6
>
>
> Add possibility to associate / create cache when creating metadata manually.



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

[jira] [Updated] (IGNITE-1575) NPE when cache is started concurrently with the node stop

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-1575:

Assignee: Andrey Gura

> NPE when cache is started concurrently with the node stop
> -
>
> Key: IGNITE-1575
> URL: https://issues.apache.org/jira/browse/IGNITE-1575
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> It's not causing any harm, but it's possible to get the NPE below during the 
> node stop.
> {noformat}
> 57724 [main] ERROR IgniteKernal%t1-1 - Got exception while starting (will 
> rollback startup routine).
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onKernalStart0(CacheContinuousQueryManager.java:91)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStart(GridCacheManagerAdapter.java:97)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:1058)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:833)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1549)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1416)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:916)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> .. application stack frames ...
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}



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

[jira] [Commented] (IGNITE-2369) Implement ability to close opened modal after browser navigation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2369:


GitHub user Dmitriyff opened a pull request:

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

IGNITE-2369 added ability to auto close popup after broswer navigation



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

$ git pull https://github.com/Dmitriyff/ignite ignite-2369

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

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


commit 7ede9440a9fabe9a1d07d8ba38f2b4c314fc2555
Author: Dmitriyff 
Date:   2016-02-09T08:32:16Z

IGNITE-2369 added ability to auto close modal dialog, after browser 
navigation

commit d3cec64ece8e92b69c01497f84584788d07cfa88
Author: Dmitriyff 
Date:   2016-02-09T08:32:52Z

Merge remote-tracking branch 'apache/ignite-843-rc2' into ignite-2369




> Implement ability to close opened modal after browser navigation
> 
>
> Key: IGNITE-2369
> URL: https://issues.apache.org/jira/browse/IGNITE-2369
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Dmitriyff
>Assignee: Dmitriyff
>
> Implement common method to close opened dialogs after browser navigation



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-1553:

Assignee: Alexey Goncharuk

> 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
>Assignee: 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-2455) SQL query fails if there are caches that were never used on this client

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2455:

Assignee: Sergi Vladykin

> SQL query fails if there are caches that were never used on this client
> ---
>
> Key: IGNITE-2455
> URL: https://issues.apache.org/jira/browse/IGNITE-2455
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Sergi Vladykin
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
> Attachments: QueryTest.java
>
>
> Test attached.
> If SQL query contains caches that were never acquired on the current client, 
> it fails with the following exception:
> {noformat}
> org.h2.jdbc.JdbcSQLException: Schema "cache2" not found;
> {noformat}
> We should automatically detect the list of required caches and create them 
> before executing the query.



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

[jira] [Updated] (IGNITE-2546) Need to introduce transformers to SCAN queries

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2546:

Assignee: Sergi Vladykin

> Need to introduce transformers to SCAN queries
> --
>
> Key: IGNITE-2546
> URL: https://issues.apache.org/jira/browse/IGNITE-2546
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Valentin Kulichenko
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>
> Need to introduce new query type:
> {code}
> public final class ScanTransformQuery extends Query {
> private final IgniteBiPredicate filter;
> private final int part;
> private final IgniteClosure, R> transformer;
> 
> // ... Constructors, getters, setters, etc. Use ScanQuery class as a 
> template.
> }
> {code}
> Transformer is mandatory. If it's not set, the exception should be thrown 
> suggesting to use {{ScanQuery}} instead.



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

[jira] [Commented] (IGNITE-2587) Unexpected exception during cache update

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-2587:
--

Investigated, there are two issues:
- temporary object created over offheap pointer (BinaryObjectOffheapImpl) is 
not unwrapped in OFFHEAP_VALUES mode
- for OFFHEAP_VALUES, OFFHEAP_TIERED modes old value is not always deserialized 
for continous query

Need to add continous query tests for OFFHEAP_VALUES, OFFHEAP_TIERED modes, 
also tests should use not only primitive keys/values,

> Unexpected exception during cache update
> 
>
> Key: IGNITE-2587
> URL: https://issues.apache.org/jira/browse/IGNITE-2587
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
> Environment: Windows 10, Oracle JDK 1.7.0_80-b15
>Reporter: Sergey Kozlov
>Assignee: Semen Boikov
>Priority: Critical
> Attachments: client_output.txt, ignite-33cb560a.0.log, 
> ignite-5e9294d1.0.log, server_output.txt
>
>
> 1. Start server node
> 2. Start client node (see the code in IGNITE-2586)
> 3. Server node failed:
> {noformat}
> [16:05:03,866][SEVERE][sys-#17%null%][GridDhtAtomicCache] 
>  Unexpected exception during cache update
> java.lang.UnsupportedOperationException
>   at 
> org.apache.ignite.internal.binary.BinaryObjectOffheapImpl.finishUnmarshal(BinaryObjectOffheapImpl.java:363)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:243)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2070)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1407)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1282)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2692)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:128)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:257)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:255)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:821)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:784)
>   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] [Closed] (IGNITE-2369) Implement ability to close opened modal after browser navigation

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Implement ability to close opened modal after browser navigation
> 
>
> Key: IGNITE-2369
> URL: https://issues.apache.org/jira/browse/IGNITE-2369
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Dmitriyff
> Fix For: 1.6
>
>
> Implement common method to close opened dialogs after browser navigation



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

[jira] [Reopened] (IGNITE-2509) Broken eviction and metrics for OFFHEAP_VALUES cache mode

[Vladimir Ershov (JIRA)]

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

Vladimir Ershov reopened IGNITE-2509:
-
  Assignee: Vladimir Ershov  (was: Denis Magda)

testPutOnHeap misses getOffHeapAllocatedSize check.

> Broken eviction and metrics for OFFHEAP_VALUES cache mode
> -
>
> Key: IGNITE-2509
> URL: https://issues.apache.org/jira/browse/IGNITE-2509
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ershov
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: EvictionBug.java, eviction_fix.patch
>
>
> In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
> values size wrongly which leads to the fact that data is evicted only when 
> either the limit on number of entries is reached or size of keys is bigger 
> than max allowed size.
> To reproduce set the following cache configuration
> {noformat}
> FifoEvictionPolicy plc = new FifoEvictionPolicy();
> plc.setMaxMemorySize(2 * 1024 * 1024);
> cacheCfg.setEvictionPolicy(plc);
> cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
> cacheCfg.setSwapEnabled(true);
> {noformat}
> Test that reproduces the issue is attached.
> Also attached a patch that fixes the issue. However we should validate that 
> the fix is full and add additional tests to the test suites.
> Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
> this cache mode. Has to be fixed as well.



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

[jira] [Commented] (IGNITE-2222) CPP: Implement Date data type support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-:
-

It seems that Java {{Date}} type is actually a number of *milliseconds* since 
epoch (i.e. January 1, 1970, 00:00:00 GMT) stored as an 64-bit integer. 
Unfortunately, there are no time types in C++ standard library except for C++11 
Chrono library, which is not supported by VS 2010 which we need to support. 
However, there is C time library which has {{time_t}} type. Unfortunately, this 
type's structure and content is implementation-specific, though it is generally 
implemented as an integral value representing the number of *seconds* elapsed 
since epoch.

So here is proposed solution - add {{ignite::Date}} type, that would contain 
milliseconds since epoch inside. This way we can store Java {{Date}} without 
losing precision and we still can use it in C++ using standard C library 
functions if we convert milliseconds to seconds which is trivial. 

> CPP: Implement Date data type support for binary protocol.
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>
> It is needed to implement {{Date}} data type support because some SQL queries 
> return data of that type and we need to be able to deserialize it on the C++ 
> client side.



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

[jira] [Commented] (IGNITE-2509) Broken eviction and metrics for OFFHEAP_VALUES cache mode

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2509:
-

Alex,

The eviction works for now but {{cache.metrics().getOffHeapAllocatedSize()}} 
still returns {{0}}.

> Broken eviction and metrics for OFFHEAP_VALUES cache mode
> -
>
> Key: IGNITE-2509
> URL: https://issues.apache.org/jira/browse/IGNITE-2509
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: EvictionBug.java, eviction_fix.patch
>
>
> In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
> values size wrongly which leads to the fact that data is evicted only when 
> either the limit on number of entries is reached or size of keys is bigger 
> than max allowed size.
> To reproduce set the following cache configuration
> {noformat}
> FifoEvictionPolicy plc = new FifoEvictionPolicy();
> plc.setMaxMemorySize(2 * 1024 * 1024);
> cacheCfg.setEvictionPolicy(plc);
> cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
> cacheCfg.setSwapEnabled(true);
> {noformat}
> Test that reproduces the issue is attached.
> Also attached a patch that fixes the issue. However we should validate that 
> the fix is full and add additional tests to the test suites.
> Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
> this cache mode. Has to be fixed as well.



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

[jira] [Updated] (IGNITE-2560) Support injections in entry processors

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2560:

Assignee: Semen Boikov

> Support injections in entry processors
> --
>
> Key: IGNITE-2560
> URL: https://issues.apache.org/jira/browse/IGNITE-2560
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
> Fix For: 1.6
>
>
> Currently resources are not injected in entry processor, which is not 
> consistent with other functionality, like closures, jobs, listeners, etc.
> To avoid performance degradation we should introspect the class only once, 
> cache this information and do not try to inject if there are no annotations.



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

[jira] [Updated] (IGNITE-2559) Transaction hangs if entry processor is not serializable

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2559:

Assignee: Alexey Goncharuk

> Transaction hangs if entry processor is not serializable
> 
>
> Key: IGNITE-2559
> URL: https://issues.apache.org/jira/browse/IGNITE-2559
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 1.6
>
> Attachments: TxTest.java
>
>
> Test attached.
> If entry processor doesn't implement {{Serializable}}, the exception is 
> thrown, but transaction hangs forever. If you try to join more nodes after 
> this happens, they will not be able to do this as well.
> Hanged thread dump:
> {noformat}
> "main" #1 prio=5 os_prio=31 tid=0x7f8b6580 nid=0x1703 waiting on 
> condition [0x70218000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x00076ca274f8> (a 
> org.apache.ignite.internal.util.future.GridEmbeddedFuture)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$24.op(GridCacheAdapter.java:2296)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$24.op(GridCacheAdapter.java:2283)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4291)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2283)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2261)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1518)
>   at TxTest.main(TxTest.java:27)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}



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

[jira] [Resolved] (IGNITE-2369) Implement ability to close opened modal after browser navigation

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2369.
--
   Resolution: Fixed
 Assignee: Pavel Konstantinov  (was: Dmitriyff)
Fix Version/s: 1.6

Fixed on staging

> Implement ability to close opened modal after browser navigation
> 
>
> Key: IGNITE-2369
> URL: https://issues.apache.org/jira/browse/IGNITE-2369
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Dmitriyff
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> Implement common method to close opened dialogs after browser navigation



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

[jira] [Created] (IGNITE-2598) Enum arguments in SQL queries are not considered with BinaryMarshaller

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2598:
---

 Summary: Enum arguments in SQL queries are not considered with 
BinaryMarshaller
 Key: IGNITE-2598
 URL: https://issues.apache.org/jira/browse/IGNITE-2598
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Assignee: Vladimir Ozerov
 Fix For: 1.6


Queries like the one below doesn't work with {{Enum}} returning a wrong result 
when binary marshaller is used.

{noformat}
SqlQuery query = new SqlQuery(Event.class, "type = 
?");
query.setArgs(EventType.EventA);
{noformat}

The same query works perfectly fine if optimized marshaller is enabled instead.

Attached the test that reproduces the issue.



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

[jira] [Closed] (IGNITE-2595) Allow to save cache with store settings and no one model linked to cache

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Allow to save cache with store settings and no one model linked to cache
> 
>
> Key: IGNITE-2595
> URL: https://issues.apache.org/jira/browse/IGNITE-2595
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> Currently we disallow to user to save cache if it has store setting but has 
> no one model assigned to it. This case is correct and we need to allow to 
> save cache.



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

[jira] [Closed] (IGNITE-2551) Next query page result link should be locked on loading of next page.

[Pavel Konstantinov (JIRA)]

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

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

Tested

> Next query page result link should be locked on loading of next page.
> -
>
> Key: IGNITE-2551
> URL: https://issues.apache.org/jira/browse/IGNITE-2551
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
> Fix For: 1.6
>
>
> In case of quick clicking by next link a request is sent on every click. 
> On some click request error is returned.



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

[jira] [Resolved] (IGNITE-2482) Unsaved changes confirmation partially does not work

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2482.
--
   Resolution: Cannot Reproduce
Fix Version/s: 1.6

Pavel, if this failed only under FF, lets close this issue.

> Unsaved changes confirmation partially does not work
> 
>
> Key: IGNITE-2482
> URL: https://issues.apache.org/jira/browse/IGNITE-2482
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.6
>
>
> # Add new cluster
> # Save it
> # Change name and click another link or [Clone]
> Expected
> Dialog with warning about unsaved changes should be shown.



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

[jira] [Updated] (IGNITE-2482) Unsaved changes confirmation partially does not work

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2482:
-
Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Unsaved changes confirmation partially does not work
> 
>
> Key: IGNITE-2482
> URL: https://issues.apache.org/jira/browse/IGNITE-2482
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> # Add new cluster
> # Save it
> # Change name and click another link or [Clone]
> Expected
> Dialog with warning about unsaved changes should be shown.



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

[jira] [Closed] (IGNITE-2364) Error on Cancel in 'Discard changes' confirmation

[Pavel Konstantinov (JIRA)]

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

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

Reproduced only in Firefox.

> Error on Cancel in 'Discard changes' confirmation
> -
>
> Key: IGNITE-2364
> URL: https://issues.apache.org/jira/browse/IGNITE-2364
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> 1) add new cache
> 2) set name, do not save
> 3) click 'Add cache' - confirmation appears
> 4) click Cancel
> {code}
> 17:33:45.760 "Error: [$rootScope:inprog] $apply already in progress
> http://errors.angularjs.org/1.4.8/$rootScope/inprog?p0=%24apply
> minErr/<@https://staging-console.gridgain.com/app.min.js:82926:18
> beginPhase@https://staging-console.gridgain.com/app.min.js:90679:1
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90415:15
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90547:19
> timeout/timeoutId<@https://staging-console.gridgain.com/app.min.js:91115:17
> completeOutstandingRequest@https://staging-console.gridgain.com/app.min.js:85333:13
> Browser/self.defer/timeoutId<@https://staging-console.gridgain.com/app.min.js:85462:13
> .confirmUnsavedChanges@https://staging-console.gridgain.com/common-module.js:878:25
> $scope.selectItem@https://staging-console.gridgain.com/all.js:550:1
> $scope.createItem@https://staging-console.gridgain.com/all.js:578:21
> anonymous/fn@https://staging-console.gridgain.com/app.min.js line 88902 > 
> Function:2:218
> ngEventHandler/https://staging-console.gridgain.com/app.min.js:92593:21
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90516:22
> $RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:90539:26
> ngEventHandler/<@https://staging-console.gridgain.com/app.min.js:92598:21
> jQuery.event.dispatch@https://staging-console.gridgain.com/app.min.js:122683:25
> jQuery.event.add/elemData.handle@https://staging-console.gridgain.com/app.min.js:122554:91
> "1 app.min.js:88108:24
> consoleLog/<() app.min.js:88108
> $ExceptionHandlerProvider/this.$get $RootScopeProvider/this.$get timeout/timeoutId<() app.min.js:91115
> completeOutstandingRequest() app.min.js:85333
> Browser/self.defer/timeoutId<() app.min.js:85462
> .confirmUnsavedChanges() common-module.js:878
> $scope.selectItem() all.js:550
> $scope.createItem() all.js:578
> anonymous/fn() app.min.js line 88902 > Function:2
> ngEventHandler/ $RootScopeProvider/this.$get $RootScopeProvider/this.$get ngEventHandler/<() app.min.js:92598
> jQuery.event.dispatch() app.min.js:122683
> jQuery.event.add/elemData.handle() app.min.js:122554
> {code}



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

[jira] [Resolved] (IGNITE-2599) Unsaved changes doesn't appear on Clone cache\igfs\model

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-2599.

Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Andrey Novikov)

Fixed. Pavel, please test

> Unsaved changes doesn't appear on Clone cache\igfs\model
> 
>
> Key: IGNITE-2599
> URL: https://issues.apache.org/jira/browse/IGNITE-2599
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>




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

[jira] [Commented] (IGNITE-2222) CPP: Implement Date and Timestamp data types support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-:
-

By analogy {{ignite::Timestamp}} is going to contain seconds and nanoseconds.

> CPP: Implement Date and Timestamp data types support for binary protocol.
> -
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> It is needed to implement {{Date}} and {{Timestamp }} data types support 
> because some SQL queries return data of such types and we need to be able to 
> deserialize it on the C++ client side.



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

[jira] [Resolved] (IGNITE-2566) Get rid of MiniFutures in GridDhtTxPrepareFuture

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh resolved IGNITE-2566.
--
Resolution: Not A Problem

> Get rid of MiniFutures in GridDhtTxPrepareFuture
> 
>
> Key: IGNITE-2566
> URL: https://issues.apache.org/jira/browse/IGNITE-2566
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
> Fix For: 1.6
>
>
> GridDhtTxPrepareFuture is instantiated for every transaction. In uses 
> compound future + minifutures concept, which is an overhead for it's rather 
> simple logic.
> It should be refactored to store miniId to request mapping internally and 
> update it's state on every response without generating additional objects.



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

[jira] [Resolved] (IGNITE-2567) Grouping

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-2567.

Resolution: Implemented

> Grouping
> 
>
> Key: IGNITE-2567
> URL: https://issues.apache.org/jira/browse/IGNITE-2567
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>




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

[jira] [Closed] (IGNITE-2567) Grouping

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn closed IGNITE-2567.
--

> Grouping
> 
>
> Key: IGNITE-2567
> URL: https://issues.apache.org/jira/browse/IGNITE-2567
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>




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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2523:


GitHub user ilantukh opened a pull request:

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

IGNITE-2523



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

$ git pull https://github.com/ilantukh/ignite ignite-2523

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

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


commit 466528329942f009c9e591a16b9453b95830b0cb
Author: vozerov-gridgain 
Date:   2016-02-03T07:24:01Z

IGNITE-2532: WIP. Only refactorings for now.

commit 29c2aee6b6ffac4f27da3732575f7d82b0e8bedd
Author: vozerov-gridgain 
Date:   2016-02-03T08:09:13Z

IGNITE-2532: WIP. Only refactorings for now.

commit 2a1a31d2d0999fdb8854a05fd7a75a4cd0b159a4
Author: vozerov-gridgain 
Date:   2016-02-03T08:36:39Z

IGNITE-2532: Single update request is finalyl wired up. Though, it is not 
optimzied yet.

commit 52d20cdcdc886c6ceaed49239e822a1d6deaa7dd
Author: vozerov-gridgain 
Date:   2016-02-03T09:03:31Z

IGNITE-2532: WIP on single message optimization.

commit 89c8074452b4bc209eb03d758e534f0ef8365d46
Author: vozerov-gridgain 
Date:   2016-02-03T09:08:18Z

IGNITE-2532: WIP on single message optimization.

commit 07c23931f9758497db50bf0851af5d6c0fb8eaa4
Author: vozerov-gridgain 
Date:   2016-02-03T09:45:42Z

IGNITE-2532: Reverting changes to GridNearAtomicUpdateFuture.

commit e066650cf4907851dca1d8ef0297f6a1522d6a87
Author: vozerov-gridgain 
Date:   2016-02-03T12:02:52Z

Merge branch 'master' into ignite-2523

commit 3967130f54fa21d25e7e284ecabaf004b937b921
Author: vozerov-gridgain 
Date:   2016-02-03T12:53:07Z

IGNITE-2523: Finalization.

commit 3d34e50c9ece0d12e35a0ff6130659cfa03bdddf
Author: vozerov-gridgain 
Date:   2016-02-04T07:44:33Z

Merge branch 'master' into ignite-2523

commit d3e1645aaeb8fd9393744cb087a9ddde27f2e95b
Author: vozerov-gridgain 
Date:   2016-02-04T07:52:48Z

IGNITE-2523: Fixed message count tests.

commit 0128f988c60cdbd9aec6996626b6ffb1ad1fa30e
Author: vozerov-gridgain 
Date:   2016-02-04T07:54:25Z

IGNITE-2523: Fixed IgniteCacheAtomicStopBusySelfTest.

commit 7e09a146acefccc885e78c57ca85f754d4db5d45
Author: vozerov-gridgain 
Date:   2016-02-04T07:59:59Z

IGNITE-2523: Fixed several other tests.

commit c54873bba2b2a0777a7ade33f5ec3da82c96ce95
Author: vozerov-gridgain 
Date:   2016-02-04T08:04:58Z

IGNITE-2523: Renaming: interface -> base.

commit e83408060970aba8f3f98ec7be1d96bab4fa888c
Author: vozerov-gridgain 
Date:   2016-02-04T09:05:56Z

IGNITE-2523: Fixing tests.

commit 1491c1f494e47618191ae7e4f79c67a5fdd9a326
Author: vozerov-gridgain 
Date:   2016-02-05T07:04:04Z

IGNITE-2523: Renamings.

commit 11a27f74f5a85320f6473a4cd2e59e35459cc587
Author: vozerov-gridgain 
Date:   2016-02-05T07:07:02Z

Merge branch 'master' into ignite-2523

commit a18c352748a86ac9e48885f1b6ae93ff9ed4f4dd
Author: vozerov-gridgain 
Date:   2016-02-05T07:09:48Z

IGNITE-2523: Minors.

commit dfdd2f4f907651a86da6fd52f18d2f189f65279d
Author: Ilya Lantukh 
Date:   2016-02-08T14:23:02Z

ignite-2523 : Created SingleUpdateResponse

commit c39410a2dbbab7e8886a407a5661b29ee985adce
Author: Ilya Lantukh 
Date:   2016-02-08T15:05:34Z

ignite-2523 : SingleUpdateResponse implementation.

commit 3c8d02a00b2bcbc194fd2112d9f8cb58ab7d571a
Author: Ilya Lantukh 
Date:   2016-02-08T15:25:21Z

ignite-2523 : Generalized usage of GridNearAtomicUpdateRequest/Response.

commit cb5bdb3f19cefe14380ac169d49e6e86bde1899a
Author: Ilya Lantukh 
Date:   2016-02-08T15:51:55Z

ignite-2523 : Generalized usage of GridNearAtomicUpdateRequest/Response.

commit 4f8220e6da06443f1ef42ac3f4b4e46f5100dcd1
Author: Ilya Lantukh 
Date:   2016-02-09T11:38:12Z

ignite-2523 : finished generalization of GridNearAtomicUpdate.

commit 2f6aff8024794cd980fd77bb96e9a74876fb7442
Author: Ilya Lantukh 
Date:   2016-02-09T12:04:52Z

ignite-2523 : Fixed failing tests.

commit 6040f45eae844fd40c113de452e70078dae9a95c
Author: Ilya Lantukh 
Date:   2016-02-09T13:14:57Z

ignite-2523 : Fixed test failures.

[jira] [Commented] (IGNITE-2566) Get rid of MiniFutures in GridDhtTxPrepareFuture

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-2566:
--

Similar to https://issues.apache.org/jira/browse/IGNITE-2533, there is no 
significant performance increase.

> Get rid of MiniFutures in GridDhtTxPrepareFuture
> 
>
> Key: IGNITE-2566
> URL: https://issues.apache.org/jira/browse/IGNITE-2566
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
> Fix For: 1.6
>
>
> GridDhtTxPrepareFuture is instantiated for every transaction. In uses 
> compound future + minifutures concept, which is an overhead for it's rather 
> simple logic.
> It should be refactored to store miniId to request mapping internally and 
> update it's state on every response without generating additional objects.



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

[jira] [Assigned] (IGNITE-2579) Investigate HashMap.Node[] allocations from GridCacheMvccManager$3

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-2579:


Assignee: Ilya Lantukh

> Investigate HashMap.Node[] allocations from GridCacheMvccManager$3
> --
>
> Key: IGNITE-2579
> URL: https://issues.apache.org/jira/browse/IGNITE-2579
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ilya Lantukh
> Fix For: 1.6
>
>
> *Problem* 
> See GridCacheMvccManager.addFuture() method. We create a weird HashSet there 
> with internal table size == 5. Can we have something more efficient here?
> *Proposed solution*
> Need to run single get-put benchmarks and check usual size of this 
> collection. If it is often equal to 1, then instead of allocating the whole 
> collection, we'd better to have a singleton first and expand to collection if 
> there are more elements. 
> Please pay attention that collection usually used as monitor in some 
> synchronized blocks.



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

[jira] [Commented] (IGNITE-2533) Get rid of GridCompoundFuture and MiniFutures in GridNearLockFuture.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-2533:
--

As seen on provided benchmarks, performance increase from this optimization is 
insignificant and lies within error bounds.

> Get rid of GridCompoundFuture and MiniFutures in GridNearLockFuture.
> 
>
> Key: IGNITE-2533
> URL: https://issues.apache.org/jira/browse/IGNITE-2533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
> Fix For: 1.6
>
>
> MiniFutures contain data and synchronization logic which isn't needed in this 
> particular case. Removing it might reduce memory consumption and improve 
> performance.



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

[jira] [Commented] (IGNITE-2222) CPP: Implement Date and Timestamp data types support for binary protocol.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-:


GitHub user isapego opened a pull request:

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

IGNITE-: Implemented Date and Timestamp classes.



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

$ git pull https://github.com/isapego/ignite ignite-

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

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


commit a55f1b5c737e4380ee9e50c0f2bd473904ec08f8
Author: isapego 
Date:   2016-02-08T15:56:47Z

IGNITE-: Test for the Date type added.

commit 39186f4042b7453026bc7eaf088ed5c7b3462f70
Author: isapego 
Date:   2016-02-08T16:39:59Z

IGNITE-: Added ignite::Date class.

commit d7bf440fa0eff01babaf0979a4ea0827561f7500
Author: isapego 
Date:   2016-02-08T16:51:46Z

IGNITE-: Added Date reading and writing to binary utils.

commit 35a6e1edd7c9a1207b035935f86671c787618b45
Author: isapego 
Date:   2016-02-08T17:03:12Z

IGNITE-: Added Date to BinaryWriterImpl.

commit af8b0db6247352ae16c93c65a898255774773173
Author: isapego 
Date:   2016-02-08T17:19:36Z

IGNITE-: Added specialisation WriteTopObject.

commit 6f86354fd4ad3f2c0ac62ba3e5333551c6233805
Author: isapego 
Date:   2016-02-08T17:24:20Z

IGNITE-: BinaryRawWriter::WriteDate[Array] implemented.

commit 34bb1d68e096e083a85868dcf473f920e54c0af2
Author: isapego 
Date:   2016-02-08T18:05:37Z

IGNITE-: Implemented BinaryReaderImpl::ReadDate[Array].

commit b03b9bfc969d76f76e4a6e5fa401061b919cad47
Author: isapego 
Date:   2016-02-08T18:08:32Z

IGNITE-: Implemented BinaryRaqReader::ReadDate[Array].

commit e36f03bc5b16a074ab9308791d38a35b9bab1d72
Author: isapego 
Date:   2016-02-08T18:21:15Z

IGNITE-: Fix for the test.

commit 0a4b2e326b99a38336832a1289ae1461697efb3b
Author: isapego 
Date:   2016-02-08T18:28:58Z

IGNITE-: Added test for DateArray.

commit f08029aeb96a887c679f821f488b5d22b7a612fb
Author: isapego 
Date:   2016-02-08T18:44:16Z

IGNITE-: Added BinaryWriter::WriteDate[Array].

commit e80350a4a0ae7bb5ab714f0bcb21b3b14236a8d8
Author: isapego 
Date:   2016-02-08T18:47:53Z

IGNITE-: Added BinaryReader::ReadDate[Array].

commit 7428a3b1b3937d36f048916aeb773a2f058373f3
Author: isapego 
Date:   2016-02-08T19:06:36Z

IGNITE-: Tests for Date type reworked.

commit 14d921b89c6d89e0368a044bd3eeff4e4f6a503f
Author: isapego 
Date:   2016-02-09T13:12:26Z

IGNITE-: Added timestamp class.

commit 0263b602c85f0f5f5c94fb80d4571612fb923813
Author: isapego 
Date:   2016-02-09T13:28:56Z

IGNITE-: Added binary utils for Timestamp.

commit 937248c3ace1b070c1c558c7fe17ce2864e735a4
Author: isapego 
Date:   2016-02-09T13:36:48Z

IGNITE-: Timestamp binary type added.

commit 37db4a2a748582b7a83b51fdf46f8648e1fa4f87
Author: isapego 
Date:   2016-02-09T13:41:56Z

IGNITE-: Added BinaryWriterImpl::WriteTimestamp[Array]().

commit a5583a79bbfec3157ae595b7c22cefc3be614706
Author: isapego 
Date:   2016-02-09T13:51:03Z

IGNITE-: Added BinaryReaderImpl::ReadTimestamp[Array]().

commit 8e1a023ff3fbc480a9c6f17a239f7e11ce04f63b
Author: isapego 
Date:   2016-02-09T13:57:05Z

IGNITE-: Added BinaryWriter::WriteTimestamp[Array]().

commit 8a851fd65a69231ff7477882554143a9f085bfcb
Author: isapego 
Date:   2016-02-09T13:59:17Z

IGNITE-: Added BinaryReader::ReadTimestamp[Array]().

commit e4f2cdf5e0c7cbffd287c024191caff5e5bed9e1
Author: isapego 
Date:   2016-02-09T14:01:11Z

IGNITE-: Added BinaryRawReader::ReadTimestamp[Array]().

commit 26cd9ea51d1f627be21ad2aee3632602b3cf5126
Author: isapego 
Date:   2016-02-09T14:04:06Z

GNITE-: Added BinaryRawWriter::WriteTimestamp[Array]().

commit 67cacde49c67a5c86f88c3adf8873b27e1a4
Author: isapego 
Date:   2016-02-09T14:14:40Z

IGNITE-: Added tests for Timestamp binary type.




> CPP: Implement Date and Timestamp data types support for binary protocol.
> -
>
> Key: IGNITE-
> URL: 

[jira] [Resolved] (IGNITE-2533) Get rid of GridCompoundFuture and MiniFutures in GridNearLockFuture.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh resolved IGNITE-2533.
--
Resolution: Unresolved

> Get rid of GridCompoundFuture and MiniFutures in GridNearLockFuture.
> 
>
> Key: IGNITE-2533
> URL: https://issues.apache.org/jira/browse/IGNITE-2533
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
> Fix For: 1.6
>
>
> MiniFutures contain data and synchronization logic which isn't needed in this 
> particular case. Removing it might reduce memory consumption and improve 
> performance.



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

[jira] [Updated] (IGNITE-2222) CPP: Implement Date and Timestamp data types support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-:

Description: It is needed to implement {{Date}} and {{Timestamp}} data 
types support because some SQL queries return data of such types and we need to 
be able to deserialize it on the C++ client side.  (was: It is needed to 
implement {{Date}} and {{Timestamp }} data types support because some SQL 
queries return data of such types and we need to be able to deserialize it on 
the C++ client side.)

> CPP: Implement Date and Timestamp data types support for binary protocol.
> -
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> It is needed to implement {{Date}} and {{Timestamp}} data types support 
> because some SQL queries return data of such types and we need to be able to 
> deserialize it on the C++ client side.



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

[jira] [Commented] (IGNITE-2448) Ignite based second level cache for MyBatis

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2448:
-

Roman, seems that I missed one important point.

We can't share several CacheConfiguration properties among different caches in 
all the cases. Among these properties are EvictionPolicy, CacheLoaderFactory, 
CacheWriterFactory. I would simply set them to null explicitly after this call

{{cacheCfg = (CacheConfiguration)factory.getBean("templateCacheCfg");}}

There is no need to support extensive functionality for myBatis in any case. 

Also let's print a warning when we initialize a cache with default config
{{cacheCfg = new CacheConfiguration(id);}}

These are all the comments I have from my side. Please go ahead and send 
pull-request for review to myBatis community.

> Ignite based second level cache for MyBatis
> ---
>
> Key: IGNITE-2448
> URL: https://issues.apache.org/jira/browse/IGNITE-2448
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>
> MyBatis [1] has a concept of a second level cache.
> It makes sense to implement a module that will allow to use Ignite as a 
> second level cache for this framework.
> In particular the following has to be done:
> - introduce ignite-cache module that will be located in MyBatis GIT 
> repository [2]
> - implement MyBatis {{Cache}} interface [3]
> - there should be configs inside of the module for different exemplary cases 
> (server node with a single local cache; server node that is a part of some 
> cluster and caches mybatis data in replicatred or partitioned cache; client 
> nodes that connects to the cluster and works with the cache); 
> - add documentation about the integration on Ignite readme.io
> - as a reference you may refer to Hazelcast [4] or other implementation
> More on caches in MyBatis
> http://www.mybatis.org/mybatis-3/sqlmap-xml.html#cache
> [1] http://www.mybatis.org/
> [2] https://github.com/mybatis/
> [3] 
> https://github.com/mybatis/mybatis-3/blob/master/src/main/java/org/apache/ibatis/cache/Cache.java
> [4] https://github.com/mybatis/hazelcast-cache



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

[jira] [Created] (IGNITE-2601) ODBC: Add support for Date and Timestamp types.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2601:
---

 Summary: ODBC: Add support for Date and Timestamp types.
 Key: IGNITE-2601
 URL: https://issues.apache.org/jira/browse/IGNITE-2601
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


We need to add support for the {{Date}} and {{Timestamp}} types support in our 
ODBC driver implementation.



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

[jira] [Reopened] (IGNITE-2599) Unsaved changes doesn't appear on Clone cache\igfs\model

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reopened IGNITE-2599:

  Assignee: Andrey Novikov  (was: Pavel Konstantinov)

Works not properly:
1) add new cache, save
2) change cache name DON'T save
3) 'Clone'
4) unsaved changes is appear and if you click Yes then you got clone with 
another values

> Unsaved changes doesn't appear on Clone cache\igfs\model
> 
>
> Key: IGNITE-2599
> URL: https://issues.apache.org/jira/browse/IGNITE-2599
> 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] [Created] (IGNITE-2600) .NET: Do not serialize object if AtomicReference CAS succeeded.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2600:
---

 Summary: .NET: Do not serialize object if AtomicReference CAS 
succeeded.
 Key: IGNITE-2600
 URL: https://issues.apache.org/jira/browse/IGNITE-2600
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Pavel Tupitsyn
 Fix For: 1.6


See PlatformAtomicReference.processInStreamOutStream() method.
If CAS suceeded, then (cmp == res).

As such, instead of writing object in binary form to the stream, we can simply 
pass boolean flag indicating successful CAS.



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

[jira] [Updated] (IGNITE-2222) CPP: Implement Date data type support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-:

Fix Version/s: 1.6

> CPP: Implement Date data type support for binary protocol.
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> It is needed to implement {{Date}} data type support because some SQL queries 
> return data of that type and we need to be able to deserialize it on the C++ 
> client side.



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

[jira] [Updated] (IGNITE-169) [Failed test] GridSessionCheckpointSelfTest fails

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-169:
---
Fix Version/s: 1.6
  Description: 
{{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
time.

Just run test N times in a loop in order to reproduce it.

{noformat}
[19:04:17,405][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
clsLdr=IsolatedClassLoader{roleName='test'}, 
clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, loc=true, 
sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
 pendingUndeploy=false, undeployed=false, usage=0], 
taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
 sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
startTime=1454958227376, endTime=9223372036854775807, 
taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
failSpi=null, loadSpi=null, usage=0, fullSup=true, 
subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
[orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
at 
org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:666)
at 
org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest.checkCheckpoints(GridSessionCheckpointAbstractSelfTest.java:145)
at 
org.apache.ignite.session.GridSessionCheckpointSelfTest.testSharedFsCheckpoint(GridSessionCheckpointSelfTest.java:48)
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:1723)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
at java.lang.Thread.run(Thread.java:745)
{noformat}

  was:GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails from time to 
time 

   Issue Type: Test  (was: Bug)
  Summary: [Failed test] GridSessionCheckpointSelfTest fails  (was: 
GridSessionCheckpointSelfTest fails)

> [Failed test] GridSessionCheckpointSelfTest fails
> -
>
> Key: IGNITE-169
> URL: https://issues.apache.org/jira/browse/IGNITE-169
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Irina Vasilinets
> Fix For: 1.6
>
>
> {{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
> time.
> Just run test N times in a loop in order to reproduce it.
> {noformat}
> [19:04:17,405][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
> closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
> dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
> clsLdr=IsolatedClassLoader{roleName='test'}, 
> clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  pendingUndeploy=false, undeployed=false, usage=0], 
> taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
> startTime=1454958227376, endTime=9223372036854775807, 
> taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
> clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=0, fullSup=true, 
> subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
> endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
> at 
> 

[jira] [Commented] (IGNITE-2555) Include offheap usage in metrics report

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2555:
-

Corresponding code could be found in IgniteKernal class (look for the phrase 
"Metrics for local node").
Essentially, we need to process "m.getNonHeap*" methods in the same way as we 
did that for "m.getHeap*".

> Include offheap usage in metrics report
> ---
>
> Key: IGNITE-2555
> URL: https://issues.apache.org/jira/browse/IGNITE-2555
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Priority: Minor
>  Labels: newbie
>
> The local node prints out the set of key parameters in its log (or console). 
> It makes sense to add offheap usage (used/free/committed) to that report.
> {noformat}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=41b12e0f, name=null]
> ^-- H/N/C [hosts=1, nodes=14, CPUs=8]
> ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%]
> ^-- Heap [used=1364MB, free=27,44%, comm=1881MB]
> ^-- Public thread pool [active=0, idle=16, qSize=0]
> ^-- System thread pool [active=1, idle=15, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}



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

[jira] [Comment Edited] (IGNITE-2405) Ignite is blocking the thread in case it can't connect to the node

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-2405 at 2/9/16 12:48 PM:
--

[~maseev],

"Failed to send join request message" appears because the node tries to connect 
to itself.
 
The node tries to reconnect in a loop since you're using 
{{TcpDiscoveryVmIpFinder}}, that is not shared, and because local node's 
addresses are not found in the list of registered addresses in the IP finder. A 
local node's address has to be specified in this kind of IP finders explicitly 
[1].

Due to network related issue on my side I can't take a look at your test, so 
can't validate your configuration completely.

What I see in the logs is that your IP finder has only one address with port 0.
2016-02-04 22:58:11,710 [main] DEBUG 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi - Using parameter 
[ipFinder=TcpDiscoveryVmIpFinder [addrs=[evilmachine/127.0.1.1:0], 
super=TcpDiscoveryIpFinderAdapter [shared=false]]]

Try to specify the list with concrete ports (by default starting from 47500).

[1] https://apacheignite.readme.io/docs/cluster-config#static-ip-based-discovery


was (Author: dmagda):
[~maseev],

"Failed to send join request message" appears because the node tries to connect 
to itself.
 
The node tries to reconnect in a loop since you're using 
{{TcpDiscoveryVmIpFinder}}, that is not shared, and because local node's 
addresses are not found in the list of registered addresses in the IP finder. A 
local node's address has to be specified in this kind of IP finders explicitly 
[1].

Due to network related issue on my side I can't take a look at your test, so 
can't validate your configuration completely.

What I see in the logs is that your IP finder has only one address with port 0.
2016-02-04 22:58:11,710 [main] DEBUG 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi - Using parameter 
[ipFinder=TcpDiscoveryVmIpFinder [addrs=[evilmachine/127.0.1.1:0], 
super=TcpDiscoveryIpFinderAdapter [shared=false]]]

You have to specify the list with concrete ports (by default starting from 
47500).

[1] https://apacheignite.readme.io/docs/cluster-config#static-ip-based-discovery

> Ignite is blocking the thread in case it can't connect to the node
> --
>
> Key: IGNITE-2405
> URL: https://issues.apache.org/jira/browse/IGNITE-2405
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Miron Aseev
>  Labels: community, newbie
> Attachments: log.out
>
>
> It seems that Apache Ignite runs an infinite loop if it can't connect to the 
> resolved hostname.
> For example, if you specify the hostname of the local machine as an address 
> for the TCPSpi, then Apache Ignite resolves it 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L915].
>  
> But after that, for some reasons, it fails to connect to the resolved address 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L925].
>  
> As a result, the control flow goes to the catch block where the exception is 
> logged (It's an IgniteSpiException. It seems it can't get acces to the host 
> according to the exception message - "Network operation timed out. Increase 
> 'failureDetectionTimeout' configuration property 
> [failureDetectionTimeout=1]"). 
> In the end, we get an infinite loop.
> On the other hand, If I set an ip address (127.0.0.1) instead of the 
> hostname, Ignite gets an empty list 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L915]
>  and the control flow breaks the loop 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L918]
>  and goes forward.
> Here's a log information which Ignite produces during its work.
> {code}
> Jan 19, 2016 7:33:02 PM java.util.logging.LogManager$RootLogger log
> SEVERE: Failed to resolve default logging config file: 
> config/java.util.logging.properties
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: 
> >>>__    
> >>>   /  _/ ___/ |/ /  _/_  __/ __/  
> >>>  _/ // (7 7// /  / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/   
> >>> 
> >>> ver. 1.5.0-final#20151229-sha1:f1f8cda2
> >>> 2015 Copyright(C) Apache Software Foundation
> >>> 
> >>> Ignite documentation: http://ignite.apache.org
> Jan 19, 2016 7:33:03 PM 

[jira] [Updated] (IGNITE-2222) CPP: Implement Date and Timestamp data types support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-:

Description: It is needed to implement {{Date}} and {{Timestamp }} data 
types support because some SQL queries return data of such types and we need to 
be able to deserialize it on the C++ client side.  (was: It is needed to 
implement {{Date}} data type support because some SQL queries return data of 
that type and we need to be able to deserialize it on the C++ client side.)

> CPP: Implement Date and Timestamp data types support for binary protocol.
> -
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> It is needed to implement {{Date}} and {{Timestamp }} data types support 
> because some SQL queries return data of such types and we need to be able to 
> deserialize it on the C++ client side.



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

[jira] [Commented] (IGNITE-2509) Broken eviction and metrics for OFFHEAP_VALUES cache mode

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-2509:
--

I believe the behavior should be as follows:
 * ONHEAP_TIERED, 50 entries on-heap, 50 entries off-heap. Then size(ONHEAP) == 
50, size(OFFHEAP) == 50, offheapAllocatedSize() > 0
 * OFFHEAP_TIERED, 100 entries offheap. Then size(ONHEAP) == 0, size(OFFHEAP) 
== 100, offheapAllocatedSize() > 0
 * OFFHEAP_VALUES, 100 entries onheap. Then size(ONHEAP) == 100, size(OFFHEAP) 
== 0, offheapAllocatedSize() > 0

> Broken eviction and metrics for OFFHEAP_VALUES cache mode
> -
>
> Key: IGNITE-2509
> URL: https://issues.apache.org/jira/browse/IGNITE-2509
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ershov
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: EvictionBug.java, eviction_fix.patch
>
>
> In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
> values size wrongly which leads to the fact that data is evicted only when 
> either the limit on number of entries is reached or size of keys is bigger 
> than max allowed size.
> To reproduce set the following cache configuration
> {noformat}
> FifoEvictionPolicy plc = new FifoEvictionPolicy();
> plc.setMaxMemorySize(2 * 1024 * 1024);
> cacheCfg.setEvictionPolicy(plc);
> cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
> cacheCfg.setSwapEnabled(true);
> {noformat}
> Test that reproduces the issue is attached.
> Also attached a patch that fixes the issue. However we should validate that 
> the fix is full and add additional tests to the test suites.
> Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
> this cache mode. Has to be fixed as well.



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

[jira] [Commented] (IGNITE-2509) Broken eviction and metrics for OFFHEAP_VALUES cache mode

[Vladimir Ershov (JIRA)]

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

Vladimir Ershov commented on IGNITE-2509:
-

Got the point, will do. 
Thanks!

> Broken eviction and metrics for OFFHEAP_VALUES cache mode
> -
>
> Key: IGNITE-2509
> URL: https://issues.apache.org/jira/browse/IGNITE-2509
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Vladimir Ershov
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: EvictionBug.java, eviction_fix.patch
>
>
> In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
> values size wrongly which leads to the fact that data is evicted only when 
> either the limit on number of entries is reached or size of keys is bigger 
> than max allowed size.
> To reproduce set the following cache configuration
> {noformat}
> FifoEvictionPolicy plc = new FifoEvictionPolicy();
> plc.setMaxMemorySize(2 * 1024 * 1024);
> cacheCfg.setEvictionPolicy(plc);
> cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
> cacheCfg.setSwapEnabled(true);
> {noformat}
> Test that reproduces the issue is attached.
> Also attached a patch that fixes the issue. However we should validate that 
> the fix is full and add additional tests to the test suites.
> Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
> this cache mode. Has to be fixed as well.



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

[jira] [Commented] (IGNITE-2380) .NET: Ignite configuration in app.config and web.config

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2380:


Github user asfgit closed the pull request at:

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


> .NET: Ignite configuration in app.config and web.config
> ---
>
> Key: IGNITE-2380
> URL: https://issues.apache.org/jira/browse/IGNITE-2380
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> * Define custom ConfigurationSection for IgniteConfiguration (see 
> https://msdn.microsoft.com/en-us/library/2tw134k3.aspx)
> * Extend Ignition class to be able to start Ignite from app.config / 
> web.config configuration
> * Make sure to include xml schema



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

[jira] [Commented] (IGNITE-1563) .Net: Implement "atomic" data structures.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1563:


Github user asfgit closed the pull request at:

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


> .Net: Implement "atomic" data structures.
> -
>
> Key: IGNITE-1563
> URL: https://issues.apache.org/jira/browse/IGNITE-1563
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> This includes:
> atomicSequence;
> atomicStamped;
> atomicReference



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

[jira] [Closed] (IGNITE-1563) .Net: Implement "atomic" data structures.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1563.
---

> .Net: Implement "atomic" data structures.
> -
>
> Key: IGNITE-1563
> URL: https://issues.apache.org/jira/browse/IGNITE-1563
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> This includes:
> atomicSequence;
> atomicStamped;
> atomicReference



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

[jira] [Closed] (IGNITE-2380) .NET: Ignite configuration in app.config and web.config

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2380.
---

> .NET: Ignite configuration in app.config and web.config
> ---
>
> Key: IGNITE-2380
> URL: https://issues.apache.org/jira/browse/IGNITE-2380
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> * Define custom ConfigurationSection for IgniteConfiguration (see 
> https://msdn.microsoft.com/en-us/library/2tw134k3.aspx)
> * Extend Ignition class to be able to start Ignite from app.config / 
> web.config configuration
> * Make sure to include xml schema



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

[jira] [Commented] (IGNITE-169) [Failed test] GridSessionCheckpointSelfTest fails

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-169:


Description updated.

> [Failed test] GridSessionCheckpointSelfTest fails
> -
>
> Key: IGNITE-169
> URL: https://issues.apache.org/jira/browse/IGNITE-169
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Irina Vasilinets
> Fix For: 1.6
>
>
> {{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
> time.
> Just run test N times in a loop in order to reproduce it.
> {noformat}
> [19:04:17,405][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
> closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
> dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
> clsLdr=IsolatedClassLoader{roleName='test'}, 
> clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  pendingUndeploy=false, undeployed=false, usage=0], 
> taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
> startTime=1454958227376, endTime=9223372036854775807, 
> taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
> clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=0, fullSup=true, 
> subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
> endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:666)
> at 
> org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest.checkCheckpoints(GridSessionCheckpointAbstractSelfTest.java:145)
> at 
> org.apache.ignite.session.GridSessionCheckpointSelfTest.testSharedFsCheckpoint(GridSessionCheckpointSelfTest.java:48)
> 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:1723)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Updated] (IGNITE-2555) Include offheap usage in metrics report

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-2555:
--
Labels: newbie  (was: )

> Include offheap usage in metrics report
> ---
>
> Key: IGNITE-2555
> URL: https://issues.apache.org/jira/browse/IGNITE-2555
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Priority: Minor
>  Labels: newbie
>
> The local node prints out the set of key parameters in its log (or console). 
> It makes sense to add offheap usage (used/free/committed) to that report.
> {noformat}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=41b12e0f, name=null]
> ^-- H/N/C [hosts=1, nodes=14, CPUs=8]
> ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%]
> ^-- Heap [used=1364MB, free=27,44%, comm=1881MB]
> ^-- Public thread pool [active=0, idle=16, qSize=0]
> ^-- System thread pool [active=1, idle=15, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}



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

[jira] [Updated] (IGNITE-2222) CPP: Implement Date and Timestamp data types support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-:

Summary: CPP: Implement Date and Timestamp data types support for binary 
protocol.  (was: CPP: Implement Date data type support for binary protocol.)

> CPP: Implement Date and Timestamp data types support for binary protocol.
> -
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> It is needed to implement {{Date}} data type support because some SQL queries 
> return data of that type and we need to be able to deserialize it on the C++ 
> client side.



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

[jira] [Assigned] (IGNITE-1783) Remove GridBoundedConcurrentLinkedHashMap and replace its usages with ConcurrentLinkedHashMap

[Vladimir Ershov (JIRA)]

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

Vladimir Ershov reassigned IGNITE-1783:
---

Assignee: (was: Vladimir Ershov)

> Remove GridBoundedConcurrentLinkedHashMap and replace its usages with 
> ConcurrentLinkedHashMap
> -
>
> Key: IGNITE-1783
> URL: https://issues.apache.org/jira/browse/IGNITE-1783
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Priority: Trivial
>  Labels: newbie
>
> From what I see {{GridBoundedConcurrentLinkedHashMap}} is redundant and the 
> only difference from {{ConcurrentLinkedHashMap}} is in order of constructor 
> arguments.



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

[jira] [Comment Edited] (IGNITE-2222) CPP: Implement Date data type support for binary protocol.

[Igor Sapego (JIRA)]

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

Igor Sapego edited comment on IGNITE- at 2/9/16 12:14 PM:
--

It seems that Java {{Date}} type is actually a number of *milliseconds* since 
epoch (i.e. January 1, 1970, 00:00:00 GMT) stored as an 64-bit integer. 
Unfortunately, there are no time types in C++ standard library except for C++11 
Chrono library, which is not supported by VS 2010 which we want to support. 
However, there is C time library which has {{time_t}} type. Unfortunately, this 
type's structure and content is implementation-specific, though it is generally 
implemented as an integral value representing the number of *seconds* elapsed 
since epoch.

So here is proposed solution - add {{ignite::Date}} type, that would contain 
milliseconds since epoch inside. This way we can store Java {{Date}} without 
losing precision and we still can use it in C++ using standard C library 
functions if we convert milliseconds to seconds which is trivial. 


was (Author: isapego):
It seems that Java {{Date}} type is actually a number of *milliseconds* since 
epoch (i.e. January 1, 1970, 00:00:00 GMT) stored as an 64-bit integer. 
Unfortunately, there are no time types in C++ standard library except for C++11 
Chrono library, which is not supported by VS 2010 which we need to support. 
However, there is C time library which has {{time_t}} type. Unfortunately, this 
type's structure and content is implementation-specific, though it is generally 
implemented as an integral value representing the number of *seconds* elapsed 
since epoch.

So here is proposed solution - add {{ignite::Date}} type, that would contain 
milliseconds since epoch inside. This way we can store Java {{Date}} without 
losing precision and we still can use it in C++ using standard C library 
functions if we convert milliseconds to seconds which is trivial. 

> CPP: Implement Date data type support for binary protocol.
> --
>
> Key: IGNITE-
> URL: https://issues.apache.org/jira/browse/IGNITE-
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 1.6
>
>
> It is needed to implement {{Date}} data type support because some SQL queries 
> return data of that type and we need to be able to deserialize it on the C++ 
> client side.



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

[jira] [Commented] (IGNITE-2405) Ignite is blocking the thread in case it can't connect to the node

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2405:
-

[~maseev],

"Failed to send join request message" appears because the node tries to connect 
to itself.
 
The node tries to reconnect in a loop since you're using 
{{TcpDiscoveryVmIpFinder}}, that is not shared, and because local node's 
addresses are not found in the list of registered addresses in the IP finder. A 
local node's address has to be specified in this kind of IP finders explicitly 
[1].

Due to network related issue on my side I can't take a look at your test, so 
can't validate your configuration completely.

What I see in the logs is that your IP finder has only one address with port 0.
2016-02-04 22:58:11,710 [main] DEBUG 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi - Using parameter 
[ipFinder=TcpDiscoveryVmIpFinder [addrs=[evilmachine/127.0.1.1:0], 
super=TcpDiscoveryIpFinderAdapter [shared=false]]]

You have to specify the list with concrete ports (by default starting from 
47500).

[1] https://apacheignite.readme.io/docs/cluster-config#static-ip-based-discovery

> Ignite is blocking the thread in case it can't connect to the node
> --
>
> Key: IGNITE-2405
> URL: https://issues.apache.org/jira/browse/IGNITE-2405
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Miron Aseev
>  Labels: community, newbie
> Attachments: log.out
>
>
> It seems that Apache Ignite runs an infinite loop if it can't connect to the 
> resolved hostname.
> For example, if you specify the hostname of the local machine as an address 
> for the TCPSpi, then Apache Ignite resolves it 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L915].
>  
> But after that, for some reasons, it fails to connect to the resolved address 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L925].
>  
> As a result, the control flow goes to the catch block where the exception is 
> logged (It's an IgniteSpiException. It seems it can't get acces to the host 
> according to the exception message - "Network operation timed out. Increase 
> 'failureDetectionTimeout' configuration property 
> [failureDetectionTimeout=1]"). 
> In the end, we get an infinite loop.
> On the other hand, If I set an ip address (127.0.0.1) instead of the 
> hostname, Ignite gets an empty list 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L915]
>  and the control flow breaks the loop 
> [here|https://github.com/apache/ignite/blob/b3d347e35a254928fd1c4a0473f1b17d642c72f3/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L918]
>  and goes forward.
> Here's a log information which Ignite produces during its work.
> {code}
> Jan 19, 2016 7:33:02 PM java.util.logging.LogManager$RootLogger log
> SEVERE: Failed to resolve default logging config file: 
> config/java.util.logging.properties
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: 
> >>>__    
> >>>   /  _/ ___/ |/ /  _/_  __/ __/  
> >>>  _/ // (7 7// /  / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/   
> >>> 
> >>> ver. 1.5.0-final#20151229-sha1:f1f8cda2
> >>> 2015 Copyright(C) Apache Software Foundation
> >>> 
> >>> Ignite documentation: http://ignite.apache.org
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: Config URL: n/a
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: Daemon mode: off
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: OS: Linux 3.13.0-74-generic amd64
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: OS user: maseev
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: Language runtime: Java Platform API Specification ver. 1.8
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: VM information: Java(TM) SE Runtime Environment 1.8.0_40-b26 Oracle 
> Corporation Java HotSpot(TM) 64-Bit Server VM 25.40-b25
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: VM total memory: 3.5GB
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: Remote Management [restart: off, REST: on, JMX (remote: off)]
> Jan 19, 2016 7:33:03 PM org.apache.ignite.logger.java.JavaLogger info
> INFO: IGNITE_HOME=null
> Jan 19, 2016 

[jira] [Created] (IGNITE-2602) Queries: offset does not work with negative or MAX_VALUE limit

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2602:
--

 Summary: Queries: offset does not work with negative or MAX_VALUE 
limit
 Key: IGNITE-2602
 URL: https://issues.apache.org/jira/browse/IGNITE-2602
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
 Fix For: 1.6


H2 allows specifying negative LIMIT with OFFSET: 
http://www.h2database.com/html/grammar.html
This does not work with Ignite (query returns empty result set).

To work around this, I tried to specify Integer.MAX_VALUE, but this causes an 
exception.

Turns out, offset+limit should be <= Integer.MAX_VALUE, which is quite 
inconvenient.

I think we should support negative LIMIT for unlimited offset queries.





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

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

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-2195:
-

1) inherited from Basic factory
2) made protected.
3) to get the user each time with  UserGroupInformation.getLoginUser() just 
seems to be more reliable: this way can be sure that we're in sync with the 
static context of UserGroupInformation. 
4) this thread will be spawned only if the login is performed from the kerberos 
ticket, but not from the keytab 
(org.apache.hadoop.security.UserGroupInformation#isKeytab == false), but in 
SecureHadoopFileSystemFactory we always have isKeytab == true.
5) Now the key tab parameters are validated in start() method, nulls are not 
allowed.
6) This sync just joins together 2 static synchronized methods, to avoid 
concurrent invocations between them. This seems to make the code more reliable.
7) removed this code.
8) fixed.
9) Added very simple test that checks only the parameters validation and 
serialization.



> 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
>
> Attachments: kerbersized_hadoop_fs_factory.zip
>
>
> 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 

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

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-2195:

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> 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: Vladimir Ozerov
>Priority: Critical
>  Labels: important
> Fix For: 1.6
>
> Attachments: kerbersized_hadoop_fs_factory.zip
>
>
> 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, 

[jira] [Created] (IGNITE-2603) OSGi support for objects passed through CacheConfiguration

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2603:
---

 Summary: OSGi support for objects passed through CacheConfiguration
 Key: IGNITE-2603
 URL: https://issues.apache.org/jira/browse/IGNITE-2603
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Assignee: Anton Vinogradov
 Fix For: 1.6


If a user sets a custom class loader with 
{{IgniteConfiguration.setClassLoader}} then it always has to be used when the 
following objects passed to {{CacheConfiguration}} are being deserialized:

- CacheStore factory;
- CacheStoreSessionListener factory;
- CachePluginConfiguration;
- AffinityKeyMapper;
- IgnitePredicate (as a node filter in CacheConfiguration.setNodeFilter(...));
- CacheEntryListenerConfiguration class with factories for CacheEntryListener 
and CacheEntryEventFilter;

In case of OSGi class loaders can be quite exotic. As an example {{CacheStore}} 
factory loaded from bundle A, can contain objects loaded from bundle B and 
bundle C. When such class loader is set as 
{{IgniteConfiguration.setClassLoader}} then deserialization of the 
{{CacheStore}} factory must work fine as well.



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

[jira] [Comment Edited] (IGNITE-169) [Failed test] GridSessionCheckpointSelfTest fails

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-169 at 2/9/16 9:57 PM:


I see two options for fix this:

# We can fix test. Communication SPI should be replaced. It should catch job 
requests (e.g. first one), get task session, invoke {{saveCheckpoint}} method 
and count latch down.
# From my point of view isn't good idea try to process delayed results from 
caller thread (at least in case of async compute facade). So I suggest remove 
this behavior (remove {{GridTaskWorker.processDelayedResponses}} method).

Thoughts?


was (Author: agura):
I see two options for fix this:

# We can fix test. Communication SPI should be replaced. It should cacth job 
requests (e.g. first one), get task session, invoke saveCheckpoint and count 
latch down.
# From my point of view isn't good idea try to process delayed results from 
caller thread (especially in case of async compute facade). So I suggest remove 
this bahavior (remove {{processDelayedResponses}} method).

Thoughts?

> [Failed test] GridSessionCheckpointSelfTest fails
> -
>
> Key: IGNITE-169
> URL: https://issues.apache.org/jira/browse/IGNITE-169
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Irina Vasilinets
> Fix For: 1.6
>
>
> {{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
> time.
> The problem is that test-runner thread invokes {{ignite.compute()}} in async 
> mode and when all jobs are mapped it invokes {{processDelayedResponses}} 
> method. At this moment is possible that all responses are received but sys 
> pool threads don't invoke {{reduce}} method. test-runner thread polls delayed 
> responses from queue and invoke {{reduce}}. So test-runner thread "steals" 
> reduce job that is waitiong on latch that should be counted down by the same 
> thread.
> Just run test N times in a loop in order to reproduce it.
> {noformat}
> [19:04:17,405][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
> closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
> dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
> clsLdr=IsolatedClassLoader{roleName='test'}, 
> clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  pendingUndeploy=false, undeployed=false, usage=0], 
> taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
> startTime=1454958227376, endTime=9223372036854775807, 
> taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
> clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=0, fullSup=true, 
> subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
> endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:666)
> at 
> org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest.checkCheckpoints(GridSessionCheckpointAbstractSelfTest.java:145)
> at 
> org.apache.ignite.session.GridSessionCheckpointSelfTest.testSharedFsCheckpoint(GridSessionCheckpointSelfTest.java:48)
> 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:1723)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Assigned] (IGNITE-169) [Failed test] GridSessionCheckpointSelfTest fails

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-169:
--

Assignee: Andrey Gura

> [Failed test] GridSessionCheckpointSelfTest fails
> -
>
> Key: IGNITE-169
> URL: https://issues.apache.org/jira/browse/IGNITE-169
> Project: Ignite
>  Issue Type: Test
>  Components: general
>Reporter: Irina Vasilinets
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> {{GridSessionCheckpointSelfTest.testSharedFsCheckpoint fails}} from time to 
> time.
> The problem is that test-runner thread invokes {{ignite.compute()}} in async 
> mode and when all jobs are mapped it invokes {{processDelayedResponses}} 
> method. At this moment is possible that all responses are received but sys 
> pool threads don't invoke {{reduce}} method. test-runner thread polls delayed 
> responses from queue and invoke {{reduce}}. So test-runner thread "steals" 
> reduce job that is waitiong on latch that should be counted down by the same 
> thread.
> Just run test N times in a loop in order to reproduce it.
> {noformat}
> [19:04:17,405][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Failed to save checkpoint (session 
> closed): GridTaskSessionImpl [taskName=GridCheckpointTestTask, 
> dep=GridDeployment [ts=1454958227376, depMode=SHARED, 
> clsLdr=IsolatedClassLoader{roleName='test'}, 
> clsLdrId=16c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, userVer=0, 
> loc=true, 
> sampleClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  pendingUndeploy=false, undeployed=false, usage=0], 
> taskClsName=org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest$GridCheckpointTestTask,
>  sesId=36c7442c251-88ba4909-a876-4106-be63-3fec03d9dcff, 
> startTime=1454958227376, endTime=9223372036854775807, 
> taskNodeId=88ba4909-a876-4106-be63-3fec03d9dcff, 
> clsLdr=IsolatedClassLoader{roleName='test'}, closed=true, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=0, fullSup=true, 
> subjId=88ba4909-a876-4106-be63-3fec03d9dcff, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=2, res=null, startTime=1454958227376, 
> endTime=1454958227386, ignoreInterrupts=false, state=DONE]]]
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint0(GridTaskSessionImpl.java:697)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:677)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:671)
> at 
> org.apache.ignite.internal.GridTaskSessionImpl.saveCheckpoint(GridTaskSessionImpl.java:666)
> at 
> org.apache.ignite.session.GridSessionCheckpointAbstractSelfTest.checkCheckpoints(GridSessionCheckpointAbstractSelfTest.java:145)
> at 
> org.apache.ignite.session.GridSessionCheckpointSelfTest.testSharedFsCheckpoint(GridSessionCheckpointSelfTest.java:48)
> 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:1723)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Created] (IGNITE-2604) CacheContinuousQueryBatchAck is sent to nodes that doesn't hold cache data

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2604:
---

 Summary: CacheContinuousQueryBatchAck is sent to nodes that 
doesn't hold cache data
 Key: IGNITE-2604
 URL: https://issues.apache.org/jira/browse/IGNITE-2604
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Assignee: Nikolay Tikhonov
 Fix For: 1.6


Presently {{CacheContinuousQueryBatchAck}} is sent to every node of the cluster 
including client nodes but in fact it has to be sent to backup nodes only. The 
reason is that the list of the backups is retrieved with 
{{ctx.discovery().cacheNodes(topVer)}} method which returns all the nodes where 
at least one cache is registered.

Refer to {{CacheContinuousQueryHandler.sendBackupAcknowledge}} method body
{noformat}
for (AffinityTopologyVersion topVer : t.get2())
nodes.addAll(ctx.discovery().cacheNodes(topVer));
{noforma}

The list has to be formed by remote nodes that contain only a particular cache

{noformat}
for (AffinityTopologyVersion topVer : t.get2())
nodes.addAll(ctx.discovery().remoteCacheNodes(cctx.name(), topVer));
{noformat}

and finally the ack has to be sent only if a node is not a client node

{noformat}
for (ClusterNode node : nodes) {
if (!node.isClient()) {
try {
cctx.io().send(node, msg, 
GridIoPolicy.SYSTEM_POOL);
{noformat}

Next, in my understanding there is no need to register 
CacheContinuousQueryBatchAck handler on the client side. Presently it's 
registered in {{CacheContinuousQueryManager.start0}} method.

Finally, since currently the ack is sent to clients as well the following 
warning floods logs in some unclear cases

{noformat}
20160208 12:56:30.301 WARN [sys-#7%null%] 
org.apache.ignite.internal.processors.cache.GridCacheIoManager [] - Received 
message without registered handler (will ignore) 
[msg=CacheContinuousQueryBatchAck 
[routineId=df328a9f-6a63-40f7-8a1b-923cfadb6337, updateCntrs={193=1455, 
898=1434, 581=307, 584=159, 75=376, 331=233, 652=434, 13=420, 910=923, 143=249, 
147=619, 150=1185, 598=338, 728=1168, 90=598, 346=1169, 283=214, 934=388, 
615=310, 807=140, 1002=1132, 555=344, 365=215, 941=342, 946=515, 1015=635, 
56=614, 378=1130, 827=720, 956=5675}], 
nodeId=d78ac9e5-60dd-4fa9-a8eb-7c5c36e189af, locTopVer=AffinityTopologyVersion 
[topVer=248, minorTopVer=1], msgTopVer=AffinityTopologyVersion [topVer=-1, 
minorTopVer=0], cacheDesc=DynamicCacheDescriptor 
[deploymentId=b8776e0c251-eb7db0e0-c35f-4a05-af44-5295c4cfdc01, locCfg=false, 
staticCfg=true, started=true, cacheType=USER, template=false, 
pluginMgr=GridCacheManagerAdapter [starting=false], updatesAllowed=true, 
startTopVer=null, rcvdOnDiscovery=true, cacheName=GETS_ORDER_MAP]]
{noformat}




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

[jira] [Updated] (IGNITE-2604) CacheContinuousQueryBatchAck is sent to nodes that doesn't hold cache data

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2604:

Description: 
Presently {{CacheContinuousQueryBatchAck}} is sent to every node of the cluster 
including client nodes but in fact it has to be sent to backup nodes only. The 
reason is that the list of the backups is retrieved with 
{{ctx.discovery().cacheNodes(topVer)}} method which returns all the nodes where 
at least one cache is registered.

Refer to {{CacheContinuousQueryHandler.sendBackupAcknowledge}} method body
{noformat}
for (AffinityTopologyVersion topVer : t.get2())
nodes.addAll(ctx.discovery().cacheNodes(topVer));
{noformat}

The list has to be formed by remote nodes that contain only a particular cache

{noformat}
for (AffinityTopologyVersion topVer : t.get2())
nodes.addAll(ctx.discovery().remoteCacheNodes(cctx.name(), topVer));
{noformat}

and finally the ack has to be sent only if a node is not a client node

{noformat}
for (ClusterNode node : nodes) {
if (!node.isClient()) {
try {
cctx.io().send(node, msg, 
GridIoPolicy.SYSTEM_POOL);
{noformat}

Next, in my understanding there is no need to register 
CacheContinuousQueryBatchAck handler on the client side. Presently it's 
registered in {{CacheContinuousQueryManager.start0}} method.

Finally, since currently the ack is sent to clients as well the following 
warning floods logs in some unclear cases

{noformat}
20160208 12:56:30.301 WARN [sys-#7%null%] 
org.apache.ignite.internal.processors.cache.GridCacheIoManager [] - Received 
message without registered handler (will ignore) 
[msg=CacheContinuousQueryBatchAck 
[routineId=df328a9f-6a63-40f7-8a1b-923cfadb6337, updateCntrs={193=1455, 
898=1434, 581=307, 584=159, 75=376, 331=233, 652=434, 13=420, 910=923, 143=249, 
147=619, 150=1185, 598=338, 728=1168, 90=598, 346=1169, 283=214, 934=388, 
615=310, 807=140, 1002=1132, 555=344, 365=215, 941=342, 946=515, 1015=635, 
56=614, 378=1130, 827=720, 956=5675}], 
nodeId=d78ac9e5-60dd-4fa9-a8eb-7c5c36e189af, locTopVer=AffinityTopologyVersion 
[topVer=248, minorTopVer=1], msgTopVer=AffinityTopologyVersion [topVer=-1, 
minorTopVer=0], cacheDesc=DynamicCacheDescriptor 
[deploymentId=b8776e0c251-eb7db0e0-c35f-4a05-af44-5295c4cfdc01, locCfg=false, 
staticCfg=true, started=true, cacheType=USER, template=false, 
pluginMgr=GridCacheManagerAdapter [starting=false], updatesAllowed=true, 
startTopVer=null, rcvdOnDiscovery=true, cacheName=GETS_ORDER_MAP]]
{noformat}


  was:
Presently {{CacheContinuousQueryBatchAck}} is sent to every node of the cluster 
including client nodes but in fact it has to be sent to backup nodes only. The 
reason is that the list of the backups is retrieved with 
{{ctx.discovery().cacheNodes(topVer)}} method which returns all the nodes where 
at least one cache is registered.

Refer to {{CacheContinuousQueryHandler.sendBackupAcknowledge}} method body
{noformat}
for (AffinityTopologyVersion topVer : t.get2())
nodes.addAll(ctx.discovery().cacheNodes(topVer));
{noforma}

The list has to be formed by remote nodes that contain only a particular cache

{noformat}
for (AffinityTopologyVersion topVer : t.get2())
nodes.addAll(ctx.discovery().remoteCacheNodes(cctx.name(), topVer));
{noformat}

and finally the ack has to be sent only if a node is not a client node

{noformat}
for (ClusterNode node : nodes) {
if (!node.isClient()) {
try {
cctx.io().send(node, msg, 
GridIoPolicy.SYSTEM_POOL);
{noformat}

Next, in my understanding there is no need to register 
CacheContinuousQueryBatchAck handler on the client side. Presently it's 
registered in {{CacheContinuousQueryManager.start0}} method.

Finally, since currently the ack is sent to clients as well the following 
warning floods logs in some unclear cases

{noformat}
20160208 12:56:30.301 WARN [sys-#7%null%] 
org.apache.ignite.internal.processors.cache.GridCacheIoManager [] - Received 
message without registered handler (will ignore) 
[msg=CacheContinuousQueryBatchAck 
[routineId=df328a9f-6a63-40f7-8a1b-923cfadb6337, updateCntrs={193=1455, 
898=1434, 581=307, 584=159, 75=376, 331=233, 652=434, 13=420, 910=923, 143=249, 
147=619, 150=1185, 598=338, 728=1168, 90=598, 346=1169, 283=214, 934=388, 
615=310, 807=140, 1002=1132, 555=344, 365=215, 941=342, 946=515, 1015=635, 
56=614, 378=1130, 827=720, 956=5675}], 
nodeId=d78ac9e5-60dd-4fa9-a8eb-7c5c36e189af, locTopVer=AffinityTopologyVersion 
[topVer=248, minorTopVer=1], msgTopVer=AffinityTopologyVersion [topVer=-1, 
minorTopVer=0], cacheDesc=DynamicCacheDescriptor 
[deploymentId=b8776e0c251-eb7db0e0-c35f-4a05-af44-5295c4cfdc01, locCfg=false, 
staticCfg=true, started=true, cacheType=USER, template=false, 
pluginMgr=GridCacheManagerAdapter [starting=false], 

[jira] [Created] (IGNITE-2605) Apache Apex Integration

[Suminda Dharmasena (JIRA)]

Suminda Dharmasena created IGNITE-2605:
--

 Summary: Apache Apex Integration
 Key: IGNITE-2605
 URL: https://issues.apache.org/jira/browse/IGNITE-2605
 Project: Ignite
  Issue Type: New Feature
Reporter: Suminda Dharmasena


Is it possible to have Apache Apex run on top of Ignite without YARN



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

[jira] [Updated] (IGNITE-2607) Run ZooKeeper on top of Ignite / Replacement for standalone ZK distribution

[Suminda Dharmasena (JIRA)]

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

Suminda Dharmasena updated IGNITE-2607:
---
Summary: Run ZooKeeper on top of Ignite / Replacement for standalone ZK 
distribution   (was: Drop in Replacement for ZooKeeper)

> Run ZooKeeper on top of Ignite / Replacement for standalone ZK distribution 
> 
>
> Key: IGNITE-2607
> URL: https://issues.apache.org/jira/browse/IGNITE-2607
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Suminda Dharmasena
>




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

[jira] [Commented] (IGNITE-2604) CacheContinuousQueryBatchAck is sent to nodes that doesn't hold cache data

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2604:
-

Reproduced the situation when the log below is printed out on a node in a loop:

{noformat}
20160208 12:56:30.301 WARN [sys-#7%null%] 
org.apache.ignite.internal.processors.cache.GridCacheIoManager [] - Received 
message without registered handler (will ignore) 
[msg=CacheContinuousQueryBatchAck 
[routineId=df328a9f-6a63-40f7-8a1b-923cfadb6337, updateCntrs={193=1455, 
898=1434, 581=307, 584=159, 75=376, 331=233, 652=434, 13=420, 910=923, 143=249, 
147=619, 150=1185, 598=338, 728=1168, 90=598, 346=1169, 283=214, 934=388, 
615=310, 807=140, 1002=1132, 555=344, 365=215, 941=342, 946=515, 1015=635, 
56=614, 378=1130, 827=720, 956=5675}], 
nodeId=d78ac9e5-60dd-4fa9-a8eb-7c5c36e189af, locTopVer=AffinityTopologyVersion 
[topVer=248, minorTopVer=1], msgTopVer=AffinityTopologyVersion [topVer=-1, 
minorTopVer=0], cacheDesc=DynamicCacheDescriptor 
[deploymentId=b8776e0c251-eb7db0e0-c35f-4a05-af44-5295c4cfdc01, locCfg=false, 
staticCfg=true, started=true, cacheType=USER, template=false, 
pluginMgr=GridCacheManagerAdapter [starting=false], updatesAllowed=true, 
startTopVer=null, rcvdOnDiscovery=true, cacheName=GETS_ORDER_MAP]]

{noformat}

Steps to reproduce:
1) Start server node A;
2) Start client node B that executes continuous query over "test" cache;
3) Start client node C that starts putting data into "test" cache;
4) Start client node D, that neither gets a reference to cache "test" 
(ignite.cache("test") nor have it in its {{IgniteConfiguration}}. This not will 
be flooded with the message above because of the issue from the description

> CacheContinuousQueryBatchAck is sent to nodes that doesn't hold cache data
> --
>
> Key: IGNITE-2604
> URL: https://issues.apache.org/jira/browse/IGNITE-2604
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
>Priority: Blocker
> Fix For: 1.6
>
>
> Presently {{CacheContinuousQueryBatchAck}} is sent to every node of the 
> cluster including client nodes but in fact it has to be sent to backup nodes 
> only. The reason is that the list of the backups is retrieved with 
> {{ctx.discovery().cacheNodes(topVer)}} method which returns all the nodes 
> where at least one cache is registered.
> Refer to {{CacheContinuousQueryHandler.sendBackupAcknowledge}} method body
> {noformat}
> for (AffinityTopologyVersion topVer : t.get2())
> nodes.addAll(ctx.discovery().cacheNodes(topVer));
> {noformat}
> The list has to be formed by remote nodes that contain only a particular cache
> {noformat}
> for (AffinityTopologyVersion topVer : t.get2())
> nodes.addAll(ctx.discovery().remoteCacheNodes(cctx.name(), topVer));
> {noformat}
> and finally the ack has to be sent only if a node is not a client node
> {noformat}
> for (ClusterNode node : nodes) {
> if (!node.isClient()) {
> try {
> cctx.io().send(node, msg, 
> GridIoPolicy.SYSTEM_POOL);
> {noformat}
> Next, in my understanding there is no need to register 
> CacheContinuousQueryBatchAck handler on the client side. Presently it's 
> registered in {{CacheContinuousQueryManager.start0}} method.
> Finally, since currently the ack is sent to clients as well the following 
> warning floods logs in some unclear cases
> {noformat}
> 20160208 12:56:30.301 WARN [sys-#7%null%] 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager [] - Received 
> message without registered handler (will ignore) 
> [msg=CacheContinuousQueryBatchAck 
> [routineId=df328a9f-6a63-40f7-8a1b-923cfadb6337, updateCntrs={193=1455, 
> 898=1434, 581=307, 584=159, 75=376, 331=233, 652=434, 13=420, 910=923, 
> 143=249, 147=619, 150=1185, 598=338, 728=1168, 90=598, 346=1169, 283=214, 
> 934=388, 615=310, 807=140, 1002=1132, 555=344, 365=215, 941=342, 946=515, 
> 1015=635, 56=614, 378=1130, 827=720, 956=5675}], 
> nodeId=d78ac9e5-60dd-4fa9-a8eb-7c5c36e189af, 
> locTopVer=AffinityTopologyVersion [topVer=248, minorTopVer=1], 
> msgTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], 
> cacheDesc=DynamicCacheDescriptor 
> [deploymentId=b8776e0c251-eb7db0e0-c35f-4a05-af44-5295c4cfdc01, locCfg=false, 
> staticCfg=true, started=true, cacheType=USER, template=false, 
> pluginMgr=GridCacheManagerAdapter [starting=false], updatesAllowed=true, 
> startTopVer=null, rcvdOnDiscovery=true, cacheName=GETS_ORDER_MAP]]
> {noformat}



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

[jira] [Created] (IGNITE-2606) Drop in Replacement for Apache YARN

[Suminda Dharmasena (JIRA)]

Suminda Dharmasena created IGNITE-2606:
--

 Summary: Drop in Replacement for Apache YARN
 Key: IGNITE-2606
 URL: https://issues.apache.org/jira/browse/IGNITE-2606
 Project: Ignite
  Issue Type: New Feature
Reporter: Suminda Dharmasena






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

[jira] [Created] (IGNITE-2607) Drop in Replacement for ZooKeeper

[Suminda Dharmasena (JIRA)]

Suminda Dharmasena created IGNITE-2607:
--

 Summary: Drop in Replacement for ZooKeeper
 Key: IGNITE-2607
 URL: https://issues.apache.org/jira/browse/IGNITE-2607
 Project: Ignite
  Issue Type: New Feature
Reporter: Suminda Dharmasena






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

[jira] [Updated] (IGNITE-2448) Ignite based second level cache for MyBatis

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-2448:
-
Fix Version/s: 1.6

> Ignite based second level cache for MyBatis
> ---
>
> Key: IGNITE-2448
> URL: https://issues.apache.org/jira/browse/IGNITE-2448
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Roman Shtykh
> Fix For: 1.6
>
>
> MyBatis [1] has a concept of a second level cache.
> It makes sense to implement a module that will allow to use Ignite as a 
> second level cache for this framework.
> In particular the following has to be done:
> - introduce ignite-cache module that will be located in MyBatis GIT 
> repository [2]
> - implement MyBatis {{Cache}} interface [3]
> - there should be configs inside of the module for different exemplary cases 
> (server node with a single local cache; server node that is a part of some 
> cluster and caches mybatis data in replicatred or partitioned cache; client 
> nodes that connects to the cluster and works with the cache); 
> - add documentation about the integration on Ignite readme.io
> - as a reference you may refer to Hazelcast [4] or other implementation
> More on caches in MyBatis
> http://www.mybatis.org/mybatis-3/sqlmap-xml.html#cache
> [1] http://www.mybatis.org/
> [2] https://github.com/mybatis/
> [3] 
> https://github.com/mybatis/mybatis-3/blob/master/src/main/java/org/apache/ibatis/cache/Cache.java
> [4] https://github.com/mybatis/hazelcast-cache



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

[jira] [Updated] (IGNITE-2448) Ignite based second level cache for MyBatis

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-2448:
-
Fix Version/s: (was: 1.6)

> Ignite based second level cache for MyBatis
> ---
>
> Key: IGNITE-2448
> URL: https://issues.apache.org/jira/browse/IGNITE-2448
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>
> MyBatis [1] has a concept of a second level cache.
> It makes sense to implement a module that will allow to use Ignite as a 
> second level cache for this framework.
> In particular the following has to be done:
> - introduce ignite-cache module that will be located in MyBatis GIT 
> repository [2]
> - implement MyBatis {{Cache}} interface [3]
> - there should be configs inside of the module for different exemplary cases 
> (server node with a single local cache; server node that is a part of some 
> cluster and caches mybatis data in replicatred or partitioned cache; client 
> nodes that connects to the cluster and works with the cache); 
> - add documentation about the integration on Ignite readme.io
> - as a reference you may refer to Hazelcast [4] or other implementation
> More on caches in MyBatis
> http://www.mybatis.org/mybatis-3/sqlmap-xml.html#cache
> [1] http://www.mybatis.org/
> [2] https://github.com/mybatis/
> [3] 
> https://github.com/mybatis/mybatis-3/blob/master/src/main/java/org/apache/ibatis/cache/Cache.java
> [4] https://github.com/mybatis/hazelcast-cache



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

[jira] [Commented] (IGNITE-2448) Ignite based second level cache for MyBatis

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-2448:
--

Thank you for pointing to this, Denis.
I nullified the properties as you suggested. Probably I have to mention in docs 
that a user cannot set eviction policy etc.

> Ignite based second level cache for MyBatis
> ---
>
> Key: IGNITE-2448
> URL: https://issues.apache.org/jira/browse/IGNITE-2448
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>
> MyBatis [1] has a concept of a second level cache.
> It makes sense to implement a module that will allow to use Ignite as a 
> second level cache for this framework.
> In particular the following has to be done:
> - introduce ignite-cache module that will be located in MyBatis GIT 
> repository [2]
> - implement MyBatis {{Cache}} interface [3]
> - there should be configs inside of the module for different exemplary cases 
> (server node with a single local cache; server node that is a part of some 
> cluster and caches mybatis data in replicatred or partitioned cache; client 
> nodes that connects to the cluster and works with the cache); 
> - add documentation about the integration on Ignite readme.io
> - as a reference you may refer to Hazelcast [4] or other implementation
> More on caches in MyBatis
> http://www.mybatis.org/mybatis-3/sqlmap-xml.html#cache
> [1] http://www.mybatis.org/
> [2] https://github.com/mybatis/
> [3] 
> https://github.com/mybatis/mybatis-3/blob/master/src/main/java/org/apache/ibatis/cache/Cache.java
> [4] https://github.com/mybatis/hazelcast-cache



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

[jira] [Updated] (IGNITE-2604) CacheContinuousQueryBatchAck is sent to nodes that doesn't hold cache data

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2604:

Priority: Blocker  (was: Major)

> CacheContinuousQueryBatchAck is sent to nodes that doesn't hold cache data
> --
>
> Key: IGNITE-2604
> URL: https://issues.apache.org/jira/browse/IGNITE-2604
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
>Priority: Blocker
> Fix For: 1.6
>
>
> Presently {{CacheContinuousQueryBatchAck}} is sent to every node of the 
> cluster including client nodes but in fact it has to be sent to backup nodes 
> only. The reason is that the list of the backups is retrieved with 
> {{ctx.discovery().cacheNodes(topVer)}} method which returns all the nodes 
> where at least one cache is registered.
> Refer to {{CacheContinuousQueryHandler.sendBackupAcknowledge}} method body
> {noformat}
> for (AffinityTopologyVersion topVer : t.get2())
> nodes.addAll(ctx.discovery().cacheNodes(topVer));
> {noformat}
> The list has to be formed by remote nodes that contain only a particular cache
> {noformat}
> for (AffinityTopologyVersion topVer : t.get2())
> nodes.addAll(ctx.discovery().remoteCacheNodes(cctx.name(), topVer));
> {noformat}
> and finally the ack has to be sent only if a node is not a client node
> {noformat}
> for (ClusterNode node : nodes) {
> if (!node.isClient()) {
> try {
> cctx.io().send(node, msg, 
> GridIoPolicy.SYSTEM_POOL);
> {noformat}
> Next, in my understanding there is no need to register 
> CacheContinuousQueryBatchAck handler on the client side. Presently it's 
> registered in {{CacheContinuousQueryManager.start0}} method.
> Finally, since currently the ack is sent to clients as well the following 
> warning floods logs in some unclear cases
> {noformat}
> 20160208 12:56:30.301 WARN [sys-#7%null%] 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager [] - Received 
> message without registered handler (will ignore) 
> [msg=CacheContinuousQueryBatchAck 
> [routineId=df328a9f-6a63-40f7-8a1b-923cfadb6337, updateCntrs={193=1455, 
> 898=1434, 581=307, 584=159, 75=376, 331=233, 652=434, 13=420, 910=923, 
> 143=249, 147=619, 150=1185, 598=338, 728=1168, 90=598, 346=1169, 283=214, 
> 934=388, 615=310, 807=140, 1002=1132, 555=344, 365=215, 941=342, 946=515, 
> 1015=635, 56=614, 378=1130, 827=720, 956=5675}], 
> nodeId=d78ac9e5-60dd-4fa9-a8eb-7c5c36e189af, 
> locTopVer=AffinityTopologyVersion [topVer=248, minorTopVer=1], 
> msgTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], 
> cacheDesc=DynamicCacheDescriptor 
> [deploymentId=b8776e0c251-eb7db0e0-c35f-4a05-af44-5295c4cfdc01, locCfg=false, 
> staticCfg=true, started=true, cacheType=USER, template=false, 
> pluginMgr=GridCacheManagerAdapter [starting=false], updatesAllowed=true, 
> startTopVer=null, rcvdOnDiscovery=true, cacheName=GETS_ORDER_MAP]]
> {noformat}



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

[jira] [Assigned] (IGNITE-2555) Include offheap usage in metrics report

[Konstantin Margorin (JIRA)]

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

Konstantin Margorin reassigned IGNITE-2555:
---

Assignee: Konstantin Margorin

> Include offheap usage in metrics report
> ---
>
> Key: IGNITE-2555
> URL: https://issues.apache.org/jira/browse/IGNITE-2555
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Konstantin Margorin
>Priority: Minor
>  Labels: newbie
>
> The local node prints out the set of key parameters in its log (or console). 
> It makes sense to add offheap usage (used/free/committed) to that report.
> {noformat}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=41b12e0f, name=null]
> ^-- H/N/C [hosts=1, nodes=14, CPUs=8]
> ^-- CPU [cur=16,73%, avg=17,39%, GC=0,6%]
> ^-- Heap [used=1364MB, free=27,44%, comm=1881MB]
> ^-- Public thread pool [active=0, idle=16, qSize=0]
> ^-- System thread pool [active=1, idle=15, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}



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

[jira] [Resolved] (IGNITE-2608) Add key fields into value fields while importing model from DB in corner case

[Vasiliy Sisko (JIRA)]

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

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

Implemented copy of key fields to value fields when value fields is empty

> Add key fields into value fields while importing model from DB in corner case
> -
>
> Key: IGNITE-2608
> URL: https://issues.apache.org/jira/browse/IGNITE-2608
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.6
>
>
> I'm imported model from some database and faced with tables which has only 
> primary key fields. In this case we currently don't generate value fields at 
> all. In run-time in visor I got an NPE exception.
> In this corner case we should add all key fields into value fields 
> automatically.



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

[jira] [Updated] (IGNITE-2609) Add validation on new name of clone object

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2609:
---
Summary: Add validation on new name of clone object   (was: Add validation 
on new name of clon object )

> Add validation on new name of clone object 
> ---
>
> Key: IGNITE-2609
> URL: https://issues.apache.org/jira/browse/IGNITE-2609
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> # Domain models: On clone new name should be a valid Java class name.
> # On input of already exist name extend name to make it unique. 



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

[jira] [Updated] (IGNITE-1506) visorcmd: inconsistent result of 'disco' command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-1506:
-
Assignee: (was: Alexey Kuznetsov)

> visorcmd: inconsistent result of 'disco' command
> 
>
> Key: IGNITE-1506
> URL: https://issues.apache.org/jira/browse/IGNITE-1506
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Priority: Minor
>
> Currently 'disco' command shows at least one event (from node which executes 
> the task) in result even if discovery events are not configured - this is a 
> bit confuses.
> I think would be better to print out something like 'discovery events are not 
> configured'.



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

[jira] [Assigned] (IGNITE-1506) visorcmd: inconsistent result of 'disco' command

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-1506:


Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> visorcmd: inconsistent result of 'disco' command
> 
>
> Key: IGNITE-1506
> URL: https://issues.apache.org/jira/browse/IGNITE-1506
> Project: Ignite
>  Issue Type: Bug
>  Components: UI
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> Currently 'disco' command shows at least one event (from node which executes 
> the task) in result even if discovery events are not configured - this is a 
> bit confuses.
> I think would be better to print out something like 'discovery events are not 
> configured'.



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

[jira] [Updated] (IGNITE-1505) Error on stopping cache in visorcmd

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-1505:
-
Assignee: (was: Vasiliy Sisko)

> Error on stopping cache in visorcmd
> ---
>
> Key: IGNITE-1505
> URL: https://issues.apache.org/jira/browse/IGNITE-1505
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Priority: Minor
>
> I'm start my tester and trying to stop cache created only on one node and got
> {code}
> visor> cache -stop
> Time of the snapshot: 09/18/15, 13:31:40
> +===+
> | # |   Name(@)   |Mode | Size  |
> +===+
> | 0 | c_partitioned3(@c4) | PARTITIONED | min: 0|
> |   | | | avg: 1.50 |
> |   | | | max: 3|
> +---+-+-+---+
> | 1 | c_replicated(@c5)   | REPLICATED  | min: 0|
> |   | | | avg: 8121.00  |
> |   | | | max: 10828|
> +---+-+-+---+
> | 2 | dcp_1(@c6)  | PARTITIONED | min: 0|
> |   | | | avg: 2700.00  |
> |   | | | max: 3773 |
> +---+-+-+---+
> | 3 | dcp_2(@c7)  | PARTITIONED | min: 2496 |
> |   | | | avg: 2672.00  |
> |   | | | max: 2809 |
> +---+-+-+---+
> | 4 | dcr_1(@c8)  | REPLICATED  | min: 0|
> |   | | | avg: 8075.50  |
> |   | | | max: 10768|
> +---+-+-+---+
> | 5 | dcr_2(@c9)  | REPLICATED  | min: 0|
> |   | | | avg: 8039.75  |
> |   | | | max: 10720|
> +---+-+-+---+
> | 6 | local-nid(@c10) | LOCAL   | min: 10792|
> |   | | | avg: 10792.00 |
> |   | | | max: 10792|
> +---+
> Choose cache number ('c' to cancel) [c]: 6
> java.lang.IllegalArgumentException: Ouch! Argument is invalid: ids must not 
> be empty.
> at 
> org.apache.ignite.internal.util.GridArgumentCheck.notEmpty(GridArgumentCheck.java:122)
> at 
> org.apache.ignite.internal.cluster.ClusterGroupAdapter.forNodeIds(ClusterGroupAdapter.java:481)
> at org.apache.ignite.visor.visor$.groupForDataNode(visor.scala:272)
> at 
> org.apache.ignite.visor.commands.cache.VisorCacheStopCommand.scan(VisorCacheStopCommand.scala:96)
> at 
> org.apache.ignite.visor.commands.cache.VisorCacheCommand$$anonfun$cache$1.apply(VisorCacheCommand.scala:284)
> at 
> org.apache.ignite.visor.commands.cache.VisorCacheCommand$$anonfun$cache$1.apply(VisorCacheCommand.scala:274)
> at scala.Option.foreach(Option.scala:245)
> at 
> org.apache.ignite.visor.commands.cache.VisorCacheCommand.cache(VisorCacheCommand.scala:274)
> at 
> org.apache.ignite.visor.commands.cache.VisorCacheCommand$$anonfun$20.apply(VisorCacheCommand.scala:783)
> at 
> org.apache.ignite.visor.commands.cache.VisorCacheCommand$$anonfun$20.apply(VisorCacheCommand.scala:783)
> at 
> org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:214)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.delayedEndpoint$org$apache$ignite$visor$commands$VisorConsole$1(VisorConsole.scala:326)
> at 
> org.apache.ignite.visor.commands.VisorConsole$delayedInit$body.apply(VisorConsole.scala:315)
> at scala.Function0$class.apply$mcV$sp(Function0.scala:40)
> at 
> scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.collection.immutable.List.foreach(List.scala:381)
> at 
> scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
> at scala.App$class.main(App.scala:76)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.main(VisorConsole.scala:315)
> at 
> org.apache.ignite.visor.commands.VisorConsole.main(VisorConsole.scala)
> {code}



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