[jira] [Created] (IGNITE-13760) Ignite.NET GetAffinity fails with NullPointerException

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-13760:
-

 Summary: Ignite.NET GetAffinity fails with NullPointerException
 Key: IGNITE-13760
 URL: https://issues.apache.org/jira/browse/IGNITE-13760
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.9
Reporter: Alexey Kukushkin


* Given there are Ignite.NET server and client nodes
* When the server node creates a cache and then the client node immediately 
gets affinity for the cache
* Then getting affinity fails with NullPointerException

{code:c#}
IgniteConfiguration IgniteCfg(bool clientMode = false) => new 
IgniteConfiguration
{
ClientMode = clientMode,
IgniteInstanceName = Guid.NewGuid().ToString(),
DiscoverySpi = new TcpDiscoverySpi
{
IpFinder = new TcpDiscoveryStaticIpFinder
{
Endpoints = new[] { "127.0.0.1:47500" }
}
}
};
using var igniteSrv = Ignition.Start(IgniteCfg());
using var igniteClient = Ignition.Start(IgniteCfg(true));
var cache1 = igniteSrv.GetOrCreateCache("cache1");
igniteClient.GetAffinity("cache1");
{code}

The igniteClient.GetAffinity fails with this exception:
{code}
Apache.Ignite.Core.Common.IgniteException
  HResult=0x80131500
  Message=Java exception occurred [class=java.lang.NullPointerException, 
message=]
  Source=Apache.Ignite.Core
  StackTrace:
   at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type, 
Action`1 writeAction)
   at Apache.Ignite.Core.Impl.PlatformTargetAdapter.DoOutOpObject(Int32 type, 
Action`1 action)
   at 
Apache.Ignite.Core.Impl.Ignite.Apache.Ignite.Core.Impl.IIgniteInternal.GetAffinity(String
 cacheName)
   at Apache.Ignite.Core.Impl.Ignite.GetAffinity(String cacheName)
   at DotNet.Sandbox.Program.Main(String[] args) in 
C:\Dev\tmp\DotNet.Sandbox\Program.cs:line 32
  This exception was originally thrown at this call stack:
Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.ExceptionCheck()

Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.CallObjectMethod(Apache.Ignite.Core.Impl.Unmanaged.Jni.GlobalRef,
 System.IntPtr, long*)

Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInStreamOutObject(Apache.Ignite.Core.Impl.Unmanaged.Jni.GlobalRef,
 int, long)
Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(int, 
System.Action)
Inner Exception 1:
JavaException: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.platform.cache.affinity.PlatformAffinity.(PlatformAffinity.java:125)
at 
org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutObject(PlatformProcessorImpl.java:640)
at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13734) .NET Service loses returned array type information

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-13734:
-

 Summary: .NET Service loses returned array type information
 Key: IGNITE-13734
 URL: https://issues.apache.org/jira/browse/IGNITE-13734
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.9
Reporter: Alexey Kukushkin


.NET service client receives Object[] instead of strongly typed array from a 
.NET service. 

There was another already resolved similar issue IGNITE-12823 .NET: Service 
method with user type array parameter can't be found that addressed the problem 
of using arrays as parameters. The problem of using arrays as results still 
exists.

h3. Reproducer

