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

[Pavel Tupitsyn (JIRA)]

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

Pavel  Tupitsyn reassigned IGNITE-1626:
---

Assignee: Pavel  Tupitsyn

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



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

[jira] [Closed] (IGNITE-1716) SQL page: rework Query UI - show Meatada types on top level

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> SQL page: rework Query UI - show Meatada types on top level
> ---
>
> Key: IGNITE-1716
> URL: https://issues.apache.org/jira/browse/IGNITE-1716
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
>
> Currently the top level is a cache-level.
> Will be much useful if metadata will be on top-level, because metadata is 
> more interesting for creating the query.



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

[jira] [Updated] (IGNITE-1865) Need to add tests on SpringResource annotation

[Roman Shtykh (JIRA)]

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

Roman Shtykh updated IGNITE-1865:
-
Assignee: (was: Roman Shtykh)

> Need to add tests on SpringResource annotation
> --
>
> Key: IGNITE-1865
> URL: https://issues.apache.org/jira/browse/IGNITE-1865
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>  Labels: newbie
>
> Ignite has SpringResource annotation, but there's no unit-tests for it.
> Need to add unit-tests.



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

[jira] [Closed] (IGNITE-1857) We should generate download.zip directly in browser

[Pavel Konstantinov (JIRA)]

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

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

> We should generate download.zip directly in browser
> ---
>
> Key: IGNITE-1857
> URL: https://issues.apache.org/jira/browse/IGNITE-1857
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
> Fix For: 1.5
>
>
> We have bunch of generate-xxx.js files that used to generate XML and Java 
> code in browser (for preview) and in server to generate "download.zip" on 
> Summary page.
> We could generate "download.zip" directly in browser with help of "zip.js" 
> library and move generate-xxx.js to frontend only.



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

[jira] [Commented] (IGNITE-1857) We should generate download.zip directly in browser

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-1857:


Tested.

> We should generate download.zip directly in browser
> ---
>
> Key: IGNITE-1857
> URL: https://issues.apache.org/jira/browse/IGNITE-1857
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.5
>Reporter: Alexey Kuznetsov
> Fix For: 1.5
>
>
> We have bunch of generate-xxx.js files that used to generate XML and Java 
> code in browser (for preview) and in server to generate "download.zip" on 
> Summary page.
> We could generate "download.zip" directly in browser with help of "zip.js" 
> library and move generate-xxx.js to frontend only.



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

[jira] [Closed] (IGNITE-1841) Need add ConnectorConfiguration to cluster configuration

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> Need add ConnectorConfiguration to cluster configuration
> 
>
> Key: IGNITE-1841
> URL: https://issues.apache.org/jira/browse/IGNITE-1841
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Andrey Novikov
> Fix For: 1.5
>
>




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

[jira] [Resolved] (IGNITE-1887) REST-HTTP change queryId generation from sequence to random.

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1887.

Resolution: Fixed
  Assignee: Semen Boikov  (was: Andrey Novikov)

Implemented. Semen, please review.

> REST-HTTP change queryId generation from sequence to random.
> 
>
> Key: IGNITE-1887
> URL: https://issues.apache.org/jira/browse/IGNITE-1887
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Novikov
>Assignee: Semen Boikov
>Priority: Minor
> Fix For: 1.5
>
>
> First problem:
>  1. client1 execute query and get queryId = 1.
>  2. node where query was executed is restarted (queryId generator
> initialized to zero).
>  3. client2 execute some query and also get queryId=1.
>  4. client1 fetch next page for queryId=1 and GETS results of client2.
> Second problem:
>  As queryId is generated sequentially it is very easy to brute force and
> some client could get data of other clients too easy.



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

[jira] [Created] (IGNITE-1894) .Net: Delegate support in the API via extension methods

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1894:
---

 Summary: .Net: Delegate support in the API via extension methods
 Key: IGNITE-1894
 URL: https://issues.apache.org/jira/browse/IGNITE-1894
 Project: Ignite
  Issue Type: Improvement
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
 Fix For: 1.6


In many places we require a single-method interface implementation from the 
user:
{code:title=ICompute}
TRes Call(IComputeFunc clo);
{code}

All of these can be extended to accept a delegate:
{code:title=ICompute}
TRes Call(Func clo);
{code}

We can't replace interfaces with delegates completely (which is desirable), 
because it will take away serialization control from the user. So the interface 
approach has to stay as a primary.
Delegate support can be added via extension methods, which wrap provided 
delegates into a class that implements corresponding interface.



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

[jira] [Closed] (IGNITE-1859) Insufficient width for POJO dropdown on Summary page

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> Insufficient width for POJO  dropdown on Summary page
> -
>
> Key: IGNITE-1859
> URL: https://issues.apache.org/jira/browse/IGNITE-1859
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
> Attachments: ig-1859.png
>
>
> Please see screen shot



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

[jira] [Commented] (IGNITE-529) Implement IgniteFlumeStreamer to stream data from Apache Flume

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-529:
-

Anton,

If IgniteDataStreamer can bring more speed, I will use it rather than using 
cache.putAll() then. Flume handles large loads of data.

Having something like this in EventTransformer interface
{code}
@Nullable List> transform(Event event);
{code}
instead of
{code}
@Nullable Map transform(Event event);
{code}
might reduce memory overhead but slow down transformation a bit. But in the 
next PR I will add batching, as it is done in other sink implementations, which 
will speed up processing in overall.

As far as I know, having a channel and feeding events should be sufficient to 
test the sink. Normally, before submitting code I check it with a simple full 
deployment I describe in README.


> Implement IgniteFlumeStreamer to stream data from Apache Flume
> --
>
> Key: IGNITE-529
> URL: https://issues.apache.org/jira/browse/IGNITE-529
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Apache Flume|http://flume.apache.org/] for more information.
> We should create {{IgniteFlumeStreamer}} which will consume messages from 
> Apache Flume and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> * Convert Flume data to Ignite data using an optional pluggable converter.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Updated] (IGNITE-1892) Incorrect focus on table fields

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko updated IGNITE-1892:
--
Description: 
Open metadata configuration dialog.
Configure query fields or aliases or indexes and add more than one row.
On edit second row focus on first field is lost.
Error popover showed in incorrect place. 
On enter should be focused next editor or row should be saved

  was:
Open metadata configuration dialog.
Configure query fields or aliases or indexes and add more than one row.
On edit second row focus on first field is lost.
Error popover showed in incorrect place. 


