[jira] [Resolved] (IGNITE-1326) IGFS: data write errors should be failed over in the level of IGFS output stream implementation.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky resolved IGNITE-1326.
-
Resolution: Fixed

This was implemented during fix IGNITE-1697.

> IGFS: data write errors should be failed over in the level of IGFS output 
> stream implementation.
> 
>
> Key: IGNITE-1326
> URL: https://issues.apache.org/jira/browse/IGNITE-1326
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> See 
> org.apache.ignite.internal.processors.igfs.IgfsDataManager.WriteCompletionFuture#onError
>  : currently if a node failed to receive data block, this implementation 
> completes the write future with an Exception, so output stream method will 
> throw exception. 
> Preferably we should do failover there , recalculate blocks affinity on the 
> new topology and re-send the block(s) again.
> We can also just use the cache .put() functionality (manual sending of the 
> file blocks was implemented due to performance optimization, as far I know).



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

[jira] [Comment Edited] (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:comment-tabpanel=14991651#comment-14991651
 ] 

Semen Boikov edited comment on IGNITE-1758 at 11/9/15 1:30 PM:
---

Created test which restarts only server nodes, it fails from time to time with 
assert:
{noformat}
[11:51:24]W: [org.apache.ignite:ignite-core] 
java.lang.AssertionError: Invalid node order: TcpDiscoveryNode 
[id=005cd5de-f1f1-435c-8ac4-f4474c28d000, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=0, intOrder=61, 
lastExchangeTime=1446724284050, loc=false, ver=1.5.0#20151105-sha1:94119c29, 
isClient=false]
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:3362)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9176)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9149)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:616)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:128)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1260)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2700(ServerImpl.java:157)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:3685)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2157)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5600)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}

Assert fails since when NodeAddFinished event is received for some node there 
are nodes with lower internal order which did not receive NodeAddFinished.

Debugged this failure, found that it is possible that some node can get IO 
error trying to send message to next node and add this node in failed list, but 
this node can still be alive and can process messages from others nodes. To fix 
this issue it is necessary to pass failedNodes collection to next nodes so that 
it will be consistent across all nodes.


was (Author: sboikov):
Created test which restarts only server nodes, it fails from time to time with 
assert:
{noformat}
[11:51:24]W: [org.apache.ignite:ignite-core] 
java.lang.AssertionError: Invalid node order: TcpDiscoveryNode 
[id=005cd5de-f1f1-435c-8ac4-f4474c28d000, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47503], discPort=47503, order=0, intOrder=61, 
lastExchangeTime=1446724284050, loc=false, ver=1.5.0#20151105-sha1:94119c29, 
isClient=false]
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:3362)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9176)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9149)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:616)
[11:51:24]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:128)
[11:51:24]W: 

[jira] [Commented] (IGNITE-1566) Hadoop: In case if IGFS name is missing in the URI, the connection failure message should be more informative.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-1566:
-

http://apache-ignite-users.70518.x6.nabble.com/How-to-config-Ignite-on-hadoop-tt1306.html

> Hadoop: In case if IGFS name is missing in the URI, the connection failure 
> message should be more informative.
> --
>
> Key: IGNITE-1566
> URL: https://issues.apache.org/jira/browse/IGNITE-1566
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> User has IGFS "igfs" configured in Ignite node.
> After that he tries to connect to it with hadoop client using command
> {code}
> $ hadoop fs -ls igfs://127.0.0.1:10500/
> {code}
> And gets the following error message:
> {code}ls: Failed to communicate with IGFS.{code} .
> The problem is that IGFS name is missing in the URI. But the error message 
> does not give any hint about that.



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

[jira] [Created] (IGNITE-1876) Access to a non-existing entry produces events

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1876:
-

 Summary: Access to a non-existing entry produces events
 Key: IGNITE-1876
 URL: https://issues.apache.org/jira/browse/IGNITE-1876
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
Priority: Minor
 Fix For: 1.6


Trying to get access to a non-existing entry produces following events:

for get operation:
CACHE_ENTRY_CREATED
CACHE_OBJECT_READ

for remove operation
CACHE_ENTRY_CREATED
CACHE_OBJECT_REMOVED

Such behavior should be either properly documented or fixed by following ways:
 - do not generate event
 - generate a new event (something named EVT_CACHE_NO_ENTRY)



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