A .NET service returning an array of user-defined types is deployed:
{code:c#}
public interface ITestService
{
Parameter[] TestReturnParametersArray();
}

public sealed class Parameter
{
public int Id { get; set; }
public int[] Values { get; set; }
}
{code}

A .NET client calls the service:
{code:c#}
Parameter[] res = svcProxy.TestReturnParametersArray()
{code}

The service call fails with exception:
{code}
System.InvalidCastException : Unable to cast object of type 'System.Object[]' 
to type 'Parameter[]'.
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13698) SQL EXPLAIN Shows Impossible Index

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-13698:
-

 Summary: SQL EXPLAIN Shows Impossible Index
 Key: IGNITE-13698
 URL: https://issues.apache.org/jira/browse/IGNITE-13698
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.9
Reporter: Alexey Kukushkin


+*Steps to Reproduce*+

1. Create a table with a VARCHAR field and an index on that field

{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}

2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'

{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}

+*Expected*+

The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be 
applied due to any of"
 # The UPPER(TITLE) SQL function on the left-hand side
 # The LIKE pattern starting from % (any symbol)

+*Actual*+

The TEST_TITLE_ASC_IDX is used

{{SELECT}}
{{ __Z0._KEY AS __C0_0}}
{{FROM PUBLIC.TEST __Z0}}
{{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
{{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13384) Auto-generated README.txt contains invalid workingDirectory property name

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-13384:
-

 Summary: Auto-generated README.txt contains invalid 
workingDirectory property name
 Key: IGNITE-13384
 URL: https://issues.apache.org/jira/browse/IGNITE-13384
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.8.1
Reporter: Alexey Kukushkin


Running ignite when the ignite's work directory is missing creates the work 
directory and generates a README.txt inside. [Currently the README wrongly 
says|https://github.com/apache/ignite/blob/864220966caa4157c4fee8a1bc85171623963604/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L9425]:

 

The "workingDirectory" should be changed to "workDirectory":

"You can change the location of working directory with \n" +
" igniteConfiguration.*setWorkDirectory*(location) or \n" +
"  in 
IgniteConfiguration .\n");

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12901:
-

 Summary: SQL: Uncorrelated subquery should run only once.
 Key: IGNITE-12901
 URL: https://issues.apache.org/jira/browse/IGNITE-12901
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin


Currently uncorrelated subqueries (where subquery is not depends on the outer 
query) are executed on each nested loop iteration in the 
org.h2.command.dml.Select#isConditionMet method. 
We may avoid this, for example, using results caching.

h2. Reproducer
{code:java}
public class SubQueryTest extends AbstractIndexingCommonTest {
/** Keys counts at the RIGHT table. */
private static final int RIGHT_CNT = 10;

/** Keys counts at the LEFT table. */
private static final int LEFT_CNT = 50;

/** {@inheritDoc} */
@SuppressWarnings("unchecked")
@Override protected void beforeTest() throws Exception {
super.beforeTest();

startGrids(1);

IgniteCache cacheA = grid(0).createCache(new CacheConfiguration()
.setName("A")
.setSqlSchema("TEST")
.setQueryEntities(Collections.singleton(new 
QueryEntity(Long.class.getTypeName(), "A_VAL")
.setTableName("A")
.addQueryField("ID", Long.class.getName(), null)
.addQueryField("JID", Long.class.getName(), null)
.addQueryField("VAL", Long.class.getName(), null)
.setKeyFieldName("ID")
)));

IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
.setCacheMode(CacheMode.REPLICATED)
.setName("B")
.setSqlSchema("TEST")
.setQueryEntities(Collections.singleton(new 
QueryEntity(Long.class.getName(), "B_VAL")
.setTableName("B")
.addQueryField("ID", Long.class.getName(), null)
.addQueryField("A_JID", Long.class.getName(), null)
.addQueryField("VAL0", String.class.getName(), null)
.setKeyFieldName("ID")
)));

Map batch = new HashMap<>();
for (long i = 0; i < LEFT_CNT; ++i) {
batch.put(i, grid(0).binary().builder("A_VAL")
.setField("JID", i % RIGHT_CNT)
.setField("VAL", i)
.build());

if (batch.size() > 1000) {
cacheA.putAll(batch);

batch.clear();
}
}
if (batch.size() > 0) {
cacheA.putAll(batch);

batch.clear();
}

for (long i = 0; i < RIGHT_CNT; ++i)
cacheB.put(i, grid(0).binary().builder("B_VAL")
.setField("A_JID", i)
.setField("VAL0", String.format("val%03d", i))
.build());
}

/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
stopAllGrids();

super.afterTest();
}

/**
 * Test local query execution.
 */
@Test
public void test() {
sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM 
B)").getAll();
}


/**
 * @param enforceJoinOrder Enforce join order mode.
 * @param sql SQL query.
 * @param args Query parameters.
 * @return Results cursor.
 */
private FieldsQueryCursor> sql(boolean enforceJoinOrder, String 
sql, Object... args) {
return grid(0).context().query().querySqlFields(new SqlFieldsQuery(sql)
.setSchema("TEST")
.setLazy(true)
.setEnforceJoinOrder(enforceJoinOrder)
.setArgs(args), false);
}
}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: IgniteCheckedException: Cannot enable read-through (loader or store is not provided) for cache

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12898:
-

 Summary: Server node with CacheStore fails to re-join the cluster: 
IgniteCheckedException: Cannot enable read-through (loader or store is not 
provided) for cache
 Key: IGNITE-12898
 URL: https://issues.apache.org/jira/browse/IGNITE-12898
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin


If a cache with external persistence is dynamically created on a non-affinity 
node then the cache affinity node cannot join the cluster after restart.
h2. Repro Steps
 # Run an "empty" Ignite node where no cache is going to be started
 # Run a cache affinity node having the "ROLE" attribute set to "DATA"
 # Create the cache from the "empty" node and use a Node Filter to limit the 
cache to the "data" node. External persistence is configured for the cache.
 # Restart the "data" node

h3. Actual Result
{{IgniteCheckedException: Cannot enable read-through (loader or store is not 
provided) for cache}}

h2. Reproducer
h3. Reproducer.java
{code:java}
public class Reproducer {
@Test
public void test() throws Exception {
final String DB_URL = "jdbc:h2:mem:test";
final String ENTITY_NAME = "Person";

Function igniteCfgFactory = instanceName ->
new IgniteConfiguration()
.setIgniteInstanceName(instanceName)
.setDiscoverySpi(new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

// 1. Run an "empty" Ignite node where no cache is going to be started
try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa", "");
 Statement dbStmt = dbConn.createStatement();
 Ignite emptyNode = 
Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
// 2. Run a "Person" cache affinity node having the "ROLE" 
attribute set to "DATA"
Map dataNodeAttrs = new HashMap<>(1);
dataNodeAttrs.put(DataNodeFilter.ATTR_NAME, 
DataNodeFilter.ATTR_VAL);

Ignite dataNode = 
Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));

// 3. Create the "Person" cache from the "empty" node and use a 
Node Filter to limit the cache to the
// "data" node. External persistence to the "Person" table in H2 DB 
is configured for the cache.
dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY 
KEY, name varchar)");

CacheJdbcPojoStoreFactory igniteStoreFactory 
= new CacheJdbcPojoStoreFactory<>();
igniteStoreFactory.setDataSourceFactory(() -> 
JdbcConnectionPool.create(DB_URL, "sa", ""))
.setTypes(
new JdbcType()
.setCacheName(ENTITY_NAME)
.setDatabaseTable(ENTITY_NAME)
.setKeyType(Integer.class)
.setValueType(ENTITY_NAME)
.setKeyFields(new JdbcTypeField(java.sql.Types.INTEGER, 
"id", Integer.class, "id"))
.setValueFields(
new JdbcTypeField(java.sql.Types.INTEGER, "id", 
Integer.class, "id"),
new JdbcTypeField(java.sql.Types.VARCHAR, "name", 
String.class, "name")
)
);

CacheConfiguration cacheCfg =
new CacheConfiguration(ENTITY_NAME)
.setCacheMode(CacheMode.REPLICATED)
.setCacheStoreFactory(igniteStoreFactory)
.setWriteThrough(true)
.setReadThrough(true)
.setNodeFilter(new DataNodeFilter());

emptyNode.createCache(cacheCfg).withKeepBinary();

// 4. Restart the "data" node
dataNode.close();
dataNode = 
Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));

dataNode.close();
}
}

private static class DataNodeFilter implements IgnitePredicate 
{
public static final String ATTR_NAME = "ROLE";
public static final String ATTR_VAL = "DATA";

@Override public boolean apply(ClusterNode node) {
Object role = node.attributes().get(ATTR_NAME);
return role != null && ATTR_VAL.equalsIgnoreCase(role.toString());
}
}
}
{code}

h3. build.gradle
{code:groovy}
dependencies {
compile group: 'org.apache.ignite', name: 'ignite-core', version: '2.8.0'
compile group: 'com.h2database', name: 'h2', version: '1.4.200'

testCompile group: 'junit', name: 'junit', version: '4.12'
}
{code}

h2. Workaround
Create dynamic caches only on the affinity nodes or use "static" caches defined 
in ignite node configuration.

h2. Stack Trace
{code}
class 

[jira] [Created] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12894:
-

 Summary: Cannot use IgniteAtomicSequence in Ignite services
 Key: IGNITE-12894
 URL: https://issues.apache.org/jira/browse/IGNITE-12894
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


h2. Repro Steps
Execute the below steps in default service deployment mode and in 
discovery-based service deployment mode. 
Use the {{ -DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to 
switch to the discovery-based service deployment mode.
 * Create a service initializing an IgniteAtomicService in method 
Service#init() and using the IgniteAtomicService in a business method.
 * Start an Ignite node with the service specified in the IgniteConfiguration
 * Invoke the service's business method on the Ignite node

h3. Actual Result
h4. In Default Service Deployment Mode
Deadlock on the business method invocation
h4. In Discovery-Based Service Deployment Mode
The method invocation fails with {{IgniteException: Failed to find deployed 
service: IgniteTestService}}

h2. Reproducer
h3. Test.java
{code:java}
public interface Test {
String sayHello(String name);
}
{code}

h3. IgniteTestService.java
{code:java}
public class IgniteTestService implements Test, Service {
private @IgniteInstanceResource Ignite ignite;
private IgniteAtomicSequence seq;

@Override public void cancel(ServiceContext ctx) {
}

@Override public void init(ServiceContext ctx) throws InterruptedException {
seq = ignite.atomicSequence("TestSeq", 0, true);
}

@Override public void execute(ServiceContext ctx) {
}

@Override public String sayHello(String name) {
return "Hello, " + name + "! #" + seq.getAndIncrement();
}
}
{code}

h3. Reproducer.java
{code:java}
public class Reproducer {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration()
.setServiceConfiguration(
new ServiceConfiguration()
.setName(IgniteTestService.class.getSimpleName())
.setMaxPerNodeCount(1)
.setTotalCount(0)
.setService(new IgniteTestService())
)
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
);

try (Ignite ignite = Ignition.start(igniteCfg)) {

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false)
.sayHello("World");
}
}
}
{code}

