[jira] [Closed] (IGNITE-1419) .Net: Add optional "raw" flag to binary type configuration.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1419.
---

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



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

[jira] [Closed] (IGNITE-2621) .NET: Compute may fail in mixed-platform cluster

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2621.
---

> .NET: Compute may fail in mixed-platform cluster
> 
>
> Key: IGNITE-2621
> URL: https://issues.apache.org/jira/browse/IGNITE-2621
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> Start Java-only node, start .NET node, attempt to execute a computation. 
> .NET jobs will fail on Java-only nodes.
> 1) Make sure that .NET nodes can be identified (via an attribute)
> 2) Use .NET projection in platform compute. 
> If Affinity computation maps to a Java-only node, there will be a 
> ClusterGroupEmptyException



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

[jira] [Commented] (IGNITE-2621) .NET: Compute may fail in mixed-platform cluster

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2621:


Github user asfgit closed the pull request at:

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


> .NET: Compute may fail in mixed-platform cluster
> 
>
> Key: IGNITE-2621
> URL: https://issues.apache.org/jira/browse/IGNITE-2621
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> Start Java-only node, start .NET node, attempt to execute a computation. 
> .NET jobs will fail on Java-only nodes.
> 1) Make sure that .NET nodes can be identified (via an attribute)
> 2) Use .NET projection in platform compute. 
> If Affinity computation maps to a Java-only node, there will be a 
> ClusterGroupEmptyException



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

[jira] [Created] (IGNITE-2752) LINQ NuGet package

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2752:
--

 Summary: LINQ NuGet package
 Key: IGNITE-2752
 URL: https://issues.apache.org/jira/browse/IGNITE-2752
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Since NuGet is merged, we should create a package for LINQ assembly, and 
include LINQPad samples in it.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-2379:

Fix Version/s: (was: 1.6)
   1.7

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



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

[jira] [Updated] (IGNITE-1510) IGFS: Weird format() and remove() semantics.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-1510:

Summary: IGFS: Weird format() and remove() semantics.  (was: Weird format() 
and remove() semantics.)

> IGFS: Weird format() and remove() semantics.
> 
>
> Key: IGNITE-1510
> URL: https://issues.apache.org/jira/browse/IGNITE-1510
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> Currently we have two methods to remove something from IGFS:
> 1) remove - performs soft delete for PRIMARY mode and hard delete for others
> 2) format - delete of all IGFS data without touching seocndary file system, 
> which can be either soft or hard depending on some very coutner-intuitive 
> conditions.
> I think we should do the following:
> 1) remove operation stays as is.
> 2) format method is deprecated and just falls-back to a new method 
> "clear(ROOT)".
> 3) "clear" operation is semantically identical to cache clear: remove 
> in-memory data, do not touch persistence layer. Essentially it just moves a 
> tree into the trash just like remove does. But also this operation will offer 
> sync and async modes. In sync mode operation exits when all in-memory data is 
> really removed even from trash. 



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

[jira] [Closed] (IGNITE-2729) .NET: Add Troubleshooting section to the documentation

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2729.
---

> .NET: Add Troubleshooting section to the documentation
> --
>
> Key: IGNITE-2729
> URL: https://issues.apache.org/jira/browse/IGNITE-2729
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Describe common issues and error messages (like "ClassNotFound", IGNITE_HOME 
> issues, x64/x86 JVM, freeze on start, Java exceptions, etc), and how to fix 
> them.



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

[jira] [Updated] (IGNITE-2751) GridH2TreeIndex.getRowCount unwraps objects' values that are not used later

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2751:

Labels: community important  (was: )

> GridH2TreeIndex.getRowCount unwraps objects' values that are not used later
> ---
>
> Key: IGNITE-2751
> URL: https://issues.apache.org/jira/browse/IGNITE-2751
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Priority: Critical
>  Labels: community, important
> Fix For: 1.6
>
>
> If to run query like "SELECT COUNT(*) FROM table" then our implementation 
> will perform a full scan filtering out entries that are not primary for a 
> given node and will calculate only a number of primary ones.
> If entries are stored off-heap then both a key and value of an entry are 
> unswapped, Unswapped values are not used by backup filters thus we have to 
> omit unswapping of the values at all.



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

[jira] [Created] (IGNITE-2751) GridH2TreeIndex.getRowCount unwraps objects' values that are not used later

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2751:
---

 Summary: GridH2TreeIndex.getRowCount unwraps objects' values that 
are not used later
 Key: IGNITE-2751
 URL: https://issues.apache.org/jira/browse/IGNITE-2751
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Priority: Critical
 Fix For: 1.6


If to run query like "SELECT COUNT(*) FROM table" then our implementation will 
perform a full scan filtering out entries that are not primary for a given node 
and will calculate only a number of primary ones.

If entries are stored off-heap then both a key and value of an entry are 
unswapped, Unswapped values are not used by backup filters thus we have to omit 
unswapping of the values at all.



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

[jira] [Updated] (IGNITE-2750) REST connection is closed on the server side ignoring unfinished client requests

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-2750:

Labels: community important  (was: )

> REST connection is closed on the server side ignoring unfinished client 
> requests
> 
>
> Key: IGNITE-2750
> URL: https://issues.apache.org/jira/browse/IGNITE-2750
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>  Labels: community, important
> Fix For: 1.6
>
>
> Client can send long running request (i.e., compute tasks) to the cluster 
> over REST connection. If a task execution takes more time than 
> {{ConnectorConfiguration.idleTimeout}} then the connection will be closed by 
> server automatically.
> The server mustn't close the connection in cases if there are unfinished 
> requests received from clients. This approach already works on the client 
> side.



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

[jira] [Commented] (IGNITE-2724) Implement configuration of ZooKeeper Ip finder

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-2724:


1) Curator tooltip has duplicated text 'CuratorFrameworkImpl', please fix
2) Please change the order of Default and Custom retry policu in the tooltip. 
'Default' should be the last according to it position in the drop down list.


> Implement configuration of ZooKeeper Ip finder
> --
>
> Key: IGNITE-2724
> URL: https://issues.apache.org/jira/browse/IGNITE-2724
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>




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

[jira] [Reopened] (IGNITE-2724) Implement configuration of ZooKeeper Ip finder

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reopened IGNITE-2724:

  Assignee: Vasiliy Sisko  (was: Pavel Konstantinov)

> Implement configuration of ZooKeeper Ip finder
> --
>
> Key: IGNITE-2724
> URL: https://issues.apache.org/jira/browse/IGNITE-2724
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.6
>
>




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