[jira] [Commented] (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:comment-tabpanel=14996565#comment-14996565
 ] 

Semen Boikov commented on IGNITE-1758:
--

One more issue found: 
- node1 starts
- node2 joins, but get IO error trying to send NodeAdded message back to node1 
(node1 still alive)
- node2 adds node1 to failed list and tries to rejoin, it is able to send join 
request to node1, but node1 does not reply since node2 was already added to 
ring, and node2 will hang inside joinTopology

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

[jira] [Assigned] (IGNITE-1847) Portables: add "field" method to PortableMetadata.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-1847:
---

Assignee: Vladimir Ozerov

> Portables: add "field" method to PortableMetadata.
> --
>
> Key: IGNITE-1847
> URL: https://issues.apache.org/jira/browse/IGNITE-1847
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> 1) Add "PortableField field()" method to PortableMetadata. Currently it is 
> located on "PortableObject", which is wrong.
> 2) PortableObject "field" and "hasField" methods must go through cached 
> PortableFields.



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

[jira] [Closed] (IGNITE-1326) IGFS: data write errors should be failed over in the level of IGFS output stream implementation.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky closed IGNITE-1326.
---

> IGFS: data write errors should be failed over in the level of IGFS output 
> stream implementation.
> 
>
> Key: IGNITE-1326
> URL: https://issues.apache.org/jira/browse/IGNITE-1326
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> See 
> org.apache.ignite.internal.processors.igfs.IgfsDataManager.WriteCompletionFuture#onError
>  : currently if a node failed to receive data block, this implementation 
> completes the write future with an Exception, so output stream method will 
> throw exception. 
> Preferably we should do failover there , recalculate blocks affinity on the 
> new topology and re-send the block(s) again.
> We can also just use the cache .put() functionality (manual sending of the 
> file blocks was implemented due to performance optimization, as far I know).



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

[jira] [Assigned] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-1681:
---

Assignee: Denis Magda  (was: Andrey Gura)

> loadAll threshold is not configurable for CacheStoreBalancingWrapper
> 
>
> Key: IGNITE-1681
> URL: https://issues.apache.org/jira/browse/IGNITE-1681
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Denis Magda
> Fix For: 1.5
>
> Attachments: master_6844370_ignite-1681.patch
>
>
> CacheStoreBalancingWrapper is created in cache store manager using default 
> constructor. There is no way to override a default value for loadAllThreshold.
> We can add a cache configuration parameter named 
> storeConcurrentLoadAllThreshold to control this:
> {code}
> CacheConfiguration {
> ...
> public int getStoreConcurrentLoadAllThreshold() {...}
> public void setStoreConcurrentLoadAllThreshold(int 
> storeConcurrentLoadAllThreshold) {...}
> ...
> }
> {code}



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

[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-429:
-

Chandresh, 
Thanks, I've started investigation/refactoring. 
Checked that test hang on each run. Seems I need to read more about Storm 
before changes ;) 

> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> 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 Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm 
> and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples 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] [Assigned] (IGNITE-1877) Add ClassLoaderCodec for OSGI support

[Andrey Kornev (JIRA)]

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

Andrey Kornev reassigned IGNITE-1877:
-

Assignee: Romain Gilles  (was: Andrey Kornev)

> Add ClassLoaderCodec for OSGI support
> -
>
> Key: IGNITE-1877
> URL: https://issues.apache.org/jira/browse/IGNITE-1877
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Dmitriy Setrakyan
>Assignee: Romain Gilles
> Fix For: 1.6
>
>
> The design is described here: 
> https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility



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

[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-429:
-

Anton,
(To save your time)

Storm testing framework times out after 5 secs. To avoid it, you need set 
STORM_TEST_TIMEOUT_MS env. variable.
{code}
$ export STORM_TEST_TIMEOUT_MS=1
$ mvn test
{code}


> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> 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 Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm 
> and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples 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] [Created] (IGNITE-1877) Add ClassLoaderCodec for OSGI support

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-1877:
-

 Summary: Add ClassLoaderCodec for OSGI support
 Key: IGNITE-1877
 URL: https://issues.apache.org/jira/browse/IGNITE-1877
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Reporter: Dmitriy Setrakyan
 Fix For: 1.6