h2. Workaround
Specifying a service wait timeout solves the problem in the discovery-based 
service deployment mode (but not in the default deployment mode):
{code:java}

ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(), 
Test.class, false, 1_000)
.sayHello("World");
{code}

This workaround cannot be used in Ignite.NET clients since .NET 
{{GetServiceProxy}} API does not support the service wait timeout, which is 
hard-coded to 0 on the server side.

h2. Full Exception in Discovery-Based Service Deployment Mode
{noformat}
[01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor] 
Failed to initialize service (service will not be deployed): IgniteTestService
class org.apache.ignite.IgniteInterruptedException: Got interrupted while 
waiting for future to complete.
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
at 
org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
at 
org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
at 
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
at java.base/java.util.HashMap.forEach(HashMap.java:1336)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.processDeploymentActions(ServiceDeploymentTask.java:302)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.init(ServiceDeploymentTask.java:262)
at 
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:475)
at 

[jira] [Created] (IGNITE-12860) .NET NullReferenceException when serializing fields of the same type in different order

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12860:
-

 Summary: .NET NullReferenceException when serializing fields of 
the same type in different order
 Key: IGNITE-12860
 URL: https://issues.apache.org/jira/browse/IGNITE-12860
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Pavel Tupitsyn


.NET NullReferenceException when serializing fields of the same type in 
different order

+*Steps to reproduce*+:
 * Implement IBinarizable for a type having multiple fields and randomly select 
subset of the fields in the  IBinarizable.WriteBinary implementation
 * Serialize the type multiple times

+*Actual result*+:

Eventual NullReferenceException at some iteration of serialization:

{{Object reference not set to an instance of an object.  }}{{at 
Apache.Ignite.Core.Impl.Binary.Structure.BinaryStructure.GetFieldId(String 
fieldName, Byte fieldType, Int32& pathIdx, Int32 actionIdx)}}{{   at 
Apache.Ignite.Core.Impl.Binary.Structure.BinaryStructureTracker.GetFieldId(String
 fieldName, Byte fieldTypeId)}}{{   at 
Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteFieldId(String fieldName, Byte 
fieldTypeId)}}{{   at 
Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteInt(String fieldName, Int32 
val)}}{{   at 
Sbt.Cashflow.Grid.Ignite.Serialization.<>c.<.cctor>b__8_26(IBinaryWriter w, 
String k, Object v) in 
d:\Repos\Sbt.CMS.Cashflow\sbt.cashflow.grid.subrepo\Sbt.Cashflow.Grid\Sbt.Cashflow.Grid\Ignite\Serialization.cs:line
 231}}{{   at Sbt.Cashflow.Grid.Ignite.Serialization.Write(IBinaryWriter 
writer, Type type, String name, Object val) in 
d:\Repos\Sbt.CMS.Cashflow\sbt.cashflow.grid.subrepo\Sbt.Cashflow.Grid\Sbt.Cashflow.Grid\Ignite\Serialization.cs:line
 51}}{{   at 
Sbt.CMS.Infrastructure.Ignite.Objects.CacheItem.WriteBinary(IBinaryWriter 
writer) in 
d:\Repos\Sbt.CMS.Cashflow\sbt.cms.subrepo\Sbt.CMS.Infrastructure\Ignite\Objects\CacheItem.cs:line
 162}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12829:
-

 Summary: Custom GROUP_CONCAT separator is ignored
 Key: IGNITE-12829
 URL: https://issues.apache.org/jira/browse/IGNITE-12829
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


According to [https://apacheignite-sql.readme.io/docs/group_concat] 
GROUP_CONCAT supports user-defined separator. Actually it is not supported.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12828) Intermittent "Failed to notify direct custom event listener" exception on node shutdown

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12828:
-

 Summary: Intermittent "Failed to notify direct custom event 
listener" exception on node shutdown
 Key: IGNITE-12828
 URL: https://issues.apache.org/jira/browse/IGNITE-12828
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


+*Reproducer*+:

Run a server node

Run a client node that:
 * Creates cache "cache1"
 * Deploys a grid service that starts a continuous query against "cache1" in 
method init()
 * Leaves the cluster

+*Actual result*+

Intermittent exception in the client node:

[16:54:38,758][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager]
 Failed to notify direct custom event listener: StartRoutineDiscoveryMessage 
[startReqData=StartRequestData 
[prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@63ae71a9,
 clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler 
[returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@594bf5b8,
 cacheName=CALC_REQUESTS, rmtFilter=null, rmtFilterDep=null, internal=false, 
notifyExisting=false, oldValRequired=true, sync=false, ignoreExpired=true, 
taskHash=0, skipPrimaryCheck=false, locOnly=false, keepBinary=true, 
ackBuf=null, cacheId=-1608655250, initTopVer=null, nodeLeft=false, 
ignoreClsNotFound=false, nodeId=null, routineId=null], bufSize=1, interval=0, 
autoUnsubscribe=true], keepBinary=true, 
routineId=021dd2ce-3d8a-41c1-a4d0-b625ea1284f4]
java.lang.NullPointerException
 at 
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82)
 at 
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193)
 at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:722)
 at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
 at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2683)
 at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2721)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
 at java.lang.Thread.run(Thread.java:745)
[16:54:39,725][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager]
 Failed to notify direct custom event listener: StartRoutineDiscoveryMessage 
[startReqData=StartRequestData 
[prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@7462c96c,
 clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler 
[returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@6451dd70,
 cacheName=DISTRIBUTED_REQUESTS, rmtFilter=null, rmtFilterDep=null, 
internal=false, notifyExisting=false, oldValRequired=true, sync=false, 
ignoreExpired=true, taskHash=0, skipPrimaryCheck=false, locOnly=false, 
keepBinary=true, ackBuf=null, cacheId=1419803136, initTopVer=null, 
nodeLeft=false, ignoreClsNotFound=false, nodeId=null, routineId=null], 
bufSize=1, interval=0, autoUnsubscribe=true], keepBinary=true, 
routineId=1fca5f04-d220-49ac-850a-0d4527e22eef]
java.lang.NullPointerException
 at 
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82)
 at 
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202)
 at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193)
 at 