[jira] [Updated] (IGNITE-2749) Web session clustering works incorrectly with WebLogic

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2749:

Attachment: master_ee01b61_ignite-2749.patch

> Web session clustering works incorrectly with WebLogic
> --
>
> Key: IGNITE-2749
> URL: https://issues.apache.org/jira/browse/IGNITE-2749
> Project: Ignite
>  Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
> Attachments: master_ee01b61_ignite-2749.patch
>
>
> {{WebSessionFilter}} has a special processing for the session ID generated by 
> WebLogic. The issue is that this processing is not applied in all required 
> cases.  E.g., session ID is transformed when new session is saved in cache 
> (see {{createSession}} method, but not transformed when it's fetched from 
> cache (see {{doFilter0}}.
> Need to go through the code, locate incorrect places and fix.



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

[jira] [Created] (IGNITE-2749) Web session clustering works incorrectly with WebLogic

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2749:
---

 Summary: Web session clustering works incorrectly with WebLogic
 Key: IGNITE-2749
 URL: https://issues.apache.org/jira/browse/IGNITE-2749
 Project: Ignite
  Issue Type: Bug
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
 Fix For: 1.6


{{WebSessionFilter}} has a special processing for the session ID generated by 
WebLogic. The issue is that this processing is not applied in all required 
cases.  E.g., session ID is transformed when new session is saved in cache (see 
{{createSession}} method, but not transformed when it's fetched from cache (see 
{{doFilter0}}.

Need to go through the code, locate incorrect places and fix.



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

[jira] [Commented] (IGNITE-257) Revisit heuristic transaction failure handling

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-257:
-

The changes have been merged. Unmuted tests on TC.

> Revisit heuristic transaction failure handling
> --
>
> Key: IGNITE-257
> URL: https://issues.apache.org/jira/browse/IGNITE-257
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.1.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 1.6
>
>
> Current tests assume that all transaction entries are invalidated, even 
> though it is not always possible. Need to revisit heuristic exception 
> handling logic.



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

[jira] [Commented] (IGNITE-2710) Session not unbind from current request after invoking request.getSession().invalidate()

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-2710:
--

Valentin, thank you!

> Session not unbind from current request after invoking 
> request.getSession().invalidate()
> 
>
> Key: IGNITE-2710
> URL: https://issues.apache.org/jira/browse/IGNITE-2710
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
> Environment: java8, tomcat8
>Reporter: YuxuanWang
>Assignee: Roman Shtykh
>  Labels: community, session, user
> Fix For: 1.6
>
>
> System.out.println(request.getSession().getId());
> request.getSession().invalidate();
> System.out.println(request.getSession().getId());
> getSession() although return the same session after the invalidation.



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

[jira] [Commented] (IGNITE-2710) Session not unbind from current request after invoking request.getSession().invalidate()

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-2710:
-

Roman,

Sorry for the delay. I will take a look at this today or tomorrow.

> Session not unbind from current request after invoking 
> request.getSession().invalidate()
> 
>
> Key: IGNITE-2710
> URL: https://issues.apache.org/jira/browse/IGNITE-2710
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
> Environment: java8, tomcat8
>Reporter: YuxuanWang
>Assignee: Roman Shtykh
>  Labels: community, session, user
> Fix For: 1.6
>
>
> System.out.println(request.getSession().getId());
> request.getSession().invalidate();
> System.out.println(request.getSession().getId());
> getSession() although return the same session after the invalidation.



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

[jira] [Commented] (IGNITE-1267) JobStealingCollisionSpi never sends jobs to a node that joined after task was executed

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-1267:
-

Removing the check completely is wrong, because in this case a job can be 
stealed by (or failed over to) a node that is not included in the cluster group 
specified when the task or closure was executed.

I think the best fix is to include the cluster group along with the list of 
nodes into the task session. Refer to any method in {{IgniteCompute}} and 
{{TC_SUBGRID}} context key. Once we have it, all such checks can be properly 
fixed.

> JobStealingCollisionSpi never sends jobs to a node that joined after task was 
> executed
> --
>
> Key: IGNITE-1267
> URL: https://issues.apache.org/jira/browse/IGNITE-1267
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>  Labels: user-request
>
> Corresponding user thread (contains detailed description of the scenario that 
> doesn't work): 
> http://apache-ignite-users.70518.x6.nabble.com/Dynamic-ComputeTask-distribution-with-new-nodes-td997.html
> Essentially, {{JobStealingCollisionSpi}} always skips jobs that are not in 
> task topology (see line 713). Task topology is static and created when task 
> is executed, so newly joined node can't steal jobs. I think it should be able 
> to do this if it satisfies initial cluster group predicate.



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

[jira] [Updated] (IGNITE-2748) Service proxy makes remote call for methods declared in java.lang.Object

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2748:

Attachment: master_d2d5d24_ignite-2748.patch

> Service proxy makes remote call for methods declared in java.lang.Object
> 
>
> Key: IGNITE-2748
> URL: https://issues.apache.org/jira/browse/IGNITE-2748
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
> Attachments: master_d2d5d24_ignite-2748.patch
>
>
> To reproduce the issue, get a service proxy and call one of 
> {{java.lang.Object}}  methods (e.g., {{hashCode}}). It will make a remote 
> call, which is not needed and can cause issues.
> In addition, we should block the gateway on proxy invocation.



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

[jira] [Updated] (IGNITE-2748) Service proxy makes remote call for methods declared in java.lang.Object

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2748:

Attachment: master_d2d5d24_ignite-2748.patch

> Service proxy makes remote call for methods declared in java.lang.Object
> 
>
> Key: IGNITE-2748
> URL: https://issues.apache.org/jira/browse/IGNITE-2748
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
> Attachments: master_d2d5d24_ignite-2748.patch
>
>
> To reproduce the issue, get a service proxy and call one of 
> {{java.lang.Object}}  methods (e.g., {{hashCode}}). It will make a remote 
> call, which is not needed and can cause issues.
> In addition, we should block the gateway on proxy invocation.



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

[jira] [Updated] (IGNITE-2748) Service proxy makes remote call for methods declared in java.lang.Object

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-2748:

Description: 
To reproduce the issue, get a service proxy and call one of 
{{java.lang.Object}}  methods (e.g., {{hashCode}}). It will make a remote call, 
which is not needed and can cause issues.

In addition, we should block the gateway on proxy invocation.

  was:To reproduce the issue, get a service proxy and call one of 
{{java.lang.Object}}  methods (e.g., {{hashCode}}). It will make a remote call, 
which is not needed and can cause issues.


> Service proxy makes remote call for methods declared in java.lang.Object
> 
>
> Key: IGNITE-2748
> URL: https://issues.apache.org/jira/browse/IGNITE-2748
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> To reproduce the issue, get a service proxy and call one of 
> {{java.lang.Object}}  methods (e.g., {{hashCode}}). It will make a remote 
> call, which is not needed and can cause issues.
> In addition, we should block the gateway on proxy invocation.



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

[jira] [Created] (IGNITE-2748) Service proxy makes remote call for methods declared in java.lang.Object

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2748:
---

 Summary: Service proxy makes remote call for methods declared in 
java.lang.Object
 Key: IGNITE-2748
 URL: https://issues.apache.org/jira/browse/IGNITE-2748
 Project: Ignite
  Issue Type: Bug
  Components: managed services
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
 Fix For: 1.6


To reproduce the issue, get a service proxy and call one of 
{{java.lang.Object}}  methods (e.g., {{hashCode}}). It will make a remote call, 
which is not needed and can cause issues.



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

[jira] [Commented] (IGNITE-2407) GetAll returns NULL after putAll

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-2407:
--

Alexey,

We always need finish responses because there is code which waits for finish 
responses before acquring locks (see usages of 
IgniteTxManager.awaitFinishAckAsync, IgniteTxManager.beforeFinishRemote). 
Didn't touch this to be on the safe side.

> GetAll returns NULL after putAll
> 
>
> Key: IGNITE-2407
> URL: https://issues.apache.org/jira/browse/IGNITE-2407
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.6
>
> Attachments: CachePutAllGetAllExample.java, putall-client.xml, 
> putall.xml
>
>
> 0. Copy attached configurations files into examples\config directory, source 
> code into org.apache.ignite.examples.datagrid
> 1. Start server 6 nodes: 
> {noformat}
> bin\ignite examples\config\putall.xml
> {noformat}
> 2. Start {{CachePutAllGetAllExample}} in IDEA. The example iterates 
> removeAll/put/putAll/getAll operations over same cache. The expected 
> behaviour is no NULL values returned by getAll.
> 3. The output like the following:
> {noformat}
> 1345
> C:\Java\jdk1.7.0_80\bin\java -Didea.launcher.port=7532 
> "-Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 
> Community Edition 14.1.4\bin" -Dfile.encoding=windows-1251 -classpath 
> "C:\Java\jdk1.7.0_80\jre\lib\charsets.jar;C:\Java\jdk1.7.0_80\jre\lib\deploy.jar;C:\Java\jdk1.7.0_80\jre\lib\javaws.jar;C:\Java\jdk1.7.0_80\jre\lib\jce.jar;C:\Java\jdk1.7.0_80\jre\lib\jfr.jar;C:\Java\jdk1.7.0_80\jre\lib\jfxrt.jar;C:\Java\jdk1.7.0_80\jre\lib\jsse.jar;C:\Java\jdk1.7.0_80\jre\lib\management-agent.jar;C:\Java\jdk1.7.0_80\jre\lib\plugin.jar;C:\Java\jdk1.7.0_80\jre\lib\resources.jar;C:\Java\jdk1.7.0_80\jre\lib\rt.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\access-bridge-64.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\dnsns.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\jaccess.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\localedata.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunec.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunjce_provider.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunmscapi.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\zipfs.jar;C:\Work\apache-ignite-fabric-1.5.0.final-bin\examples\target\classes;C:\Users\gridgain\.m2\repository\javax\cache\cache-api\1.0.0\cache-api-1.0.0.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-core\1.5.0.final\ignite-core-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\org\gridgain\ignite-shmem\1.0.0\ignite-shmem-1.0.0.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-spring\1.5.0.final\ignite-spring-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-core\4.1.0.RELEASE\spring-core-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-aop\4.1.0.RELEASE\spring-aop-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-beans\4.1.0.RELEASE\spring-beans-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-context\4.1.0.RELEASE\spring-context-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-expression\4.1.0.RELEASE\spring-expression-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-tx\4.1.0.RELEASE\spring-tx-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-jdbc\4.1.0.RELEASE\spring-jdbc-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-log4j\1.5.0.final\ignite-log4j-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-indexing\1.5.0.final\ignite-indexing-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\commons-codec\commons-codec\1.6\commons-codec-1.6.jar;C:\Users\gridgain\.m2\repository\org\apache\lucene\lucene-core\3.5.0\lucene-core-3.5.0.jar;C:\Users\gridgain\.m2\repository\com\h2database\h2\1.3.175\h2-1.3.175.jar;C:\Users\gridgain\.m2\repository\com\google\code\simple-spring-memcached\spymemcached\2.7.3\spymemcached-2.7.3.jar;C:\Users\gridgain\.m2\repository\org\jboss\netty\netty\3.2.0.Final\netty-3.2.0.Final.jar;C:\Users\gridgain\.m2\repository\org\codehaus\jettison\jettison\1.1\jettison-1.1.jar;C:\Users\gridgain\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar;C:\Program
>  Files (x86)\JetBrains\IntelliJ IDEA Community Edition 
> 14.1.4\lib\idea_rt.jar" com.intellij.rt.execution.application.AppMain 
> 

[jira] [Commented] (IGNITE-2505) IgniteTxImplicitSingleStateImpl#allEntries() and #writes() instantiate new collection on every call

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-2505:
--

Looks good. Please go ahead and merge.

> IgniteTxImplicitSingleStateImpl#allEntries() and #writes() instantiate new 
> collection on every call
> ---
>
> Key: IGNITE-2505
> URL: https://issues.apache.org/jira/browse/IGNITE-2505
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Ilya Lantukh
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> It can be optimized by creating and storing Collections.singletonList() on 
> #addEntry() call.



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

[jira] [Updated] (IGNITE-2505) IgniteTxImplicitSingleStateImpl#allEntries() and #writes() instantiate new collection on every call

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-2505:
-
Assignee: Vladimir Ozerov  (was: Alexey Goncharuk)

> IgniteTxImplicitSingleStateImpl#allEntries() and #writes() instantiate new 
> collection on every call
> ---
>
> Key: IGNITE-2505
> URL: https://issues.apache.org/jira/browse/IGNITE-2505
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Ilya Lantukh
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> It can be optimized by creating and storing Collections.singletonList() on 
> #addEntry() call.



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

[jira] [Commented] (IGNITE-2407) GetAll returns NULL after putAll

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-2407:
--

Semyon,

Changes look good. I have one question, though, regarding 
{{GridDhtTxFinishFuture:221}}. Why do we need to send finish reply in 
FULL_ASYNC mode? Shouldn't we just check {{if (tx.syncMode() == FULL_SYNC)}} ?

> GetAll returns NULL after putAll
> 
>
> Key: IGNITE-2407
> URL: https://issues.apache.org/jira/browse/IGNITE-2407
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 1.6
>
> Attachments: CachePutAllGetAllExample.java, putall-client.xml, 
> putall.xml
>
>
> 0. Copy attached configurations files into examples\config directory, source 
> code into org.apache.ignite.examples.datagrid
> 1. Start server 6 nodes: 
> {noformat}
> bin\ignite examples\config\putall.xml
> {noformat}
> 2. Start {{CachePutAllGetAllExample}} in IDEA. The example iterates 
> removeAll/put/putAll/getAll operations over same cache. The expected 
> behaviour is no NULL values returned by getAll.
> 3. The output like the following:
> {noformat}
> 1345
> C:\Java\jdk1.7.0_80\bin\java -Didea.launcher.port=7532 
> "-Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 
> Community Edition 14.1.4\bin" -Dfile.encoding=windows-1251 -classpath 
> "C:\Java\jdk1.7.0_80\jre\lib\charsets.jar;C:\Java\jdk1.7.0_80\jre\lib\deploy.jar;C:\Java\jdk1.7.0_80\jre\lib\javaws.jar;C:\Java\jdk1.7.0_80\jre\lib\jce.jar;C:\Java\jdk1.7.0_80\jre\lib\jfr.jar;C:\Java\jdk1.7.0_80\jre\lib\jfxrt.jar;C:\Java\jdk1.7.0_80\jre\lib\jsse.jar;C:\Java\jdk1.7.0_80\jre\lib\management-agent.jar;C:\Java\jdk1.7.0_80\jre\lib\plugin.jar;C:\Java\jdk1.7.0_80\jre\lib\resources.jar;C:\Java\jdk1.7.0_80\jre\lib\rt.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\access-bridge-64.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\dnsns.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\jaccess.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\localedata.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunec.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunjce_provider.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunmscapi.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\zipfs.jar;C:\Work\apache-ignite-fabric-1.5.0.final-bin\examples\target\classes;C:\Users\gridgain\.m2\repository\javax\cache\cache-api\1.0.0\cache-api-1.0.0.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-core\1.5.0.final\ignite-core-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\org\gridgain\ignite-shmem\1.0.0\ignite-shmem-1.0.0.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-spring\1.5.0.final\ignite-spring-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-core\4.1.0.RELEASE\spring-core-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-aop\4.1.0.RELEASE\spring-aop-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-beans\4.1.0.RELEASE\spring-beans-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-context\4.1.0.RELEASE\spring-context-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-expression\4.1.0.RELEASE\spring-expression-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-tx\4.1.0.RELEASE\spring-tx-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-jdbc\4.1.0.RELEASE\spring-jdbc-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-log4j\1.5.0.final\ignite-log4j-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-indexing\1.5.0.final\ignite-indexing-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\commons-codec\commons-codec\1.6\commons-codec-1.6.jar;C:\Users\gridgain\.m2\repository\org\apache\lucene\lucene-core\3.5.0\lucene-core-3.5.0.jar;C:\Users\gridgain\.m2\repository\com\h2database\h2\1.3.175\h2-1.3.175.jar;C:\Users\gridgain\.m2\repository\com\google\code\simple-spring-memcached\spymemcached\2.7.3\spymemcached-2.7.3.jar;C:\Users\gridgain\.m2\repository\org\jboss\netty\netty\3.2.0.Final\netty-3.2.0.Final.jar;C:\Users\gridgain\.m2\repository\org\codehaus\jettison\jettison\1.1\jettison-1.1.jar;C:\Users\gridgain\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar;C:\Program
>  Files (x86)\JetBrains\IntelliJ IDEA Community Edition 
> 14.1.4\lib\idea_rt.jar" com.intellij.rt.execution.application.AppMain 
> org.apache.ignite.examples.datagrid.CachePutAllGetAllExample
> [17:56:05]

[jira] [Updated] (IGNITE-2407) GetAll returns NULL after putAll

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-2407:
-
Assignee: Semen Boikov  (was: Alexey Goncharuk)

> GetAll returns NULL after putAll
> 
>
> Key: IGNITE-2407
> URL: https://issues.apache.org/jira/browse/IGNITE-2407
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Semen Boikov
>Priority: Critical
> Fix For: 1.6
>
> Attachments: CachePutAllGetAllExample.java, putall-client.xml, 
> putall.xml
>
>
> 0. Copy attached configurations files into examples\config directory, source 
> code into org.apache.ignite.examples.datagrid
> 1. Start server 6 nodes: 
> {noformat}
> bin\ignite examples\config\putall.xml
> {noformat}
> 2. Start {{CachePutAllGetAllExample}} in IDEA. The example iterates 
> removeAll/put/putAll/getAll operations over same cache. The expected 
> behaviour is no NULL values returned by getAll.
> 3. The output like the following:
> {noformat}
> 1345
> C:\Java\jdk1.7.0_80\bin\java -Didea.launcher.port=7532 
> "-Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 
> Community Edition 14.1.4\bin" -Dfile.encoding=windows-1251 -classpath 
> "C:\Java\jdk1.7.0_80\jre\lib\charsets.jar;C:\Java\jdk1.7.0_80\jre\lib\deploy.jar;C:\Java\jdk1.7.0_80\jre\lib\javaws.jar;C:\Java\jdk1.7.0_80\jre\lib\jce.jar;C:\Java\jdk1.7.0_80\jre\lib\jfr.jar;C:\Java\jdk1.7.0_80\jre\lib\jfxrt.jar;C:\Java\jdk1.7.0_80\jre\lib\jsse.jar;C:\Java\jdk1.7.0_80\jre\lib\management-agent.jar;C:\Java\jdk1.7.0_80\jre\lib\plugin.jar;C:\Java\jdk1.7.0_80\jre\lib\resources.jar;C:\Java\jdk1.7.0_80\jre\lib\rt.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\access-bridge-64.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\dnsns.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\jaccess.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\localedata.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunec.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunjce_provider.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\sunmscapi.jar;C:\Java\jdk1.7.0_80\jre\lib\ext\zipfs.jar;C:\Work\apache-ignite-fabric-1.5.0.final-bin\examples\target\classes;C:\Users\gridgain\.m2\repository\javax\cache\cache-api\1.0.0\cache-api-1.0.0.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-core\1.5.0.final\ignite-core-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\org\gridgain\ignite-shmem\1.0.0\ignite-shmem-1.0.0.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-spring\1.5.0.final\ignite-spring-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-core\4.1.0.RELEASE\spring-core-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-aop\4.1.0.RELEASE\spring-aop-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-beans\4.1.0.RELEASE\spring-beans-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-context\4.1.0.RELEASE\spring-context-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-expression\4.1.0.RELEASE\spring-expression-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-tx\4.1.0.RELEASE\spring-tx-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\org\springframework\spring-jdbc\4.1.0.RELEASE\spring-jdbc-4.1.0.RELEASE.jar;C:\Users\gridgain\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-log4j\1.5.0.final\ignite-log4j-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar;C:\Users\gridgain\.m2\repository\org\apache\ignite\ignite-indexing\1.5.0.final\ignite-indexing-1.5.0.final.jar;C:\Users\gridgain\.m2\repository\commons-codec\commons-codec\1.6\commons-codec-1.6.jar;C:\Users\gridgain\.m2\repository\org\apache\lucene\lucene-core\3.5.0\lucene-core-3.5.0.jar;C:\Users\gridgain\.m2\repository\com\h2database\h2\1.3.175\h2-1.3.175.jar;C:\Users\gridgain\.m2\repository\com\google\code\simple-spring-memcached\spymemcached\2.7.3\spymemcached-2.7.3.jar;C:\Users\gridgain\.m2\repository\org\jboss\netty\netty\3.2.0.Final\netty-3.2.0.Final.jar;C:\Users\gridgain\.m2\repository\org\codehaus\jettison\jettison\1.1\jettison-1.1.jar;C:\Users\gridgain\.m2\repository\stax\stax-api\1.0.1\stax-api-1.0.1.jar;C:\Program
>  Files (x86)\JetBrains\IntelliJ IDEA Community Edition 
> 14.1.4\lib\idea_rt.jar" com.intellij.rt.execution.application.AppMain 
> org.apache.ignite.examples.datagrid.CachePutAllGetAllExample
> [17:56:05]__   
> [17:56:05]   /  _/ ___/ |/ /  _/_  __/ __/ 
> [17:56:05]  _/ // (7 7// /  / / / _/   
> [17:56:05] /___/\___/_/|_/___/ /_/ /___/  
> [17:56:05] 
> [17:56:05] ver. 

[jira] [Created] (IGNITE-2747) ODBC: Time cast returns wrong results for Linux.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2747:
---

 Summary: ODBC: Time cast returns wrong results for Linux.
 Key: IGNITE-2747
 URL: https://issues.apache.org/jira/browse/IGNITE-2747
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


Current time cast does not work for Linux because {{timezone}} variable does 
not return right time offset for Linux.

Also, {{gmtime}} is not thread-safe so it seems that we should use some 
platform-specific functions for time-conversion operations.



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

[jira] [Commented] (IGNITE-255) Jvm8 warns that MaxPermSize is ignored

[Saikat Maitra (JIRA)]

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

Saikat Maitra commented on IGNITE-255:
--

[~dmagda]

Thank you Denis !!!

> Jvm8 warns that MaxPermSize is ignored
> --
>
> Key: IGNITE-255
> URL: https://issues.apache.org/jira/browse/IGNITE-255
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: sprint-1
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>
> Jaba8 doesn't support MaxPermSize anymore. Either we should replace it in 
> ignite.sh by a similar option of Java8 or set it only if ignite.sh started 
> for Java7
> {noformat}
> D:\GridGain\Ignite-SP1\ignite-fabric-1.0.0-RC1-SNAPSHOT>bin\ignite.bat
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
> support was removed in 8.0
> [15:50:16]__  
> [15:50:16]   /  _/ ___/ |/ /  _/_  __/ __/
> [15:50:16]  _/ // (_ /// /  / / / _/
> [15:50:16] /___/\___/_/|_/___/ /_/ /___/
> [15:50:16]
> [15:50:16] ver. 1.0.0-RC1-SNAPSHOT#20150214-sha1:4d01989c
> [15:50:16] 2015 Copyright(C) Apache Software Foundation
> [15:50:16]
> {noformat}



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

[jira] [Closed] (IGNITE-2333) Hotspot in GridDhtPartitionTopologyImpl readLock() and readUnlock() methods

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2333.
---

> Hotspot in GridDhtPartitionTopologyImpl readLock() and readUnlock() methods
> ---
>
> Key: IGNITE-2333
> URL: https://issues.apache.org/jira/browse/IGNITE-2333
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> When running simple PUT benchmark in ATOMIC cache, read lock-unlock consumes 
> up to 10% of time.



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

[jira] [Closed] (IGNITE-2734) Preloading fails during entry preloading for binary enum with OFFHEAP_VALUES cache memory mode

[Andrey Gura (JIRA)]

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

Andrey Gura closed IGNITE-2734.
---

> Preloading fails during entry preloading for binary enum with OFFHEAP_VALUES 
> cache memory mode 
> ---
>
> Key: IGNITE-2734
> URL: https://issues.apache.org/jira/browse/IGNITE-2734
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> Preloading fails during preloading of entry for {{BinaryEnumObjectImpl}} 
> value type and cache memory mode is {{OFFHEAP_VALUES}}. 
> {{GridCacheReplicatedPreloadOffHeapSelfTest.testDeployment}} fails on TC.
> {noformat}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.util.offheap.unsafe.GridUnsafeMemory.putOffHeap(GridUnsafeMemory.java:413)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.value(GridCacheMapEntry.java:252)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.update(GridCacheMapEntry.java:2916)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3258)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:683)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:572)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:408)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:605)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$400(GridCacheIoManager.java:81)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1108)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2239)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1004)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:973)
> 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] [Commented] (IGNITE-2718) modules/zookeeper/target/libs directory does not have all dependencies

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-2718:
--