The design is described here: 
https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility



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

[jira] [Updated] (IGNITE-1867) Fix java class names and package declaration

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-1867:
---
Description: 
I noticed a few issues when I imported my project, created using the web 
console, in IDEA -

1. ServerConfigurationFactory class name is create in the file called 
“ConfigurationFactory.java”. Class name and file name should be the same.
2. The package declaration for ClientConfigurationFactory and 
SeverConfigurationFactory classes is missing.
3. There should be simple 'nodeStartup' class for starting a node, in the IDE, 
using the XML configuration file.
4. Missing near configuration for client in java code.

  was:
I noticed a few issues when I imported my project, created using the web 
console, in IDEA -

1. ServerConfigurationFactory class name is create in the file called 
“ConfigurationFactory.java”. Class name and file name should be the same.
2. The package declaration for ClientConfigurationFactory and 
SeverConfigurationFactory classes is missing.
3. There should be simple 'nodeStartup' class for starting a node, in the IDE, 
using the XML configuration file.


> Fix java class names and package declaration
> 
>
> Key: IGNITE-1867
> URL: https://issues.apache.org/jira/browse/IGNITE-1867
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Prachi Garg
>Assignee: Andrey Novikov
> Fix For: 1.5
>
>
> I noticed a few issues when I imported my project, created using the web 
> console, in IDEA -
> 1. ServerConfigurationFactory class name is create in the file called 
> “ConfigurationFactory.java”. Class name and file name should be the same.
> 2. The package declaration for ClientConfigurationFactory and 
> SeverConfigurationFactory classes is missing.
> 3. There should be simple 'nodeStartup' class for starting a node, in the 
> IDE, using the XML configuration file.
> 4. Missing near configuration for client in java code.



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

[jira] [Commented] (IGNITE-1753) Rework CacheJdbcPojoStore to new API.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-1753:
--

Updated wiki 
https://cwiki.apache.org/confluence/display/IGNITE/Jdbc+Store+Configuration
#Dropped configuration class
#Removed keepSerializws property

> Rework CacheJdbcPojoStore to new API.
> -
>
> Key: IGNITE-1753
> URL: https://issues.apache.org/jira/browse/IGNITE-1753
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.5
>
>
> We need to rework CacheJdbcPojoStore and its factory as described here: 
> https://cwiki.apache.org/confluence/display/IGNITE/Jdbc+Store+Configuration



--
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=14997902#comment-14997902
 ] 

Roman Shtykh commented on IGNITE-529:
-

Anton, thank you for your feedback.

I rewrote my code following your recommendations as closely as I could.
I extended StreamAdapter as you advised (although the docs say it is optional 
;)) and used an extractor for converting Flume events. However, Flume is 
different from other streamers we have so far. Sink, which is normally 
instantiated with Flume deployment, is central here, not the streamer. User 
does not create a cache or a streamer and cannot pass it as a parameter. Sink 
reads configurations provided in conf file and instantiates the streamer 
through those parameters.
And therefore having two extractors does not work here (lines 124-126 of 
IgniteSink.java) -- I wish it was one interface, but for now I used 
StreamMultipleTupleExtractor here.

As I said, the sink is central here, and probably in future this integration 
has to be a part of Flume, not Ignite.

I hope you have a chance at looking how Flume works
https://flume.apache.org/FlumeDeveloperGuide.html


> 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-1853) Implement plugins support

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1853:


GitHub user Dmitriyff opened a pull request:

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

IGNITE-1853 added ability to inject extension for app



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

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

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

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


commit 83a57d80748d11e0e9abf462d348d4e5e6b1982b
Author: Dmitriyff 
Date:   2015-11-10T04:03:58Z

IGNITE-1853 added task to inject extension to app

commit a331f6246b659b2b0623f9f9a19cc0a6ea13d6a1
Author: Dmitriyff 
Date:   2015-11-10T04:05:57Z

Merge branch 'ignite-843-rc1' of https://github.com/apache/ignite into 
ignite-1853




> Implement plugins support
> -
>
> Key: IGNITE-1853
> URL: https://issues.apache.org/jira/browse/IGNITE-1853
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.5
>Reporter: Dmitriyff
>Assignee: Dmitriyff
> Fix For: 1.5
>
>
> add task ruuner support to project, implement task to include plugins for app



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