> Incorrect focus on table fields
> ---
>
> Key: IGNITE-1892
> URL: https://issues.apache.org/jira/browse/IGNITE-1892
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 1.5
>
>
> Open metadata configuration dialog.
> Configure query fields or aliases or indexes and add more than one row.
> On edit second row focus on first field is lost.
> Error popover showed in incorrect place. 
> On enter should be focused next editor or row should be saved



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

[jira] [Created] (IGNITE-1898) Make it possible to obtain the local Ignite instance statically

[Andrey Kornev (JIRA)]

Andrey Kornev created IGNITE-1898:
-

 Summary: Make it possible to obtain the local Ignite instance 
statically
 Key: IGNITE-1898
 URL: https://issues.apache.org/jira/browse/IGNITE-1898
 Project: Ignite
  Issue Type: Improvement
  Components: general
Reporter: Andrey Kornev
Priority: Minor


Currently the ways to obtain the local instance of Ignite make use of the grid 
name or the node UUID with the corresponding {{Ignition.ignite()}} methods. 
However, during deserialization if would sometime be desirable to be able to 
obtain the local instance of Ignite (the one on which the given class is being 
deserialized) without relying on the grid name. Such instance can then be used 
to look up the node-local resources and any other context. The grid name is not 
reliable way to serialize/deserialize {{IgniteKernal}} in a situation when a 
single JVM has multiple Ignite nodes started (as is often the case in unit 
tests).

The proposed solution is to
# implement a custom ThreadFactory to be used with the public, system, utility 
and so on thread pools. For all newly created thread, the factory will create a 
thread local and initialize it with the current instance of Ignite.
# modify the classes that create their own threads, to do the same.
# provide a public static method on the Ignition class
{{public static Ignite getLocalNode();}}
that returns the value of the thread local. It throws {{IllegalStateException}} 
if the method is invoked from a non-Ignite thread.

This will guarantee that all threads started by a particular Ignite instance 
will have the instance reference available in their thread locals.




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

[jira] [Created] (IGNITE-1899) Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite nodes started in the same JVM

[Andrey Kornev (JIRA)]

Andrey Kornev created IGNITE-1899:
-

 Summary: Incorrect Ignite (IgniteKernal) instance deserialized 
when multiple Ignite nodes started in the same JVM
 Key: IGNITE-1899
 URL: https://issues.apache.org/jira/browse/IGNITE-1899
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Andrey Kornev


The current approach to serialization/deserialization of {{IgniteKernal}} is 
flawed as it relies on the grid name. However, in a situation when a single JVM 
instance has multiple Ignite instances started (as is often the case in unit 
tests) this approach doesn't work. Ignite requires that each Ignite instance 
started within the same JVM be assigned different names. Thus, during 
deserialization on another node a wrong instance of {{IgniteKernal}} gets 
looked up.

Say, the JVM instance has 2 nodes started: node A and node B. Then, when the 
node A serializes {{IgniteKernal}} it'll write the grid name "A" to the wire. 
Then, during deserialization of the {{IgniteKernal}} instance on the node B, 
the name "A" will be read from the wire and used to look up the Ignite instance 
uisng {{Ignition.ignite("A");}}. Clearly the class (holding a reference to 
{{IgniteKernal}}) ends up with a wrong instance of Ignite. If the class also 
retrieves the node-local resources by doing 
{{Ignition.ignite(deserializedGridName).cluster().nodeLocalMap()}} then it may 
end up with incorrect data.

As of Ignite 1.4, {{ClusterGroupAdapter}} class or any other class that 
serialize the instance of {{IgniteKernal}} suffer from this issue. The fix 
would be to simply stop serializing the grid name altogether and during 
deserialization rely on the thread local instead, as per IGNITE-1898.



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

[jira] [Updated] (IGNITE-1891) SSL on Windows for different major version of JDK

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-1891:
--
Description: 
1. Copy examples/config/example-ignite.xml in 
examples/config/example-ignite-ssl.xml
2. Put SSL section:
{code:title=example-ignite-ssl.xml|borderStyle=solid}


http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xmlns:util="http://www.springframework.org/schema/util;
   xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd;>























































127.0.0.1:47500..47509








{code}
3. Start two nodes with the config above. But 1st is under JDK1.7 and 2nd is 
under JDK 1.8
Second node failed:
{noformat}
21:43:59,345][SEVERE][exchange-worker-#48%null%][GridDhtPartitionsExchangeFuture]
 Failed to send local partitions to oldest node (will retry after timeout) 
[oldestNodeId=37a2346c-3a07-4a96-a6da-c375cba47b41, 
exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=0], nodeId=de92d445, evt=NODE_JOINED]]
class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=37a2346c-3a07-4a96-a6da-c375cba47b41, 
addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 192.168.100.9, 
2001:0:9d38:6ab8:2099:222b:4db9:9941], 
sockAddrs=[ksm-homepc/192.168.100.9:47500, 
0:0:0:0:0:0:0:1/0:0:0:0:0:0:0:1:47500, ksm-homepc/192.168.100.9:47500, 
/127.0.0.1:47500, /192.168.100.9:47500, 
/2001:0:9d38:6ab8:2099:222b:4db9:9941:47500], discPort=47500, order=1, 
intOrder=1, lastExchangeTime=1447267436638, loc=false, 
ver=1.5.0#2015-sha1:388a8921, isClient=false], topic=TOPIC_CACHE, 
msg=GridDhtPartitionsSingleMessage [parts={-2100569601=GridDhtPartitionMap 
[nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=100, 
size=100], 689859866=GridDhtPartitionMap 
[nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=511, 
size=511], 1325947219=GridDhtPartitionMap 
[nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=20, 
size=20]}, client=false, super=GridDhtPartitionsAbstractMessage 
[exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=0], nodeId=de92d445, evt=NODE_JOINED], lastVer=GridCacheVersion 
[topVer=0, nodeOrderDrId=0, globalTime=0, order=1447267431316], 
super=GridCacheMessage [msgId=1, depInfo=null, err=null, skipPrepare=false]]], 
policy=2]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1071)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:612)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:972)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendPartitions(GridDhtPartitionsExchangeFuture.java:1013)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:879)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1230)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=37a2346c-3a07-4a96-a6da-c375cba47b41, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
192.168.100.9, 

[jira] [Updated] (IGNITE-1891) SSL on Windows for different major version of JDK

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-1891:
--
Summary: SSL on Windows for different major version of JDK  (was: SSL on 
Windows)