Roman, 

We have to add explicitly only dependencies we want to see at result build. 
Transitive dependencies will not get into result build. Final artifact size 
should be as small as possible.
Please make sure you did not add redundant dependencies .

> modules/zookeeper/target/libs directory does not have all dependencies
> --
>
> Key: IGNITE-2718
> URL: https://issues.apache.org/jira/browse/IGNITE-2718
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-zookeeper
>Reporter: Dustin Chesterman
>Assignee: Roman Shtykh
>Priority: Critical
>  Labels: community
> Fix For: 1.6
>
>
> If you specify the zookeeper ip finder in the example cache config there are 
> a host of classnotfound exceptions.  I believe these need to be populated 
> into the build target lib dir.
> {code}
> 
> 
> 
> 
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder">
>  value="false" />
> 
> 
>  value="192.168.200.11:2181" />
> 
> 
> 
> {code}



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

[jira] [Commented] (IGNITE-2333) Hotspot in GridDhtPartitionTopologyImpl readLock() and readUnlock() methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2333:


Github user asfgit closed the pull request at:

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


> Hotspot in GridDhtPartitionTopologyImpl readLock() and readUnlock() methods
> ---
>
> Key: IGNITE-2333
> URL: https://issues.apache.org/jira/browse/IGNITE-2333
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache, general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> When running simple PUT benchmark in ATOMIC cache, read lock-unlock consumes 
> up to 10% of time.



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