[jira] [Commented] (IGNITE-1845) .Net: Adopt portable API changes.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1845:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1845 .Net: Adopt portable API changes.



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

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

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

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


commit 0ce9ba16edcecd666c6f352c296a9e098948b616
Author: Pavel Tupitsyn 
Date:   2015-11-09T17:12:03Z

IGNITE-1845 .Net: Adopt portable API changes.




> .Net: Adopt portable API changes.
> -
>
> Key: IGNITE-1845
> URL: https://issues.apache.org/jira/browse/IGNITE-1845
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel  Tupitsyn
>Priority: Blocker
> Fix For: 1.5
>
>
> Important API changes will be introduced as a part of IGNITE-950. 
> Once these changes are in place, we need to port them to .Net.



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

[jira] [Commented] (IGNITE-1079) Implement Ignite-based cluster manager for Vert.x framework.

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-1079:
-

Pull request with fix was accepted and merged into vertx-core master branch.

> Implement Ignite-based cluster manager for Vert.x framework.
> 
>
> Key: IGNITE-1079
> URL: https://issues.apache.org/jira/browse/IGNITE-1079
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Gura
>Priority: Trivial
>  Labels: newbie
> Fix For: 1.5
>
>
> Implement Ignite-based cluster manager for Vert.x framework: http://vertx.io/
> vertx-hazelcast could be used as start point: 
> https://github.com/vert-x3/vertx-hazelcast



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

[jira] [Assigned] (IGNITE-1093) Rebalancing with default parameters is very slow

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-1093:


Assignee: Pavel Konstantinov  (was: Anton Vinogradov)

> Rebalancing with default parameters is very slow
> 
>
> Key: IGNITE-1093
> URL: https://issues.apache.org/jira/browse/IGNITE-1093
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-7
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Critical
> Fix For: 1.5
>
> Attachments: Plot_ThroughputLatencyProbe_01.png, rebalancing.zip
>
>
> # Start one node with partitioned cache with one backup.
> # Load into the cache 40billions of keys using DataStreamer
> # Start second node on the same host



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

[jira] [Commented] (IGNITE-708) Need to remove background partition exchange

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-708:
-

Gianfranco, 
I've finished task & merged it to master. 



> Need to remove background partition exchange
> 
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
>  Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Blocker
>  Labels: datagrid
> Fix For: 1.5, 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the 
> oldest node in topology) and coordinator spreads full partition map to every 
> node in topology. This happens for each cache separately. This seems to take 
> place even if there were no changes to local partition maps. Given we 
> guarantee communication message delivery this background process seems to be 
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount 
> of live caches at some point of app lifecycle and app may suffer from  
> background exchange which is obviously not a requirement (and may be never 
> has been the one).



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

[jira] [Commented] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

[Artem Shutak (JIRA)]

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

Artem Shutak commented on IGNITE-1678:
--

Finished with an implementation.

Working on tests: improve old tests and add new tests.

In process of testing faced with an issue related to using of internal 
transactions and dead-lock after. Will investigate.

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Artem Shutak
> Fix For: 1.6
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



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

[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm

[Chandresh Pancholi (JIRA)]

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

Chandresh Pancholi commented on IGNITE-429:
---

Before that can you check whats the mistake am i making with ignite node that i 
am starting?
One node i am starting in beforetest and another one is in StormStreamer class.

> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
>  Issue Type: Sub-task
>  Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> 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 Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm 
> and stream them into Ignite caches. 
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples 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] [Assigned] (IGNITE-1876) Access to a non-existing entry produces events

[Michael Griggs (JIRA)]

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

Michael Griggs reassigned IGNITE-1876:
--

Assignee: Michael Griggs  (was: Yakov Zhdanov)

> Access to a non-existing entry produces events
> --
>
> Key: IGNITE-1876
> URL: https://issues.apache.org/jira/browse/IGNITE-1876
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Sergey Kozlov
>Assignee: Michael Griggs
>Priority: Minor
> Fix For: 1.6
>
>
> Trying to get access to a non-existing entry produces following events:
> for get operation:
> CACHE_ENTRY_CREATED
> CACHE_OBJECT_READ
> for remove operation
> CACHE_ENTRY_CREATED
> CACHE_OBJECT_REMOVED
> Such behavior should be either properly documented or fixed by following ways:
>  - do not generate event
>  - generate a new event (something named EVT_CACHE_NO_ENTRY)



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