[jira] [Created] (IGNITE-12826) Poor JDBC Cache Store performance due to default fetch size

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12826:
-

 Summary: Poor JDBC Cache Store performance due to default fetch 
size
 Key: IGNITE-12826
 URL: https://issues.apache.org/jira/browse/IGNITE-12826
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


JDBC "fetchSize" parameter specifies the number of rows to be fetched from the 
database when additional rows are needed. For most drivers it is 10 by default. 
Larger fetchSize can significantly improve performance due to less network 
roundtrips (at expense of greater memory consumption).

For some reason out-of-box JDBC POJO Cache Store uses default fetchSize in the 
loadCache method implementation. 

We have very poor loadCache performance when loading large amount of data from 
Oracle with the default fetchSize of 10. We tried setting fetchSize to 20K and 
that improved performance 40 times.

We need to use JdbcDialect#fetchSize in the loadCache implementation so that 
users could implement a custom JdbcDialect to configure fetchSIze.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12825) Serialize Java and .NET dates using same calendars

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12825:
-

 Summary: Serialize Java and .NET dates using same calendars
 Key: IGNITE-12825
 URL: https://issues.apache.org/jira/browse/IGNITE-12825
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Java and .NET use different calendars for dates serialization. That results in 
some dates written using Java API deserialized into different dates using .NET 
API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using Java API 
will be read as 31-Dec-1991 1:00:00 MSK using .NET API. 

Java and .NET API must use same calendars for dates serialization.

+*Note:*+

Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored 
locally that could be manually updated using Timezone Updater Tool 
([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html])

.NET uses its own calendars that cannot be manually updated. 

All the Java/.NET calendar differences I saw were 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12824) Change .NET API to write Dates in interoperable format by default

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12824:
-

 Summary: Change .NET API to write Dates in interoperable format by 
default
 Key: IGNITE-12824
 URL: https://issues.apache.org/jira/browse/IGNITE-12824
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.8
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Presently BinaryReflectiveSerializer serialises .NET dates Ignite objects by 
default. This could be changed by either setting 
BinaryReflectiveSerializer.ForceTimestamp property to "true" or adding 
"QuerySqlField" attribute to Date fields. I have multiple Ignite/GridGain users 
using this functionality and all of them are confused with this default 
behavior. Let's see if we can change the default behavior to save .NET dates in 
interoperable Ignite TIMESTAMP format, converting them to UTC dates inside 
BinaryReflectiveSerializer so that the users do not have to do the 
ToUniversalDate conversion manually.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12823) .NET client cannot find service method with user type array parameter

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12823:
-

 Summary: .NET client cannot find service method with user type 
array parameter
 Key: IGNITE-12823
 URL: https://issues.apache.org/jira/browse/IGNITE-12823
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


*+Setup+*
 * Java service with a method having an array of user types as a parameters, 
for example, caclulate(Parameter[] params)

*+Actions+*
 * .NET client calls the GG Java service, for example, 
ignite.GetServices().GetServiceProxy().calculate(new[] \{new 
Parameter()});

*+Expected+*
 * The service method is called

*+Actual+*
 * Exception "Could not find proxy method 'calculate' in class ICalculator"

*+Workaround+*
 * Replace array of user types with array of objects in the service methods 
signatures, for example, caclulate(Object[] params)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12807) Key and Value fields with same name and SQL DML

[Alexey Kukushkin (Jira)]

Alexey Kukushkin created IGNITE-12807:
-

 Summary: Key and Value fields with same name and SQL DML
 Key: IGNITE-12807
 URL: https://issues.apache.org/jira/browse/IGNITE-12807
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Key/Value API allows both the Key and Value have fields with same name. This is 
a very popular arrangement since most users are ready to sacrifice extra memory 
footprint for the sake of having a self-sufficient value entity.

Using SQL DML to update such an entry will update only the key field, leaving 
the value field unchanged. This is a huge usability issue for the mixed K/V and 
SQL API apps.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-10874) JDBC thin driver metadata misses caches with queryEntities and names containing underscores

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10874:
-

 Summary: JDBC thin driver metadata misses caches with 
queryEntities and names containing underscores
 Key: IGNITE-10874
 URL: https://issues.apache.org/jira/browse/IGNITE-10874
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Affects Versions: 2.7
Reporter: Alexey Kukushkin


+*Steps to reproduce*+

1) Build and run this app:

 
{code:java}
public class App {
public static void main(String[] ags) {
try (Ignite ignite = Ignition.start(
new IgniteConfiguration()
.setDiscoverySpi(
new TcpDiscoverySpi()
.setIpFinder(
new 
TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500"))
)
)
)) {
final String NAME = "V_MODELS_SHORT";

ignite.getOrCreateCache(
new CacheConfiguration<>()
.setName(NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setQueryEntities(Collections.singleton(
new QueryEntity()
.setKeyType(Integer.class.getTypeName())
.setValueType(NAME)
.setKeyFieldName("VMS_ID")
.setFields(
Stream.of(
new AbstractMap.SimpleEntry<>("VMS_ID", 
Integer.class.getTypeName()),
new 
AbstractMap.SimpleEntry<>("VMS_HASVERSION", Boolean.class.getTypeName())
).collect(Collectors.toMap(
AbstractMap.SimpleEntry::getKey,
AbstractMap.SimpleEntry::getValue,
(u, v) -> {
throw new 
IllegalStateException(String.format("Duplicate key %s", u));
},
LinkedHashMap::new
))
)
))
);

System.in.read();
}
}
}
{code}
2) While the app is running use a JDBC database management tool like DBeaver to 
open a JDBC thin driver connection to Ignite.

3) Check table "V_MODELS_SHORT" under schema "V_MODELS_SHORT"

+*Expected*+

3) Table "V_MODELS_SHORT" is visible under  schema "V_MODELS_SHORT"

+*Actual*+

 

3) There is no table "V_MODELS_SHORT" under  schema "V_MODELS_SHORT"

+*Notes*+

You still can run queries on table V_MODELS_SHORT in DBeaver. For example, 
these queries work fine:
{code:java}
INSERT INTO V_MODELS_SHORT.V_MODELS_SHORT VALUES (1, 'false');

SELECT * FROM V_MODELS_SHORT.V_MODELS_SHORT;
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10430) Ignite.NET Data Region Metrics: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10430:
-

 Summary: Ignite.NET Data Region Metrics: PagesRead, PagesWritten, 
PagesReplaced, OffHeapSize, OffheapUsedSize
 Key: IGNITE-10430
 URL: https://issues.apache.org/jira/browse/IGNITE-10430
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Add Ignite.NET Data Region Metrics presently existing in Java but missing in 
.NET: PagesRead, PagesWritten, PagesReplaced, OffHeapSize, OffheapUsedSize



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10100) No public Java API to call Ignite.NET service

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10100:
-

 Summary: No public Java API to call Ignite.NET service
 Key: IGNITE-10100
 URL: https://issues.apache.org/jira/browse/IGNITE-10100
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.6
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Ignite wraps .NET services in PlatformDotNetServiceImpl implementing 
PlatformService interface.

