[jira] [Created] (IGNITE-13341) OOME is ignored if thrown in a client connector thread
Stanislav Lukyanov created IGNITE-13341:
---
Summary: OOME is ignored if thrown in a client connector thread
Key: IGNITE-13341
URL: https://issues.apache.org/jira/browse/IGNITE-13341
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Stanislav Lukyanov
If a thin client operation causes OOME then the thread will die and an error
will be logged, but that's all. The clients are left hanging and waiting for
reply until timeout.
Correct behavior in this case would be to trigger Failure Handler.
Example of the error:
{code}
Exception in thread "client-connector-#69%xxx%" java.lang.OutOfMemoryError:
Java heap space
Aug 08, 2020 7:08:43 AM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Runtime error caught during grid runnable execution: GridWorker
[name=message-received-notify, igniteInstanceName=xxx, finished=false,
heartbeatTs=1596859722580, hashCode=1209004925, interrupted=false,
runner=client-connector-#66%xxx%]
java.lang.OutOfMemoryError: Java heap space
at
org.apache.ignite.internal.binary.streams.BinaryMemoryAllocatorChunk.reallocate(BinaryMemoryAllocatorChunk.java:68)
at
org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.ensureCapacity(BinaryHeapOutputStream.java:64)
at
org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.unsafeEnsure(BinaryAbstractOutputStream.java:261)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteBinaryObject(BinaryWriterExImpl.java:970)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:756)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:231)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:164)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:151)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:523)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObject(BinaryWriterExImpl.java:1502)
at
org.apache.ignite.internal.processors.platform.client.ClientObjectResponse.encode(ClientObjectResponse.java:43)
at
org.apache.ignite.internal.processors.platform.client.ClientMessageParser.encode(ClientMessageParser.java:459)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:203)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:49)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:278)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:108)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:135)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:69)
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)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13340) copyOnRead=false doesn't work for byte array values
Stanislav Lukyanov created IGNITE-13340: --- Summary: copyOnRead=false doesn't work for byte array values Key: IGNITE-13340 URL: https://issues.apache.org/jira/browse/IGNITE-13340 Project: Ignite Issue Type: Bug Components: cache Reporter: Stanislav Lukyanov If near cache is used and copyOnRead=false is set then the Java object should only be created on the first read, and all subsequent reads must use the same copy. However, when byte array value is used (e.g. `put(42, new byte[100]`) then the copying is done on every read. It seems that the reason is that byte array values have their own implementation of `CacheObject` - `CacheObjectByteArrayImpl`. That implementation doesn't use `CacheObjectValueContext::storeValue` which controls whether copying needs to be done; CacheObjectImpl uses it. Need to correctly implement copyOnRead=false for caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13330) Document java thin client features implemented in 2.8 and 2.9 release
[ https://issues.apache.org/jira/browse/IGNITE-13330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173372#comment-17173372 ] Aleksey Plekhanov commented on IGNITE-13330: [~Artem Budnikov], [~abudnikov] can you please have a look? > Document java thin client features implemented in 2.8 and 2.9 release > - > > Key: IGNITE-13330 > URL: https://issues.apache.org/jira/browse/IGNITE-13330 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: important > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Document implemented in 2.8 and 2.9 release features for java thin client: > * Partition awareness > * Cluster API > * Cluster group API > * Compute > * Services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13331) Document .NET thin client features implemented in 2.9 release
[ https://issues.apache.org/jira/browse/IGNITE-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13331: --- Description: Document .NET thin client features: * Cluster API * Cluster group API * Compute API * Server discovery was: Document .NET thin client features: * Cluster API * Cluster group API * Compute API * Server discovery * Continues queries > Document .NET thin client features implemented in 2.9 release > - > > Key: IGNITE-13331 > URL: https://issues.apache.org/jira/browse/IGNITE-13331 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Priority: Major > Labels: important > Fix For: 2.9 > > > Document .NET thin client features: > * Cluster API > * Cluster group API > * Compute API > * Server discovery -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13323) GridDhtPartitionsExchangeFuture logging improvements
[ https://issues.apache.org/jira/browse/IGNITE-13323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov reassigned IGNITE-13323: --- Assignee: (was: Yaroslav Molochkov) > GridDhtPartitionsExchangeFuture logging improvements > > > Key: IGNITE-13323 > URL: https://issues.apache.org/jira/browse/IGNITE-13323 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Yaroslav Molochkov >Priority: Major > > Firstly, logging in said class should be improved to address possible cluster > topology/connectivity issues: > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#processFullMessage, > upon entering that method and before critical section begins we should log > that at info level. This way we won't have to speculate if thread is waiting > on a lock to > not.(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#mux) > Secondly, > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#sendAllPartitions. > Logging should reflect the amount of nodes that should receive messages > (collection that is sent to said method) and the amount of nodes that should > receive the message (or, in other words, we successfully managed to send the > message to a particular node, then sum it up). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13330) Document java thin client features implemented in 2.8 and 2.9 release
[ https://issues.apache.org/jira/browse/IGNITE-13330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-13330: -- Assignee: Aleksey Plekhanov > Document java thin client features implemented in 2.8 and 2.9 release > - > > Key: IGNITE-13330 > URL: https://issues.apache.org/jira/browse/IGNITE-13330 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: important > Fix For: 2.9 > > > Document implemented in 2.8 and 2.9 release features for java thin client: > * Partition awareness > * Expiration policy > * Cluster API > * Cluster group API > * Compute > * Services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13330) Document java thin client features implemented in 2.8 and 2.9 release
[ https://issues.apache.org/jira/browse/IGNITE-13330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13330: --- Description: Document implemented in 2.8 and 2.9 release features for java thin client: * Partition awareness * Cluster API * Cluster group API * Compute * Services was: Document implemented in 2.8 and 2.9 release features for java thin client: * Partition awareness * Expiration policy * Cluster API * Cluster group API * Compute * Services > Document java thin client features implemented in 2.8 and 2.9 release > - > > Key: IGNITE-13330 > URL: https://issues.apache.org/jira/browse/IGNITE-13330 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: important > Fix For: 2.9 > > > Document implemented in 2.8 and 2.9 release features for java thin client: > * Partition awareness > * Cluster API > * Cluster group API > * Compute > * Services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had been closed before.
[
https://issues.apache.org/jira/browse/IGNITE-13102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173146#comment-17173146
]
Stanilovsky Evgeny commented on IGNITE-13102:
-
[~ksirotkin] looks good, plz remove mentioned by [~antonovsergey93] stub, rerun
appropriate TC suite, probably you can check it locally and proceed.
> IgniteCache#isClosed() returns false on server node even if the cache had
> been closed before.
> -
>
> Key: IGNITE-13102
> URL: https://issues.apache.org/jira/browse/IGNITE-13102
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Sergey Antonov
>Assignee: Konstantin Sirotkin
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IgniteCache#isClosed() still returns {{false}} even after
> {{IgniteCache#close()}}. Only server nodes affect by this problem.
> Simple reproducer:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx node = startGrid(0);
> IgniteCache cache =
> node.getOrCreateCache(DEFAULT_CACHE_NAME);
> assertFalse(cache.isClosed());
> cache.close();
> // java.lang.AssertionError
> assertTrue(cache.isClosed());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13327) Add a metric for processed keys when rebuilding indexes.
[ https://issues.apache.org/jira/browse/IGNITE-13327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173122#comment-17173122 ] Kirill Tkalenko edited comment on IGNITE-13327 at 8/7/20, 12:58 PM: [~ivan.glukos] Please make review. was (Author: ktkale...@gridgain.com): [~ivan.glukos] > Add a metric for processed keys when rebuilding indexes. > > > Key: IGNITE-13327 > URL: https://issues.apache.org/jira/browse/IGNITE-13327 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > It would be useful to understand how long it will take to rebuild indexes, > since there can be a lot of data and indexes. Now there are following metrics > that allow to estimate approximately how many indexes are left to rebuild: > # IsIndexRebuildInProgress - rebuilding cache indexes in the process; > # IndexBuildCountPartitionsLeft - remaining number of partitions (by cache > group) to rebuild indexes for. > For a more accurate estimate, I suggest adding a metric for caches "Number of > keys processed when rebuilding indexes" with the name > "IndexRebuildKeyProcessed". This way we can estimate for cache how much index > rebuilding will take. To do this, we can get "CacheSize" and use new metric > to find out how many keys are left to process. > I also suggest adding methods: > # org.apache.ignite.cache.CacheMetrics#getIndexRebuildKeyProcessed > # org.apache.ignite.cache.CacheMetrics#IsIndexRebuildInProgress -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13327) Add a metric for processed keys when rebuilding indexes.
[ https://issues.apache.org/jira/browse/IGNITE-13327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173121#comment-17173121 ] Kirill Tkalenko commented on IGNITE-13327: -- I checked *TutorialStepByStepExampleSelfTest.testExampletest* on master it also fell. https://ci.ignite.apache.org/viewLog.html?buildId=5526816; > Add a metric for processed keys when rebuilding indexes. > > > Key: IGNITE-13327 > URL: https://issues.apache.org/jira/browse/IGNITE-13327 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > It would be useful to understand how long it will take to rebuild indexes, > since there can be a lot of data and indexes. Now there are following metrics > that allow to estimate approximately how many indexes are left to rebuild: > # IsIndexRebuildInProgress - rebuilding cache indexes in the process; > # IndexBuildCountPartitionsLeft - remaining number of partitions (by cache > group) to rebuild indexes for. > For a more accurate estimate, I suggest adding a metric for caches "Number of > keys processed when rebuilding indexes" with the name > "IndexRebuildKeyProcessed". This way we can estimate for cache how much index > rebuilding will take. To do this, we can get "CacheSize" and use new metric > to find out how many keys are left to process. > I also suggest adding methods: > # org.apache.ignite.cache.CacheMetrics#getIndexRebuildKeyProcessed > # org.apache.ignite.cache.CacheMetrics#IsIndexRebuildInProgress -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13327) Add a metric for processed keys when rebuilding indexes.
[
https://issues.apache.org/jira/browse/IGNITE-13327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173118#comment-17173118
]
Ignite TC Bot commented on IGNITE-13327:
{panel:title=Branch: [pull/8126/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5526812]]
* IgniteExamplesSelfTestSuite: TutorialStepByStepExampleSelfTest.testExample -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8126/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5525629]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=1d378ac3-7651-445d-a76e-48be0636e231, topVer=0,
msgTemplate=null, span=null, nodeId8=8e09d4dc, msg=, type=NODE_JOINED,
tstamp=1596744332378], val2=AffinityTopologyVersion
[topVer=8389012778780031521, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=1d378ac3-7651-445d-a76e-48be0636e231, topVer=0,
msgTemplate=null, span=null, nodeId8=8e09d4dc, msg=, type=NODE_JOINED,
tstamp=1596744332378], val2=AffinityTopologyVersion
[topVer=8389012778780031521, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f1bca65c371-d457ff8c-2ae1-4a90-a4fa-1665e2ff7b7b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=2f9d86a9-13c3-4633-8a10-5f8aa827ce8b, topVer=0, msgTemplate=null,
span=null, nodeId8=2f9d86a9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596744332378]], val2=AffinityTopologyVersion
[topVer=-5874992666583183135, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f1bca65c371-d457ff8c-2ae1-4a90-a4fa-1665e2ff7b7b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=2f9d86a9-13c3-4633-8a10-5f8aa827ce8b, topVer=0, msgTemplate=null,
span=null, nodeId8=2f9d86a9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596744332378]], val2=AffinityTopologyVersion
[topVer=-5874992666583183135, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5525630]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bb086e8c-8cfb-4761-8289-e896eac00884, topVer=0,
msgTemplate=null, span=null, nodeId8=9f0efa02, msg=, type=NODE_JOINED,
tstamp=1596744256139], val2=AffinityTopologyVersion
[topVer=-6607061135612521726, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bb086e8c-8cfb-4761-8289-e896eac00884, topVer=0,
msgTemplate=null, span=null, nodeId8=9f0efa02, msg=, type=NODE_JOINED,
tstamp=1596744256139], val2=AffinityTopologyVersion
[topVer=-6607061135612521726, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f8acf55c371-059a8177-ff39-46ed-b0b9-dec57149fabf, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=f07361c6-1fcb-4a67-a005-2d2441c68229, topVer=0, msgTemplate=null,
span=null, nodeId8=f07361c6, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596744256139]], val2=AffinityTopologyVersion
[topVer=7320540078826162217, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=f8acf55c371-059a8177-ff39-46ed-b0b9-dec57149fabf, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=f07361c6-1fcb-4a67-a005-2d2441c68229, topVer=0, msgTemplate=null,
span=null, nodeId8=f07361c6, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596744256139]], val2=AffinityTopologyVersion
[topVer=7320540078826162217, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[
https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173116#comment-17173116
]
Alexey Goncharuk commented on IGNITE-5038:
--
[~maliev], a few comments:
* Why is thread-local only set to one value? I think we should use try-finally
to always keep the current behavior.
* We need to add tests to verify that user class loaders do not leak to the
static cache. Also, what happens if I call {{deserialize()}} and pass system
class loader?
[~gvvinblade] can you take a look at the change as well?
> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: features
> Attachments: results-compound-20170802.zip,
> results-compound-20170808.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize
> an object using a context class loader if it failed to do so with a custom
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13098) TcpCommunicationSpi split to independent classes
[
https://issues.apache.org/jira/browse/IGNITE-13098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173013#comment-17173013
]
Ignite TC Bot commented on IGNITE-13098:
{panel:title=Branch: [pull/8057/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8057/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5525471]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=820e4b86-6df2-4d44-af89-6c97410dc97a, topVer=0,
msgTemplate=null, span=null, nodeId8=d03dbb38, msg=, type=NODE_JOINED,
tstamp=1596741683852], val2=AffinityTopologyVersion
[topVer=8378924801797081360, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=820e4b86-6df2-4d44-af89-6c97410dc97a, topVer=0,
msgTemplate=null, span=null, nodeId8=d03dbb38, msg=, type=NODE_JOINED,
tstamp=1596741683852], val2=AffinityTopologyVersion
[topVer=8378924801797081360, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=09a8835c371-4c0998e2-b4ac-448a-a292-806b69b72e7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=4d31c3b8-b825-447a-9ada-1f616602d659, topVer=0, msgTemplate=null,
span=null, nodeId8=4d31c3b8, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596741683852]], val2=AffinityTopologyVersion
[topVer=3600646592563058421, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=09a8835c371-4c0998e2-b4ac-448a-a292-806b69b72e7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=4d31c3b8-b825-447a-9ada-1f616602d659, topVer=0, msgTemplate=null,
span=null, nodeId8=4d31c3b8, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596741683852]], val2=AffinityTopologyVersion
[topVer=3600646592563058421, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5525472]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=26cf835c371-7d8273ec-cef4-4d2a-866e-dec71312fb9a, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=eea2b362-d4eb-4b61-960f-df75b3109e20, topVer=0, msgTemplate=null,
span=null, nodeId8=eea2b362, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596741712990]], val2=AffinityTopologyVersion
[topVer=3717633026555016160, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f621a928-34cd-4adb-b5dc-3d99c22ceb5b, topVer=0,
msgTemplate=null, span=null, nodeId8=cd5d6b7f, msg=, type=NODE_JOINED,
tstamp=1596741712990], val2=AffinityTopologyVersion
[topVer=-172409504567755083, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f621a928-34cd-4adb-b5dc-3d99c22ceb5b, topVer=0,
msgTemplate=null, span=null, nodeId8=cd5d6b7f, msg=, type=NODE_JOINED,
tstamp=1596741712990], val2=AffinityTopologyVersion
[topVer=-172409504567755083, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=26cf835c371-7d8273ec-cef4-4d2a-866e-dec71312fb9a, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=eea2b362-d4eb-4b61-960f-df75b3109e20, topVer=0, msgTemplate=null,
span=null, nodeId8=eea2b362, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596741712990]], val2=AffinityTopologyVersion
[topVer=3717633026555016160, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5525494buildTypeId=IgniteTests24Java8_RunAll]
> TcpCommunicationSpi split to independent classes
>
>
> Key: IGNITE-13098
> URL: https://issues.apache.org/jira/browse/IGNITE-13098
[jira] [Created] (IGNITE-13339) Sql query fails with NullPointerException caused by calling CAST in order by clause
Taras Ledkov created IGNITE-13339:
-
Summary: Sql query fails with NullPointerException caused by
calling CAST in order by clause
Key: IGNITE-13339
URL: https://issues.apache.org/jira/browse/IGNITE-13339
Project: Ignite
Issue Type: Test
Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.9
Sql statements to reproduce:
CREATE TABLE Person(ID INTEGER PRIMARY KEY, NAME VARCHAR(100));
INSERT INTO Person(ID, NAME) VALUES (1, 'Ed'), (2, 'Ann'), (3, 'Emma');
select name,id from Person order by CAST(id as long)
Result:
{code:java}
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2572)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2505)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2463)
at
org.apache.ignite.internal.visor.query.VisorQueryUtils.lambda$scheduleQueryStart$0(VisorQueryUtils.java:409)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7157)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:826)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
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: null
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3050)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2531)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2569)
... 9 more
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlFunction.getSQL(GridSqlFunction.java:124)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuery.getSortLimitSQL(GridSqlQuery.java:171)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlSelect.getSQL(GridSqlSelect.java:182)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:371)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split0(GridSqlQuerySplitter.java:280)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:212)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:501)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:173)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:132)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1115)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2515)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2511)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:35)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3027)
... 11 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had been closed before.
[
https://issues.apache.org/jira/browse/IGNITE-13102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172987#comment-17172987
]
Konstantin Sirotkin commented on IGNITE-13102:
--
[~zstan], can you review please?
> IgniteCache#isClosed() returns false on server node even if the cache had
> been closed before.
> -
>
> Key: IGNITE-13102
> URL: https://issues.apache.org/jira/browse/IGNITE-13102
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Sergey Antonov
>Assignee: Konstantin Sirotkin
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteCache#isClosed() still returns {{false}} even after
> {{IgniteCache#close()}}. Only server nodes affect by this problem.
> Simple reproducer:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx node = startGrid(0);
> IgniteCache cache =
> node.getOrCreateCache(DEFAULT_CACHE_NAME);
> assertFalse(cache.isClosed());
> cache.close();
> // java.lang.AssertionError
> assertTrue(cache.isClosed());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13183) Query timeout redesign
[
https://issues.apache.org/jira/browse/IGNITE-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172964#comment-17172964
]
Taras Ledkov commented on IGNITE-13183:
---
[~korlov], [~amashenkov] please review the patch.
> Query timeout redesign
> --
>
> Key: IGNITE-13183
> URL: https://issues.apache.org/jira/browse/IGNITE-13183
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation:*
> Now the query timeout is set up for each node separately by the node
> configuration. This property isn't propagated for the all nodes of cluster.
> Also user cannot change / disable query timeout without restart all nodes of
> the cluster.
> *Proposal fix:*
> - Adds the default query timeout property to the
> {{DistributedSqlConfiguration}}. Use distributed metastore to store and
> manage the property.
> - Deprecates the {{SqlConfiguration#defaultQueryTimeout}} property and use it
> to set up initial value of new property
> {{DistributedSqlConfiguration#defaultQueryTimeout}}
> - Adds info about explicit query timeout to {{GridH2QueryRequest}} (boolean
> flag {{explicitTimeout=false}} by default). This is necessary so that the
> default timeout may be used for queries from old nodes.
> - When query timeout is set to zero by old node ({{explicitTimeout=false}})
> we assume this is the default value and use default timeout for this queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13183) Query timeout redesign
[
https://issues.apache.org/jira/browse/IGNITE-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172963#comment-17172963
]
Ignite TC Bot commented on IGNITE-13183:
{panel:title=Branch: [pull/8107/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8107/head] Base: [master] : New Tests
(86)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}JDBC Driver{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5524191]]
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcThinDefaultTimeoutTest.testDefaultTimeout - PASSED{color}
{color:#8b}Queries 2{color} [[tests
77|https://ci.ignite.apache.org/viewLog.html?buildId=5524194]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout5 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout4 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout3 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout2 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout1 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaTest.testConcurrent - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaTest.testNoExplicitTimeout3 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaTest.testNoExplicitTimeout2 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaUpdateTest.testExplicitTimeout1 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testConcurrent - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testNoExplicitTimeout3 - PASSED{color}
... and 66 new tests
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5524263]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=fde83dd3-87dd-4051-b491-0b163cefee46, topVer=0,
msgTemplate=null, span=null, nodeId8=bdcff348, msg=, type=NODE_JOINED,
tstamp=1596718533648], val2=AffinityTopologyVersion
[topVer=-3224697000647306806, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=fde83dd3-87dd-4051-b491-0b163cefee46, topVer=0,
msgTemplate=null, span=null, nodeId8=bdcff348, msg=, type=NODE_JOINED,
tstamp=1596718533648], val2=AffinityTopologyVersion
[topVer=-3224697000647306806, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=41c47d3c371-3ab6251c-d509-44ad-b701-0cc77701629b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=7e8b4e55-07bd-416a-a2ed-bfed6bba2097, topVer=0, msgTemplate=null,
span=null, nodeId8=7e8b4e55, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596718533648]], val2=AffinityTopologyVersion
[topVer=2909400609439604322, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=41c47d3c371-3ab6251c-d509-44ad-b701-0cc77701629b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=7e8b4e55-07bd-416a-a2ed-bfed6bba2097, topVer=0, msgTemplate=null,
span=null, nodeId8=7e8b4e55, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596718533648]], val2=AffinityTopologyVersion
[topVer=2909400609439604322, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5524264]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f2d28df4-9fcc-47ba-963d-19fc77487bd7, topVer=0,
msgTemplate=null, span=null, nodeId8=2daefe40, msg=, type=NODE_JOINED,
tstamp=1596718676462], val2=AffinityTopologyVersion
[topVer=4325650850547293441, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f2d28df4-9fcc-47ba-963d-19fc77487bd7, topVer=0,
[jira] [Commented] (IGNITE-13306) CpuLoad metric return -1 under Java 11
[
https://issues.apache.org/jira/browse/IGNITE-13306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172953#comment-17172953
]
Denis Mekhanikov commented on IGNITE-13306:
---
[~slukyanov], this fix doesn't work. The issue is that we try to access a
public method in an internal class. In case of OpenJDK Hotspot it's
{{com.sun.management.internal.OperatingSystemImpl}}.
The proper way to fix this issue would be to cast the used
{{java.lang.management.OperatingSystemMXBean}} object to
{{com.sun.management.OperatingSystemMXBean}} and use the method
{{OperatingSystemMXBean#getSystemCpuLoad}} from there. But in this case we will
rely on the Sun interface (which we probably already rely on).
Another option is to access this method through reflection using the public
interface somehow, but not the implementation class. This is better than the
first option only in case if there is another implementation of
{{OperatingSystemMXBean}} that has a {{getSystemCpuLoad}} method.
> CpuLoad metric return -1 under Java 11
> --
>
> Key: IGNITE-13306
> URL: https://issues.apache.org/jira/browse/IGNITE-13306
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Start cluster under Java 11.
> Observed:
> CpuLoad metric will return -1
> Expected:
> Real CpuLoad.
> We investigated this issue and found that under Java 11 code failed with
> following trace:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to get property value
> [property=processCpuTime,
> obj=com.sun.management.internal.OperatingSystemImpl@1dd92fe2] at
> org.apache.ignite.internal.util.IgniteUtils.property(IgniteUtils.java:8306)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$MetricsUpdater.getCpuLoad(GridDiscoveryManager.java:3131)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$MetricsUpdater.run(GridDiscoveryManager.java:3093)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:364)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:233)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.base/java.lang.Thread.run(Thread.java:834) Caused by:
> java.lang.reflect.InaccessibleObjectException: Unable to make public long
> com.sun.management.internal.OperatingSystemImpl.getProcessCpuTime()
> accessible: module jdk.management does not "opens
> com.sun.management.internal" to unnamed module @35fb3008 at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:192) at
> org.apache.ignite.internal.util.IgniteUtils.property(IgniteUtils.java:8297)
> ... 6 more
> {code}
> Under Java 8 metric has expected value.
>
> Solution:
> The behaviour is expected because in Java 11 the CPU load metrics is moved to
> JDK internal module which is not accessible by default. Adding the following
> line to the jvm in which Ignite node is started should solve the issue:
> {noformat}
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