[jira] [Commented] (IGNITE-2734) Preloading fails during entry preloading for binary enum with OFFHEAP_VALUES cache memory mode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2734:


Github user agura closed the pull request at:

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


> Preloading fails during entry preloading for binary enum with OFFHEAP_VALUES 
> cache memory mode 
> ---
>
> Key: IGNITE-2734
> URL: https://issues.apache.org/jira/browse/IGNITE-2734
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> Preloading fails during preloading of entry for {{BinaryEnumObjectImpl}} 
> value type and cache memory mode is {{OFFHEAP_VALUES}}. 
> {{GridCacheReplicatedPreloadOffHeapSelfTest.testDeployment}} fails on TC.
> {noformat}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.util.offheap.unsafe.GridUnsafeMemory.putOffHeap(GridUnsafeMemory.java:413)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.value(GridCacheMapEntry.java:252)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.update(GridCacheMapEntry.java:2916)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3258)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:683)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:572)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:408)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:605)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$400(GridCacheIoManager.java:81)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1108)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2239)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1004)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:973)
> 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] [Assigned] (IGNITE-2721) Optimize ATOMIC cache request/responses.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-2721:


Assignee: (was: Ilya Lantukh)

> Optimize ATOMIC cache request/responses.
> 
>
> Key: IGNITE-2721
> URL: https://issues.apache.org/jira/browse/IGNITE-2721
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> Our request/responses for ATOMIC cache has lots of fields which are normally 
> unused.
> To give an idea on possible optimizations lets look closely on 
> GridNearAtomicUpdateRequest:
> * {{futVer}} - could be converted to int
> * {{syncMode}} - why do we pass it? Can it be derived from cache config?
> * {{op}} - can it be derived form request?
> * Entry processors and invoke arguments - can be moved to extras, or separate 
> request class can be created for them.
> * Conflict data - usually null, must be moved to extras
> * Expiry policy - must be moved to extras.
> * {{filter}} - only one filter is ever passed - when we need to compare 
> existing value. Lets pass the value instead!
> * Lots of flags - can be written as a single byte. Though, it's priority is 
> not so high.
> * {{topVer}} - could easily be inlined to save allocations and network 
> traffic. 
> As a result of this investigation we must create a list of optimizations to 
> be performed and prioritize them. Then we should implement them one by one, 
> keeping them merged in a separate branch (not master!) until we are sure that 
> we did everything we can.



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