[jira] [Commented] (IGNITE-1370) StreamTupleExtractor should allow extracting multiple tuples from a single event

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-1370:
--

Your first design idea (modifying StreamTupleExtractor to add a second method 
returning a Map) is better for real use cases.
In some cases if you want to initialize a user-specified extractor you have no 
knowledge of. For instance, from a configuration file you have to do the 
following
{code}
Class clazz =  
(Class)Class.forName(tupleExtractorCls);
then create new instance
{code}
What should be Some_Extractor? Single or multiple?


> StreamTupleExtractor should allow extracting multiple tuples from a single 
> event
> 
>
> Key: IGNITE-1370
> URL: https://issues.apache.org/jira/browse/IGNITE-1370
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: ignite-1.4
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
> Fix For: 1.5
>
>
> Currently the {{StreamTupleExtractor}} interface contains a single method:
> {code}
> public Map.Entry extract(T msg);
> {code}
> Which only allows extracting a single Entry from an incoming event.
> In real life, it could be that an event contains multiple entries. 



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

[jira] [Closed] (IGNITE-1875) SQL : SCAN does not work, returns an empty table

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> SQL : SCAN does not work, returns an empty table 
> -
>
> Key: IGNITE-1875
> URL: https://issues.apache.org/jira/browse/IGNITE-1875
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
>
> First time I'm faced with this issue on default cache, but then I'm 
> reproduced it on any other cache.
> In all cases the result is the same - an empty result table with vertical 
> scroll.



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

[jira] [Closed] (IGNITE-1763) We need somehow handle long field name in metadata dialog

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> We need somehow handle long field name in metadata dialog
> -
>
> Key: IGNITE-1763
> URL: https://issues.apache.org/jira/browse/IGNITE-1763
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
> Attachments: ig-1763.png
>
>
> Please see attachment



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

[jira] [Closed] (IGNITE-1687) Add possibility to insert fully qualified name to the query from metadata popup

[Pavel Konstantinov (JIRA)]

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

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

Tested.

> Add possibility to insert fully qualified name to the query from metadata 
> popup 
> 
>
> Key: IGNITE-1687
> URL: https://issues.apache.org/jira/browse/IGNITE-1687
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>
> Such possibility will help user to construct cross-cache queries.



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

[jira] [Resolved] (IGNITE-1875) SQL : SCAN does not work, returns an empty table

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1875.

Resolution: Fixed
  Assignee: Pavel Konstantinov

Fixed. Pavel, please test, use latest ignite and agent build.

> SQL : SCAN does not work, returns an empty table 
> -
>
> Key: IGNITE-1875
> URL: https://issues.apache.org/jira/browse/IGNITE-1875
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.5
>
>
> First time I'm faced with this issue on default cache, but then I'm 
> reproduced it on any other cache.
> In all cases the result is the same - an empty result table with vertical 
> scroll.



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

[jira] [Closed] (IGNITE-1872) Remove Binaries.builder(int) method.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1872.
---

> Remove Binaries.builder(int) method.
> 
>
> Key: IGNITE-1872
> URL: https://issues.apache.org/jira/browse/IGNITE-1872
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> This method is not usable if object is created for the first time and there 
> is no metadata for it. 
> GIven that it has relatively small value, let's remove it form API.



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

[jira] [Resolved] (IGNITE-1872) Remove Binaries.builder(int) method.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-1872.
-
Resolution: Fixed

> Remove Binaries.builder(int) method.
> 
>
> Key: IGNITE-1872
> URL: https://issues.apache.org/jira/browse/IGNITE-1872
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> This method is not usable if object is created for the first time and there 
> is no metadata for it. 
> GIven that it has relatively small value, let's remove it form API.



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

[jira] [Updated] (IGNITE-1874) Adjust initial placement and size of metadada popup on SQL

[Pavel Konstantinov (JIRA)]

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

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

> Adjust initial placement and size of metadada popup on SQL
> --
>
> Key: IGNITE-1874
> URL: https://issues.apache.org/jira/browse/IGNITE-1874
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.5
>
> Attachments: ig-1874.png
>
>
> Currently if user opens two metadata popups then they will cross each other 
> (please see attachment).
> Because of that I suggest:
> 1) change initial position - align with top of query be vertical
> 2) change initial height - the same as initial query height



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