> SSL on Windows for different major version of JDK
> -
>
> Key: IGNITE-1891
> URL: https://issues.apache.org/jira/browse/IGNITE-1891
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4, 1.5
> Environment: Windows 8, Windows 10,
> Oracle JDK 1.7.0_80 64bit
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
>Priority: Critical
> Fix For: 1.5
>
>
> 1. Copy examples/config/example-ignite.xml in 
> examples/config/example-ignite-ssl.xml
> 2. Put SSL section:
> {code:title=example-ignite-ssl.xml|borderStyle=solid}
> 
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xmlns:util="http://www.springframework.org/schema/util;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd;>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
> 
> 
>  class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller">
> 
> 
> 
> 
> 
> 
> 
> 
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_STARTED"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_FINISHED"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_FAILED"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_TIMEDOUT"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_SESSION_ATTR_SET"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_REDUCED"/>
> 
>  static-field="org.apache.ignite.events.EventType.EVT_CACHE_OBJECT_PUT"/>
>  static-field="org.apache.ignite.events.EventType.EVT_CACHE_OBJECT_READ"/>
>  static-field="org.apache.ignite.events.EventType.EVT_CACHE_OBJECT_REMOVED"/>
> 
> 
> 
> 
>  value="D:\apache-ignite-fabric-1.5.0-bin\examples\config\server.jks"/>
> 
> 
>  factory-method="getDisabledTrustManager"/>
> 
> 
> 
> 
>  class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
> 
> 
> 
> 127.0.0.1:47500..47509
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> 3. Start two nodes with the config above. Second node failed:
> {noformat}
> 21:43:59,345][SEVERE][exchange-worker-#48%null%][GridDhtPartitionsExchangeFuture]
>  Failed to send local partitions to oldest node (will retry after timeout) 
> [oldestNodeId=37a2346c-3a07-4a96-a6da-c375cba47b41, 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
> minorTopVer=0], nodeId=de92d445, evt=NODE_JOINED]]
> class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
> may have left the grid or TCP connection cannot be established due to 
> firewall issues) [node=TcpDiscoveryNode 
> [id=37a2346c-3a07-4a96-a6da-c375cba47b41, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 192.168.100.9, 2001:0:9d38:6ab8:2099:222b:4db9:9941], 
> sockAddrs=[ksm-homepc/192.168.100.9:47500, 
> 0:0:0:0:0:0:0:1/0:0:0:0:0:0:0:1:47500, ksm-homepc/192.168.100.9:47500, 
> /127.0.0.1:47500, /192.168.100.9:47500, 
> /2001:0:9d38:6ab8:2099:222b:4db9:9941:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1447267436638, loc=false, 
> ver=1.5.0#2015-sha1:388a8921, isClient=false], topic=TOPIC_CACHE, 
> msg=GridDhtPartitionsSingleMessage [parts={-2100569601=GridDhtPartitionMap 
> [nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=100, 
> size=100], 689859866=GridDhtPartitionMap 
> [nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=511, 
> size=511], 1325947219=GridDhtPartitionMap 
> 

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

[Pavel Tupitsyn (JIRA)]

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

Pavel  Tupitsyn commented on IGNITE-1626:
-

TODO:
* Create nuspec file which includes all required files (dll, default config, 
jars)
* Investigate nuget on linux
* x86/x64?

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



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel  Tupitsyn commented on IGNITE-1626:
-

x86/x64: Standard way is to have two different packages.
https://github.com/taliesins/neosis/pull/1

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



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel  Tupitsyn edited comment on IGNITE-1626 at 11/12/15 12:53 PM:


TODO:
* Create nuspec file which includes all required files (dll, default config, 
jars)
* Create TC build that packs and publishes new nuget package
* x86/x64?


was (Author: ptupitsyn):
TODO:
* Create nuspec file which includes all required files (dll, default config, 
jars)
* Investigate nuget on linux
* x86/x64?

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



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

[jira] [Resolved] (IGNITE-442) IgniteFs should correctly work in proxy mode

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky resolved IGNITE-442.

Resolution: Cannot Reproduce

At present time nobody can recall, what the problem is. Closing.

> IgniteFs should correctly work in proxy mode
> 
>
> Key: IGNITE-442
> URL: https://issues.apache.org/jira/browse/IGNITE-442
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: sprint-1
>Reporter: Alexey Kuznetsov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 1.5
>
>




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

[jira] [Closed] (IGNITE-442) IgniteFs should correctly work in proxy mode

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky closed IGNITE-442.
--

> IgniteFs should correctly work in proxy mode
> 
>
> Key: IGNITE-442
> URL: https://issues.apache.org/jira/browse/IGNITE-442
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: sprint-1
>Reporter: Alexey Kuznetsov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 1.5
>
>




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

[jira] [Updated] (IGNITE-1891) SSL on Windows for different major version of JDK

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-1891:
--
Priority: Minor  (was: Critical)

> SSL on Windows for different major version of JDK
> -
>
> Key: IGNITE-1891
> URL: https://issues.apache.org/jira/browse/IGNITE-1891
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4, 1.5
> Environment: Windows 8, Windows 10,
> Oracle JDK 1.7.0_80 64bit
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
>Priority: Minor
> Fix For: 1.5
>
>
> 1. Copy examples/config/example-ignite.xml in 
> examples/config/example-ignite-ssl.xml
> 2. Put SSL section:
> {code:title=example-ignite-ssl.xml|borderStyle=solid}
> 
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xmlns:util="http://www.springframework.org/schema/util;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/util
> http://www.springframework.org/schema/util/spring-util.xsd;>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
> 
> 
> 
>  class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller">
> 
> 
> 
> 
> 
> 
> 
> 
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_STARTED"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_FINISHED"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_FAILED"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_TIMEDOUT"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_SESSION_ATTR_SET"/>
>  static-field="org.apache.ignite.events.EventType.EVT_TASK_REDUCED"/>
> 
>  static-field="org.apache.ignite.events.EventType.EVT_CACHE_OBJECT_PUT"/>
>  static-field="org.apache.ignite.events.EventType.EVT_CACHE_OBJECT_READ"/>
>  static-field="org.apache.ignite.events.EventType.EVT_CACHE_OBJECT_REMOVED"/>
> 
> 
> 
> 
>  value="D:\apache-ignite-fabric-1.5.0-bin\examples\config\server.jks"/>
> 
> 
>  factory-method="getDisabledTrustManager"/>
> 
> 
> 
> 
>  class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  class="org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder">
> 
> 
> 
> 127.0.0.1:47500..47509
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> 3. Start two nodes with the config above. But 1st is under JDK1.7 and 2nd is 
> under JDK 1.8
> Second node failed:
> {noformat}
> 21:43:59,345][SEVERE][exchange-worker-#48%null%][GridDhtPartitionsExchangeFuture]
>  Failed to send local partitions to oldest node (will retry after timeout) 
> [oldestNodeId=37a2346c-3a07-4a96-a6da-c375cba47b41, 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
> minorTopVer=0], nodeId=de92d445, evt=NODE_JOINED]]
> class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
> may have left the grid or TCP connection cannot be established due to 
> firewall issues) [node=TcpDiscoveryNode 
> [id=37a2346c-3a07-4a96-a6da-c375cba47b41, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 192.168.100.9, 2001:0:9d38:6ab8:2099:222b:4db9:9941], 
> sockAddrs=[ksm-homepc/192.168.100.9:47500, 
> 0:0:0:0:0:0:0:1/0:0:0:0:0:0:0:1:47500, ksm-homepc/192.168.100.9:47500, 
> /127.0.0.1:47500, /192.168.100.9:47500, 
> /2001:0:9d38:6ab8:2099:222b:4db9:9941:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1447267436638, loc=false, 
> ver=1.5.0#2015-sha1:388a8921, isClient=false], topic=TOPIC_CACHE, 
> msg=GridDhtPartitionsSingleMessage [parts={-2100569601=GridDhtPartitionMap 
> [nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=100, 
> size=100], 689859866=GridDhtPartitionMap 
> [nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=511, 
> size=511], 1325947219=GridDhtPartitionMap 

[jira] [Updated] (IGNITE-1891) SSL on Windows for different major version of JDK

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-1891:
--
Description: 
1. Copy examples/config/example-ignite.xml in 
examples/config/example-ignite-ssl.xml
2. Put SSL section:
{code:title=example-ignite-ssl.xml|borderStyle=solid}


http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xmlns:util="http://www.springframework.org/schema/util;
   xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd;>























































127.0.0.1:47500..47509








{code}
3. Start two nodes with the config above. But 1st is under JDK1.7 and 2nd is 
under JDK 1.8
Second node failed:
{noformat}
21:43:59,345][SEVERE][exchange-worker-#48%null%][GridDhtPartitionsExchangeFuture]
 Failed to send local partitions to oldest node (will retry after timeout) 
[oldestNodeId=37a2346c-3a07-4a96-a6da-c375cba47b41, 
exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=0], nodeId=de92d445, evt=NODE_JOINED]]
class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=37a2346c-3a07-4a96-a6da-c375cba47b41, 
addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 192.168.100.9, 
2001:0:9d38:6ab8:2099:222b:4db9:9941], 
sockAddrs=[ksm-homepc/192.168.100.9:47500, 
0:0:0:0:0:0:0:1/0:0:0:0:0:0:0:1:47500, ksm-homepc/192.168.100.9:47500, 
/127.0.0.1:47500, /192.168.100.9:47500, 
/2001:0:9d38:6ab8:2099:222b:4db9:9941:47500], discPort=47500, order=1, 
intOrder=1, lastExchangeTime=1447267436638, loc=false, 
ver=1.5.0#2015-sha1:388a8921, isClient=false], topic=TOPIC_CACHE, 
msg=GridDhtPartitionsSingleMessage [parts={-2100569601=GridDhtPartitionMap 
[nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=100, 
size=100], 689859866=GridDhtPartitionMap 
[nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=511, 
size=511], 1325947219=GridDhtPartitionMap 
[nodeId=de92d445-9162-43b1-ae84-fb8601a5e35c, updateSeq=2, moving=20, 
size=20]}, client=false, super=GridDhtPartitionsAbstractMessage 
[exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=0], nodeId=de92d445, evt=NODE_JOINED], lastVer=GridCacheVersion 
[topVer=0, nodeOrderDrId=0, globalTime=0, order=1447267431316], 
super=GridCacheMessage [msgId=1, depInfo=null, err=null, skipPrepare=false]]], 
policy=2]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1071)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:612)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendLocalPartitions(GridDhtPartitionsExchangeFuture.java:972)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendPartitions(GridDhtPartitionsExchangeFuture.java:1013)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:879)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1230)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=37a2346c-3a07-4a96-a6da-c375cba47b41, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
192.168.100.9, 

