[jira] [Created] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
Alexandr Shapkin created IGNITE-14324: - Summary: EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s Key: IGNITE-14324 URL: https://issues.apache.org/jira/browse/IGNITE-14324 Project: Ignite Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.11 Scenario: Kubernetes world, a server node, a k8s service, and a thick client. The client is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected to the server node. When a service goes down alongside the server, no EVT_CLIENT_NODE_DISCONNECTED is caught and the client reports only about a socket exception and inability to resolve IP addresses from the services, cause k8s resource is not available. The DEBUG logs (attached) show that discovery is constantly trying to use KubernetesIpFinder and restore the connection. Expected: Discovery realizes that a client is disconnected, no more reconnection attempts happen and EVT_CLIENT_NODE_DISCONNECTED is thrown. Solution: Count resolution attempts and if it’s more than the threshold (2 if failuredetectiontimeout is not configured, otherwise #reconnCount) give up and invoke disconnection logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13822) NPE in SQL query [with xxx as (select xxx)]
Alexandr Shapkin created IGNITE-13822:
-
Summary: NPE in SQL query [with xxx as (select xxx)]
Key: IGNITE-13822
URL: https://issues.apache.org/jira/browse/IGNITE-13822
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.9
Reporter: Alexandr Shapkin
We use '*with xxx as (select xxx)* ', which works very fine in 2.8.1 and other
past release versions. After we upgrade to 2.9.0, such SQL starts to throw an
exception.
Note, the SQL works fine while Ignite just started. The error happens after
Ignite runs a while. And after that, the error seems to happen every time.
{code:java}
args=Object[] [], stmtType=SELECT_STATEMENT_TYPE, autoCommit=true,
partResReq=false, super=JdbcRequest [type=2, reqId=790418]]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
to parse query. General error: "java.lang.NullPointerException" [5-197]
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:194)
at
org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:355)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:222)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1071)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2779)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2775)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3338)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$2(GridQueryProcessor.java:2795)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2833)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2769)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2727)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:647)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:320)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:202)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:56)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException" [5-197]
at
org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at
org.h2.message.DbException.toSQLException(DbException.java:280)
at org.h2.message.TraceObject.logAndConvert(TraceObject.java:357)
at
org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:697)
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
... 26 more
Caused by: java.lang.NullPointerException
at
[jira] [Created] (IGNITE-13453) Docker: Change run.sh to call java directly
Alexandr Shapkin created IGNITE-13453: - Summary: Docker: Change run.sh to call java directly Key: IGNITE-13453 URL: https://issues.apache.org/jira/browse/IGNITE-13453 Project: Ignite Issue Type: Improvement Affects Versions: 2.8.1 Reporter: Alexandr Shapkin Assignee: Ilya Murchenko Fix For: 2.9 ignite.sh is cumbersome in Docker as it creates the hassle with signals not being propagated but adds little value as most of what ignite.sh discovers about the system is known beforehand for our Docker images. Let's replace ignite.sh call with direct java invocation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13160) .NET: wrong affinity key registration with AffinityKeyMapped attribute
Alexandr Shapkin created IGNITE-13160:
-
Summary: .NET: wrong affinity key registration with
AffinityKeyMapped attribute
Key: IGNITE-13160
URL: https://issues.apache.org/jira/browse/IGNITE-13160
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Alexandr Shapkin
When QueryEntities is set alongside a custom key that utilizes the
AffinityKeyMapped attribute, the field won't be taken into account for some
reason. When QueryEntities configuration gets removed, all works fine, setting
KeyConfiguration manually helps as well. At the same time, the BinaryType
registration itself looks fine.
After the investigation, it turned out that affinityKey field is not being
registered on cache registration, and null is being cached instead. Later on
Ignite correctly tries to register a custom class as a key, but it's never
being updated internally case the real value is already cached.
Reproducer (add to the AffinityTest.cs):
{code:java}
///
/// Tests AffinityKeyMapped attribute should map to the same partitions
/// for the same field value.
///
[Test]
public void TestCustomAffinity()
{
IIgnite g = Ignition.GetIgnite("grid-0");
var cacheCfg = new CacheConfiguration("mycache")
{
// Without QueryEntities tests passes.
QueryEntities = new List()
{
new QueryEntity(typeof(MyKey), typeof(int))
}
};
g.GetOrCreateCache(cacheCfg);
var key1 = new MyKey {Data = "data1", AffinityKey = 1};
var key2 = new MyKey {Data = "data2", AffinityKey = 1};
ICacheAffinity aff = g.GetAffinity(cacheCfg.Name);
Assert.AreEqual(aff.GetPartition(key1), aff.GetPartition(key2));
}
public class MyKey
{
[QuerySqlField]
public string Data { get; set; }
[AffinityKeyMapped]
public long AffinityKey { get; set; }
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12385) .NET Thin Client: introduce ClusterGroup API
Alexandr Shapkin created IGNITE-12385: - Summary: .NET Thin Client: introduce ClusterGroup API Key: IGNITE-12385 URL: https://issues.apache.org/jira/browse/IGNITE-12385 Project: Ignite Issue Type: New Feature Components: thin client Affects Versions: 2.7.6 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.9 We need to implement IClusterGroup API for thin clients. Let's start with following methods: * IClusterGroup.ForDotNet() * IClusterGroup.ForAttributes() * IClusterGroup.GetNodes() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12381) QueryParser: propagate H2 ErrorCode to IgniteSQLException
Alexandr Shapkin created IGNITE-12381: - Summary: QueryParser: propagate H2 ErrorCode to IgniteSQLException Key: IGNITE-12381 URL: https://issues.apache.org/jira/browse/IGNITE-12381 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.7.6 Reporter: Alexandr Shapkin QueryParser#parseH2 method generalizes all h2 error codes as IgniteQueryErrorCode.PARSING Whereas the actual error code could be more specific, like [TABLE_OR_VIEW_NOT_FOUND_1|https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html#c42102] = 42102 Let's try to convert those codes into the appropriate IgniteQueryErrorCode values as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12293) .NET thin client: config serialization should use OpCodes
Alexandr Shapkin created IGNITE-12293: - Summary: .NET thin client: config serialization should use OpCodes Key: IGNITE-12293 URL: https://issues.apache.org/jira/browse/IGNITE-12293 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.7.6 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.9 Thin client configuration could be partially serialized via ClientCacheConfigurationSerializer.java But this #OpCode based serialization is limited only to .NET -> Java direction. Let's use OpCodes as a default implementation for all supported platforms, this will help us to add a new configuration section only for a specific platform. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12177) CPP: Add Java compute support
Alexandr Shapkin created IGNITE-12177: - Summary: CPP: Add Java compute support Key: IGNITE-12177 URL: https://issues.apache.org/jira/browse/IGNITE-12177 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7.5 Reporter: Alexandr Shapkin Currently compute.h contains only platform-specific API declaration (C++). But Ignite does allow a native Java task execution. This feature already has been implemented for .NET platform. Lets port the same changes to C++ client (use PlatformCompute#OP_EXEC_NATIVE). This would help us to create a workaround for a mixed platform cluster that requires a compute calls. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12163) CacheEntryEventType.Removed is not being rised
Alexandr Shapkin created IGNITE-12163: - Summary: CacheEntryEventType.Removed is not being rised Key: IGNITE-12163 URL: https://issues.apache.org/jira/browse/IGNITE-12163 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.7.5 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Steps to reproduce: * Create a cache with user-defined type * Add an ICacheEntryEventListener in order to be notified of CacheEntryEventType.Removed events * Put a value in the cache * Remove that value Expected: CacheEntryEventType.Removed event get captured Actual: CacheEntryEventType.Updated event get captured Update: After these changes https://issues.apache.org/jira/browse/IGNITE-8714 New logic of detecting events (ContinuousQueryUtils.cs) now relies on the Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-11999) .NET unable to specify JvmDllPath for standalone node
Alexandr Shapkin created IGNITE-11999: - Summary: .NET unable to specify JvmDllPath for standalone node Key: IGNITE-11999 URL: https://issues.apache.org/jira/browse/IGNITE-11999 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.7.5 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.8 We have a -JvmDllPath CLI parameter/Ignite.JvmDllPath xml config for standalone nodes, that should take care about JVM dll location configuration. This parameter won't work since Apache.Ignite.Config.Configurator expects another one: /** Command line argument: Path to JVM dll. */ private const string CmdJvmDll = "JvmDll"; -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11984) .NET CompiledQuery won't work with strings
Alexandr Shapkin created IGNITE-11984: - Summary: .NET CompiledQuery won't work with strings Key: IGNITE-11984 URL: https://issues.apache.org/jira/browse/IGNITE-11984 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7.5 Reporter: Alexandr Shapkin Consider two samples: var cache = GetClientCache(); var persons = cache.AsCacheQueryable(); This works: var qry = CompiledQuery.Compile((int id) => persons.Where(x => x.Value.Id == id)); This won't: var qry = CompiledQuery.Compile((string id) => persons.Where(x => x.Value.Name.Equals(id))); Error compiling query: entire LINQ expression should be specified within lambda passed to Compile method. Reason: GetCompiledQuery method -> var paramValues becomes null Because of that CacheQueryExpressionVisitor -> VisitConstant will not be executed -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11895) .NET Resharper inspections got broken after update
Alexandr Shapkin created IGNITE-11895: - Summary: .NET Resharper inspections got broken after update Key: IGNITE-11895 URL: https://issues.apache.org/jira/browse/IGNITE-11895 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Resharper Inspection add new violation after migration from 2018.1.4 to version 2019.1 Lets suppress this new warning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11893) .NET enum platform compatibility
Alexandr Shapkin created IGNITE-11893: - Summary: .NET enum platform compatibility Key: IGNITE-11893 URL: https://issues.apache.org/jira/browse/IGNITE-11893 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.7 Reporter: Alexandr Shapkin Let's make some warnings about platform compatibility. [https://apacheignite-net.readme.io/docs/platform-interoperability] We have a writeEnum/readEnum methods. In java writeEnum can write only ordinal value, but in .NET we can assign any number to the enumValue. So any custom enum-to-primitive value binding would not be taken into account. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11805) .NET runnable core executable
Alexandr Shapkin created IGNITE-11805: - Summary: .NET runnable core executable Key: IGNITE-11805 URL: https://issues.apache.org/jira/browse/IGNITE-11805 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.8 Let's create a runnable .Net core executable similarly to Apache.Ignite.exe This will helps us to start a server with a single dotnet command. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11709) .NET thin client: introduce ClusterGroup methods
Alexandr Shapkin created IGNITE-11709: - Summary: .NET thin client: introduce ClusterGroup methods Key: IGNITE-11709 URL: https://issues.apache.org/jira/browse/IGNITE-11709 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.8 Let's start implementing IClusterGroup methods for thin client. Desired functionality, according to the regular client * ForAttribute * ForCacheNodes * ForDotNet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11690) .NET: Cache iteration hangs with enabled peerAssemblyLoading
Alexandr Shapkin created IGNITE-11690:
-
Summary: .NET: Cache iteration hangs with enabled
peerAssemblyLoading
Key: IGNITE-11690
URL: https://issues.apache.org/jira/browse/IGNITE-11690
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
Solution to reproduce:
[https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0]
Given:
* 2 server .NET nodes with PeerAssembly = enabled
* Simple custom type cache with a few records
{code:java}
ignite.GetOrCreateCache(new CacheConfiguration(Hotel.Cache, new
QueryEntity(typeof(Guid), typeof(Hotel;
{code}
* 1 Client node that spawn computation task and performs a simple iteration
over cache
{code:java}
class HelloAction : IComputeAction
{
[InstanceResource]
private IIgnite _ignite;
public void Invoke()
{
var hotels = _ignite.GetCache("SomeName").ToList()
}
}
{code}
Problem:
One of the server nodes successfully performs the computation, but the other
getting locked inside the
{code:java}
AssemblyRequestResult ComputeApplySafe(ICompute compute, GetAssemblyFunc func,
AssemblyRequest req)
{code}
When I disable PeerAssembly then all is getting back to normal
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