To call a .NET service from a Java client I have to use invokeMethod API 
defined in PlatformService interface. 

The problem is for some reason PlatformService is defined in internal Ignite 
package apache.ignite.internal.processors.platform.services. This API must be 
public.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10075) Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10075:
-

 Summary: Avoid binary configurations of Ignite Java service params 
and result when calling it from Ignite.NET
 Key: IGNITE-10075
 URL: https://issues.apache.org/jira/browse/IGNITE-10075
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.6
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Presently if there is an Ignite Java service taking parameters of complex 
(composite) types and returning a result of complex type then all the complex 
types must be explicitly specified in the binary configuration.

We need to enhance Ignite not to require binary configuration assuming that we 
use the same type, package/namespace and field/property names on both the .NET 
and Java sides (or provide a custom name mapper for relaxed naming conventions).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10074) Structured Exception information is lost when Ignite .NET client calls Ignite Java service

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10074:
-

 Summary: Structured Exception information is lost when Ignite .NET 
client calls Ignite Java service
 Key: IGNITE-10074
 URL: https://issues.apache.org/jira/browse/IGNITE-10074
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.6
Reporter: Alexey Kukushkin


Suppose an Ignite service in Java throws *new 
ModelVerificationException(“ERROR!”)* to signal about a failure.

An Ignite.NET client of such a Java service would receive this exception:

Apache.Ignite.Core.Services.ServiceInvocationException
 * *Message*: Proxy method invocation failed with an exception. Examine 
InnerException for details.
 * *InnerException*: Apache.Ignite.Core.Common.IgniteException

o   *Message*: ERROR!

o   *InnerException*: Apache.Ignite.Core.Common.JavaException
 * *JavaClassName*: class org.apache.ignite.IgniteCheckedException
 * *JavaMessage*: ERROR!
 * *InnerException*: null
 * *Message*: class org.apache.ignite.IgniteCheckedException: ERROR!
   at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332)
   at 
org.apache.ignite.internal.processors.platform.services.PlatformServices$ServiceProxyHolder.invoke(PlatformServices.java:589)
   at 
org.apache.ignite.internal.processors.platform.services.PlatformServices.processInObjectStreamOutObjectStream(PlatformServices.java:289)
   at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inObjectStreamOutObjectStream(PlatformTargetProxyImpl.java:172)
Caused by: ModelVerificationException: ERROR!
   at ... 

Ignite service wraps the custom ModelVerificationException in a 
IgniteCheckedException, which we get information for on the client side. There 
is no structured information about the custom exception in the client.

We need to have information about the custom exception on the client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10073) Ignite NuGet package without embedded Ignite JARs

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10073:
-

 Summary: Ignite NuGet package without embedded Ignite JARs
 Key: IGNITE-10073
 URL: https://issues.apache.org/jira/browse/IGNITE-10073
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.6
Reporter: Alexey Kukushkin


The existing Apache.Ignite NuGet package includes Ignite JARs deployed into the 
"libs" directory in the .NET project output directory upon the package 
installation.

We prefer using external Ignite JARs from $IGNITE_HOME/libs instead of the JARs 
in the local libs directory.

Right now we have to manually remove local "libs" directory after every 
Apache.Ignite package installation or upgrade.

It would help us having another Ignite NuGet package without the embedded 
Ignite JARs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10072) Apache.Ignite NuGet package removes existing post-build actions

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-10072:
-

 Summary: Apache.Ignite NuGet package removes existing post-build 
actions
 Key: IGNITE-10072
 URL: https://issues.apache.org/jira/browse/IGNITE-10072
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.6
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Setup:
 # A *.csproj file with any one ore more post-build actions specified opened in 
Visual Studio

Steps to reproduce:
 # In Visual Studio -> Package Manager Console run "Install-Package 
Apache.Ignite"
 # Open the csproj file in a test editor and check the post-build actions 

Expected:
 # Package Apache.Ignite installed OK
 # The initial post-build actions are still in the csproj file

Actual:
 # As expected
 # The initial post-build actions are gone



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9454) SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-9454:


 Summary: SecurityPermissionSetBuilder fails to append system 
permission CACHE_CREATE
 Key: IGNITE-9454
 URL: https://issues.apache.org/jira/browse/IGNITE-9454
 Project: Ignite
  Issue Type: Bug
  Components: security
Affects Versions: 2.5
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE, 
CACHE_DESTROY and JOIN_AS_SERVER

+*Reproducer*+:

SecurityPermissionSetBuilder.create().appendSystemPermission(SecurityPermission.CACHE_CREATE)

The code above throw IgniteException saying that a security permission name 
should begin with either EVENTS_ or ADMIN_

*+Solution+:*

Update SecurityPermissionSetBuilder to:
 # allow system permissions CACHE_CREATE, CACHE_DESTROY and JOIN_AS_SERVER
 # restrict cache presmissions CACHE_CREATE, CACHE_DESTROY
 # add automated tests

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9357) Spark Structured Streaming with Ignite as data source and sink

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-9357:


 Summary: Spark Structured Streaming with Ignite as data source and 
sink
 Key: IGNITE-9357
 URL: https://issues.apache.org/jira/browse/IGNITE-9357
 Project: Ignite
  Issue Type: New Feature
  Components: spark
Affects Versions: 2.7
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


We are working on a PoC where we want to use Ignite as a data storage and Spark 
as a computation engine. We found that Ignite is not supported neither as a 
source nor as a Sink when using Spark Structured Streaming, which is a must for 
us.

We are enhancing Ignite to support Spark streaming with Ignite. We will send 
docs and code for review for the Ignite Community to consider if the Community 
want to accept this feature. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-9204:


 Summary: Test 
org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
 Key: IGNITE-9204
 URL: https://issues.apache.org/jira/browse/IGNITE-9204
 Project: Ignite
  Issue Type: Test
  Components: thin client
Affects Versions: 2.6
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
 Fix For: 2.7


According to [Apache Ignite Team 
City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
 test org.apache.ignite.client.ReliabilityTest@testFailover fails 
intermittently with this message:

 
{noformat}
java.lang.AssertionError: Ignite cluster is unavailable expected null, but 
was: at 
org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
 at 
org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88) 
* Text was not loaded fully because its' size exceeds 2 MB, see full log 
for the whole text *
{noformat}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9197) Java thin client querying empty table results in NoSuchElementException

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-9197:


 Summary: Java thin client querying empty table results in 
NoSuchElementException
 Key: IGNITE-9197
 URL: https://issues.apache.org/jira/browse/IGNITE-9197
 Project: Ignite
  Issue Type: Bug
  Components: thin client