[jira] [Assigned] (IGNITE-1355) Potential NPE in CacheAffinityProxy

[Semen Boikov (JIRA)]

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

Semen Boikov reassigned IGNITE-1355:


Assignee: Artem Shutak  (was: Semen Boikov)

> Potential NPE in CacheAffinityProxy
> ---
>
> Key: IGNITE-1355
> URL: https://issues.apache.org/jira/browse/IGNITE-1355
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Artem Shutak
>Priority: Critical
> Fix For: 1.5
>
>
> NPE was observed on TC:
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor$AffinityInfo.access$1800(GridAffinityProcessor.java:537)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor$CacheAffinityProxy.mapPartitionToPrimaryAndBackups(GridAffinityProcessor.java:879)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:423)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCacheCrossCacheTxFailoverTest.crossCacheTxFailover(IgniteCacheCrossCacheTxFailoverTest.java:355)
> {noformat}
> As I see method CacheAffinityProxy.cache() can return null, but there are no 
> checks for null.



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

[jira] [Updated] (IGNITE-1900) Ignite JMX problem with Spring Boot

[wmz7year (JIRA)]

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

wmz7year updated IGNITE-1900:
-
Description: 
I use Ignite with Spring Boot.
When start application,Spring Boot will register JMX info.

In IgniteMXBean interface,There is two method getUserAttributesFormatted and 
getLifecycleBeansFormatted return Collection
But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method will 
get method return type.

 final Type rawType = objType.getRawType();
if (rawType instanceof Class) {
Class c = (Class) rawType;
if (c == List.class || c == Set.class || c == SortedSet.class) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 1);
if (c == SortedSet.class)
mustBeComparable(c, actuals[0]);
return makeArrayOrCollectionMapping(objType, actuals[0], 
factory);
} else {
boolean sortedMap = (c == SortedMap.class);
if (c == Map.class || sortedMap) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 2);
if (sortedMap)
mustBeComparable(c, actuals[0]);
return makeTabularMapping(objType, sortedMap,
actuals[0], actuals[1], factory);
}
}
}