[jira] [Created] (IGNITE-2746) .NET: Improve ReflectiveSerializer control with attributes

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2746:
--

 Summary: .NET: Improve ReflectiveSerializer control with attributes
 Key: IGNITE-2746
 URL: https://issues.apache.org/jira/browse/IGNITE-2746
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 1.6


Allow custom field names and ordering (similar to DataMemberAttribute, for 
example: 
https://msdn.microsoft.com/en-us/library/system.runtime.serialization.datamemberattribute(v=vs.110).aspx)



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

[jira] [Updated] (IGNITE-2739) .NET: AffinityKey support

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2739:
---
Description: 
Add AffinityKey class and AffinityKeyMapped attribute to allow custom affinity 
mapping.
This is crucial for SQL joins to work properly.
See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in Java.

  was:
Add AffinityKey to allow custom affinity mapping.
This is crucial for SQL joins to work properly.
See org.apache.ignite.cache.affinity.AffinityKey in Java.


> .NET: AffinityKey support
> -
>
> Key: IGNITE-2739
> URL: https://issues.apache.org/jira/browse/IGNITE-2739
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.6
>
>
> Add AffinityKey class and AffinityKeyMapped attribute to allow custom 
> affinity mapping.
> This is crucial for SQL joins to work properly.
> See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in 
> Java.



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

[jira] [Commented] (IGNITE-2729) .NET: Add Troubleshooting section to the documentation

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2729:


Done: https://apacheignite-net.readme.io/docs/troubleshooting

> .NET: Add Troubleshooting section to the documentation
> --
>
> Key: IGNITE-2729
> URL: https://issues.apache.org/jira/browse/IGNITE-2729
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> Describe common issues and error messages (like "ClassNotFound", IGNITE_HOME 
> issues, x64/x86 JVM, freeze on start, Java exceptions, etc), and how to fix 
> them.



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

[jira] [Commented] (IGNITE-2740) .NET: IGNITE_HOME resolution restricts custom deployment

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2740:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-2740 Remove error in IGNITE_HOME check



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

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

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

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


commit 917051798822aec2afe03cf0c121766732bd0471
Author: Pavel Tupitsyn 
Date:   2016-03-02T10:43:32Z

Remove forced IGNITE_HOME check




> .NET: IGNITE_HOME resolution restricts custom deployment
> 
>
> Key: IGNITE-2740
> URL: https://issues.apache.org/jira/browse/IGNITE-2740
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.6
>
>
> Need to make sure that users may deploy Ignite JARs with their applications 
> in any way they want.
> Currently we have quite restrictive checks in IgniteHome.IsIgniteHome method.
> Documentation should also be updated with "Deployment" page.



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

[jira] [Commented] (IGNITE-2740) .NET: IGNITE_HOME resolution restricts custom deployment

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2740:


* Removed exception on failed IGNITE_HOME resolve (it was added incorrectly as 
part of IGNITE-1626).
* Added documentation: https://apacheignite-net.readme.io/docs/deployment

IGNITE-1626 also introduced another way: put jars into "libs" folder near 
Apache.Ignite.Core.dll. We can add that to the documentation after release.

> .NET: IGNITE_HOME resolution restricts custom deployment
> 
>
> Key: IGNITE-2740
> URL: https://issues.apache.org/jira/browse/IGNITE-2740
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> Need to make sure that users may deploy Ignite JARs with their applications 
> in any way they want.
> Currently we have quite restrictive checks in IgniteHome.IsIgniteHome method.
> Documentation should also be updated with "Deployment" page.



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

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

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-2654:


Assignee: (was: Vladimir Ozerov)

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



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

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

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-2654:


Assignee: Vladimir Ozerov  (was: Ilya Lantukh)

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



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

[jira] [Created] (IGNITE-2745) Fast access to GridTopic listeners.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2745:
---

 Summary: Fast access to GridTopic listeners.
 Key: IGNITE-2745
 URL: https://issues.apache.org/jira/browse/IGNITE-2745
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6


Currently all listeners are located inside a ConcurrentHashMap. It takes some 
time to get a listener from it.

The most important listeners are those of GridTopic enum. Let's store these 
listeners in volatile array where enum ordinal will be listener index.



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

[jira] [Created] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2744:
---

 Summary: Optimize "unwindEvict" call in 
GridCacheIoManager.processMessage().
 Key: IGNITE-2744
 URL: https://issues.apache.org/jira/browse/IGNITE-2744
 Project: Ignite
  Issue Type: Sub-task
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


We call this method on every (!!!) received cache message. This call is pretty 
heavy as it iterates over all caches. 
We need to optimize it. E.g., check evicts only for the cache to which received 
message belongs. And iterate over the whole set only if we know for sure that 
several caches are affected (e.g. due to cross-cache TX).



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

[jira] [Closed] (IGNITE-2409) Is CU.clientNode() really needed?

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-2409.
---

> Is CU.clientNode() really needed?
> -
>
> Key: IGNITE-2409
> URL: https://issues.apache.org/jira/browse/IGNITE-2409
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Profiling shows medium hot spot in the method 
> GridCacheUtils.clientNode(ClusterNode) - considerable amount of time is spent 
> on attributes map lookup. 
> What is interesting is that ClusterNode already has isClient() method which 
> do not require any lookups.
> Can we simply remove GridCacheUtils.clientNode() method and use 
> ClusterNode.isClient() instead?



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

[jira] [Assigned] (IGNITE-2409) Is CU.clientNode() really needed?

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-2409:
---

Assignee: Vladimir Ozerov  (was: Alexey Goncharuk)

> Is CU.clientNode() really needed?
> -
>
> Key: IGNITE-2409
> URL: https://issues.apache.org/jira/browse/IGNITE-2409
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Profiling shows medium hot spot in the method 
> GridCacheUtils.clientNode(ClusterNode) - considerable amount of time is spent 
> on attributes map lookup. 
> What is interesting is that ClusterNode already has isClient() method which 
> do not require any lookups.
> Can we simply remove GridCacheUtils.clientNode() method and use 
> ClusterNode.isClient() instead?



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

[jira] [Updated] (IGNITE-2742) Do not save "confirm" on user sign up

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2742:
---
Description: 
Current save request contains "confirm":"1"
No needs to save this parameters to the DB.

  was:
Current save request contains "confirm":"1"
No needs to save these parameters to the DB.


> Do not save "confirm" on user sign up
> -
>
> Key: IGNITE-2742
> URL: https://issues.apache.org/jira/browse/IGNITE-2742
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 1.6
>
>
> Current save request contains "confirm":"1"
> No needs to save this parameters to the DB.



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

[jira] [Updated] (IGNITE-2742) Do not save "confirm" on user sign up

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2742:
---
Description: 
Current save request contains "confirm":"1"
No needs to save these parameters to the DB.

  was:
Current save request contains "confirm":"1","agree":true.
No needs to save these parameters to the DB.


> Do not save "confirm" on user sign up
> -
>
> Key: IGNITE-2742
> URL: https://issues.apache.org/jira/browse/IGNITE-2742
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 1.6
>
>
> Current save request contains "confirm":"1"
> No needs to save these parameters to the DB.



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

[jira] [Updated] (IGNITE-2742) Do not save "confirm" on user sign up

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-2742:
---
Summary: Do not save "confirm" on user sign up  (was: Do not save "confirm" 
and "agree" on user sign up)

> Do not save "confirm" on user sign up
> -
>
> Key: IGNITE-2742
> URL: https://issues.apache.org/jira/browse/IGNITE-2742
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 1.6
>
>
> Current save request contains "confirm":"1","agree":true.
> No needs to save these parameters to the DB.



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

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

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-2523:
--

Implemented optimizations for clock mode, but haven't tested them for all cases.

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



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

[jira] [Created] (IGNITE-2743) Broken download page on ignite.apache.org

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2743:
--

 Summary: Broken download page on ignite.apache.org
 Key: IGNITE-2743
 URL: https://issues.apache.org/jira/browse/IGNITE-2743
 Project: Ignite
  Issue Type: Bug
  Components: website
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Priority: Blocker
 Fix For: 1.6


There are two download pages:
* https://ignite.apache.org/download.cgi (correct)
* https://ignite.apache.org/download (incorrect)

All links are broken on the second one. You can't get on this broken page from 
our website, but it is the first page in Google for "apache ignite download": 
https://www.google.ru/search?q=apache+ignite+download

Ideally, https://ignite.apache.org/download should be the correct link (.cgi in 
the url is from 90's)



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

[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-640:
--

Hi Konstantin!

Very good start!

I have reviewed 
https://github.com/apache/ignite/compare/master...ruskim:ignite-640?expand=1 
and here are my comments.

1. I don't think we need busy lock in the map. I don't see in in IgniteSet or 
IgniteQueue either. Can you please point me to the usages in data structures?
2. IgniteMultimap interface should be documented and contain "public" modifiers 
for members. Please take a look at IgniteQueue, for instance, and be consistent.
3. I don't like ArrayLists as values. They will often have 1-2-3 elements. I 
would use exact size arrays. This way we avoid unnecessary memory overhead. Or 
investigate use single-linked list structure. Maybe we should provide an 
ability to choose the backing structure. I.e. if map is not supposed to change 
very often then arrays seems to be perfect.
4. Using "key" provided by user as map key is not correct. You can end up with 
the situation when several multimaps can backed by the same cache. This way you 
require keys to be unique across all maps. Please see GridCacheQueueItemKey or 
GridCacheSetItemKey
5. Can I ask you to fully design multimap interface and then send notice to dev 
list so others can review?
6. I would also think of providing support for comparable values.

Yakov

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Konstantin Margorin
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> 

[jira] [Updated] (IGNITE-2740) .NET: IGNITE_HOME resolution restricts custom deployment

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2740:
---
Description: 
Need to make sure that users may deploy Ignite JARs with their applications in 
any way they want.

Currently we have quite restrictive checks in IgniteHome.IsIgniteHome method.

Documentation should also be updated with "Deployment" page.

  was:
Need to make sure that users may deploy Ignite JARs with their applications in 
any way they want.

Currently we have quite restrictive checks in IgniteHome.IsIgniteHome method.

Documentation should also be updated.


> .NET: IGNITE_HOME resolution restricts custom deployment
> 
>
> Key: IGNITE-2740
> URL: https://issues.apache.org/jira/browse/IGNITE-2740
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Blocker
> Fix For: 1.6
>
>
> Need to make sure that users may deploy Ignite JARs with their applications 
> in any way they want.
> Currently we have quite restrictive checks in IgniteHome.IsIgniteHome method.
> Documentation should also be updated with "Deployment" page.



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

[jira] [Commented] (IGNITE-2734) Preloading fails during entry preloading for binary enum with OFFHEAP_VALUES cache memory mode

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-2734:
-

Done.

> Preloading fails during entry preloading for binary enum with OFFHEAP_VALUES 
> cache memory mode 
> ---
>
> Key: IGNITE-2734
> URL: https://issues.apache.org/jira/browse/IGNITE-2734
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
>
> Preloading fails during preloading of entry for {{BinaryEnumObjectImpl}} 
> value type and cache memory mode is {{OFFHEAP_VALUES}}. 
> {{GridCacheReplicatedPreloadOffHeapSelfTest.testDeployment}} fails on TC.
> {noformat}
> java.lang.AssertionError
> at 
> org.apache.ignite.internal.util.offheap.unsafe.GridUnsafeMemory.putOffHeap(GridUnsafeMemory.java:413)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.value(GridCacheMapEntry.java:252)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.update(GridCacheMapEntry.java:2916)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3258)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:683)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:572)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:408)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:605)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:303)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$400(GridCacheIoManager.java:81)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1108)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2239)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1004)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:973)
> 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] [Resolved] (IGNITE-2732) Store factory mismatch in generated project

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko resolved IGNITE-2732.
---
Resolution: Won't Fix