Affects Versions: 2.6
 Environment: +*Reproducer*+
{code:java}
@Test
public void testGettingEmptyResultWhenQueryingEmptyTable() throws Exception {
try (Ignite ignored = Ignition.start(Config.getServerConfiguration());
 IgniteClient client = Ignition.startClient(new 
ClientConfiguration().setAddresses(Config.SERVER))
) {
final String TBL = "Person";

client.query(
new SqlFieldsQuery("CREATE TABLE IF NOT EXISTS " + TBL + " (id INT 
PRIMARY KEY, name VARCHAR)")
).getAll();

List> res = client.query(new SqlFieldsQuery("SELECT * FROM " + 
TBL)).getAll();

assertNotNull(res);
assertEquals(0, res.size());
}
}

{code}
*Expected*

The test above should pass

*Actual*

java.util.NoSuchElementException
 at java.util.ArrayList$Itr.next(ArrayList.java:862)
 at 
org.apache.ignite.internal.client.thin.ClientQueryCursor$1.next(ClientQueryCursor.java:87)
 at 
org.apache.ignite.internal.client.thin.ClientQueryCursor.getAll(ClientQueryCursor.java:45)
 at 
org.apache.ignite.client.FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable(FunctionalQueryTest.java:171)
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
 Fix For: 2.7


+*Reproducer*+

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8237) Ignite blocks on SecurityException in exchange-worker due to unauthorised off-heap cache configuration

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8237:


 Summary: Ignite blocks on SecurityException in exchange-worker due 
to unauthorised off-heap cache configuration 
 Key: IGNITE-8237
 URL: https://issues.apache.org/jira/browse/IGNITE-8237
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Ignite blocks on SecurityException in exchange-worker due to unauthorised 
off-heap cache configuration. Consider moving IGNITE_DISABLE_OFFHEAP_CACHE 
system property check to a more appropriate place to avoid blocking Ignite.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8221) Cache management and server node authorisation

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8221:


 Summary: Cache management and server node authorisation
 Key: IGNITE-8221
 URL: https://issues.apache.org/jira/browse/IGNITE-8221
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Kukushkin
Assignee: Vladimir Ozerov


Add new authorisation checks requested by multiple Apache Ignite users:

CACHE_CREATE

CACHE_DESTROY

JOIN_AS_SERVER

Also, create an Ignite system property to allow disabling "on-heap" cache 
feature. 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8135) Missing SQL-DDL Authorization

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8135:


 Summary: Missing SQL-DDL Authorization
 Key: IGNITE-8135
 URL: https://issues.apache.org/jira/browse/IGNITE-8135
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.5
Reporter: Alexey Kukushkin


Ignite has infrastructure to support 3-rd party security plugins. To support 
authorization, Ignite has security checks spread all over the code delegating 
actual authorization to a 3rd party security plugins if configured.

In addition to existing checks, Ignite 2.5 will authorise "create" and 
"destroy" cache operations.

The problem is authorization is not implemented for SQL at all - even if 
authorization is enabled, it is currently possible to run any SQL to 
create/drop/alter caches and read/modify/remove the cache data thus bypassing 
security. The problem exists for both DDL (create/drop/alter table) and DML 
(select/merge/insert/delete).

This ticket addresses DDL only: DML will be addressed by a different ticket.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8076) Java Thin Client Authentication

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8076:


 Summary: Java Thin Client Authentication
 Key: IGNITE-8076
 URL: https://issues.apache.org/jira/browse/IGNITE-8076
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


Java thin client was merged into branch 2.4.4. Java thin client supports 
authentication by sending user credentials to server. Implement handling 
authentication on the server side.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8067) Java thin client code review: move parsing from TcpClientCache to ClientMessageParser

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8067:


 Summary: Java thin client code review: move parsing from 
TcpClientCache to ClientMessageParser
 Key: IGNITE-8067
 URL: https://issues.apache.org/jira/browse/IGNITE-8067
 Project: Ignite
  Issue Type: Task
  Components: thin client
Affects Versions: 2.5
Reporter: Alexey Kukushkin


Code review comments 9 and 10 from 
https://issues.apache.org/jira/browse/IGNITE-7421?focusedCommentId=16398310=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16398310
 were left as technical debt due to Java thin client delivery urgency.
This task is to address:

9) {{SerDes}} - configuration serialization/deserialization is already 
implemented({{ClientCacheConfigurationSerializer}}). I think all we need is to 
implement converter from CacheConfiguration to ClientCacheConfiguration and 
vice versa.
10) {{ClientOperation}} and {{TcpClientCache}} - duplicates logic of 
{{ClientMessageParser}}. Let's simply add two new methods to decode response 
and encode request to this class, and remove all lambdas from 
{{TcpClientCache}} - we should not define the same format twice.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7858) "Cannot find cache" error for existing cache on unstable topology

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7858:


 Summary: "Cannot find cache" error for existing cache on unstable 
topology 
 Key: IGNITE-7858
 URL: https://issues.apache.org/jira/browse/IGNITE-7858
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexey Kukushkin


Java thin client high availability test fails with "Cannot find cache" error 
for existing cache.

Reproducer:

git fetch professional
git checkout ignite-7421
Open org.apache.ignite.thinclient.system.ReliabilityTest and search for "TODO: 
fix CACHE_DOES_NOT_EXIST server error". Then remove the try/catch block leaving 
only assertion call.
Run test testFailover



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7623) Thin client Java API - async API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7623:


 Summary: Thin client Java API - async API
 Key: IGNITE-7623
 URL: https://issues.apache.org/jira/browse/IGNITE-7623
 Project: Ignite
  Issue Type: Sub-task
  Components: clients
Reporter: Alexey Kukushkin


Implement Async version of all the client APIs. This is a big task - consider 
splitting it into multiple tasks. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7434) Thin client Java API - cache query API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7434:


 Summary: Thin client Java API - cache query API
 Key: IGNITE-7434
 URL: https://issues.apache.org/jira/browse/IGNITE-7434
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache query thin client Java API including unit 
and system tests and samples.

Cache
        query(qry: Query): QueryCursor
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7435) Thin client Java API - fields query API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7435:


 Summary: Thin client Java API - fields query API
 Key: IGNITE-7435
 URL: https://issues.apache.org/jira/browse/IGNITE-7435
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache fields query thin client Java API 
including unit and system tests and samples.

Cache
         query(qry: SqlFieldsQuery): FieldsQueryCursor
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7433) Thin client Java API - cache clear

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7433:


 Summary: Thin client Java API - cache clear
 Key: IGNITE-7433
 URL: https://issues.apache.org/jira/browse/IGNITE-7433
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache clear thin client Java API including unit 
and system tests and samples.

