[jira] [Created] (IGNITE-14599) Add generic way to bootstrap configuration
Alexander Lapin created IGNITE-14599:
Summary: Add generic way to bootstrap configuration
Key: IGNITE-14599
URL: https://issues.apache.org/jira/browse/IGNITE-14599
Project: Ignite
Issue Type: Improvement
Reporter: Alexander Lapin
Assignee: Alexander Lapin
Currently it's possible to bootstrap configuration only with json formatted
string.
{code:java}
Ignite start(@Nullable String jsonStrBootstrapCfg);
{code}
Instead of given temporary solution some sort of generic implementation should
be used, for example configuration file with set of formats: json, hocon.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14586) Remove @SupperessWarnings when implementation provided.
Alexander Lapin created IGNITE-14586: Summary: Remove @SupperessWarnings when implementation provided. Key: IGNITE-14586 URL: https://issues.apache.org/jira/browse/IGNITE-14586 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14581) Implement IgniteImpl close method
Alexander Lapin created IGNITE-14581: Summary: Implement IgniteImpl close method Key: IGNITE-14581 URL: https://issues.apache.org/jira/browse/IGNITE-14581 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Assignee: Alexander Lapin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14580) Add exception handling logic to IgntitionProcessor
Alexander Lapin created IGNITE-14580: Summary: Add exception handling logic to IgntitionProcessor Key: IGNITE-14580 URL: https://issues.apache.org/jira/browse/IGNITE-14580 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Assignee: Alexander Lapin Handle Ignition service lack and throw proper exception from start method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14579) Start rest manager
Alexander Lapin created IGNITE-14579: Summary: Start rest manager Key: IGNITE-14579 URL: https://issues.apache.org/jira/browse/IGNITE-14579 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Assignee: Alexander Lapin Update IgntionImpl with code that will start rest manager. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14578) Bootstrap configuation manager with distributed configuraiton
Alexander Lapin created IGNITE-14578: Summary: Bootstrap configuation manager with distributed configuraiton Key: IGNITE-14578 URL: https://issues.apache.org/jira/browse/IGNITE-14578 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Assignee: Alexander Lapin Update IgntionImpl with code that will * Add distributed root keys. * Bootstrap distributed configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14522) CommunicationManager refactoring
Alexander Lapin created IGNITE-14522: Summary: CommunicationManager refactoring Key: IGNITE-14522 URL: https://issues.apache.org/jira/browse/IGNITE-14522 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14100) GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
Alexander Lapin created IGNITE-14100:
Summary: GridCachePartitionedNodeRestartTest fails due to wrong tx
mapping
Key: IGNITE-14100
URL: https://issues.apache.org/jira/browse/IGNITE-14100
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Assignee: Alexander Lapin
Sometimes
GridCachePartitionedNodeRestartTest#testRestartWithTxEightNodesTwoBackups hangs
with the following AssertionError:
{code:java}
[18:06:54]W: [org.gridgain:ignite-core] java.lang.AssertionError:
cacheId=-838655627, localNode = c2156a8f-1ac7-4098-8808-b1f9fad5, dhtNodes
= [TcpDiscoveryNode [id=51df7fb1-2cad-4bfc-a02e-8225fbc0,
consistentId=127.0.0.1:47500, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
lastExchangeTime=1603552013349, loc=false, ver=8.8.127#20201023-sha1:8f62caf2,
isClient=false], TcpDiscoveryNode [id=c2156a8f-1ac7-4098-8808-b1f9fad5,
consistentId=127.0.0.1:47504, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
[/127.0.0.1:47504], discPort=47504, order=21, intOrder=13,
lastExchangeTime=1603552013259, loc=true, ver=8.8.127#20201023-sha1:8f62caf2,
isClient=false], TcpDiscoveryNode [id=f7355089-fdea-4a96-af57-00ebeb94,
consistentId=127.0.0.1:47505, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
[/127.0.0.1:47505], discPort=47505, order=22, intOrder=14,
lastExchangeTime=1603552013390, loc=false, ver=8.8.127#20201023-sha1:8f62caf2,
isClient=false], TcpDiscoveryNode [id=4e8a8c17-e1c7-43e2-8461-9b5348d3,
consistentId=127.0.0.1:47503, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
[/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
lastExchangeTime=1603552013349, loc=false, ver=8.8.127#20201023-sha1:8f62caf2,
isClient=false], TcpDiscoveryNode [id=d4f66e72-4ecc-4aca-a6d1-91242331,
consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1603552013349, loc=false, ver=8.8.127#20201023-sha1:8f62caf2,
isClient=false]]
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1669)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1355)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:732)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1125)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:591)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:388)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:197)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:174)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:134)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:219)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:217)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
[18:06:54]W: [org.gridgain:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
[jira] [Created] (IGNITE-14036) Tracing: add ability to trace compute operations.
Alexander Lapin created IGNITE-14036: Summary: Tracing: add ability to trace compute operations. Key: IGNITE-14036 URL: https://issues.apache.org/jira/browse/IGNITE-14036 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin After implementing update and check whether removeAll() and clear() traced properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13870) Remove GridCacheAdapter#validateCacheKey cause it seems to be obsolete
Alexander Lapin created IGNITE-13870: Summary: Remove GridCacheAdapter#validateCacheKey cause it seems to be obsolete Key: IGNITE-13870 URL: https://issues.apache.org/jira/browse/IGNITE-13870 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13869) Add extra map query logging within the debug level.
Alexander Lapin created IGNITE-13869: Summary: Add extra map query logging within the debug level. Key: IGNITE-13869 URL: https://issues.apache.org/jira/browse/IGNITE-13869 Project: Ignite Issue Type: Bug Components: sql Reporter: Alexander Lapin Assignee: Alexander Lapin For some cases, particularly partition pruning and affinity awareness checks, it would be useful to log map queries on a recipient nodes in case of debug log level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13868) Create caches simultaneously in same non-existing cache group led to NPE
Alexander Lapin created IGNITE-13868:
Summary: Create caches simultaneously in same non-existing cache
group led to NPE
Key: IGNITE-13868
URL: https://issues.apache.org/jira/browse/IGNITE-13868
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Assignee: Alexander Lapin
1 server 1 client
Case:
server create cache and group
client create cache in previous group
{code:java}
Caused by: java.lang.NullPointerException
at
java.util.Collections$UnmodifiableCollection.(Collections.java:1026)
at java.util.Collections$UnmodifiableList.(Collections.java:1302)
at java.util.Collections.unmodifiableList(Collections.java:1287)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentV2.(GridAffinityAssignmentV2.java:108)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.initialize(GridAffinityAssignmentCache.java:205)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.init(GridAffinityAssignmentCache.java:750)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CacheGroupHolder.(CacheAffinitySharedManager.java:2635)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CacheGroupAffNodeHolder.(CacheAffinitySharedManager.java:2692)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedGroup(CacheAffinitySharedManager.java:1339)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$initAffinityOnCacheGroupsStart$641a38d$1(CacheAffinitySharedManager.java:1001)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10575)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10498)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initAffinityOnCacheGroupsStart(CacheAffinitySharedManager.java:997)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:975)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:833)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1238)
... 5 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13867) IgniteCacheTxExpiryPolicyTest.testNearAccess almost stably fails in CE master
Alexander Lapin created IGNITE-13867:
Summary: IgniteCacheTxExpiryPolicyTest.testNearAccess almost
stably fails in CE master
Key: IGNITE-13867
URL: https://issues.apache.org/jira/browse/IGNITE-13867
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Assignee: Alexander Lapin
[TC|https://ci.ignite.apache.org/project.html?testNameId=-5197950048275421802&projectId=IgniteTests24Java8&buildTypeId=IgniteTests24Java8_CacheExpiryPolicy&tab=testDetails&branch_IgniteTests24Java8=ignite-2.9.1&fromExperimentalUI=true&showExperimentalUIOptout=true]
{code:java}
java.lang.AssertionError: Unexpected non-null value for grid 1 expected null,
but was:<1>
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13640) Opencensus module has no runtime dependencies.
Alexander Lapin created IGNITE-13640: Summary: Opencensus module has no runtime dependencies. Key: IGNITE-13640 URL: https://issues.apache.org/jira/browse/IGNITE-13640 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin Fix For: 2.9.1 Need to add dependencies to pom.xml * io.opencensus.opencensus-impl-core - 0.22.0 version * io.grpc.grpc-context - 1.19.0 version * com.lmax.disruptor - 3.4.2 version * com.google.guava.guava - 26.0-android version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13393) Tracing: Atomic cache read/write flow.
Alexander Lapin created IGNITE-13393: Summary: Tracing: Atomic cache read/write flow. Key: IGNITE-13393 URL: https://issues.apache.org/jira/browse/IGNITE-13393 Project: Ignite Issue Type: New Feature Reporter: Alexander Lapin Assignee: Alexander Lapin Implement tracing for atomic cache operations: * put * putAll * putAsync * putAllAsync * remove * removeAll * removeAsync * removeAllAsync * get * getAll * getAsync * getAllAsync Also add ability to include root cache read/write operations to tx tracing flow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13375) Operations started on client nodes are not traced.
Alexander Lapin created IGNITE-13375: Summary: Operations started on client nodes are not traced. Key: IGNITE-13375 URL: https://issues.apache.org/jira/browse/IGNITE-13375 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin Fix For: 2.10 Root spans should be created on client node like it’s done on server node. I suppose that to already existent node join span creation we should add: * addMessage * node stop * custom event -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13374) Initial PME hangs because of multiple blinking nodes
Alexander Lapin created IGNITE-13374: Summary: Initial PME hangs because of multiple blinking nodes Key: IGNITE-13374 URL: https://issues.apache.org/jira/browse/IGNITE-13374 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin Fix For: 2.10 *Root cause* of the issue is a race inside GridDhtPartitionsExchangeFuture on client side between two processes: # When old coordinator fails and the new one takes over it sends GridDhtPartitionsSingleRequest messages to all nodes including clients to restore exchange results. Processing this message on client includes updating current coordinator reference (crd field). # When future receives discovery notification about old coordinator failure it should detect change of coordinator and send GridDhtPartitionsSingleMessage to new coordinator to obtain affinity. But updated crd field prevents client from detecting coordinator failure and sending SingleMessage to new coordinator which in turn leads to hanging client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
Alexander Lapin created IGNITE-13373: Summary: WAL segmentns do not released on releaseHistoryForPreloading() Key: IGNITE-13373 URL: https://issues.apache.org/jira/browse/IGNITE-13373 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest WALPointer that was reserved during reserveHistoryForPreloading in reservedForPreloading field. As a result it's possible to release wall reservation on releaseHIstoryForPreloading(). * searchAndReserveCheckpoints() was slightly refactored: now it returns not only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so that there’s no need to recalculate it within reserveHistoryForExchange(). * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13251) Deadlock between grid-timeout-worker and a thread opening a communication connection.
Alexander Lapin created IGNITE-13251:
Summary: Deadlock between grid-timeout-worker and a thread opening
a communication connection.
Key: IGNITE-13251
URL: https://issues.apache.org/jira/browse/IGNITE-13251
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
rid-timeout-worker is known to go into a deadlock state with other threads in a
few scenarios.
The general scheme is:
1. A thread `T` is holding lock `L` and is trying to establish a communication
connection, hanging in `safeTcpHandshake` method. Due to the logic of
`safeTcpHandshake`, `grid-timeout-worker` needs to send a signal to `T` in
order for it to proceed.
2. `grid-timeout-worker` is trying to acquire `L`. Hence, the deadlock.
It may include more threads. The lock `L` can be different: checkpoint lock,
GridCacheMapEntry lock, etc.
#
## Example
The below example shows a lock between
* `grid-timeout-worker` trying to acquire a cp read lock in a
`dumpLongRunningTransactions`
* `tcp-comm-worker` trying to establish a connection but hanging on socket
read due to unstable network
* checkpointer trying to start a checkpoint and acquire cp write lock
* `utility` worker waiting for the connection to be established by
`tcp-comm-worker` while holding cp read lock
{code:java}
Thread [name="grid-timeout-worker-#23", id=42, state=WAITING, blockCnt=6991,
waitCnt=1746467]
Lock
[object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@4545a8b9,
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1707)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:715)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:511)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.tryLocalGet(GridPartitionedSingleGetFuture.java:399)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:366)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:243)
at
o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:232)
at
o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:246)
at
o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4190)
at
o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4171)
at
o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1362)
at
o.a.i.i.processors.task.GridTaskProcessor.saveTaskMetadata(GridTaskProcessor.java:908)
at
o.a.i.i.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:746)
at
o.a.i.i.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:477)
at
o.a.i.i.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:674)
at
o.a.i.i.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:479)
at o.a.i.i.IgniteComputeImpl.callAsync0(IgniteComputeImpl.java:809)
at o.a.i.i.IgniteComputeImpl.callAsync(IgniteComputeImpl.java:794)
at
o.a.i.i.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningTransaction(GridCachePartitionExchangeManager.java:2115)
at
o.a.i.i.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2012)
- locked
o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ActionLimiter@47b86e8f
at
o.a.i.i.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2180)
at o.a.i.i.IgniteKernal$4.run(IgniteKernal.java:1478)
at
o.a.i.i.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:410)
- locked
o.a.i.i.processors.timeout.GridTimeoutProcessor$CancelableTask@67c951c7
at
o.a.i.i.process
[jira] [Created] (IGNITE-13238) Instant not supported whithin the scope of jdbc thin.
Alexander Lapin created IGNITE-13238:
Summary: Instant not supported whithin the scope of jdbc thin.
Key: IGNITE-13238
URL: https://issues.apache.org/jira/browse/IGNITE-13238
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.9
Reporter: Alexander Lapin
Reproducer:
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testInstantDataType
{code:java}
[2020-07-10
09:12:36,183][ERROR][client-connector-#196%thin.JdbcThinCacheToJdbcDataTypesCoverageTest0%][JdbcRequestHandler]
Failed to execute SQL query [reqId=11, req=JdbcQueryExecuteRequest
[schemaName=cachebb4b3282_3ad0_4ee3_9959_806c33521406, pageSize=1024,
maxRows=0, sqlQry=SELECT * FROM tablebb4b3282_3ad0_4ee3_9959_806c33521406 WHERE
_key = ?, args=Object[] [-292275055-05-16T16:47:04.192Z],
stmtType=SELECT_STATEMENT_TYPE, autoCommit=true, partResReq=false,
super=JdbcRequest [type=2, reqId=11]]]
javax.cache.CacheException: Failed to calculate derived partitions for query.
at
org.apache.ignite.internal.sql.optimizer.affinity.PartitionResult.calculatePartitions(PartitionResult.java:132)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSelectDistributed(IgniteH2Indexing.java:1682)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSelect0(IgniteH2Indexing.java:1412)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSelect(IgniteH2Indexing.java:1291)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1128)
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:200)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:54)
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:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to wrap
value[type=24, value=-292275055-05-16T16:47:04.192Z]
at
org.apache.ignite.internal.processors.query.h2.H2Utils.wrap(H2Utils.java:668)
at
org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:520)
at
org.apache.ignite.internal.processors.query.h2.affinity.H2PartitionResolver.partition(H2PartitionResolver.java:43)
at
org.apache.ignite.internal.sql.optimizer.affinity.PartitionParameterNode.applySingle(PartitionParameterNode.java:72)
at
org.apache.ignite.internal.sql.optimizer.affinity.PartitionSingleNode.apply(PartitionSingleNode.java:47)
at
org.apache.ignite.internal.sql.optimizer.affinity.PartitionResult.calculatePartitions(PartitionResult.java:114)
... 25 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13236) Rebalance doesn't happen after restart if node failed at the moment of rebalance
Alexander Lapin created IGNITE-13236: Summary: Rebalance doesn't happen after restart if node failed at the moment of rebalance Key: IGNITE-13236 URL: https://issues.apache.org/jira/browse/IGNITE-13236 Project: Ignite Issue Type: Bug Environment: !Screen Shot 2019-08-05 at 18.20.46.png! Reporter: Alexander Lapin Attachments: Screen Shot 2019-08-05 at 18.20.46.png, image-2020-07-09-14-55-51-574.png Steps to reproduce: 1. Start 2 nodes in baseline 2. Stream a lot of data. 3. Stop the second node, clean the persistence and start it again(with the same consistent id 4. Kill the first node at the moment of rebalancing (make sure that not all data was rebalanced) 5. Partition loss will be detected. 6. Return first node to the cluster. 7. Result: !image-2020-07-09-14-55-51-574.png! Data is not rebalanced, All data(primary and backup) is stored on the first node only, while the second node has the same small subset of the data. It's reproducible with any Partition loss policy. Resetting lost partitions, activation/deactivation doesn't help. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13233) Invalid milliseconds value of java.util.Date converted to java.sql.Timestamp via JDBC Thin.
Alexander Lapin created IGNITE-13233: Summary: Invalid milliseconds value of java.util.Date converted to java.sql.Timestamp via JDBC Thin. Key: IGNITE-13233 URL: https://issues.apache.org/jira/browse/IGNITE-13233 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin In some cases, for example in case of new java.util.Date(Long.MAX_VALUE), milliseconds part of java.sql.Timestamp retrieved via JDBC has different value than previously putted via cache API java.util.Date. Date.getTime() 9223372036854775*807* Timestamp.getTime() 9223372036854775*191* Reproducer org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testDateDataType -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13232) JDBC thin: it's not possible to use array of objects as value in where _key=
Alexander Lapin created IGNITE-13232: Summary: JDBC thin: it's not possible to use array of objects as value in where _key= Key: IGNITE-13232 URL: https://issues.apache.org/jira/browse/IGNITE-13232 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Reproducers: org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testObjectArrayDataType -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13231) Unable to use character in where _key= clause via JDBC Thin, if previously putted within cache API.
Alexander Lapin created IGNITE-13231:
Summary: Unable to use character in where _key= clause
via JDBC Thin, if previously putted within cache API.
Key: IGNITE-13231
URL: https://issues.apache.org/jira/browse/IGNITE-13231
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Unable to use character in where _key= clause via JDBC Thin, if
previously putted within cache API.
Following exception will be got:
{color:#172b4d}{{java.sql.{color:#6554c0}SQLException{color}:
{color:#6554c0}Failed{color} {color:#0052cc}to{color} parse query.
{color:#6554c0}Hexadecimal{color} string {color:#0052cc}with{color} odd number
of characters: {color:#36b37e}"a"{color}; SQL statement:SELECT * FROM
tableefa88adf_7a52_4cac_9a2b_253c4880a369 {color:#6554c0}WHERE{color} _key =
{color:#36b37e}'a'{color}
[{color:#0052cc}90003{color}-{color:#0052cc}199{color}]}}{color}
Reproducer:
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testCharacterDataType
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13060) Tracing: initial implementation
Alexander Lapin created IGNITE-13060: Summary: Tracing: initial implementation Key: IGNITE-13060 URL: https://issues.apache.org/jira/browse/IGNITE-13060 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Assignee: Alexander Lapin Initial tracing implementation. See [IEP-48|https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing] for details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12326) JDBC thin returns java.util.Date instead of java.sql.Date if input values, putted to cache via cache API are LocalDate or java.sql.Date.
Alexander Lapin created IGNITE-12326: Summary: JDBC thin returns java.util.Date instead of java.sql.Date if input values, putted to cache via cache API are LocalDate or java.sql.Date. Key: IGNITE-12326 URL: https://issues.apache.org/jira/browse/IGNITE-12326 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Fix For: 2.8 JDBC thin returns java.util.Date instead of java.sql.Date if input values, putted to cache via cache API are LocalDate or java.sql.Date. Reproducers: org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testSqlDateDataType org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalDateDataType -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12322) Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account
Alexander Lapin created IGNITE-12322:
Summary: Changing baseline via set command may cause NPEs if
configured NodeFilter takes node attributes into account
Key: IGNITE-12322
URL: https://issues.apache.org/jira/browse/IGNITE-12322
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Fix For: 2.8
VisorBaselineTask doesn't allow to add() offline baseline node, but allows to
set() collection of nodes where at least one is offline and doesn’t belong to
current BLT.
We should prohibit passing offline nodes to setBaselineTopology(…) (in case
they are not part of current BLT): otherwise we won't be able to calculate
affinity in case NodeFilter is configured.
{code:java}
2019-07-16 13:38:01.658 ERROR 16507 --- [exchange-worker-#165]
.c.d.d.p.GridDhtPartitionsExchangeFuture : Failed to reinitialize local
partitions (rebalancing will be stopped): GridDhtPartitionExchangeId
[topVer=AffinityTopologyVersion [topVer=481, minorTopVer=1],
discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=e53b5aca-9432-4cbe-9626-da480b86d417, addrs=ArrayList [10.12.85.13,
127.0.0.1], sockAddrs=HashSet [lpposput50143.phx.aexp.com/10.12.85.13:47550,
/127.0.0.1:47550], discPort=47550, order=288, intOrder=148,
lastExchangeTime=1563309481590, loc=true, ver=2.5.7#20190326-sha1:b45b8438,
isClient=false], topVer=481, nodeId8=e53b5aca, msg=null,
type=DISCOVERY_CUSTOM_EVT, tstamp=1563309481580]DiscoveryCustomEvent
[customMsg=ChangeGlobalStateMessage
[id=bb76b94db61-f4fff892-04f6-4153-9210-1a19749fec35,
reqId=1b5cae87-ad46-4d62-8525-bc1a5015b0d8,
initiatingNodeId=e53b5aca-9432-4cbe-9626-da480b86d417, activate=true,
baselineTopology=BaselineTopology [id=3, branchingHash=-1403071463,
branchingType='New BaselineTopology',
baselineNodes=[/dev/shm/ignite/storagepath/lpposput50142.phx.aexp.com,
/dev/shm/ignite/storagepath/lpposput50143.phx.aexp.com,
/dev/shm/ignite/storagepath/lpposput50133.phx.aexp.com,
/dev/shm/ignite/storagepath/lpposput50134.phx.aexp.com,
/dev/shm/ignite/storagepath/lpposput50141.phx.aexp.com,
/dev/shm/ignite/storagepath/lpposput50140.phx.aexp.com]],
forceChangeBaselineTopology=true, timestamp=1563309481551],
affTopVer=AffinityTopologyVersion [topVer=481, minorTopVer=1], super=],
nodeId=e53b5aca, evt=DISCOVERY_CUSTOM_EVT]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.cluster.DetachedClusterNode.attribute(DetachedClusterNode.java:69)
~[ignite-core-2.5.7.jar!/:2.5.7]
at com.aexp.rc.ignite.CacheNodeFilter.apply(CacheNodeFilter.java:14)
~[classes!/:0.1.0-SNAPSHOT]
at com.aexp.rc.ignite.CacheNodeFilter.apply(CacheNodeFilter.java:6)
~[classes!/:0.1.0-SNAPSHOT]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1362)
~[ignite-core-2.5.7.jar!/:2.5.7]
at
org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:331)
~[ignite-core-2.5.7.jar!/:2.5.7]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.calculate(GridAffinityAssignmentCache.java:347)
~[ignite-core-2.5.7.jar!/:2.5.7]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$15.applyx(CacheAffinitySharedManager.java:1899)
~[ignite-core-2.5.7.jar!/:2.5.7]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$15.applyx(CacheAffinitySharedManager.java:1895)
~[ignite-core-2.5.7.jar!/:2.5.7]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$forAllRegisteredCacheGroups$e0a6939d$1(CacheAffinitySharedManager.java:1268)
~[ignite-core-2.5.7.jar!/:2.5.7]
at
org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10529)
~[ignite-core-2.5.7.jar!/:2.5.7]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_161]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_161]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[na:1.8.0_161]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
Suppressed: java.lang.NullPointerException: null
... 14 common frames omitted
Suppressed: java.lang.NullPointerException: null
... 14 common frames omitted
Suppressed: java.lang.NullPointerException: null
... 14 common frames omitted
Suppressed: java.lang.NullPointerException: null
... 14 common frames omitted
Suppressed: java.lang.NullPointerException: null
... 14 common frames omitted
Suppressed: java.lang.NullPointerException: null
at
org.apache.ignite.internal.cluster.DetachedClusterNode.attribute(DetachedClusterNode.java:69)
~[ignite-core-2.5.7.jar!/
[jira] [Created] (IGNITE-12321) Rebalance doesn't happen after restart if node failed at the moment of rebalance.
Alexander Lapin created IGNITE-12321: Summary: Rebalance doesn't happen after restart if node failed at the moment of rebalance. Key: IGNITE-12321 URL: https://issues.apache.org/jira/browse/IGNITE-12321 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Fix For: 2.8 Steps to reproduce: 1. Start 2 nodes in baseline 2. Stream a lot of data. 3. Stop the second node, clean the persistence and start it again(with the same consistent id 4. Kill the first node at the moment of rebalancing (make sure that not all data was rebalanced) 5. Partition loss will be detected. 6. Return first node to the cluster. 7. Result: Data is not rebalanced, All data(primary and backup) is stored on the first node only, while the second node has the same small subset of the data. It's reproducible with any Partition loss policy. Resetting lost partitions, activation/deactivation doesn't help. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12320) Partial index rebuild fails in case indexed cache contains different datatypes
Alexander Lapin created IGNITE-12320:
Summary: Partial index rebuild fails in case indexed cache
contains different datatypes
Key: IGNITE-12320
URL: https://issues.apache.org/jira/browse/IGNITE-12320
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Fix For: 2.8
The problem is that in case cache contains different datatypes, all of them
will be passed to IndexRebuildPartialClosure during iteration over partition.
Perhaps, TableCacheFilter is supposed to filter out entries of unwanted types,
but it doesn't work properly.
Steps to reprocude:
1. Add entries of different types (both indexed and not) to cache
2. Trigger partial index rebuild
Index rebuild will fail with the following error:
{code:java}
[2019-08-20
00:33:55,640][ERROR][pub-#302%h2.GridIndexFullRebuildTest3%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=98629247,
val2=844420635165670]], msg=Runtime failure on row: %s ]]]
class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=98629247,
val2=844420635165670]], msg=Runtime failure on row: %s ]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5126)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2236)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2183)
at
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:285)
at
org.apache.ignite.internal.processors.query.h2.IndexRebuildPartialClosure.apply(IndexRebuildPartialClosure.java:49)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:3867)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:254)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:217)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartitions(SchemaIndexCacheVisitorImpl.java:176)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.visit(SchemaIndexCacheVisitorImpl.java:135)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash0(IgniteH2Indexing.java:2191)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$7.body(IgniteH2Indexing.java:2154)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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: class org.apache.ignite.binary.BinaryObjectException: Failed to get
field because type ID of passed object differs from type ID this BinaryField
belongs to [expected=-635374417, actual=1778229603]
at
org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:287)
at
org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:109)
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:220)
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:116)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:331)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:122)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:106)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:350)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:56)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:4614)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:4534)
at
org.apache.ign
[jira] [Created] (IGNITE-12315) In case of using ArrayBlockingQueue as key, cache.get() returns null.
Alexander Lapin created IGNITE-12315:
Summary: In case of using ArrayBlockingQueue as key, cache.get()
returns null.
Key: IGNITE-12315
URL: https://issues.apache.org/jira/browse/IGNITE-12315
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
In case of using ArrayBlockingQueue as key, cache.get() returns null. In case
of using ArrayList or LinkedList everything works as expected.
{code:java}
ArrayBlockingQueue queueToCheck = new ArrayBlockingQueue<>(5);
queueToCheck.addAll(Arrays.asList(1, 2, 3));
cache.put(queueToCheck, "aaa");
cache.put(queueToCheck); // returns null
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12314) Unexpected return type in case of retrieving Byte[]{1,2,3} from cache value.
Alexander Lapin created IGNITE-12314:
Summary: Unexpected return type in case of retrieving
Byte[]{1,2,3} from cache value.
Key: IGNITE-12314
URL: https://issues.apache.org/jira/browse/IGNITE-12314
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Unexpected return type in case of retrieving Byte[]\{1,2,3} from cache value:
{color:#172b4d}{{cache.{color:#172b4d}put{color}({color:#36b37e}"aaa"{color},
{color:#0052cc}new{color} {color:#6554c0}Byte{color}[]
{{color:#0052cc}1{color}, {color:#0052cc}2{color}, {color:#0052cc}3{color}});
cache.{color:#172b4d}get{color}({color:#36b37e}"aaa"{color});}}{color}
Byte[3]@... expected with corresponding content, however Object[3]@... got.
Seems that it's related to primitive wrapers, cause String[] as value works as
expected:
{color:#172b4d}{{cache.{color:#172b4d}put{color}({color:#36b37e}"aaa"{color},
{color:#0052cc}new{color} {color:#6554c0}String{color}[]
{{color:#36b37e}"1"{color}, {color:#36b37e}"2"{color},
{color:#36b37e}"3"{color}});
cache.{color:#172b4d}get{color}({color:#36b37e}"aaa"{color});}}{color}
Arrays of primitives also works as expected:
{color:#172b4d}{{cache.{color:#172b4d}put{color}({color:#36b37e}"aaa"{color},
{color:#0052cc}new{color} {color:#0052cc}byte{color}[]
{{color:#0052cc}1{color}, {color:#0052cc}2{color}, {color:#0052cc}3{color}});
cache.{color:#172b4d}get{color}({color:#36b37e}"aaa"{color});}}{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12313) Unable to update value via sql update query if a key is a byte array within non-mvcc mode.
Alexander Lapin created IGNITE-12313:
Summary: Unable to update value via sql update query if a key is a
byte array within non-mvcc mode.
Key: IGNITE-12313
URL: https://issues.apache.org/jira/browse/IGNITE-12313
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: [B
cannot be cast to java.lang.Comparable
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2350)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2283)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2210)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2183)
at
org.apache.ignite.sqltests.SqlDataTypesCoverageTests.checkCRUD(SqlDataTypesCoverageTests.java:381)
at
org.apache.ignite.sqltests.SqlDataTypesCoverageTests.checkBasicSqlOperations(SqlDataTypesCoverageTests.java:335)
at
org.apache.ignite.sqltests.SqlDataTypesCoverageTests.testBinaryDataType(SqlDataTypesCoverageTests.java:269)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2075)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: [B cannot be cast to
java.lang.Comparable
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2828)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2309)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2347)
... 17 more
Caused by: java.lang.ClassCastException: [B cannot be cast to
java.lang.Comparable
at
org.apache.ignite.internal.binary.BinaryObjectImpl.compareForDml(BinaryObjectImpl.java:863)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender$BatchEntryComparator.compare(DmlBatchSender.java:423)
at java.util.TreeMap.compare(TreeMap.java:1295)
at java.util.TreeMap.put(TreeMap.java:538)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender$Batch.put(DmlBatchSender.java:368)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender.add(DmlBatchSender.java:118)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.doUpdate(DmlUtils.java:252)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:168)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2765)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2625)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2555)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1167)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1093)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2293)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2289)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:35)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2805)
... 19 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12312) JDBC thin: it's not possible to use LocalDate/LocalTime/LocalDateTime as value in where _key=.
Alexander Lapin created IGNITE-12312:
Summary: JDBC thin: it's not possible to use
LocalDate/LocalTime/LocalDateTime as value in where _key=.
Key: IGNITE-12312
URL: https://issues.apache.org/jira/browse/IGNITE-12312
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
JDBC thin: it's not possible to use LocalDateTime (converted internally to
java.sql.Timestamp) as value in where _key=.
In case of following query
{color:#172b4d}{{stmt.{color:#172b4d}executeQuery{color}({color:#36b37e}"SELECT
* FROM "{color} + tableName +{color:#36b37e}" where _key >=
PARSEDATETIME('2019-09-05 17:43:01.144', '-MM-dd HH:mm:ss.SSS') and _key <=
PARSEDATETIME('2019-09-05 17:43:01.144', '-MM-dd
HH:mm:ss.SSS')"{color});}}{color}
expected row would be returned, however in case of
{color:#172b4d}{{stmt.{color:#172b4d}executeQuery{color}({color:#36b37e}"SELECT
* FROM "{color} + tableName +{color:#36b37e}" where _key =
PARSEDATETIME('2019-09-05 17:43:01.144', '-MM-dd
HH:mm:ss.SSS')"{color});}}{color}
no rows would be returned.
Reproducers:
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalDateTimeDataType
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalTimeDataType
org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalDateDataType
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12311) DELETE by PK doesn't work if PK is TINYINT or SMALLINT.
Alexander Lapin created IGNITE-12311:
Summary: DELETE by PK doesn't work if PK is TINYINT or SMALLINT.
Key: IGNITE-12311
URL: https://issues.apache.org/jira/browse/IGNITE-12311
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
1. Start bin\ignite.bat
2. Start bin\sqlline.bat -d org.apache.ignite.IgniteJdbcThinDriver -u
jdbc:ignite:thin://127.0.0.1/distributedJoins=true
3. Execute operations:
{color:#172b4d}{{{color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
create table t1 (a tinyint {color:#0052cc}null{color} primary key, b
VARCHAR);{color:#6554c0}No{color} rows affected
({color:#0052cc}0{color},{color:#0052cc}198{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
insert into t1 values ({color:#0052cc}1{color},
{color:#36b37e}'a'{color});{color:#0052cc}1{color} row affected
({color:#0052cc}0{color},{color:#0052cc}036{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
select * from
t1;+++|
{color:#6554c0}A{color}|
{color:#6554c0}B{color}
|+++|
{color:#0052cc}1{color} | a
|+++{color:#0052cc}1{color}
row selected ({color:#0052cc}0{color},{color:#0052cc}048{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
update t1 set b = {color:#36b37e}'b'{color} where
a={color:#0052cc}1{color};{color:#0052cc}1{color} row affected
({color:#0052cc}0{color},{color:#0052cc}018{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
select * from
t1;+++|
{color:#6554c0}A{color}|
{color:#6554c0}B{color}
|+++|
{color:#0052cc}1{color} | b
|+++{color:#0052cc}1{color}
row selected ({color:#0052cc}0{color},{color:#0052cc}006{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
delete from t1 where a={color:#0052cc}1{color};{color:#6554c0}No{color} rows
affected ({color:#0052cc}0{color},{color:#0052cc}003{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>
select * from
t1;+++|
{color:#6554c0}A{color}|
{color:#6554c0}B{color}
|+++|
{color:#0052cc}1{color} | b
|+++{color:#0052cc}1{color}
row selected ({color:#0052cc}0{color},{color:#0052cc}006{color}
seconds){color:#0052cc}0{color}:
jdbc:ignite:thin://{color:#0052cc}127.0{color}{color:#0052cc}.0{color}{color:#0052cc}.1{color}/>}}{color}
Same behavoir is for SMALLINT type
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12310) SortedEvictionPolicy fails with java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang. in case of Byte, Short, Long, etc.
Alexander Lapin created IGNITE-12310:
Summary: SortedEvictionPolicy fails with
java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang. in case of Byte, Short, Long, etc.
Key: IGNITE-12310
URL: https://issues.apache.org/jira/browse/IGNITE-12310
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
{code:java}
java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
at java.lang.Integer.compareTo(Integer.java:52)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:359)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$DefaultHolderComparator.compare(SortedEvictionPolicy.java:347)
at
java.util.concurrent.ConcurrentSkipListMap.cpr(ConcurrentSkipListMap.java:655)
at
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:835)
at
java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1979)
at
org.apache.ignite.internal.util.GridConcurrentSkipListSet.add(GridConcurrentSkipListSet.java:142)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy$GridConcurrentSkipListSetEx.add(SortedEvictionPolicy.java:397)
at
org.apache.ignite.cache.eviction.sorted.SortedEvictionPolicy.touch(SortedEvictionPolicy.java:175)
at
org.apache.ignite.cache.eviction.AbstractEvictionPolicy.onEntryAccessed(AbstractEvictionPolicy.java:87)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:228)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.touch(GridCacheMapEntry.java:5052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3104)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1905)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:814)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:666)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1104)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAll0(GridDhtAtomicCache.java:654)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAll(GridCacheAdapter.java:2513)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.putAll(IgniteCacheProxyImpl.java:1264)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:863)
at
org.apache.ignite.internal.processors.cache.GridCacheDataTypesCoverageTest.checkBasicCacheOperations(GridCacheDataTypesCoverageTest.java:624)
at
org.apache.ignite.internal.processors.cache.GridCacheDataTypesCoverageTest.testLongDataType(GridCacheDataTypesCoverageTest.java:347)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2075)
at java.lang.Thread.run(Thread.java:748)
[2019-08-23 12:26:39,784][INFO ][main][root] >>> Stoppin
[jira] [Created] (IGNITE-12308) Data types coverage for basic sql operations.
Alexander Lapin created IGNITE-12308: Summary: Data types coverage for basic sql operations. Key: IGNITE-12308 URL: https://issues.apache.org/jira/browse/IGNITE-12308 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Lapin Fix For: 2.8 For more details see: https://issues.apache.org/jira/browse/IGNITE-12307 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12307) Data types coverage for basic cache operations.
Alexander Lapin created IGNITE-12307: Summary: Data types coverage for basic cache operations. Key: IGNITE-12307 URL: https://issues.apache.org/jira/browse/IGNITE-12307 Project: Ignite Issue Type: Task Components: cache Reporter: Alexander Lapin Fix For: 2.8 The data types used for testing are not collected at single test/suite and it's not clear which types are covered and which not. We should redesign the coverage and cover following Operations: * put * putAll * remove * removeAll * get * getAll Data Types both for value and key (if applicable): * byte/Byte * short/Short * int/Integer * long/Long * float/Float * double/Double * boolean/Boolean * char/String * Arrays of primitives (single type) * Arrays of Objects (different types) * Collections ** List ** Queue ** Set * Objects based on: ** primitives only ** primitives + collections ** primitives + collections + nested objects Persistance mode: * in-memory * PDS Cache configurations: * atomic/tx/mvcc * replication/partitioned * TTL/no TTL * QueryEntnty * Backups=1,2 * EvictionPolicy * writeSynchronizationMode(FULL_SYNC, PRIMARY_SYNC, FULL_ASYNC) * onheapCacheEnabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12036) Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account
Alexander Lapin created IGNITE-12036: Summary: Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account Key: IGNITE-12036 URL: https://issues.apache.org/jira/browse/IGNITE-12036 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin VisorBaselineTask doesn't allow to add() offline baseline node, but allows to set() collection of nodes where at least one is offline and doesn’t belong to current BLT. We should prohibit passing offline nodes to setBaselineTopology(…) (in case they are not part of current BLT): otherwise we won't be able to calculate affinity in case NodeFilter is configured. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11705) Jdbc Thin: add ability to control affinity cache size.
Alexander Lapin created IGNITE-11705: Summary: Jdbc Thin: add ability to control affinity cache size. Key: IGNITE-11705 URL: https://issues.apache.org/jira/browse/IGNITE-11705 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Within AffinityCache there are two properties DISTRIBUTIONS_CACHE_LIMIT and SQL_CACHE_LIMIT that are hard coded. We should add an ability to control given parameters within some sort of configuration. IgniteSystemProperties is not an option however. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11661) Jdbc Thin: Implement tests for best effort affinity
Alexander Lapin created IGNITE-11661: Summary: Jdbc Thin: Implement tests for best effort affinity Key: IGNITE-11661 URL: https://issues.apache.org/jira/browse/IGNITE-11661 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Test plan draft. # Сheck that requests go to the expected number of nodes for different combinations of conditions ** Transactional *** Without params Select * Different partition tree options(All/NONE/Group/CONST) produced by different query types. Dml * - // - *** With params - // - ** Non-Transactional *** - // - # Check that request/response functionality works fine if server response lacks partition result. # Check that partition result is supplied only in case of rendezvous affinity function without custom filters. # Check that best effort functionality works fine for different partitions count. # Сheck that a change in topology leads to jdbc thin affinity cache invalidation. ## Topology changed during partition result retrieval. ## Topology changed during cache distribution retrieval. ## Topology changed during best-effort-affinity-unrelated query. # Check that jdbc thin best effort affinity works fine if cache is full and new data still coming. For given case we probably should decrease cache boundaries. # Check that proper connection is used if set of nodes we are connected to and set of nodes derived from partitions ## Fully intersect; ## Partially intersect; ## Doesn't intersect, i.e. ||User Specified||Derived from partitons|| |host:port1 - > UUID1 host:port2 -> UUID2|partition1 -> UUID3| No intersection, so random connection should be used. # Check client reconnection after failure. # Check that jdbc thin best effort affinity skipped if it is switched off. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11566) JDBC Thin: add support for custom partitions count within the client side best effort affinity
Alexander Lapin created IGNITE-11566: Summary: JDBC Thin: add support for custom partitions count within the client side best effort affinity Key: IGNITE-11566 URL: https://issues.apache.org/jira/browse/IGNITE-11566 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11565) JDBC Thin: add connection resolution in case of multiple partitons
Alexander Lapin created IGNITE-11565: Summary: JDBC Thin: add connection resolution in case of multiple partitons Key: IGNITE-11565 URL: https://issues.apache.org/jira/browse/IGNITE-11565 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin At this moment, we only calculate target node id if there is none or single partitions. Implement node resolution logic for multiple partitions case. The basic idea is that we should use random node from one of presented in connections if it's derived from calculated partitions or totally random if there are no matches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11507) SQL: Ensure that affinity topology version doesn't change during PartitionResult construction/application.
Alexander Lapin created IGNITE-11507: Summary: SQL: Ensure that affinity topology version doesn't change during PartitionResult construction/application. Key: IGNITE-11507 URL: https://issues.apache.org/jira/browse/IGNITE-11507 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Lapin Fix For: 2.8 Currently some actions might be performed (for example cache removal) during PartitionResult construction, so it might become invalid. Besides that it's not possible to associate PartitionResult with affinity topology version, so it is impossible to guarantee that the partition result is used on the same version on which it was built. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11321) JDBC Thin: implement nodes multi version support in case of best effort affinity mode.
Alexander Lapin created IGNITE-11321: Summary: JDBC Thin: implement nodes multi version support in case of best effort affinity mode. Key: IGNITE-11321 URL: https://issues.apache.org/jira/browse/IGNITE-11321 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Fix For: 2.8 Currently in case of best effort affinity mode we throw SQLException if the version of any of the nodes to which we connect is different from the version of all other nodes.Given logic needs to be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11320) JDBC Thin: add support for individual reconnect in case of best effort affinity mode.
Alexander Lapin created IGNITE-11320: Summary: JDBC Thin: add support for individual reconnect in case of best effort affinity mode. Key: IGNITE-11320 URL: https://issues.apache.org/jira/browse/IGNITE-11320 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Fix For: 2.8 Currently in case of best effort affinity mode we either connect to all nodes specified by user or throw SQLException. Given logic needs to be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11314) JDBC Thin: add transaction-scoped flag to JdbcHandler's responses.
Alexander Lapin created IGNITE-11314: Summary: JDBC Thin: add transaction-scoped flag to JdbcHandler's responses. Key: IGNITE-11314 URL: https://issues.apache.org/jira/browse/IGNITE-11314 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Within the context of best effort affinity, and particular, multi-connections, it's necessary to use "sticky" connections in case of "next page" requests, transactions, streaming and copy. In order to implement transaction-based-sticky use case we need to know whether we are in transnational scope or not. So JdbcRequestHandler ought to retrieve query execution plan, analyse whether transaction exists and propagate corresponding flag to the client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11309) JDBC Thin: add flag or property to disable best effort affinity
Alexander Lapin created IGNITE-11309: Summary: JDBC Thin: add flag or property to disable best effort affinity Key: IGNITE-11309 URL: https://issues.apache.org/jira/browse/IGNITE-11309 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.8 Reporter: Alexander Lapin It's necessary to have an ability to disable best effort affinity among thin clients including thin jdbc client. It's not obvious whether it should be flag in connection string, app properties or some other place, so research required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11287) JDBC Thin: best effort affinity
Alexander Lapin created IGNITE-11287: Summary: JDBC Thin: best effort affinity Key: IGNITE-11287 URL: https://issues.apache.org/jira/browse/IGNITE-11287 Project: Ignite Issue Type: Task Reporter: Alexander Lapin It's an umbrella ticket for implementing [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] within the scope of JDBC Thin driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11258) JDBC: update connection setup logic.
Alexander Lapin created IGNITE-11258: Summary: JDBC: update connection setup logic. Key: IGNITE-11258 URL: https://issues.apache.org/jira/browse/IGNITE-11258 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Lapin # On thin client startup it connects to *all* *nodes* provided by user by client configuration. # Upon handshake server returns its UUID to client. # By the end of the startup procedure, client have open connections to all available server nodes and the following mapping (*nodeMap*): [UUID => Connection]. Connection to all nodes helps to identify available nodes, but can lead to significant delay, when thin client is used on a large cluster with a long IP list provided by user. To lower this delay, asynchronous establishment of connections can be used. For more information see [IEP-23: Best Effort Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11257) JDBC: update handshake protocol so that the node returns its UUID.
Alexander Lapin created IGNITE-11257: Summary: JDBC: update handshake protocol so that the node returns its UUID. Key: IGNITE-11257 URL: https://issues.apache.org/jira/browse/IGNITE-11257 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Lapin Fix For: 2.8 Add node UUID to successful handshake response. For more information see [IEP-23: Best Effort Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11197) SQL:Ability to resolve partiton for temporal data types.
Alexander Lapin created IGNITE-11197: Summary: SQL:Ability to resolve partiton for temporal data types. Key: IGNITE-11197 URL: https://issues.apache.org/jira/browse/IGNITE-11197 Project: Ignite Issue Type: Bug Components: sql Reporter: Alexander Lapin Within org.apache.ignite.internal.sql.optimizer.affinity.PartitionUtils#convert it's now possible to convert following data types: * BOOLEAN, * BYTE, * SHORT, * INT, * LONG, * FLOAT, * DOUBLE, * STRING, * DECIMAL, * UUID; Following temporal data types should also be supported: * DATE, * TIME, * TIMESTAMP The most critical part here is that convertation result should be exactly the same as H2 convertation result (see org.apache.ignite.internal.processors.query.h2.H2Utils#convert), in other case partitions might be resolved incorrectly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11019) SQL: explain plan of a simple query contains merge table
Alexander Lapin created IGNITE-11019:
Summary: SQL: explain plan of a simple query contains merge table
Key: IGNITE-11019
URL: https://issues.apache.org/jira/browse/IGNITE-11019
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Alexander Lapin
Fix For: 2.8
In case of simple* query like following "select * from Organization org where
org._KEY = 1 or org._KEY = 2" explain plan will contain merge table despite the
fact that it's skipped within regular query flow.
{code:java|title=GridReduceQueryExecutor#query}
final boolean skipMergeTbl = !qry.explain() && qry.skipMergeTable()
{code}
Explain plan output:
: [SELECT
ORG__Z0.NAME AS __C0_0,
ORG__Z0.DEBTCAPITAL AS __C0_1,
ORG__Z0.ID AS __C0_2
FROM "orgBetweenTest".ORGANIZATION ORG__Z0
/* "orgBetweenTest"."_key_PK": _KEY IN(1, 2) */
WHERE ORG__Z0._KEY IN(1, 2)]
: [SELECT
__C0_0 AS NAME,
__C0_1 AS DEBTCAPITAL,
__C0_2 AS ID
FROM PUBLIC.__T0
/* "orgBetweenTest"."merge_scan" */]
*simple query by means of GridSqlQuery#simpleQuery
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10893) ClientListenerResponse.status uses codes both from IgniteQueryErrorCode and ClientListenerResponse itself.
Alexander Lapin created IGNITE-10893: Summary: ClientListenerResponse.status uses codes both from IgniteQueryErrorCode and ClientListenerResponse itself. Key: IGNITE-10893 URL: https://issues.apache.org/jira/browse/IGNITE-10893 Project: Ignite Issue Type: Bug Components: sql Reporter: Alexander Lapin Fix For: 2.8 ClientListenerResponse.status might be set as one of IgniteQueryErrorCode constants. Besides that, ClientListenerResponse has few codes as constants itself. These codes may intersect, in particular, ClientListenerResponse.STATUS_FAILED == IgniteQueryErrorCode.UNKNOWN. Seems that it works fine at the moment, however it looks unsafe. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10836) Add documentation for jdbc thin query cancel
Alexander Lapin created IGNITE-10836: Summary: Add documentation for jdbc thin query cancel Key: IGNITE-10836 URL: https://issues.apache.org/jira/browse/IGNITE-10836 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Alexander Lapin Fix For: 2.8 Query cancel for jdbc thin was implemented. At least error codes page ([https://apacheignite-sql.readme.io/docs/error-codes-27)] should be updated, cause new error code (57014 Query cancelled) was added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10340) JDBC thin: in some cases it's not possible to convert IllegalStateException to SQLException with appropriate message.
Alexander Lapin created IGNITE-10340:
Summary: JDBC thin: in some cases it's not possible to convert
IllegalStateException to SQLException with appropriate message.
Key: IGNITE-10340
URL: https://issues.apache.org/jira/browse/IGNITE-10340
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.6
Reporter: Alexander Lapin
In case of using already closed JdbcBulkLoadProcessor following exception might
be thrown:
{code}
[12:04:15] (err) Error processing file batchjava.lang.IllegalStateException:
Data streamer has been closed.
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closedException(DataStreamerImpl.java:1081)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.lock(DataStreamerImpl.java:443)
...
{code}
However, cause cancellationReason is null it's not possible to detect whether
query was cancelled or not:
{code:title=DataStreamerImpl.java|borderStyle=solid}
private void closedException() {
throw new IllegalStateException("Data streamer has been closed.",
cancellationReason);
}
{code}
Reproducer:
{code}
org.apache.ignite.jdbc.thin.JdbcThinStatementCancelSelfTest
#testExpectSQLExceptionAndAFAPControlRetrievalAfterCancelingLongRunningFileUpload
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