Node code and node spring start up class in incompatible in case when 
JdbcPojoStoreFactory is configured.

> Store factory mismatch in generated project
> ---
>
> Key: IGNITE-2732
> URL: https://issues.apache.org/jira/browse/IGNITE-2732
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
> Fix For: 1.6
>
>
> To reproduce:
> 1) create cluster
> 2) import DEMO model
> 3) download the project
> 4) open in Idea
> 5) run ServerNodeCodeStartup
> 6) run ServerNodeSpringStartup
> {code}
> class org.apache.ignite.IgniteCheckedException: Store factory mismatch (fix 
> store factory in cache configuration or set 
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property) 
> [cacheName=DepartmentCache, 
> localStoreFactory=config.ServerConfigurationFactory$3, 
> remoteStoreFactory=org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory,
>  rmtNodeId=61deca2a-8624-4785-8660-d7fc039a619b]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.checkAttributeMismatch(GridCacheUtils.java:1218)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.checkCache(GridCacheProcessor.java:2701)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:732)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:909)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1688)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1547)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1003)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:534)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:515)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   at startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:19)
> {code}



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

[jira] [Commented] (IGNITE-1419) .Net: Add optional "raw" flag to binary type configuration.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1419:


Fine, I've made it writeable with usage check.

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



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