Cache
        clear()
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7432) Thin client Java API - cache atomic get/put/replace/remove

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7432:


 Summary: Thin client Java API - cache atomic 
get/put/replace/remove 
 Key: IGNITE-7432
 URL: https://issues.apache.org/jira/browse/IGNITE-7432
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache atomic get/put/replace/remove  thin 
client Java API including unit and system tests and samples.

Cache
        getAndPut(key, val): V
        getAndReplace(key, val): V
        getAndRemove(key): V
        putIfAbsent
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7431) Thin client Java API - cache replace/remove API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7431:


 Summary: Thin client Java API - cache replace/remove API
 Key: IGNITE-7431
 URL: https://issues.apache.org/jira/browse/IGNITE-7431
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache replace/remove thin client Java API 
including unit and system tests and samples.

Cache
        replace(key, val)
        replace(key, oldVal, newVal)
        remove(key)
        remove(key, val)
        removeAll()
        removeAll(keys: Set)
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7430) Thin client Java API - cache putAll/getAll

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7430:


 Summary: Thin client Java API - cache putAll/getAll
 Key: IGNITE-7430
 URL: https://issues.apache.org/jira/browse/IGNITE-7430
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache putAll/getAll thin client Java API 
including unit and system tests and samples.

Cache
        getAll(keys: Set): Map
         getAll
 
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7429) Thin client Java API - cache put/get/contains

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7429:


 Summary: Thin client Java API - cache put/get/contains
 Key: IGNITE-7429
 URL: https://issues.apache.org/jira/browse/IGNITE-7429
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement cache put/get/contains thin client Java API 
including unit and system tests and samples.

Cache
       put(key, val)
        get(key): V
        containsKey(key): boolean
 
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7427) Thin client Java API - failover

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7427:


 Summary: Thin client Java API - failover
 Key: IGNITE-7427
 URL: https://issues.apache.org/jira/browse/IGNITE-7427
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement failover in thin client Java API including unit 
and system tests and samples.

ClientConfiguration(failover configuration)
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7426) Thin client Java API - encryption

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7426:


 Summary: Thin client Java API - encryption
 Key: IGNITE-7426
 URL: https://issues.apache.org/jira/browse/IGNITE-7426
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement SSL/TLS configuration client Java API including 
unit and system tests and samples.

ClientConfiguration(ssl configuration)
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7425) Thin client Java API - binary objects

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7425:


 Summary: Thin client Java API - binary objects
 Key: IGNITE-7425
 URL: https://issues.apache.org/jira/browse/IGNITE-7425
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement binary object thin client Java API including 
unit and system tests and samples.

Ignite
    binary(): IgniteBinary
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7424) Thin client Java API - cache enumeration

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7424:


 Summary: Thin client Java API - cache enumeration
 Key: IGNITE-7424
 URL: https://issues.apache.org/jira/browse/IGNITE-7424
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement list caches thin client Java API including unit 
and system tests and samples.

Ignite
    cacheNames(): Collection
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7423) Thin client Java API - cache management

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7423:


 Summary: Thin client Java API - cache management
 Key: IGNITE-7423
 URL: https://issues.apache.org/jira/browse/IGNITE-7423
 Project: Ignite
  Issue Type: Sub-task
 Environment: Implement get/create/destroy cache thin client Java API 
including unit and system tests and samples.

Ignite
    cache(name: String)
    createCache(name): Cache
    getOrCreateCache(name): Cache
    destroyCache(name)
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7422) Thin client Java API - startClient

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7422:


 Summary: Thin client Java API - startClient
 Key: IGNITE-7422
 URL: https://issues.apache.org/jira/browse/IGNITE-7422
 Project: Ignite
  Issue Type: Sub-task
  Components: thin client
Reporter: Alexey Kukushkin


Implement below thin client Java API including unit and system tests and 
samples. BinaryObject, failover and encryption is not part of this task.

Ignition
    startClient(:ClientConfiguration): Ignite
ClientConfiguration(port, host, binaryConfiguration, sslConfiguration,
etc...)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7421) Thin client Java API - data grid API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7421:


 Summary: Thin client Java API - data grid API
 Key: IGNITE-7421
 URL: https://issues.apache.org/jira/browse/IGNITE-7421
 Project: Ignite
  Issue Type: New Feature
  Components: thin client
 Environment: Implement below Java bindings for the thin client 
protocol. The client configuration must support failover and encryption.

Cache
    JCache (limited)
        getName(): String
        put(key, val)
        get(key): V
        getAll(keys: Set): Map
        containsKey(key): boolean
        getAndPut(key, val): V
        getAndReplace(key, val): V
        getAndRemove(key): V
        putIfAbsent
        replace(key, val)
        replace(key, oldVal, newVal)
        putAll
        clear
        remove(key)
        remove(key, val)
        removeAll()
        removeAll(keys: Set)
        getConfiguration(clazz): Configuration
        close()
    size(modes: CachePeekMode...)
    query(qry: Query): QueryCursor
    query(qry: SqlFieldsQuery): FieldsQueryCursor
    withKeepBinary(): IgniteCache
Ignite
    cache(name: String)
    cacheNames(): Collection
    binary(): IgniteBinary
    createCache(name): Cache
    getOrCreateCache(name): Cache
    destroyCache(name)
Ignition
    startClient(:ClientConfiguration): Ignite
ClientConfiguration(port, host, binaryConfiguration, sslConfiguration,
etc...)
Reporter: Alexey Kukushkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7411:


 Summary: JDBC thin client selects NULL cache ID values of entries 
added with Java API
 Key: IGNITE-7411
 URL: https://issues.apache.org/jira/browse/IGNITE-7411
 Project: Ignite
  Issue Type: Bug
  Components: thin client
Affects Versions: 2.3
Reporter: Alexey Kukushkin