The Collection will not match any type for this although IgniteKernal 
return type is Set or List.


I think IgniteMXBean interface should change Collection to Set and List

  was:
I use Ignite with Spring Boot.
When start application,Spring Boot will register JMX info.

In IgniteMXBean interface,There is two method getUserAttributesFormatted and 
getLifecycleBeansFormatted return Collection
But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method will 
get method return type.

 final Type rawType = objType.getRawType();
if (rawType instanceof Class) {
Class c = (Class) rawType;
if (c == List.class || c == Set.class || c == SortedSet.class) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 1);
if (c == SortedSet.class)
mustBeComparable(c, actuals[0]);
return makeArrayOrCollectionMapping(objType, actuals[0], 
factory);
} else {
boolean sortedMap = (c == SortedMap.class);
if (c == Map.class || sortedMap) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 2);
if (sortedMap)
mustBeComparable(c, actuals[0]);
return makeTabularMapping(objType, sortedMap,
actuals[0], actuals[1], factory);
}
}
}

The Collection will not match any type for this although IgniteKernal 
return type is Set.


I think IgniteMXBean interface should change Collection to Set and List


> Ignite JMX problem with Spring Boot
> ---
>
> Key: IGNITE-1900
> URL: https://issues.apache.org/jira/browse/IGNITE-1900
> Project: Ignite
>  Issue Type: Bug
>  Components: 1.4
>Affects Versions: ignite-1.4
>Reporter: wmz7year
>
> I use Ignite with Spring Boot.
> When start application,Spring Boot will register JMX info.
> In IgniteMXBean interface,There is two method getUserAttributesFormatted and 
> getLifecycleBeansFormatted return Collection
> But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method 
> will get method return type.
>  final Type rawType = objType.getRawType();
> if (rawType instanceof Class) {
> Class c = (Class) rawType;
> if (c == List.class || c == Set.class || c == SortedSet.class) {
> Type[] actuals = objType.getActualTypeArguments();
> assert(actuals.length == 1);
> if (c == SortedSet.class)
> mustBeComparable(c, actuals[0]);
> return makeArrayOrCollectionMapping(objType, actuals[0], 
> factory);
> } else {
> boolean sortedMap = (c == SortedMap.class);
> if (c == Map.class || sortedMap) {
> Type[] actuals = objType.getActualTypeArguments();
> assert(actuals.length == 2);
> if (sortedMap)
> mustBeComparable(c, actuals[0]);
> return makeTabularMapping(objType, sortedMap,
> actuals[0], actuals[1], factory);
> }
> }
> }
> The Collection will not match any type for this although IgniteKernal 
> 

[jira] [Updated] (IGNITE-1895) Entries aren't evicted for LRU policy

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-1895:
--
Attachment: example-ignite-lru-client.xml
example-ignite-lru.xml

> Entries aren't evicted for LRU policy
> -
>
> Key: IGNITE-1895
> URL: https://issues.apache.org/jira/browse/IGNITE-1895
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5
>Reporter: Sergey Kozlov
>Assignee: Yakov Zhdanov
> Fix For: 1.5
>
> Attachments: example-ignite-lru-client.xml, example-ignite-lru.xml
>
>
> 1. :
> {code:title=CacheLruExample.java|borderStyle=solid}
> package org.apache.ignite.examples.datagrid;
> import java.util.HashMap;
> import java.util.Map;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteException;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.examples.ExampleNodeStartup;
> public class CachePutGetExample {
> /** Cache name. */
> private static final String CACHE_NAME = "cache_0001";
> public static void main(String[] args) throws IgniteException, 
> InterruptedException {
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite-lru-client.xml")) {
> try (IgniteCache cache = 
> ignite.getOrCreateCache(CACHE_NAME)) {
> System.out.println();
> System.out.println(">>> Test started.");
> int counter = 0;
> for (int i = 1; i <= 100; i++) {
> if (cache.get(i) != null)
> counter++;
> }
> System.out.println(">>> Get: found not-null keys " + 
> Integer.toString(counter));
> Thread.sleep(1000);
> for (int i = 1; i <= 100; i++) {
> cache.remove(i);
> }
> System.out.println(">>> Remove: 1..100");
> Thread.sleep(1000);
> counter = 0;
> for (int i = 1; i <= 100; i++) {
> cache.put(i, Integer.toString(i));
> counter++;
> }
> System.out.println(">>> Put: 1..100");
> Thread.sleep(1000);
> counter = 0;
> for (int i = 50; i <= 100; i++) {
> if (cache.get(i) != null)
> counter++;
> }
> System.out.println(">>> Get 50..100");
> Thread.sleep(1000);
> for (int i = 30; i <= 49; i++) {
> cache.put(i, Integer.toString(i));
> }
> System.out.println(">>> Put: 30..49");
> Thread.sleep(1000);
> counter = 0;
> for (int i = 1; i <= 100; i++) {
> if (cache.get(i) != null)
> counter++;
> }
> System.out.println(">>> Get: found not-null keys (must be 
> 50): " + Integer.toString(counter));
> }
> }
> }
> }
> {code}
> 2. Copy attached configurations in examples/config directory
> 3. Start two nodes with example-ignite-lru.xml
> 3. Compile and run example
> 4. The output of example shows that cache has more entries than defined by 
> max size in eviction policy:
> {noformat}
> ...
> [16:34:47,088][INFO ][main][GridDiscoveryManager] Topology snapshot [ver=3, 
> servers=2, clients=1, CPUs=8, heap=3.8GB]
> >>> Test started.
> >>> Get: found not-null keys 0
> >>> Remove: 1..100
> >>> Put: 1..100
> >>> Get 50..100
> >>> Put: 30..49
> >>> Get: found not-null keys (must be 50): 70
> ...
> {noformat}



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

[jira] [Commented] (IGNITE-183) Delete busyLock from IgfsMetaManager

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-183:


The problem is that the busyLock exists both in IgfsImpl and IgfsMetamanager, 
so in many cases bothe the busy locks are acquired, what is redundant.
The suggestion is to consider possibility to have only one busy lock, and have 
it locked only once.  

> Delete busyLock from IgfsMetaManager
> 
>
> Key: IGNITE-183
> URL: https://issues.apache.org/jira/browse/IGNITE-183
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: sprint-1
>Reporter: Alexey Kuznetsov
>Assignee: Ivan Veselovsky
> Fix For: 1.6
>
>
> It seems that busy lock is not needed and owner busy lock could be used when 
> needed.
> Ask Yakov or Alex G. for details if needed.



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