[jira] [Commented] (IGNITE-1232) Support distributed SQL JOIN

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-1232:
--

Looked at failures, there are following issues:

- when run query on replicated cache from server node then query is always 
executed locally (see IgniteCacheProxy.query). Tried to do a simple fix to do 
not use local execution if distributed join flag is set, but got assert in 
GridReduceQueryExecutor, need more knowledge about query execution to properly 
fix it.

- when join replicated and partitioned caches from client node get this error 
'Queries running on replicated cache should not contain JOINs with partitioned 
tables'
{noformat}
javax.cache.CacheException: Queries running on replicated cache should not 
contain JOINs with partitioned tables [rCache=REPLICATED_1, 
pCache=PARTITIONED_b0_1]
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:428)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:548)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:996)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:61)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:73)
at 
org.apache.ignite.internal.processors.cache.IgniteCrossCachesDistributedJoinQueryTest.checkOrganizationPersonsJoin(IgniteCrossCachesDistributedJoinQueryTest.java:417)
{noformat}

Do we really should prohibit such queries with distributed join?

- can get wrong result when run query using IgntieCache which does not 
participate in query (e.g. join person and accounts caches, but use 
organization cache to run query). Should we fix it or prohibit such queries?


> Support distributed SQL JOIN 
> -
>
> Key: IGNITE-1232
> URL: https://issues.apache.org/jira/browse/IGNITE-1232
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergi Vladykin
>Assignee: Sergi Vladykin
> Fix For: 1.6
>
>




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