[jira] [Resolved] (IGNITE-1687) Add possibility to insert fully qualified name to the query from metadata popup

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1687.

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

Added insert of fully qualified name for cache. Pavel, please test

> Add possibility to insert fully qualified name to the query from metadata 
> popup 
> 
>
> Key: IGNITE-1687
> URL: https://issues.apache.org/jira/browse/IGNITE-1687
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> Such possibility will help user to construct cross-cache queries.



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

[jira] [Closed] (IGNITE-1846) CPP: Adopt portable API changes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1846.
---

> CPP: Adopt portable API changes.
> 
>
> Key: IGNITE-1846
> URL: https://issues.apache.org/jira/browse/IGNITE-1846
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> Important API changes will be introduced as a part of IGNITE-950. 
> Once these changes are in place, we need to port them to CPP.



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

[jira] [Resolved] (IGNITE-1846) CPP: Adopt portable API changes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-1846.
-
Resolution: Fixed

> CPP: Adopt portable API changes.
> 
>
> Key: IGNITE-1846
> URL: https://issues.apache.org/jira/browse/IGNITE-1846
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> Important API changes will be introduced as a part of IGNITE-950. 
> Once these changes are in place, we need to port them to CPP.



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

[jira] [Assigned] (IGNITE-1846) CPP: Adopt portable API changes.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-1846:
---

Assignee: Vladimir Ozerov

> CPP: Adopt portable API changes.
> 
>
> Key: IGNITE-1846
> URL: https://issues.apache.org/jira/browse/IGNITE-1846
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Fix For: 1.5
>
>
> Important API changes will be introduced as a part of IGNITE-950. 
> Once these changes are in place, we need to port them to CPP.



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

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-1864:
-

I think we should deprecate {{CacheTmLookup}} interface with its 
implementations and {{txManagerLookupClassName}} configuration property. We can 
use JCache factory instead:

{code}
TransactionConfiguration.setTxManagerFactory(Factory 
factory)
{code}

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



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

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko updated IGNITE-1864:

Priority: Critical  (was: Major)

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



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

[jira] [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=14996318#comment-14996318
 ] 

Anton Vinogradov commented on IGNITE-529:
-

Roman, 
1) I meant that streamer should use already created cache specified at it's 
configuration. In other words, user should create cache and pass it at a 
streamer parameter.
Try code simmilar to following:
 try (IgniteDataStreamer dataStreamer = 
grid().dataStreamer(null)) {
Streamer streamer = new StreamerInstance(dataStreamer);

2) JmsStreamer seems to be wrongly designed. Please follow 
https://cwiki.apache.org/confluence/display/IGNITE/Streamers+Implementation+Guidelines
 .

Using StreamAdapter.addMessage() is a correct way. Only one of *TupleExtractor 
should be used in this case.

> 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-1875) SQL : SCAN does not work, returns an empty table

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-1875:
---
Summary: SQL : SCAN does not work, returns an empty table   (was: SCAN for 
default cache does not work )

> SQL : SCAN does not work, returns an empty table 
> -
>
> Key: IGNITE-1875
> URL: https://issues.apache.org/jira/browse/IGNITE-1875
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
>
> 1) start node with default cache
> 2) start agent 
> 3) execute scan
> observed:  empty table in result



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

[jira] [Updated] (IGNITE-1875) SQL : SCAN does not work, returns an empty table

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-1875:
---
Description: 
First time I'm faced with this issue on default cache, but then I'm reproduced 
it on any other cache.
In all cases the result is the same - an empty result table with vertical 
scroll.

  was:
1) start node with default cache
2) start agent 
3) execute scan

observed:  empty table in result


> SQL : SCAN does not work, returns an empty table 
> -
>
> Key: IGNITE-1875
> URL: https://issues.apache.org/jira/browse/IGNITE-1875
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
> Fix For: 1.5
>
>
> First time I'm faced with this issue on default cache, but then I'm 
> reproduced it on any other cache.
> In all cases the result is the same - an empty result table with vertical 
> scroll.



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