[jira] [Commented] (IGNITE-529) Implement IgniteFlumeStreamer to stream data from Apache Flume

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-529:
-

Roman,

In "Prepare than put" case DataStreamer should not give more speed.
But can give in "Put while preparing" can. 

My Idea was to do somethilg like this:

public boolean transform(Event event, IgniteDataStreamer 
dataStreamer){
try{
   for (Something s: Event){
  List datas = s.extract();

  for (Tuple data: datas)
 dataStreamer.addData(data.get1(), data.get2());   
   }

   dataStreamer.flush();
}catch(Exception e){
return false
}

return true;
}

This case can give more speed, but I think that usage of putAll is good enough 
for initial implementation.


> Implement IgniteFlumeStreamer to stream data from Apache Flume
> --
>
> Key: IGNITE-529
> URL: https://issues.apache.org/jira/browse/IGNITE-529
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Apache Flume|http://flume.apache.org/] for more information.
> We should create {{IgniteFlumeStreamer}} which will consume messages from 
> Apache Flume and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> * Convert Flume data to Ignite data using an optional pluggable converter.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Commented] (IGNITE-1637) IGFS: Consistent properties propagation.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-1637:
-

First of all, HDFS does not have notion of "file properties" -- it has file 
permission and a set of named attributes, such as modification time or 
replication factor.
With regards to created files permissions, HDFS behavior is different for file 
and directory creation.

If a file is created, the created directories get 
org.apache.hadoop.fs.permission.FsPermission#getDirDefault (0777) permission. 
Umask *is* applied to the created file, but is *not* applied to the created 
directories.

If a directory is created, all the parent directories are created with the same 
permission that is requested for the directory itself. The only exception is 
that "wx" (write and execute) permissions are explicitly added for the owner on 
the parent directories to be able to write child directories. Umask *is* 
applied to all the created directories. 
If umask conflicts with the added permissions , the added permissions take 
priority.


> IGFS: Consistent properties propagation.
> 
>
> Key: IGNITE-1637
> URL: https://issues.apache.org/jira/browse/IGNITE-1637
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
> Fix For: 1.5
>
>
> IGFS has methods accepting properties map. E.g., create, append, mkdirs. 
> How we should apply these properties? Two strategies are possible:
> 1) Apply there properties only to leaf node, and set defaults to parent nodes.
> 2) Apply there properties to all created nodes.
> Lets take HDFS as a reference for this. 



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

[jira] [Commented] (IGNITE-529) Implement IgniteFlumeStreamer to stream data from Apache Flume

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-529:
-

Anton,

I got it -- this is the optimization for a case when a Flume event is large and 
potentially contains data that can contain many keys. Thank you for sharing 
this idea!
But, yes, probably it is just a special case. Let's focus on putAll for now.


> Implement IgniteFlumeStreamer to stream data from Apache Flume
> --
>
> Key: IGNITE-529
> URL: https://issues.apache.org/jira/browse/IGNITE-529
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under 
> high load. It was previously named {{IgniteDataLoader}}, see ticket 
> IGNITE-394.
> See [Apache Flume|http://flume.apache.org/] for more information.
> We should create {{IgniteFlumeStreamer}} which will consume messages from 
> Apache Flume and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> * Convert Flume data to Ignite data using an optional pluggable converter.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.



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

[jira] [Commented] (IGNITE-1637) IGFS: Consistent properties propagation.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-1637:
-

Request IGNITE-1850 suggests to always use defaults for implicitly created 
directories in IGFS.

> IGFS: Consistent properties propagation.
> 
>
> Key: IGNITE-1637
> URL: https://issues.apache.org/jira/browse/IGNITE-1637
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
> Fix For: 1.5
>
>
> IGFS has methods accepting properties map. E.g., create, append, mkdirs. 
> How we should apply these properties? Two strategies are possible:
> 1) Apply there properties only to leaf node, and set defaults to parent nodes.
> 2) Apply there properties to all created nodes.
> Lets take HDFS as a reference for this. 



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

[jira] [Created] (IGNITE-1895) Entries aren't evicted for LRU policy

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1895:
-

 Summary: Entries aren't evicted for LRU policy
 Key: IGNITE-1895
 URL: https://issues.apache.org/jira/browse/IGNITE-1895
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
 Fix For: 1.5


1. :
{code:title=CacheLruExample.java|borderStyle=solid}
package org.apache.ignite.examples.datagrid;

import java.util.HashMap;
import java.util.Map;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.IgniteException;
import org.apache.ignite.Ignition;
import org.apache.ignite.examples.ExampleNodeStartup;