[jira] [Commented] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-1903:
-

Hi Michael,

Actually I don't have a view presently on how this can be fixed. I need to dig 
into the code.

I would recommend you trying to form a view on how this can be implemented and 
sent an email to the dev list asking for ideas from the rest of the community.

Does this work for you?

> CacheStore implementation is serialised to grid clients whether they require 
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 1.6
>
>
> See User discussion thread:  
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary:  When a grid client joins the grid (clientMode=true) it 
> receives a message from the server node(s) on the grid that contains the 
> serialized CacheStore implementation object.  If the client does not have 
> this class on its CLASSPATH (and there is no reason it should, as it is a 
> client) then the de-serialization of this message will fail, causing this 
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1 
> class org.apache.ignite.IgniteCheckedException: Failed to find class with 
> given class loader for unmarshalling (make sure same versions of all classes 
> are available on all nodes or enable peer-class-loading): 
> sun.misc.Launcher$AppClassLoader@14dad5dc 
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>  
> at 
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> Caused by: java.lang.ClassNotFoundException: 
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore 
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of 
> a TRANSACTIONAL cache can begin the transaction on the underlying store.  
> The only current solution to this is to add the grid node's CacheStore 
> implementation class definition to the CLASSPATH of the client.  This creates 
> an *undesirable coupling* between server and client.



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