[jira] [Created] (IGNITE-1872) Remove Binaries.builder(int) method.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1872:
---

 Summary: Remove Binaries.builder(int) method.
 Key: IGNITE-1872
 URL: https://issues.apache.org/jira/browse/IGNITE-1872
 Project: Ignite
  Issue Type: Task
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.5


This method is not usable if object is created for the first time and there is 
no metadata for it. 
GIven that it has relatively small value, let's remove it form API.



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

[jira] [Created] (IGNITE-1873) .Net: Investigate BinaryFormatter vs DataContractSerializer vs XmlSerializer

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1873:
---

 Summary: .Net: Investigate BinaryFormatter vs 
DataContractSerializer vs XmlSerializer
 Key: IGNITE-1873
 URL: https://issues.apache.org/jira/browse/IGNITE-1873
 Project: Ignite
  Issue Type: Improvement
  Components: interop
Affects Versions: 1.6
Reporter: Pavel  Tupitsyn
Priority: Minor
 Fix For: 1.6


DataContractSerializer and XmlSerializer, in binary mode (BinaryWriter), are 
said to be faster and produce more compact results than BinaryFormatter.

We can consider changing it in SerializableObjectHolder. Need to run benchmarks 
first.

Comprehensive feature comparison: 
http://manski.net/2014/10/net-serializers-comparison-chart/



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

[jira] [Created] (IGNITE-1874) Adjust initial placement and size of metadada popup on SQL

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1874:
--

 Summary: Adjust initial placement and size of metadada popup on SQL
 Key: IGNITE-1874
 URL: https://issues.apache.org/jira/browse/IGNITE-1874
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Priority: Minor


Currently if user opens two metadata popups then they will cross each other 
(please see attachment).
Because of that I suggest:
1) change initial position - align with top of query be vertical
2) change initial height - the same as initial query height



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

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

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1716.

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

Reworked metadata dialog. Pavel, please check

> 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
>Assignee: 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] [Resolved] (IGNITE-1161) Close rest sql cursor after delay

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1161.

Resolution: Fixed

> Close rest sql cursor after delay 
> --
>
> Key: IGNITE-1161
> URL: https://issues.apache.org/jira/browse/IGNITE-1161
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Irina Vasilinets
>Assignee: Andrey Novikov
> Fix For: 1.5
>
> Attachments: ignite-1161.patch, master_ignite-1161.patch, 
> master_ignite-1161.patch
>
>
> QueryCommandHandler stores cursors for all queries that was executed by rest. 
> Old queries cursors should be closed after delay and should be removed from 
> the map.



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

[jira] [Closed] (IGNITE-1161) Close rest sql cursor after delay

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-1161.
--
Assignee: (was: Andrey Novikov)

> Close rest sql cursor after delay 
> --
>
> Key: IGNITE-1161
> URL: https://issues.apache.org/jira/browse/IGNITE-1161
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Irina Vasilinets
> Fix For: 1.5
>
> Attachments: ignite-1161.patch, master_ignite-1161.patch, 
> master_ignite-1161.patch
>
>
> QueryCommandHandler stores cursors for all queries that was executed by rest. 
> Old queries cursors should be closed after delay and should be removed from 
> the map.



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

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

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-1841:


Fixed

> 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
>Assignee: Andrey Novikov
> Fix For: 1.5
>
>




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

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

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1841.

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

> 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
>Assignee: Pavel Konstantinov
> Fix For: 1.5
>
>




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

[jira] [Assigned] (IGNITE-1763) We need somehow handle long field name in metadata dialog

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-1763:
--

Assignee: Andrey Novikov

> We need somehow handle long field name in metadata dialog
> -
>
> Key: IGNITE-1763
> URL: https://issues.apache.org/jira/browse/IGNITE-1763
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: 1.5
>
> Attachments: ig-1763.png
>
>
> Please see attachment



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

[jira] [Resolved] (IGNITE-1763) We need somehow handle long field name in metadata dialog

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-1763.

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

Fixed. Pavel, please test.

> We need somehow handle long field name in metadata dialog
> -
>
> Key: IGNITE-1763
> URL: https://issues.apache.org/jira/browse/IGNITE-1763
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.5
>
> Attachments: ig-1763.png
>
>
> Please see attachment



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

[jira] [Commented] (IGNITE-1428) .Net: Use struct with fixed layout for InteropMemory operations.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1428:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1428 .Net: Use struct with fixed layout for InteropMemory operations.



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

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

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

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