I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-TBD.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 ) {
 conn.prepareStatement(
 "CREATE TABLE " + CACHE_NAME + "(" +
 "ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" +
 ") WITH \"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
 ).execute();

IgniteCache, Person> cache = cln.cache("SQL_PUBLIC_" + 
CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] \{1, 2}, new byte[] \{3, 
4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7248) "Schema not found" error when setting streaming mode for JDBC driver

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7248:


 Summary: "Schema not found" error when setting streaming mode for 
JDBC driver
 Key: IGNITE-7248
 URL: https://issues.apache.org/jira/browse/IGNITE-7248
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexey Kukushkin


Using JDBC "thick" driver in streaming mode fails with a "Schema not found" 
erorr:

Connection connection = 
DriverManager.getConnection("jdbc:ignite:cfg://streaming=true:cache=CACHE@file:/path-to-ignite-config.xml");

// using connection to create a table works fine but this exception is 
generated when using the connection to execute INSER INTO...

class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
to set schema for DB connection for thread [schema=]

org.h2.jdbc.JdbcSQLException: Schema  not found; SQL statement:
SET SCHEMA "" [90079-195]

See [link 
UserList|https://mail.google.com/mail/u/0/#label/Apache+Ignite+Users/15f25f4d70ade793]
 for more details




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7215) Documentation bug: "Cross-cache Query" page is dead

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7215:


 Summary: Documentation bug: "Cross-cache Query" page is dead
 Key: IGNITE-7215
 URL: https://issues.apache.org/jira/browse/IGNITE-7215
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.3
Reporter: Alexey Kukushkin


Could not find "Cross-cache Queries" section in the latest Ignite 2.3 docs. The 
only page that references "cross-cache queries" is [JDBC Client 
Driver|https://apacheignite-sql.readme.io/docs#section-jdbc-client-driver] and 
it points to a [dead 
link|https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7065) Cannot use multiple Ignite Kafka Sink Connectors

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7065:


 Summary: Cannot use multiple Ignite Kafka Sink Connectors 
 Key: IGNITE-7065
 URL: https://issues.apache.org/jira/browse/IGNITE-7065
 Project: Ignite
  Issue Type: Bug
  Components: 2.3
Affects Versions: 2.3
Reporter: Alexey Kukushkin
 Fix For: 2.4


Stopping an Ignite Kafka sink connector makes other connectors deployed in the 
same worker unusable. As a result we cannot stream different topics in 
different caches since connector support streaming to single cache only.

See 
http://apache-ignite-users.70518.x6.nabble.com/Issues-with-multiple-kafka-connectors-questions-regarding-ignite-caches-tc18297.html
 for more details. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6889) ignite.queue() returns null when queue configuration is null

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-6889:


 Summary: ignite.queue() returns null when queue configuration is 
null
 Key: IGNITE-6889
 URL: https://issues.apache.org/jira/browse/IGNITE-6889
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.3, 2.2
Reporter: Alexey Kukushkin


ignite.queue() returns null when queue configuration is null.

Reproducer: assertTrue(ignite.queue("a_queue", 1000, null) != null)

We should either allow specifying null as a queue configuration (meaning 
default configuration) or raise an IllegalArgumentException if collection 
configuration is null



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6879) Support Spring 2.0

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-6879:


 Summary: Support Spring 2.0
 Key: IGNITE-6879
 URL: https://issues.apache.org/jira/browse/IGNITE-6879
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
  Components: spring
Affects Versions: 2.3
Reporter: Alexey Kukushkin


Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
with Spring 2.0. Trying to change the Spring dependency version to 
2.0.0.release results in compile errors like below and requires regression in 
general. 
This improvement was created to either migrate from Spring 1.1 to 2.0 or create 
another set of modules ignite-spring-xxx-2 to have backward compatibility with 
Spring 1.1.

[ERROR] 
/Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
 name clash: deleteAll(java.lang.Iterable) in 
org.apache.ignite.springdata.repository.IgniteRepository and 
deleteAll(java.lang.Iterable) in 
org.springframework.data.repository.CrudRepository have the same erasure, yet 
neither overrides the other




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6802) NullPointerException when WAL store and WAL archive paths are same

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-6802:


 Summary: NullPointerException when WAL store and WAL archive paths 
are same 
 Key: IGNITE-6802
 URL: https://issues.apache.org/jira/browse/IGNITE-6802
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Alexey Kukushkin
 Fix For: 2.4


Configuring WAL store and WAL archive paths to be the same results in 
NullPointerException. We should display a meaningful error about the 
misconfiguration instead.

See 
http://apache-ignite-users.70518.x6.nabble.com/NullPointerException-in-FileWriteAheadLogManager-java-1313-tc17860.html
The thread includes the reproducer code and stack trace. I was able to 
reproduce the issue with today's (31-Oct-2017) Apache master.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6801) Ignite Kafka Connector certification with Confluent

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-6801:


 Summary: Ignite Kafka Connector certification with Confluent
 Key: IGNITE-6801
 URL: https://issues.apache.org/jira/browse/IGNITE-6801
 Project: Ignite
  Issue Type: Improvement
  Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
 Environment: 

Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin
 Fix For: 2.4


Certifying Ignite Kafka connector with Confluent will give Ignite Community 
benefits like:
* TBD (I will put the benefits here after I confirm them)

A certified connector must be coded according to [these 
requirements](https://www.confluent.io/wp-content/uploads/Partner-Dev-Guide-for-Kafka-Connect.pdf),
 reviewed and approved by Confluent.
The existing ignite-kafka module does not comply with the requirements.

The purpose of this task to develop a certified version of the connector.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5966) IgniteCache#get() fails with "Requesting mapping from grid failed" when deserialising binary object loaded from CacheJdbcPojoStoreFactory

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-5966:


 Summary: IgniteCache#get() fails with "Requesting mapping from 
grid failed" when deserialising binary object loaded from 
CacheJdbcPojoStoreFactory
 Key: IGNITE-5966
 URL: https://issues.apache.org/jira/browse/IGNITE-5966
 Project: Ignite
  Issue Type: Bug
 Environment: Ignite 2.1.4
Reporter: Alexey Kukushkin
Assignee: Alexey Kukushkin


STEPS TO REPRODUCE
1. A running MySQL database with at least one table with an Integer key and 
some data
2. Use WebConsole to automatically generate an Ignite project from the RDBMS. 
In the WebConsole add a cache for the table containing data
3. Build the project
4. Start the cluster (run ServerNodeSpringStartup)
5. Load the data (run LoadCaches)
6. Run simple "get data" code against the running cluster with the data loaded. 
Make sure you do NOT keep binary and do NOT put anything to the cache except 
loading data on step #5. For example, if the cache is "AircraftCache", the type 
is "Aircraft" and a row with ID 1 exists in the DB, then:
IgniteCache aircraftCache = 
ignite.getOrCreateCache("AircraftCache");
System.out.format("1->%s\n", aircraftCache.get(1));
EXPECTED:
1...5: Project is generated, cluster runs, data is loaded
6: The entry with ID 1 is output to the console
ACTUAL:"
1..5: As expected
6: javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
Requesting mapping from grid failed for [platformId=0, typeId=-1267085398]
ANALYSIS
The “typeId -> MappedName” mappings are stored in the 
MarshallerContextImpl$allCaches[platformId] map.
My understanding is according to the existing implementations it is expected 
the mapping will always be registered when BinaryContext#descriptorForClass() 
-> MarshallerContextImpl#registerClassName(typeId) is called either from 
BinaryWriterExImpl or BinaryReaderExImpl.
However, that mechanism is never called when 
CacheJdbcPojoStore@buildBinaryObject builds the object, calling 
BinaryObjectBuilderImpl#build(). The latter method still requests 
BinaryContext#updateMetadata, which updates 
CacheObjectBinaryProcessorImpl#metadataFileStore on all server nodes. But the 
metadataFileStore is not the place where MarshallerContextImpl get mappings 
from.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)