[jira] [Created] (IGNITE-8127) .NET: Fix flaky test ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress
Alexey Popov created IGNITE-8127: Summary: .NET: Fix flaky test ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress Key: IGNITE-8127 URL: https://issues.apache.org/jira/browse/IGNITE-8127 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.5 Reporter: Alexey Popov Assignee: Alexey Popov https://ci.ignite.apache.org/viewLog.html?buildId=1173105=buildResultsDiv=IgniteTests24Java8_IgnitePlatformNetLongRunning Test(s) failed. Some tasks should have failed. Expected: True But was: False at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, String message, Object[] args) at Apache.Ignite.Core.Tests.Client.ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress() in c:\BuildAgent\work\bd85361428dcdb1\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Client\ClientConnectionTest.cs:line 277 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8108) .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup
Alexey Popov created IGNITE-8108: Summary: .NET: Fix flaky EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup Key: IGNITE-8108 URL: https://issues.apache.org/jira/browse/IGNITE-8108 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.5 Reporter: Alexey Popov Assignee: Alexey Popov https://ci.ignite.apache.org/viewLog.html?buildId=1171195=IgniteTests24Java8_IgnitePlatformNetIntegrations=buildLog&_focus=6035 Test uses multicast ipFinder. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts
Hi Yakov, Do the proposed changes look good to you? Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.
Alexey Popov created IGNITE-7889:
Summary: .NET: linq GroupBy and Where does not work together.
Key: IGNITE-7889
URL: https://issues.apache.org/jira/browse/IGNITE-7889
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.1
Reporter: Alexey Popov
Assignee: Alexey Popov
The following code completely ignores the Where condition:
{noformat}
var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 &&
m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
.Select(g => new KeyValuePair<string, int>(g.Key,
g.Select(m => m.Value.Version).Min()));
{noformat}
debugger shows SQL without WHERE:
{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery
[Sql=select _T0.CONTRACTID, min (_T0.VERSION) from "someCache".MODEL as _T0
group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024,
EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00,
ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7888) ODBC: Add support for SQL_ATTR_LOGIN_TIMEOUT
Alexey Popov created IGNITE-7888: Summary: ODBC: Add support for SQL_ATTR_LOGIN_TIMEOUT Key: IGNITE-7888 URL: https://issues.apache.org/jira/browse/IGNITE-7888 Project: Ignite Issue Type: Improvement Components: odbc Affects Versions: 2.1 Reporter: Alexey Popov Assignee: Igor Sapego Fix For: 2.5 It would be great if we can support SQL_ATTR_LOGIN_TIMEOUT even without login/password connection parameter. Now we have some default timeout for initial ODBC connection establishment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts
Yakov, 1. The proposal list of parameters to deprecate: TcpDiscoverySpi.setConnectTimeout (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpDiscoverySpi.setReconnectCount (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpDiscoverySpi.setSocketTimeout (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpDiscoverySpi.setAckTimeout (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpDiscoverySpi.setMaxAckTimeout (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpDiscoverySpi.setNetworkTimeout (IgniteConfiguration.setNetworkTimeout should be used here) TcpCommunicationSpi.setConnectTimeout (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpCommunicationSpi.setMaxConnectTimeout (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpCommunicationSpi.setReconnectCount (covered by IgniteConfiguration.setFailureDetectionTimeout) TcpCommunicationSpi.setSocketWriteTimeout (IgniteConfiguration.setNetworkTimeout should be used here) 2. Internal logic should continue to use IgniteConfiguration.setFailureDetectionTimeout and IgniteConfiguration.setNetworkTimeout as it is now. The deprecated parameters should be alive for a while with the corresponding javadoc update. TcpDiscoverySpi.getNetworkTimeout should use IgniteConfiguration.getNetworkTimeout by default. TcpCommunicationSpi.getSocketWriteTimeout should use IgniteConfiguration.getNetworkTimeout by default. In a few releases, the deprecated parameters could be removed. 3. I think we can keep the existent description of the parameters. Probably, it could be updated for more clear statements for IgniteConfiguration.setFailureDetectionTimeout and IgniteConfiguration.setNetworkTimeout. Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts
Hi Igniters, We often see similar questions from users and customers related to IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations. And we see several side-effects after incorrect timeout configuration. I tried to briefly describe these timeout settings (please see below) and found out that the most of them do not have sense in terms of cluster functions/operations and could not be explained to the users. I propose to deprecate most of them and leave only the timeouts we can explain in common terms ( (setFailureDetectionTimeout, setNetworkTimeout, setJoinTimeout and some others). Please let me know your thoughts. Thanks, Alexey GLOBAL: IgniteConfiguration.setNetworkTimeout: It is a global timeout for high-level operations where a network is involved. For instance, IgniteMessaging delivery uses this timeout or DiscoverySpi handshake. IgniteConfiguration.setFailureDetectionTimeout: It is a global timeout for detecting failures at IgniteSpi implementations (including DiscoverySpi and CommunicationSpi). The failure detection algorithm actually limits a range of simple network operations related to a single logical operation (for instance, a reliable delivery of some DiscoverySpi message within a cluster). Failure detection timeout is a cumulative timeout for a socket connection, sending and receiving data bytes and all possible socket retries (if some failure happens). This timeout is intended to simplify the failure detection condition from a user perspective. IgniteConfiguration.setClientFailureDetectionTimeout: - it is a special case for DiscoverySpi client-node Ignite. TCP DISCOVERY SPI: If you need more control over failure detection algorithm for TcpDiscoverySpi you can explicitly use the following low-level options (that will disable failureDetectoinTimeout logic): 1. TcpDiscoverySpi.setConnectTimeout - socket connection timeout 2. TcpDiscoverySpi.setReconnectCount - number of reconnect attempts used when establishing connection with the remote node and sending messages to it 3. TcpDiscoverySpi.setSocketTimeout - socket write timeout. The write operation will be repeated getReconnectCount() times if it exceeds this timeout 4. TcpDiscoverySpi.setAckTimeout - message acknowledgment timeout. If a message acknowledgment is not received within this timeout, sending is considered as failed and SPI will try to repeat send operation. It is automatically doubled for simultaneous retries up to getMaxAckTimeout value. 5. TcpDiscoverySpi.setMaxAckTimeout - maximum connection timeout, if the getAckTimeout reaches getMaxAckTimeout then SPI give up sending retries Another important TcpDiscoverySpi timeouts: TcpDiscoverySpi.setJoinTimeout - It is a timeout for join process when a new/restarted node joins a cluster. The node tries to connect to all available IP addresses provided by ipFinder within this timeout. If the timeout is exceeded, the node will give up and throw an exception from Ignition.start(). TcpDiscoverySpi.setNetworkTimeout - timeout for high-level operations like handshake. It looks like it should be deprecated and the IgniteConfiguration.getNetworkTimeout should be used here. TCP COMMUNICATION SPI: If you need more control over failure detection algorithm for TcpCommunicationSpi you can explicitly use the following low-level options (that will disable failureDetectoinTimeout logic): 1. TcpCommunicationSpi.setConnectTimeout - socket connection timeout, will be automatically doubled for simultaneous retries (up to getReconnectCount) related to a single logical operation 2. TcpCommunicationSpi.setMaxConnectTimeout - maximum connection timeout, the higher limit of getReconnectCount-times doubled getConnectTimeout 3. TcpCommunicationSpi.setReconnectCount - number of reconnect attempts used when establishing connection with the remote node and sending messages to it Another important TcpCommunicationSpi timeouts: TcpDiscoverySpi.setSocketWriteTimeout - timeout to send a message. TcpDiscoverySpi.setIdleConnectionTimeout - maximum idle connection timeout upon which a connection will be closed. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-7851) .NET: linq query throws "Hexadecimal string with odd number of characters" exception
Alexey Popov created IGNITE-7851:
Summary: .NET: linq query throws "Hexadecimal string with odd
number of characters" exception
Key: IGNITE-7851
URL: https://issues.apache.org/jira/browse/IGNITE-7851
Project: Ignite
Issue Type: Bug
Components: platforms, sql
Affects Versions: 2.3
Reporter: Alexey Popov
Attachments: FirstOrDefaultKeyIssue.zip
Simple linq query with .Key throws an exception
{code}
var models = cache.AsCacheQueryable();
var entry = models.FirstOrDefault(m => m.Key == @"TST-1/1");
{code}
Apache.Ignite.Core.Common.IgniteException: Hexadecimal string with odd number
of characters: "TST-1/1" [90003-195] --->
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number of
characters: "TST-1/1" [90003-195]
at
org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:519)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1240)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:877)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
Caused by: javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number of
characters: "TST-1/1" [90003-195]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1917)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:368)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1234)
... 2 more
Caused by: class org.apache.ignite.IgniteCheckedException: Hexadecimal string
with odd number of characters: "TST-1/1" [90003-195]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2468)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
... 5 more
Caused by: org.h2.message.DbException: Hexadecimal string with odd number of
characters: "TST-1/1" [90003-195]
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
at org.h2.value.Value.convertTo(Value.java:957)
at
org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:262)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.bindPartitionInfoParameter(IgniteH2Indexing.java:2520)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.calculateQueryPartitions(IgniteH2Indexing.java:2480)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeTwoStepsQuery(IgniteH2Indexing.java:1556)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1500)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
... 6 more
Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of
characters: "TST-1/1" [90003-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
... 19 more
--- End of inner exception stack trace ---
at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* target,
Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte* errMsgChars,
Int32 errMsgCharsLen, SByte* stackTraceChars, Int32 stackTraceCharsLen, Void*
errData, Int32 errDataLen)
at
Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.TargetInStreamOutObject(Void*
ctx, Void* target, Int32 opType, Int64 memPtr)
at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
Action`1 writeAction)
at Apache.Ignite.Core.Impl.Cache.CacheImpl`2.QueryFields[T](SqlFieldsQuery
qry, Func`3 readerFunc)
at
Apache.Ignite.Linq.Impl.CacheField
[jira] [Created] (IGNITE-7824) Rollback part of IGNITE-7170 changes
Alexey Popov created IGNITE-7824: Summary: Rollback part of IGNITE-7170 changes Key: IGNITE-7824 URL: https://issues.apache.org/jira/browse/IGNITE-7824 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.4 Reporter: Alexey Popov Please rollback changes done by mistake: U.quietAndWarn(log, "Nodes started on local machine require more than 20% of physical RAM what can " + back to: U.quietAndWarn(log, "Nodes started on local machine require more than 80% of physical RAM what can " + -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7720) Update ODBC cluster configuration: replace OdbcConfiguration with ClientConnectorConfiguration
Alexey Popov created IGNITE-7720:
Summary: Update ODBC cluster configuration: replace
OdbcConfiguration with ClientConnectorConfiguration
Key: IGNITE-7720
URL: https://issues.apache.org/jira/browse/IGNITE-7720
Project: Ignite
Issue Type: Task
Components: documentation
Affects Versions: 2.3
Reporter: Alexey Popov
https://apacheignite-sql.readme.io/docs/odbc-driver#section-cluster-configuration
Please note that ODBC configuration is depricated. It is better to update this
page with
ClientConnectorConfiguration
BTW, https://apacheignite-sql.readme.io/docs/jdbc-driver is already updated )
/**
* ODBC configuration.
*
* Deprecated as of Apache Ignite 2.1. Please use {@link
ClientConnectorConfiguration} and
* {@link
IgniteConfiguration#setClientConnectorConfiguration(ClientConnectorConfiguration)}
instead.
*/
@Deprecated
public class OdbcConfiguration {
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7705) DIscoverySpi should inherit networkTimeout from IgniteConfiguration
Alexey Popov created IGNITE-7705:
Summary: DIscoverySpi should inherit networkTimeout from
IgniteConfiguration
Key: IGNITE-7705
URL: https://issues.apache.org/jira/browse/IGNITE-7705
Project: Ignite
Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexey Popov
Now we have global network timeout (from IgniteConfiguration) Please see
{{IgniteConfiguration.setNetworkTimeout}}.
And we have a specific {{DiscoverySpi.setNetworkTimeout}}. DiscoverySpi should
use a global network timeout (by default) if {{DiscoverySpi.setNetworkTimeout}}
were not explicitly called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7704) Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations
Alexey Popov created IGNITE-7704: Summary: Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations Key: IGNITE-7704 URL: https://issues.apache.org/jira/browse/IGNITE-7704 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.3 Reporter: Alexey Popov We often see similar questions related to IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations. And we see several side-effects after incorrect timeout configuration. It looks like this question is not well documented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7627) Introduce a new eviction policy to avoid eviction of Index pages
Alexey Popov created IGNITE-7627: Summary: Introduce a new eviction policy to avoid eviction of Index pages Key: IGNITE-7627 URL: https://issues.apache.org/jira/browse/IGNITE-7627 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Alexey Popov It would be great if we can have a new type of eviction policy that does not affect index pages when persistence is on. So, the index pages always will be in-mem and that will improve an overall system performance for random reads with persistence is on. For instance, MongoDB works that way. It always keeps all indexes in-mem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7263) Daemon-mode Ignite node should not open client port (10800)
Alexey Popov created IGNITE-7263: Summary: Daemon-mode Ignite node should not open client port (10800) Key: IGNITE-7263 URL: https://issues.apache.org/jira/browse/IGNITE-7263 Project: Ignite Issue Type: Bug Components: visor Affects Versions: 2.1 Reporter: Alexey Popov Priority: Minor When I run a Visor console with default configuration file it opens a default port (10800) for ODBC driver connection (and for thin JDBC, and for new "thin" client). Then I run several Ignite nodes. So after that, the ODBC driver with default settings goes directly to a Visor (daemon-mode Ignite) and does not able to get any data (daemon-mode Ignite does not keep any data) It is better to avoid such situation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7247) C++: Change default mapper behavior for BinaryConfiguration
Alexey Popov created IGNITE-7247: Summary: C++: Change default mapper behavior for BinaryConfiguration Key: IGNITE-7247 URL: https://issues.apache.org/jira/browse/IGNITE-7247 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.3 Reporter: Alexey Popov C# and Java use the following BinaryConfiguration params by default: *BinaryBasicNameMapper with simpleName property set to false, and *BinaryBasicIdMapper with lowerCase property set to true. while C++ uses the following BinaryConfiguration params by default: *BinaryBasicNameMapper with simpleName property set to *true*, and *BinaryBasicIdMapper with lowerCase property set to true. So, the Java (for instance, a Visor app) can't join C++ nodes by default. Let's have the default configuration properties the same for all platforms. The same issue was changed for .NET under https://issues.apache.org/jira/browse/IGNITE-2398 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7192) JDBC: support FQDN to multiple IPs during connection establishment
Alexey Popov created IGNITE-7192: Summary: JDBC: support FQDN to multiple IPs during connection establishment Key: IGNITE-7192 URL: https://issues.apache.org/jira/browse/IGNITE-7192 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 2.1 Reporter: Alexey Popov Thin JDBC driver may have FQDN (host name) at a connection string. Currently, it resolves this FQDN to one IP and tries to connect to this IP only. It is better to try to connect to multiple IPs one-by-one if DNS returns multiple A-records (FQDN can be resolved to several IPs) until successful connection. It could give a simple fallback option for the JDBC thin driver users. A similar functionality is already implemented in ODBC driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7191) JDBC: set socket buffer to 64k by default
Alexey Popov created IGNITE-7191: Summary: JDBC: set socket buffer to 64k by default Key: IGNITE-7191 URL: https://issues.apache.org/jira/browse/IGNITE-7191 Project: Ignite Issue Type: Improvement Components: jdbc Affects Versions: 2.1 Reporter: Alexey Popov TCP socket buffer size can significantly affect user-visible performance (actually, latency) for SQL queries, especially if Ignite cluster is run at the remote hosts. It is better to have 64k TCP socket buffer size (instead of default 8k) by default to avoid possible delays in TCP transport. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7170) Fix javadoc MemoryConfiguration (20% instead of 80%)
Alexey Popov created IGNITE-7170: Summary: Fix javadoc MemoryConfiguration (20% instead of 80%) Key: IGNITE-7170 URL: https://issues.apache.org/jira/browse/IGNITE-7170 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.3 Reporter: Alexey Popov Assignee: Alexey Popov Priority: Trivial -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
Alexey Popov created IGNITE-7153:
Summary: Redis: BufferUnderflowException at
GridRedisProtocolParser.readBulkStr for values > 8kb
Key: IGNITE-7153
URL: https://issues.apache.org/jira/browse/IGNITE-7153
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.3
Environment: Win, PHP 7, php_redis-3.1.1-7.0
Reporter: Alexey Popov
Exception:
{noformat}
[15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
Failed to process selector key [ses=GridSelectorNioSessionImpl
[worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
[name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
hashCode=396395638, interrupted=false,
runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
inRecovery=null, outRecovery=null, super=GridNioSessionImpl
[locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
sndSchedTime=1512734602674, lastSndTime=1512734602674,
lastRcvTime=1512734602674, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
[jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
accepted=true]]]
java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
[15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
Closing NIO session because of unhandled exception.
class org.apache.ignite.internal.util.nio.GridNioException: null
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
at
org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3
RE: Does the Ignite C# client support distributed queues?
Hi Raymond, You are right, distributed queues require changes at Ignite core. https://issues.apache.org/jira/browse/IGNITE-2701 It was created almost 1 year ago. Please vote for this feature. As far as I know there is no plan/schedule for it. Thank you, Alexey From: Raymond Wilson Sent: Friday, December 1, 2017 5:58 AM To: u...@ignite.apache.org Cc: dev@ignite.apache.org Subject: RE: Does the Ignite C# client support distributed queues? Looking at it I see it's blocked by 2701 (which has additional dependencies, all of which say they are blocked by 2701). I understand there is an intention to bring the C# client up to par with the Java client. Is there a ticket/schedule yet for this? Raymond. -Original Message- From: vkulichenko [mailto:valentin.kuliche...@gmail.com] Sent: Friday, December 1, 2017 1:30 PM To: u...@ignite.apache.org Subject: RE: Does the Ignite C# client support distributed queues? Oops, I read wrong! This is not supported. There is a ticket, but it doesn't seem to be active at the moment: https://issues.apache.org/jira/browse/IGNITE-1417 -Val -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
RE: Ignite Logger & logging file config output
Yes, it is implemented for all Ignite loggers.
However, some loggers (Slf4jLogger) does not have logging file configuration,
so they show less details.
Thank you,
Alexey
From: Nikolai Tikhonov
Sent: Friday, December 1, 2017 5:21 PM
To: dev@ignite.apache.org
Subject: Re: Ignite Logger & logging file config output
Alexey,
Looks cool and helpful! I understand correctly that improvement is
implemented for all type of loggers which Ignite supports?
On Fri, Dec 1, 2017 at 5:18 PM, Alexey Popov <tank2.a...@gmail.com> wrote:
> Hi Denis,
>
> https://issues.apache.org/jira/browse/IGNITE-6971
>
> Sample quite=true output:
>
> [17:16:41]__
> [17:16:41] / _/ ___/ |/ / _/_ __/ __/
> [17:16:41] _/ // (7 7// / / / / _/
> [17:16:41] /___/\___/_/|_/___/ /_/ /___/
> [17:16:41]
> [17:16:41] ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV
> [17:16:41] 2017 Copyright(C) Apache Software Foundation
> [17:16:41]
> [17:16:41] Ignite documentation: http://ignite.apache.org
> [17:16:41]
> [17:16:41] Quiet mode.
> [17:16:41] ^-- Logging to file 'C:\incubator-ignite\work\log\
> ignite-7317b109.log'
> [17:16:41] ^-- Logging by 'Log4JLogger [quiet=true,
> config=/C:/incubator-ignite/config/ignite-log4j.xml]'
> [17:16:41] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
> or "-v" to ignite.{sh|bat}
> [17:16:41]
> [17:16:41] OS: Windows 10 10.0 amd64
> [17:16:41] VM information: Java(TM) SE Runtime Environment 1.8.0_141-b15
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.141-b15
> [17:16:41] Initial heap size is 254MB (should be no less than 512MB, use
> -Xms512m -Xmx512m).
> [17:16:41] Configured plugins:
> [17:16:41] ^-- None
> [17:16:41]
>
> Sample verbose output:
>
> >>>__
> >>> / _/ ___/ |/ / _/_ __/ __/
> >>> _/ // (7 7// / / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/
> >>>
> >>> ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2017 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org
>
> 2017-12-01T17:06:49,403][INFO ][main][IgniteKernal%verboseLogGrid] Config
> URL: n/a
> 2017-12-01T17:06:49,403][INFO ][main][IgniteKernal%verboseLogGrid] Daemon
> mode: off
> 2017-12-01T17:06:49,403][INFO ][main][IgniteKernal%verboseLogGrid] OS:
> Windows 10 10.0 amd64
> 2017-12-01T17:06:49,404][INFO ][main][IgniteKernal%verboseLogGrid] OS
> user: gridgain
> 2017-12-01T17:06:49,408][INFO ][main][IgniteKernal%verboseLogGrid] PID:
> 5984
> 2017-12-01T17:06:49,408][INFO ][main][IgniteKernal%verboseLogGrid]
> Language runtime: Java Platform API Specification ver. 1.8
> 2017-12-01T17:06:49,408][INFO ][main][IgniteKernal%verboseLogGrid] VM
> information: Java(TM) SE Runtime Environment 1.8.0_141-b15 Oracle
> Corporation Java HotSpot(TM) 64-Bit Server VM 25.141-b15
> 2017-12-01T17:06:49,409][INFO ][main][IgniteKernal%verboseLogGrid] VM
> total memory: 3.5GB
> 2017-12-01T17:06:49,409][INFO ][main][IgniteKernal%verboseLogGrid] Remote
> Management [restart: off, REST: off, JMX (remote: off)]
> 2017-12-01T17:06:49,416][INFO ][main][IgniteKernal%verboseLogGrid]
> Logger: Log4J2Logger [quiet=false, config=C:\incubator-ignite\
> modules\core\src\test\config\log4j2-verbose-test.xml]
> 2017-12-01T17:06:49,417][INFO ][main][IgniteKernal%verboseLogGrid]
> IGNITE_HOME=C:\incubator-ignite
> 2017-12-01T17:06:49,417][INFO ][main][IgniteKernal%verboseLogGrid] VM
> arguments: [-ea, -Didea.test.cyclic.buffer.size=1048576,
> -javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition
> 2017.2.5\lib\idea_rt.jar=64660:C:\Program Files\JetBrains\IntelliJ IDEA
> Community Edition 2017.2.5\bin, -Dfile.encoding=UTF-8]
> 2017-12-01T17:06:49,417][INFO ][main][IgniteKernal%verboseLogGrid] System
> cache's DataRegion size is configured to 40 MB. Use
> DataStorageConfiguration.systemCacheMemorySize property to change the
> setting.
> 2017-12-01T17:06:49,427][INFO ][main][IgniteKernal%verboseLogGrid]
> Configured caches [in 'sysMemPlc' dataRegion: ['ignite-sys-cache']]
> 2017-12-01T17:06:49,430][WARN ][pub-#19%verboseLogGrid%][GridDiagnostic]
> This operating system has been tested less rigorously: Windows 10 10.0
> amd64. Our team will appreciate the feedback if you experience any problems
> running ignite in this environment.
> 2017-12-01T17:06:49,436][INFO ][main][IgniteKernal%verboseLogGrid] 3-rd
> party licenses can be found at: C:\incubator-ignite\libs\licenses
>
> Thank you,
> Alexey
>
> From: Denis Magda
> Sent: Tuesday, November 21, 2017 2:01 AM
> To: dev@ignite.apache.org
> Subject: Re: Ignite Logger & logging file config outp
RE: Ignite Logger & logging file config output
Hi Denis,
https://issues.apache.org/jira/browse/IGNITE-6971
Sample quite=true output:
[17:16:41]__
[17:16:41] / _/ ___/ |/ / _/_ __/ __/
[17:16:41] _/ // (7 7// / / / / _/
[17:16:41] /___/\___/_/|_/___/ /_/ /___/
[17:16:41]
[17:16:41] ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV
[17:16:41] 2017 Copyright(C) Apache Software Foundation
[17:16:41]
[17:16:41] Ignite documentation: http://ignite.apache.org
[17:16:41]
[17:16:41] Quiet mode.
[17:16:41] ^-- Logging to file
'C:\incubator-ignite\work\log\ignite-7317b109.log'
[17:16:41] ^-- Logging by 'Log4JLogger [quiet=true,
config=/C:/incubator-ignite/config/ignite-log4j.xml]'
[17:16:41] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
"-v" to ignite.{sh|bat}
[17:16:41]
[17:16:41] OS: Windows 10 10.0 amd64
[17:16:41] VM information: Java(TM) SE Runtime Environment 1.8.0_141-b15 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 25.141-b15
[17:16:41] Initial heap size is 254MB (should be no less than 512MB, use
-Xms512m -Xmx512m).
[17:16:41] Configured plugins:
[17:16:41] ^-- None
[17:16:41]
Sample verbose output:
>>>__
>>> / _/ ___/ |/ / _/_ __/ __/
>>> _/ // (7 7// / / / / _/
>>> /___/\___/_/|_/___/ /_/ /___/
>>>
>>> ver. 2.4.0-SNAPSHOT#19700101-sha1:DEV
>>> 2017 Copyright(C) Apache Software Foundation
>>>
>>> Ignite documentation: http://ignite.apache.org
2017-12-01T17:06:49,403][INFO ][main][IgniteKernal%verboseLogGrid] Config URL:
n/a
2017-12-01T17:06:49,403][INFO ][main][IgniteKernal%verboseLogGrid] Daemon mode:
off
2017-12-01T17:06:49,403][INFO ][main][IgniteKernal%verboseLogGrid] OS: Windows
10 10.0 amd64
2017-12-01T17:06:49,404][INFO ][main][IgniteKernal%verboseLogGrid] OS user:
gridgain
2017-12-01T17:06:49,408][INFO ][main][IgniteKernal%verboseLogGrid] PID: 5984
2017-12-01T17:06:49,408][INFO ][main][IgniteKernal%verboseLogGrid] Language
runtime: Java Platform API Specification ver. 1.8
2017-12-01T17:06:49,408][INFO ][main][IgniteKernal%verboseLogGrid] VM
information: Java(TM) SE Runtime Environment 1.8.0_141-b15 Oracle Corporation
Java HotSpot(TM) 64-Bit Server VM 25.141-b15
2017-12-01T17:06:49,409][INFO ][main][IgniteKernal%verboseLogGrid] VM total
memory: 3.5GB
2017-12-01T17:06:49,409][INFO ][main][IgniteKernal%verboseLogGrid] Remote
Management [restart: off, REST: off, JMX (remote: off)]
2017-12-01T17:06:49,416][INFO ][main][IgniteKernal%verboseLogGrid] Logger:
Log4J2Logger [quiet=false,
config=C:\incubator-ignite\modules\core\src\test\config\log4j2-verbose-test.xml]
2017-12-01T17:06:49,417][INFO ][main][IgniteKernal%verboseLogGrid]
IGNITE_HOME=C:\incubator-ignite
2017-12-01T17:06:49,417][INFO ][main][IgniteKernal%verboseLogGrid] VM
arguments: [-ea, -Didea.test.cyclic.buffer.size=1048576, -javaagent:C:\Program
Files\JetBrains\IntelliJ IDEA Community Edition
2017.2.5\lib\idea_rt.jar=64660:C:\Program Files\JetBrains\IntelliJ IDEA
Community Edition 2017.2.5\bin, -Dfile.encoding=UTF-8]
2017-12-01T17:06:49,417][INFO ][main][IgniteKernal%verboseLogGrid] System
cache's DataRegion size is configured to 40 MB. Use
DataStorageConfiguration.systemCacheMemorySize property to change the setting.
2017-12-01T17:06:49,427][INFO ][main][IgniteKernal%verboseLogGrid] Configured
caches [in 'sysMemPlc' dataRegion: ['ignite-sys-cache']]
2017-12-01T17:06:49,430][WARN ][pub-#19%verboseLogGrid%][GridDiagnostic] This
operating system has been tested less rigorously: Windows 10 10.0 amd64. Our
team will appreciate the feedback if you experience any problems running ignite
in this environment.
2017-12-01T17:06:49,436][INFO ][main][IgniteKernal%verboseLogGrid] 3-rd party
licenses can be found at: C:\incubator-ignite\libs\licenses
Thank you,
Alexey
From: Denis Magda
Sent: Tuesday, November 21, 2017 2:01 AM
To: dev@ignite.apache.org
Subject: Re: Ignite Logger & logging file config output
Good point. Could you create a ticket and probably contribute this improvement?
—
Denis
> On Nov 20, 2017, at 3:12 AM, Alexey Popov <tank2.a...@gmail.com> wrote:
>
> Hi Igniters,
>
> Could you please advise why Ignite does not indicate
> 1) the logger type it uses
> 2) the logger configuration file (name) it applies
> during startup?
>
> Can we add such output to IgniteLogger implementations?
>
> Thanks,
> Alexey
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
RE: Thin Client Protocol documentation
Pavel, I believe ClientListenerNioListener.onHandshake() could support more than one Handshake request format (be backward compatible), for instance, if we will have a new handshake code = 0xABCD that differs from 0x01 byte. It is a design vs architecture question. I can’t understand why the legacy Handshake format should be used for a new protocol. If this protocol is supposed to be public it should have no exceptions for message formats. Thank you, Alexey From: Pavel Tupitsyn Sent: Thursday, November 30, 2017 12:11 PM To: dev@ignite.apache.org Subject: Re: Thin Client Protocol documentation Hi Alexey, 1,2,3 are related only to handshake. All other operations are consistent. Handshake request format is dictated by existing client connector that is shared with ODBC and JDBC clients (see ClientListenerNioListener.onHandshake). so we can't add magic numbers or change operation code. But yes, we can add server version to the handshake response, and I think this makes sense. > 4. The same comments for success flag (1 byte) and status code (4 bytes) in responses. Let's leave only status code. We don't have a success flag in responses, there is just a 4-byte status code, 0 indicates success, everything else is an error. Thanks, Pavel On Thu, Nov 30, 2017 at 12:01 PM, Alexey Popov <tank2.a...@gmail.com> wrote: > Hi Pavel, > > Let me add my 5 cents. > > 1. It would be great if both Handshake request & response have some > "magic" number (2 or 4 bytes) inside their msg body. That will simplify > handling situations when non-Ignite client connects to Ignite server and > vice versa. > > 2. It makes sense to add server version to successful Handshake response > as well. It will help to understand & debug possible backward compatibility > issues in the field by *.pcap logs analysis & etc. > > 3. Can we have a more strict header for all message types? > As far as I understand, > Handshake request has: > 1) length - 4 byte > 2) Handshake code - 1 byte > 3) body - (length - 1) bytes > > while OP_CACHE_GET request has: > 1) length - 4 byte > 2) OP_CACHE_GET code - 2 bytes > 3) request id - 4 bytes > 4) body - (length - 2 - 4) bytes > > Why some messages have Operation code with 1 byte while others - 2 bytes? > Why some requests/responses have request-id while others don't? Let's > simplify parser work ) > > 4. The same comments for success flag (1 byte) and status code (4 bytes) > in responses. Let's leave only status code. > > Thank you, > Alexey > > From: Pavel Tupitsyn > Sent: Wednesday, November 22, 2017 4:04 PM > To: dev@ignite.apache.org > Subject: Thin Client Protocol documentation > > Igniters, > > I've put together a detailed description of our Thin Client protocol > in form of IEP on wiki: > https://cwiki.apache.org/confluence/display/IGNITE/IEP- > 9+Thin+Client+Protocol > > > To clarify: > - Protocol implementation is in master (see ClientMessageParser class) > - Protocol has not been released yet, so we are free to change anything > - Protocol is only used by .NET Thin Client for now, but is supposed to be > used from other languages by third party contributors > - More operations will be added in future, this is a first set of them, > cache-related > > > Please review the document and let me know your thoughts. > Is there anything missing or wrong? > > We should make sure that the foundation is solid and extensible. > > > Thanks, > Pavel > >
RE: Thin Client Protocol documentation
Hi Pavel, Let me add my 5 cents. 1. It would be great if both Handshake request & response have some "magic" number (2 or 4 bytes) inside their msg body. That will simplify handling situations when non-Ignite client connects to Ignite server and vice versa. 2. It makes sense to add server version to successful Handshake response as well. It will help to understand & debug possible backward compatibility issues in the field by *.pcap logs analysis & etc. 3. Can we have a more strict header for all message types? As far as I understand, Handshake request has: 1) length - 4 byte 2) Handshake code - 1 byte 3) body - (length - 1) bytes while OP_CACHE_GET request has: 1) length - 4 byte 2) OP_CACHE_GET code - 2 bytes 3) request id - 4 bytes 4) body - (length - 2 - 4) bytes Why some messages have Operation code with 1 byte while others - 2 bytes? Why some requests/responses have request-id while others don't? Let's simplify parser work ) 4. The same comments for success flag (1 byte) and status code (4 bytes) in responses. Let's leave only status code. Thank you, Alexey From: Pavel Tupitsyn Sent: Wednesday, November 22, 2017 4:04 PM To: dev@ignite.apache.org Subject: Thin Client Protocol documentation Igniters, I've put together a detailed description of our Thin Client protocol in form of IEP on wiki: https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol To clarify: - Protocol implementation is in master (see ClientMessageParser class) - Protocol has not been released yet, so we are free to change anything - Protocol is only used by .NET Thin Client for now, but is supposed to be used from other languages by third party contributors - More operations will be added in future, this is a first set of them, cache-related Please review the document and let me know your thoughts. Is there anything missing or wrong? We should make sure that the foundation is solid and extensible. Thanks, Pavel
[jira] [Created] (IGNITE-7047) NPE at org.jsr166.ConcurrentLinkedHashMap.replace
Alexey Popov created IGNITE-7047: Summary: NPE at org.jsr166.ConcurrentLinkedHashMap.replace Key: IGNITE-7047 URL: https://issues.apache.org/jira/browse/IGNITE-7047 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.1 Reporter: Alexey Popov Assignee: Alexey Popov NPE happens sometimes at heavy load after receiving GridDhtTxOnePhaseCommitAckRequest, no more details ERROR 11/25/17 17:39:28 [::sys-stripe-2-#3%null%] cache.GridCacheIoManager> Failed processing message [senderId=0393e394-09a9-4c02-b33e-fb4d99c3539f, msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersi on [topVer=123129570, order=1511649564004, nodeOrder=2]], super=GridCacheMessage [msgId=95, depInfo=null, err=null, skipPrepare=false]]] java.lang.NullPointerException at org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097) at org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483) at java.lang.Thread.run(Thread.java:745) ERROR 11/25/17 17:39:28 [::sys-stripe-14-#15%null%] cache.GridCacheIoManager> Failed processing message [senderId=52c4ced0-49f3-4075-9b2f-7d619adf6d33, msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion [topVer=123129570, order=1511649564004, nodeOrder=4]], super=GridCacheMessage [msgId=97, depInfo=null, err=null, skipPrepare=false]]] java.lang.NullPointerException at org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.jav
Re: Data Rebalancing status API
Hm, actually, I've missed existent MXBean: RebalancingPartitionsCount. Probably it should be enough. Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Confusing slf4j error messages
I've opened a ticket https://issues.apache.org/jira/browse/IGNITE-6828 some time ago to fix this message. If nobody argues I will prepare a patch. Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Data Rebalancing status API
Hi Igniters, I saw several cases when Ignite users/admins need to ensure if Data Rebalancing is NOT in progress to prevent possible data loss. For instance, when nodes one-by-one are moved out of the cluster for maintenance and returned back by some script. Currently, this information could be received only by listening to EVT_CACHE_REBALANCE_STARTED and EVT_CACHE_REBALANCE_STOPPED events. Why Ignite doesn't provide any public API to get a cache (or node) rebalancing state? Can we add some API for such purpose? Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-6974) .NET: consoleWrite error during application shutdown
Alexey Popov created IGNITE-6974: Summary: .NET: consoleWrite error during application shutdown Key: IGNITE-6974 URL: https://issues.apache.org/jira/browse/IGNITE-6974 Project: Ignite Issue Type: Bug Components: platforms Reporter: Alexey Popov Priority: Minor from Gitter: Hey all (again xD)! Using Apache Ignite .NET 2.3 I (sometimes) get an error when shutting down my application. The error is only observable on server nodes and not on every shutdown. Seems like a kind of race condition. The application runs as windows service. The windows application event log shows the following error (see above) and a I get a hs_err_pid[PID].log like that (snip): Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Ljava/lang/String;Z)V+0 j org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(Ljava/lang/String;Z)V+2 j org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write([BII)V+18 j java.io.PrintStream.write([BII)V+16 j sun.nio.cs.StreamEncoder.writeBytes()V+120 j sun.nio.cs.StreamEncoder.implFlushBuffer()V+11 j sun.nio.cs.StreamEncoder.flushBuffer()V+15 j java.io.OutputStreamWriter.flushBuffer()V+4 j java.io.PrintStream.write(Ljava/lang/String;)V+27 j java.io.PrintStream.print(Ljava/lang/String;)V+9 j org.apache.ignite.internal.util.IgniteUtils.quiet(Z[Ljava/lang/Object;)V+126 j org.apache.ignite.internal.IgniteKernal.stop0(Z)V+943 j org.apache.ignite.internal.IgniteKernal.stop(Z)V+6 j org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(Z)V+162 j org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(Z)V+26 j org.apache.ignite.internal.IgnitionEx.stop(Ljava/lang/String;ZZ)Z+72 j org.apache.ignite.Ignition.stop(Ljava/lang/String;Z)Z+3 j org.apache.ignite.internal.processors.platform.PlatformIgnition.stop(Ljava/lang/String;Z)Z+2 v ~StubRoutines::call_stub For me it seems that the Java side wants to write something to the (.NET) console using a callback and the underlying memory is already freed - therefore we get a AccessViolation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6971) Ignite Logger type & logging file config indication
Alexey Popov created IGNITE-6971: Summary: Ignite Logger type & logging file config indication Key: IGNITE-6971 URL: https://issues.apache.org/jira/browse/IGNITE-6971 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.1 Reporter: Alexey Popov Priority: Minor Please see http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Logger-amp-logging-file-config-output-td24435.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Ignite Logger & logging file config output
Hi Igniters, Could you please advise why Ignite does not indicate 1) the logger type it uses 2) the logger configuration file (name) it applies during startup? Can we add such output to IgniteLogger implementations? Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-6955) Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4
Alexey Popov created IGNITE-6955: Summary: Update com.google.code.simple-spring-memcached:spymemcached to 2.8.4 Key: IGNITE-6955 URL: https://issues.apache.org/jira/browse/IGNITE-6955 Project: Ignite Issue Type: Improvement Components: examples Affects Versions: 2.3 Reporter: Alexey Popov Assignee: Alexey Popov Priority: Minor Please update com.google.code.simple-spring-memcached:spymemcached to 2.8.4 version. This version does not have "netty" dependencies -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6946) Change Ignite Logger configuration on the fly
Alexey Popov created IGNITE-6946: Summary: Change Ignite Logger configuration on the fly Key: IGNITE-6946 URL: https://issues.apache.org/jira/browse/IGNITE-6946 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: general Affects Versions: 2.3 Reporter: Alexey Popov It would be great if we can change Ignite Logger configuration on the fly without restarting the cluster node. I will really help to debug an issue while it is reproducible at the current cluster state. It should be done within the configured type of a logger, i.e. it is enough to change logging levels without changing the Logger type itself. Such configuration change should be done for all supported logger types (JUL, log4j, log4i2 and others). Also it should be done easily, for instance, via Visor, WebConsole or any other user-friendly tool ). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: Confusing slf4j error messages
It will utilize commons-logging (it is in dependency tree) according to https://spring.io/blog/2009/12/04/logging-dependencies-in-spring/ "The nice thing about commons-logging is that you don’t need anything else to make your application work. It has a runtime discovery algorithm that looks for other logging frameworks in well known places on the classpath and uses one that it thinks is appropriate (or you can tell it which one if you need to). If nothing else is available you get pretty nice looking logs just from the JDK (java.util.logging or JUL for short). You should find that your Spring application works and logs happily to the console out of the box in most situations, and that’s important." Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Confusing slf4j error messages
Hi Igniters, Ignite examples and Ignite itself with some configurations prints out annoying messages related to slf4j: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. The reason for these messages is inside org.springframework.data:spring-data-commons. It adds a dependency to jcl-over-slf4j that "activates" slf4j. slf4j then tries to find slf4j-TO-SOMELOGGER to forward all messages to SOMELOGGER. Actually, it does not result in any issues with Ignite logging itself, it just confusing Ignite users. So, there are two options here to avoid these annoying messages: 1. exclude jcl-over-slf4j dependency from spring-data-commons in Ignite .pom files 2. add slf4j-TO-SOMELOGGER (for instance, slf4j-log4j12 for log4j, or slf4j-simple) dependency Please advice on a better solution here. Thank you, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-6907) Add LINQ many-to-many test and LINQ with transactions test
Alexey Popov created IGNITE-6907: Summary: Add LINQ many-to-many test and LINQ with transactions test Key: IGNITE-6907 URL: https://issues.apache.org/jira/browse/IGNITE-6907 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: platforms Affects Versions: 2.3 Reporter: Alexey Popov 1) Please add more many-to-many tests with LINQ. 2) Please add test with LINQ & Transactions to show/test how it could be used together Probably it could be put to some example instead of unit tests -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6896) .NET: support Multidimensional Arrays in binary serializer
Alexey Popov created IGNITE-6896:
Summary: .NET: support Multidimensional Arrays in binary serializer
Key: IGNITE-6896
URL: https://issues.apache.org/jira/browse/IGNITE-6896
Project: Ignite
Issue Type: Improvement
Security Level: Public (Viewable by anyone)
Components: platforms
Affects Versions: 2.3
Reporter: Alexey Popov
It is found that legacy 2D, 3D, etc. are not working in BinarySerializer.
Sample reproducer:
{code:java}
[Test]
public void TestXX()
{
var array2D = new float[32, 32];
var res = TestUtils.SerializeDeserialize(array2D);
Assert.AreEqual(array2D, res);
}
{code}
BTW, please note that 2D array in Java (a[2][2]) is just a jugged array:
obj = {byte[2][]@1928}
0 = {byte[2]@1974}
1 = {byte[2]@1975}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6876) ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT
Alexey Popov created IGNITE-6876: Summary: ODBC: Add support for SQL_ATTR_CONNECTION_TIMEOUT Key: IGNITE-6876 URL: https://issues.apache.org/jira/browse/IGNITE-6876 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: odbc Affects Versions: 2.1 Reporter: Alexey Popov Remote ODBC client should be able to request a timeout for socket send/receive operations. It should be done with SQL_ATTR_CONNECTION_TIMEOUT attribute. If an application with ODBC driver experiences a timeout for some query, it can continue to work after closing the connection and establishing a new one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6835) ODBC driver should handle ungraceful tcp disconnects
Alexey Popov created IGNITE-6835: Summary: ODBC driver should handle ungraceful tcp disconnects Key: IGNITE-6835 URL: https://issues.apache.org/jira/browse/IGNITE-6835 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: odbc Affects Versions: 2.1 Reporter: Alexey Popov It is found that ungraceful TCP disconnect makes ODBC driver stuck at socket recv(). Ungraceful TCP disconnect could be caused: 1. Network failure (or new firewall rules) 2. Remote party shutdown (Half Closed Connection) So, the proposal is: setup socket options: 1) SO_KEEPALIVE enabled 2) TCP_KEEPIDLE to 60 sec. It is 2 hour by default 3) TCP_KEEPINTVL to 5 (?) sec. It is 1 sec at Win and 75 sec at Linux by default. 4) send/receive buffers to some greater value (8k by default) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6828) Confusing messages "SLF4J: Failed to load class" at Ignite start
Alexey Popov created IGNITE-6828: Summary: Confusing messages "SLF4J: Failed to load class" at Ignite start Key: IGNITE-6828 URL: https://issues.apache.org/jira/browse/IGNITE-6828 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: general Affects Versions: 2.1 Reporter: Alexey Popov Assignee: Alexey Popov How to reproduce: 1. build Ignite 2. go to examples\ 3. run: mvn exec:java -Dexec.mainClass="org.apache.ignite.examples.ExampleNodeStartup" you will see the following confusing output: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. SLF4J dependency comes from org.springframework.data:spring-data-commons: [INFO] +- org.apache.ignite:ignite-spring-data:jar:2.3.0-SNAPSHOT:compile [INFO] | +- (org.apache.ignite:ignite-core:jar:2.3.0-SNAPSHOT:compile - omitted for duplicate) [INFO] | +- (org.apache.ignite:ignite-indexing:jar:2.3.0-SNAPSHOT:compile - omitted for duplicate) [INFO] | +- org.springframework.data:spring-data-commons:jar:1.13.1.RELEASE:compile [INFO] | | +- (org.springframework:spring-core:jar:4.3.7.RELEASE:compile - omitted for duplicate) [INFO] | | +- (org.springframework:spring-beans:jar:4.3.7.RELEASE:compile - omitted for duplicate) [INFO] | | +- org.slf4j:slf4j-api:jar:1.7.24:compile [INFO] | | \- org.slf4j:jcl-over-slf4j:jar:1.7.24:runtime [INFO] | | \- (org.slf4j:slf4j-api:jar:1.7.24:runtime - omitted for duplicate) [INFO] | \- (org.apache.ignite:ignite-spring:jar:2.3.0-SNAPSHOT:compile - omitted for duplicate) We should remove this dependency because it is confusing and does not affects to Ignite logging functionality -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: ipFinder configuration for Samples
I've created https://issues.apache.org/jira/browse/IGNITE-6826 Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
ipFinder configuration for Samples
Hi, Igniters I wonder why Ignite examples have multicast ipFinder for DiscoverySpi at their configuration? It is a quite common case to try them locally and Vm ipFinder is the best option for that. Multicast ipFinder adds some instability when several persons try & debug samples or evaluate a new Ignite version at the same local network. It looks like default ipFinder could simplify cluster deployment with default configs. However, I hardly believe that someone deploys the samples into remote hosts without changing IPs. I propose to change default configs for examples from multicast to vm ipFinder. Thank you, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors
Alexey Popov created IGNITE-6690: Summary: DiscoverySpi: Clientmode Ignite should not fail on handshake errors Key: IGNITE-6690 URL: https://issues.apache.org/jira/browse/IGNITE-6690 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: general Affects Versions: 2.2 Reporter: Alexey Popov Assignee: Alexey Popov Fix For: 2.4 Ignite in Client mode should not fail on handshake unmarshalling errors. It should go to the next IP/port from ipFinder list http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
DiscoverySpi Handshake unmarshalling errors at Client (client mode)
Hi Igniters, I am looking into Client DiscoverySpi procedure and see some differences in Client behavior when it trying to connect to servers. Case 1: If the Client can't connect (Connection refused) to some Server it goes to the next IP/port from the ipFinder list. Case 2: But if the client can't succesfully finish Discovery Handshake procedure with the Server it does not try to connect to other IPs. It just throws an TcpDiscoverySpi exception like this back to a user code "class org.apache.ignite.IgniteCheckedException: Failed to start SPI: TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller [], reconCnt=10, maxAckTimeout=60, forceSrvMode=false, clientReconnectDisabled=false]" Case 2 can happen when IP/port was taken by non-Ignite server. For instance, it could be taken by misconfigured HTTP server and the Client just can't unmarshall the server HTTP response: Caused by: java.io.StreamCorruptedException: invalid stream header: 48545450 at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:857) at java.io.ObjectInputStream.(ObjectInputStream.java:349) at org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:39) at org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:119) So, I would like to change the client behavior in Case 2. It should handle Discovery Handshake unmarshalling error in the same way it does with "Connection refused" errors. It should try to connect to other servers. Your thoughts? Thanks, Alexey -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum
Alexey Popov created IGNITE-6627:
Summary: .NET: cache deserialization fail with complex value type
& enum
Key: IGNITE-6627
URL: https://issues.apache.org/jira/browse/IGNITE-6627
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.2
Reporter: Alexey Popov
There is an deserialization issue with complex structure.
Please see the sample code below:
{noformat}
public enum SampleEnum : byte
{
One = 0,
Two = 1,
Three = 2
}
{noformat}
{noformat}
var cache = ignite.GetOrCreateCache<string,
Dictionary<SampleEnum, Dictionary<int, int>>>("mySampleCache");
cache.Put("DictData", Dict);
var result = cache.Get("DictData");
{noformat}
{{cache.Get("DictData"); }} fails with eception:
{"The constructor to deserialize an object of type
'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
was not found."}
if we change
Dictionary<SampleEnum, Dictionary<int, int>>
to
Dictionary<int, Dictionary<int, int>>
then everything is ok
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
welcome
Hello Ignite Community! My name is Alexey Popov. I want to contribute to Apache Ignite. My Jira ID alexey.tank2 Thanks!