public class CachePutGetExample {
/** Cache name. */
private static final String CACHE_NAME = "cache_0001";

public static void main(String[] args) throws IgniteException, 
InterruptedException {
try (Ignite ignite = 
Ignition.start("examples/config/example-ignite-lru-client.xml")) {
try (IgniteCache cache = 
ignite.getOrCreateCache(CACHE_NAME)) {
System.out.println();
System.out.println(">>> Test started.");

int counter = 0;
for (int i = 1; i <= 100; i++) {
if (cache.get(i) != null)
counter++;
}
System.out.println(">>> Get: found not-null keys " + 
Integer.toString(counter));
Thread.sleep(1000);

for (int i = 1; i <= 100; i++) {
cache.remove(i);
}
System.out.println(">>> Remove: 1..100");
Thread.sleep(1000);


counter = 0;
for (int i = 1; i <= 100; i++) {
cache.put(i, Integer.toString(i));
counter++;
}
System.out.println(">>> Put: 1..100");
Thread.sleep(1000);


counter = 0;
for (int i = 50; i <= 100; i++) {
if (cache.get(i) != null)
counter++;
}
System.out.println(">>> Get 50..100");
Thread.sleep(1000);


for (int i = 30; i <= 49; i++) {
cache.put(i, Integer.toString(i));
}
System.out.println(">>> Put: 30..49");
Thread.sleep(1000);


counter = 0;
for (int i = 1; i <= 100; i++) {
if (cache.get(i) != null)
counter++;
}
System.out.println(">>> Get: found not-null keys (must be 50): 
" + Integer.toString(counter));
}
}
}

}
{code}

2. Copy attached configurations in examples/config directory
3. Start two nodes with example-ignite-lru.xml
3. Compile and run example
4. The output of example shows that cache has more entries than defined by max 
size in eviction policy:

{noformat}
...
[16:34:47,088][INFO ][main][GridDiscoveryManager] Topology snapshot [ver=3, 
servers=2, clients=1, CPUs=8, heap=3.8GB]

>>> Test started.
>>> Get: found not-null keys 0
>>> Remove: 1..100
>>> Put: 1..100
>>> Get 50..100
>>> Put: 30..49
>>> Get: found not-null keys (must be 50): 70
...
{noformat}



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

[jira] [Updated] (IGNITE-1758) Clients don't survive during massive servers shutdown

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-1758:
-
Fix Version/s: (was: 1.5)
   1.6

> Clients don't survive during massive servers shutdown
> -
>
> Key: IGNITE-1758
> URL: https://issues.apache.org/jira/browse/IGNITE-1758
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.6
>
> Attachments: ignite-1758-test.patch
>
>
> There is a real world use case.
> Start sensible amount of servers and clients.
> Perform cache operations under a transaction.
> Stop a half of the servers. Clients must survive and keep execution their 
> transactions.
> Did the following test:
> - Started 14 servers and 14 clients;
> - Clients execute transactional put operations;
> - Stopped 7 servers.
> Getting different assertions on clients side.
> {noformat}
> [15:47:33,401][ERROR][tcp-client-disco-msg-worker-#521%internal.IgniteClientReconnectCacheMultiThreadedTest18][TcpDiscoverySpi]
>  Runtime error caught during grid runnable execution: IgniteSpiThread 
> [name=tcp-client-disco-msg-worker-#521%internal.IgniteClientReconnectCacheMultiThreadedTest18]
> java.lang.AssertionError: lastVer=29, newVer=32, locNode=TcpDiscoveryNode 
> [id=80f14def-9d49-43a0-96bc-6b83aedb3008, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:0], discPort=0, order=26, intOrder=0, 
> lastExchangeTime=1445428036418, loc=true, ver=1.4.1#19700101-sha1:, 
> isClient=true], msg=TcpDiscoveryNodeFailedMessage 
> [failedNodeId=3020dc65-ed3e-426f-8784-5bb766961003, order=4, warning=null, 
> super=TcpDiscoveryAbstractMessage 
> [sndNodeId=10c5cfe9-df07-4dfe-a5c0-460087aa9001, 
> id=eed3e3a8051-008a978d-28cc-4f0c-8728-4a815f858000, 
> verifierNodeId=800cf998-828e-4f56-af6a-c2760c5ed008, topVer=32, pendingIdx=0, 
> isClient=false]]
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.updateTopologyHistory(ClientImpl.java:720)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$2700(ClientImpl.java:118)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeFailedMessage(ClientImpl.java:1812)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1543)
>   at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1467)
>   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> {noformat}
> java.lang.AssertionError: Missed message future [rcvCnt=141, acked=0, 
> desc=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0, 
> reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode 
> [id=6090f64b-e019-440b-9d0e-c3642bd3a006, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47503], discPort=47503, order=3, intOrder=3, 
> lastExchangeTime=1445428027468, loc=false, ver=1.4.1#19700101-sha1:, 
> isClient=false], connected=false, connectCnt=1, queueLimit=5120]]
>   at 
> org.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor.ackReceived(GridNioRecoveryDescriptor.java:181)
>   at 
> org.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor.onHandshake(GridNioRecoveryDescriptor.java:251)
>   at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2331)
>   at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2084)
>   at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:1978)
>   at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1914)
>   at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
>   at 
> org.apache.ignite.internal.processors.clock.GridClockSyncProcessor.publish(GridClockSyncProcessor.java:305)
>   at 
> org.apache.ignite.internal.processors.clock.GridClockSyncProcessor.access$800(GridClockSyncProcessor.java:54)
>   at 
> org.apache.ignite.internal.processors.clock.GridClockSyncProcessor$TimeCoordinator.body(GridClockSyncProcessor.java:382)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel  Tupitsyn updated IGNITE-1626:

Comment: was deleted

(was: TODO:
* Create nuspec file which includes all required files (dll, default config, 
jars)
* Create TC build that packs and publishes new nuget package
* x86/x64?)

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



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

[jira] [Closed] (IGNITE-1884) .Net: JNI local ref can't be accessed from another thread

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1884.
---

> .Net: JNI local ref can't be accessed from another thread
> -
>
> Key: IGNITE-1884
> URL: https://issues.apache.org/jira/browse/IGNITE-1884
> Project: Ignite
>  Issue Type: Bug
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel  Tupitsyn
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> Documentation: 
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html
> {code}
> Local references are only valid in the thread in which they are created. The 
> native code must not pass local references from one thread to another.
> {code}
> We have two places where we DO pass local JNI reference to another thread:
> * CacheParallelLoadStoreAdapter
> * CacheTestStore.LoadCache
> And, potentially (due to user code):
> * UnmanagedCallbacks.DataStreamerStreamReceiverInvoke
> For some reason it has worked for us before.
> But renamings in IGNITE-1881 have caused test execution order to change, and 
> these store tests cause process crash.
> To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be 
> executed before store tests. All other tests can be excluded. 100% repro 
> rate: "FATAL ERROR in native method: Bad global or local ref passed to JNI".



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

[jira] [Commented] (IGNITE-183) Delete busyLock from IgfsMetaManager

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-183:


fixed by the following way: IgfsImpl and IgfsMetaManager use the same instance 
of busyLock.

> Delete busyLock from IgfsMetaManager
> 
>
> Key: IGNITE-183
> URL: https://issues.apache.org/jira/browse/IGNITE-183
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: sprint-1
>Reporter: Alexey Kuznetsov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> It seems that busy lock is not needed and owner busy lock could be used when 
> needed.
> Ask Yakov or Alex G. for details if needed.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1626:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1626 .Net: Create NuGet package.



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

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

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

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


commit f6786765ea52540ff18227c798eb0c9ae47715c4
Author: Pavel Tupitsyn 
Date:   2015-11-12T11:58:43Z

IGNITE-1626 .Net: Create NuGet package.

commit 9df5a1e2ab5ac73e3064a014c26c024db7a72e37
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:08:49Z

wip

commit 300124b846c4b7a40738e4d1e0417ee1658cd1b4
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:12:12Z

wip

commit fe651ecd8696622417365f3d207d1056f0b9fb6e
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:25:50Z

wip

commit 2a13da32b11275e663bbc18bd1fb2bf3dedab3d1
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:27:26Z

wip

commit 5d2a7c5fd8a162add23f156206d0369763c56cd1
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:34:03Z