commit 1fab21a310944968bf19b4a427cacb9d2c75addf
Author: Pavel Tupitsyn 
Date:   2015-11-05T12:13:57Z

wip

commit 65b989970bab32dc4bce5fe183b49c7315e8c5f3
Author: Pavel Tupitsyn 
Date:   2015-11-05T12:19:49Z

wip

commit 63f1b36561241774443d01d27730e62927873308
Author: Pavel Tupitsyn 
Date:   2015-11-05T12:20:29Z

wip

commit f75c3ed6ecd3c836be0c303baf894e264bf5553a
Author: Pavel Tupitsyn 
Date:   2015-11-05T12:23:03Z

Fix tests

commit 03ed34af4978a3c7ab29a8cadb1eef30065cb96d
Author: Pavel Tupitsyn 
Date:   2015-11-05T12:26:50Z

wip

commit 3b76c04da552c8d44d7ab9d08b3fbd22cb273849
Author: Pavel Tupitsyn 
Date:   2015-11-05T12:48:55Z

wip

commit e6a6b375d879eb7d828528e431ea1b9e505c98e9
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:07:37Z

wip refactoring

commit 6fb0d47a846b5d089acf5942f8bec01dcb2391fe
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:13:31Z

wip refactoring

commit 4fcd28c40d90f5d5d8e1f311a40f0d2016a9e7bd
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:15:56Z

wip

commit d0bb22690d381bee1b26729522e3c2681e128f35
Author: Pavel Tupitsyn 
Date:   2015-11-09T08:52:34Z

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

commit 7ffa810637293c34f8d5e6556224b5fb0ca19516
Author: Pavel Tupitsyn 
Date:   2015-11-09T09:10:45Z

wip

commit 5cf7c4334c9814c1f8970054a8a1e42469be3fe6
Author: Pavel Tupitsyn 
Date:   2015-11-09T09:18:55Z

wip




> .Net: Use struct with fixed layout for InteropMemory operations.
> 
>
> Key: IGNITE-1428
> URL: https://issues.apache.org/jira/browse/IGNITE-1428
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel  Tupitsyn
>Priority: Minor
>
> This will decrease probability of bugs caused by pointer arithmetics.



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

[jira] [Assigned] (IGNITE-1862) CPP: Fix string handling

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-1862:
---

Assignee: Vladimir Ozerov  (was: Igor Sapego)

> CPP: Fix string handling
> 
>
> Key: IGNITE-1862
> URL: https://issues.apache.org/jira/browse/IGNITE-1862
> Project: Ignite
>  Issue Type: Task
>  Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> Currently we write strings using 2 bytes for each simbol. This way we are 
> trying to mimic UTF16, which is natural for Java. 
> Instead of doing this weird things, we should:
> 1) Tell user that we expect UTF8 string.
> 2) Write strings as plain char*.
> Once it is done, we will be able to remove "convertStrings" property from 
> PortableMarshaller.



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

[jira] [Closed] (IGNITE-1803) Optimize random portable field lookup.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-1803.
---

> Optimize random portable field lookup.
> --
>
> Key: IGNITE-1803
> URL: https://issues.apache.org/jira/browse/IGNITE-1803
> Project: Ignite
>  Issue Type: Task
>  Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> This ticket should be implemented after IGNITE-1770 is ready because it 
> relies on constant-time lookup feature availability.
> The following optimizations should be performed:
> 1) Create method "PortableFieldReader createFieldReader()" on PortableObject 
> interface. This will minimize garbage and let us get rid from unnecessary 
> header parsing.
> 2) Field position is calculated as follows: 
> - Lookup ID mapper for type, get ID;
> - Lookup schemas for type;
> - Lookup schema for schema ID;
> - Lookup field offset for field ID inside schema.
> 4 (!!!) map lookups! It should work as follows:
> - Lookup ID mapper and schemas for type;
> - Lookup field offset using (schema ID + field ID).
> The latter lookup should be performed from highly optimized long->int map, 
> not from conventional HashMap.
> 3) Normal field scan is faster than constant-time lookup when amount of 
> fields is about 10. We need to have two field search strategies and pick the 
> most performant one based on field count (which can be derived in advance 
> from object footer size).



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