wip

commit c3bac9ca07a57ac67dde42bafdc006fe168586fc
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:37:18Z

wip

commit b7b1fb667f6200bd06f04cfb80fb3af15a32b802
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:45:43Z

wip

commit 846a9b6577e9466ad606a19c9bd7bfc851668135
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:57:09Z

wip

commit 608f92c8534e91cbae2e597da08f152152e54145
Author: Pavel Tupitsyn 
Date:   2015-11-12T14:07:43Z

Install.ps1 done

commit 7421d89cdf0822c93b932692e86aa86569aa2f99
Author: Pavel Tupitsyn 
Date:   2015-11-12T14:11:28Z

wip

commit cdeb2fed1503bc0e309cdd331023b9443317a68b
Author: Pavel Tupitsyn 
Date:   2015-11-12T14:19:37Z

Fix IgniteHome resolution

commit 1f410bb53ab62e095c6b5f3a8518fdd45adf
Author: Pavel Tupitsyn 
Date:   2015-11-12T15:22:04Z

Move nuget files to project folder

commit 628465c272ea82eeb9c303da7b245d108f611da1
Author: Pavel Tupitsyn 
Date:   2015-11-12T16:07:48Z

Merge remote-tracking branch 'remotes/upstream/ignite-1282' into ignite-1626




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



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

[jira] [Resolved] (IGNITE-1637) IGFS: Consistent properties propagation.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky resolved IGNITE-1637.
-
Resolution: Fixed
  Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

Implicit directory creation is fixed as it done in HDFS , with the exception 
that we don't use umask-s in IGFS.
Pull request https://github.com/apache/ignite/pull/198 .
Closing IGNITE-1850 as a duplicate of this one.


> IGFS: Consistent properties propagation.
> 
>
> Key: IGNITE-1637
> URL: https://issues.apache.org/jira/browse/IGNITE-1637
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> IGFS has methods accepting properties map. E.g., create, append, mkdirs. 
> How we should apply these properties? Two strategies are possible:
> 1) Apply there properties only to leaf node, and set defaults to parent nodes.
> 2) Apply there properties to all created nodes.
> Lets take HDFS as a reference for this. 



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

[jira] [Closed] (IGNITE-1850) IGFS: implicitly created directoried should always have default properties

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky closed IGNITE-1850.
---

> IGFS: implicitly created directoried should always have default properties
> --
>
> Key: IGNITE-1850
> URL: https://issues.apache.org/jira/browse/IGNITE-1850
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> Currently we have #create, #append , #mkdirs operations that implicitly 
> create parent directories if they are absent.
> Now #mkdirs uses the properties passed in for the implicitly created 
> directories if they are not null, and uses default properties (with 0777 
> permission flag) if the properties are not given.
> #create & #append use for the implicitly created directories properties 
> passed in for newly created file, if the passed in properties are not null, 
> and use default properties (with 0777 permission flag) if they are not given.
> It would be more logical to always use defaults for the implicitly created 
> directories. 



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel  Tupitsyn edited comment on IGNITE-1626 at 11/12/15 4:17 PM:
---

* nuspec file created to include all necessary JAR files, 
Apache.Ignite.Core.dll, and default config file
* version is being set automatically from assemblyinfo
* IGNITE_HOME resolve logic adjusted to detect NuGet deployment
* Package tested locally: no extra steps from the user are required (besides 
Java installation). Install package => Ignition.Start works.

* TC config created to build nupkg: 
http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet

> INFRA team must be asked about a place where NuGet package could be stored.
No need for this. Package is created by TC task, tested, and then pushed to 
nuget.org.

What is left:
* proper wording in summary and description
* icon


was (Author: ptupitsyn):
* nuspec file created to include all necessary JAR files, 
Apache.Ignite.Core.dll, and default config file
* version is being set automatically from assemblyinfo
* IGNITE_HOME resolve logic adjusted to detect NuGet deployment
* Package tested locally: no extra steps from the user are required (besides 
Java installation). Install package => Ignition.Start works.

* TC config created to build nupkg: 
http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet

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



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

[jira] [Created] (IGNITE-1896) .Net: Improve query API

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1896:
---

 Summary: .Net: Improve query API
 Key: IGNITE-1896
 URL: https://issues.apache.org/jira/browse/IGNITE-1896
 Project: Ignite
  Issue Type: Improvement
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


Current API is very clumsy.
Cache is generic, however we require the user to specify query type explicitly.
There are cases when query type is a string and/or is different from current 
cache generic type, so the current API has to be kept.

However, we should provide simple methods with generic inference:
{code}
IQueryCursor> ScanQuery(ICacheEntryFilter 
filter);
IQueryCursor> SqlQuery(string sql, params object[] 
args);
IQueryCursor> SqlQuery(string sql, bool local, 
params object[] args);
IQueryCursor> TextQuery(string text);
IQueryCursor> TextQuery(string text, bool local);
{code}



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

[jira] [Created] (IGNITE-1897) Add failover to write-behind cache store

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-1897:
---

 Summary: Add failover to write-behind cache store
 Key: IGNITE-1897
 URL: https://issues.apache.org/jira/browse/IGNITE-1897
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
 Fix For: 1.6


Currently there is a possibility of losing database updates if primary node 
fails. We should maintain updates queue on backup node as well and flush it if 
needed.

The implementation should be similar to what is done with continuous queries in 
scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426



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

[jira] [Updated] (IGNITE-1897) Add failover to write-behind cache store

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1897:

Description: 
Currently there is a possibility of losing database updates if primary node 
fails. We should maintain updates queue on backup node as well and flush it if 
needed.

The implementation should be similar to what is done with continuous queries in 
scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426

Corresponding user@ thread: 
http://apache-ignite-users.70518.x6.nabble.com/Write-behind-question-td1936.html

  was:
Currently there is a possibility of losing database updates if primary node 
fails. We should maintain updates queue on backup node as well and flush it if 
needed.

The implementation should be similar to what is done with continuous queries in 
scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426


> Add failover to write-behind cache store
> 
>
> Key: IGNITE-1897
> URL: https://issues.apache.org/jira/browse/IGNITE-1897
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> Currently there is a possibility of losing database updates if primary node 
> fails. We should maintain updates queue on backup node as well and flush it 
> if needed.
> The implementation should be similar to what is done with continuous queries 
> in scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426
> Corresponding user@ thread: 
> http://apache-ignite-users.70518.x6.nabble.com/Write-behind-question-td1936.html



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