Phani Introduction
Hello, I am Phani, currently working as an Engineer; interested in distributed systems, caches, persistent stores. I am looking forward to be part of this wonderful Ignite community and contribute. My jira user: psadusumilli. Please let me know if you need any information to add me to the group. -- Thank you Phani S Adusumilli
[jira] [Created] (IGNITE-13106) Java thin client: Race between response and notification for compute tasks
Aleksey Plekhanov created IGNITE-13106:
--
Summary: Java thin client: Race between response and notification
for compute tasks
Key: IGNITE-13106
URL: https://issues.apache.org/jira/browse/IGNITE-13106
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Java thin client {{ClientCompute.execute()}} method can hang due to race
between processing of COMPUTE_TASK_EXECUTE response and COMPUTE_TASK_FINISHED
notification.
These messages are strongly ordered on the server-side. But on the client-side
response and notification are processed by different threads. If notification
will be processed before response, task future will never be completed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
maintenance on repository.apache.org - may have broken an ignite staging repository
Hello ignite folks. I noticed that there is a staging repo on repository.apache.org, it's url is here: https://repository.apache.org/content/repositories/orgapacheignite-1249 I had to address some data integrity issues on repository.apache.org and that staging repo may have been a casualty. Likely the easiest fix would be to drop that repository and stage a new build. If you have any questions, please let me know. -Wes -- Wes Wannemacher
Re: [DISCUSSION] Key and Value fields with same name and SQL DML
Hi Alexey, Let me answer the second question first How would you change ICache interface which has this member? We will keep the key-value interface at least for backward compatibility. Plus, it might be preferred by those who use caching APIs only. So, this method will stay as-is. What whould be returned from the query like this "select > _key from cache" if we don't know the type of the key? ExpandoObject, > Tuple, > BinaryObject? I would go for BinaryObject. Also, I would review if we really need to make "_key" visible for application developers. - Denis On Tue, May 26, 2020 at 4:22 AM Alexey Sasov wrote: > Hello. Looks good. What whould be returned from the query like this "select > _key from cache" if we don't know the type of the key? ExpandoObject, > Tuple, > BinaryObject? How would you change ICache interface which has this member? > > /// Queries cache. > /// Query. > /// Cursor. > IQueryCursor> Query(QueryBase qry); > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
Hello, Kirill! I'd prefer to don't create a new implementation of a failure handler. We already have 4 different failure handlers. We will have 6 FH (StopNodeFH with exit code, StopNodeOrHaltFH with exit code), if we go your way. It won't make our product simpler and easier. I think, we must notify a user if the cluster node had been stopped by a failure handler. We can't achieve this goal without changing current FH behavior. So I propose to change it and stop the process with KILL_EXIT_CODE. But it would be nice if users will have a flag for avoiding process stop after a node failure. We can introduce a new JVM option or FH parameter for that reason. Of course, we must highlight this change in the release notes. пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл : > I think that [1] and [2] should not be changed, because we can kill > another client code in this jvm. > I suggest for these purposes to create a new [3] which will be like [1] > but with a call [4] after node stop. > Objections or comments? > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > [3] - org.apache.ignite.failure.FailureHandler > [4] - java.lang.System#exit > > 25.05.2020, 22:09, "Dmitriy Pavlov" : > > It seems reasonable to me. Also I would like to propose adding value of > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > without > > going to Java code. > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > : > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > >> > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > >> antonovserge...@gmail.com>: > >> > > >> >I've created the Ignite ticket for this improvement [1]. > >> > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > >> > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > antonovserge...@gmail.com >: > >> > > >> >> Hello, Igniters! > >> >> > >> >> I'd like to discuss behaviour of Ignite process exit code if the > node > >> was > >> >> stopped by failure handler [1][2]. At the moment ignite process > returns > >> >> exit code 0 after the stop in all scenarios, except runtime halt by > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > >> >> > >> >> My proposal: always finish Ignite process with code [3], if a node > was > >> >> stopped by FH. It could be helpful for administration purposes, you > can > >> >> distinguish normal node stop from node stop by FH on OS level. > >> >> > >> >> WDYT? > >> >> > >> >> [1] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > >> >> > >> >> [2] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > >> >> > >> >> [3] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > >> >> -- > >> >> BR, Sergey Antonov > >> >> > >> > > >> >-- > >> >BR, Sergey Antonov > >> > > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13105) Spring data 2.0 IgniteRepositoryQuery#transformQueryCursor contains cursor leak
Alexey Kuznetsov created IGNITE-13105:
-
Summary: Spring data 2.0
IgniteRepositoryQuery#transformQueryCursor contains cursor leak
Key: IGNITE-13105
URL: https://issues.apache.org/jira/browse/IGNITE-13105
Project: Ignite
Issue Type: Improvement
Components: springdata
Affects Versions: 2.8.1
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
Fix For: 2.9
This code produce cursor leak in RunningQueryManager:
If result set contains one ore more rows.
{code}
case ONE_VALUE:
Iterator iter = qryIter.iterator();
if (iter.hasNext())
return iter.next().get(0);
return null;
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13104) Spring data 2.0 IgniteRepositoryImpl#deleteAllById contains wrong code
Alexey Kuznetsov created IGNITE-13104:
-
Summary: Spring data 2.0 IgniteRepositoryImpl#deleteAllById
contains wrong code
Key: IGNITE-13104
URL: https://issues.apache.org/jira/browse/IGNITE-13104
Project: Ignite
Issue Type: Improvement
Components: springdata
Affects Versions: 2.8.1
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
Fix For: 2.9
{code}
/** {@inheritDoc} */
@Override public void deleteAllById(Iterable ids) {
if (ids instanceof Set)
cache.removeAll((Set)ids);
if (ids instanceof Collection)
cache.removeAll(new HashSet<>((Collection)ids));
TreeSet keys = new TreeSet<>();
for (ID id : ids)
keys.add(id);
cache.removeAll(keys);
}
{code}
As you can see cache.removeAll may be executed THREE times in some situations.
Also this method can throw ClassCast exception if ids collection contains
objects that are not implement Comparable interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
I think that [1] and [2] should not be changed, because we can kill another client code in this jvm. I suggest for these purposes to create a new [3] which will be like [1] but with a call [4] after node stop. Objections or comments? [1] - org.apache.ignite.failure.StopNodeFailureHandler [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler [3] - org.apache.ignite.failure.FailureHandler [4] - java.lang.System#exit 25.05.2020, 22:09, "Dmitriy Pavlov" : > It seems reasonable to me. Also I would like to propose adding value of > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > Dev ops/admins/anyone who admins Ignite may want to know it's value without > going to Java code. > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky : > >> Thank you Sergey, as for me — very useful proposal huge +1 here. >> >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < >> antonovserge...@gmail.com>: >> > >> >I've created the Ignite ticket for this improvement [1]. >> > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 >> > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < antonovserge...@gmail.com >: >> > >> >> Hello, Igniters! >> >> >> >> I'd like to discuss behaviour of Ignite process exit code if the node >> was >> >> stopped by failure handler [1][2]. At the moment ignite process returns >> >> exit code 0 after the stop in all scenarios, except runtime halt by >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] >> >> >> >> My proposal: always finish Ignite process with code [3], if a node was >> >> stopped by FH. It could be helpful for administration purposes, you can >> >> distinguish normal node stop from node stop by FH on OS level. >> >> >> >> WDYT? >> >> >> >> [1] >> >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html >> >> >> >> [2] >> >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html >> >> >> >> [3] >> >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE >> >> -- >> >> BR, Sergey Antonov >> >> >> > >> >-- >> >BR, Sergey Antonov >> >
[jira] [Created] (IGNITE-13103) Investigate marshalling errors when changing fields of lambda's capturingClass
Ilya Kasnacheev created IGNITE-13103:
Summary: Investigate marshalling errors when changing fields of
lambda's capturingClass
Key: IGNITE-13103
URL: https://issues.apache.org/jira/browse/IGNITE-13103
Project: Ignite
Issue Type: Bug
Components: binary, compute
Affects Versions: 2.8.1
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
Trying to execute static lambda whose outer type's fields changed leads to the
following error:
{code}
Exception in thread "main" class org.apache.ignite.IgniteException: Remote job
threw user exception (override or implement ComputeTask.result(..) method if
you would like to have automatic failover for this exception): Failed to
serialize object
[typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4]
at
org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:102)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1062)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1055)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7037)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1055)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:862)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.processDelayedResponses(GridTaskWorker.java:711)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:542)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:829)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:497)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:244)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runAsync(GridClosureProcessor.java:216)
at
org.apache.ignite.internal.IgniteComputeImpl.runAsync0(IgniteComputeImpl.java:702)
at
org.apache.ignite.internal.IgniteComputeImpl.run(IgniteComputeImpl.java:678)
at
com.gridgain.deployer.c.ComputeCallerStarter.start(ComputeCallerStarter.java:19)
at
com.gridgain.deployer.c.ComputeCallerStarter.main(ComputeCallerStarter.java:13)
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
serialize object
[typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:853)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
at
org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:84)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:57)
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10386)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1397)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:664)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:536)
... 9 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
serialize object [typeName=java.lang.invoke.SerializedLambda]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:853)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:227)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:524)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObject(BinaryWriterExImpl.java:1503)
at
[jira] [Created] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had closed before.
Sergey Antonov created IGNITE-13102:
---
Summary: IgniteCache#isClosed() returns false on server node even
if the cache had closed before.
Key: IGNITE-13102
URL: https://issues.apache.org/jira/browse/IGNITE-13102
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8.1, 2.8
Reporter: Sergey Antonov
Fix For: 2.9
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] [Created] (IGNITE-13101) Metastore may leave uncompleted write futures during node stop
Alexey Goncharuk created IGNITE-13101:
-
Summary: Metastore may leave uncompleted write futures during node
stop
Key: IGNITE-13101
URL: https://issues.apache.org/jira/browse/IGNITE-13101
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
I've got the following thread-dump (only relevant parts are retained) during
one of the teamcity runs:
{code}
"sys-#103862%baseline.IgniteStableBaselineBinObjFieldsQuerySelfTest0%" #107048
prio=5 os_prio=0 tid=0x7fa2d8009800 nid=0x480d waiting on condition
[0x7fa1d1cdc000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.remove(GridMetricManager.java:411)
at
org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.remove(CacheGroupMetricsImpl.java:497)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:512)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCacheGroup(GridCacheProcessor.java:2901)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCacheGroup(GridCacheProcessor.java:2889)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCacheStopRequestOnExchangeDone(GridCacheProcessor.java:2781)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2878)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2431)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3832)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3608)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:3207)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$200(GridDhtPartitionsExchangeFuture.java:154)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2994)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2982)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2982)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1989)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.preprocessSingleMessage(GridCachePartitionExchangeManager.java:524)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1100(GridCachePartitionExchangeManager.java:182)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:407)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:389)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3715)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3694)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
Re: [DISCUSSION] IEP-47 Native persistence defragmentation
Hi Ivan, I have an idea about suggested maintenance mode. First of all, I agree with your ideas about discovery restrictions: node should not join topology when performing defragmentation. At the same time I haven't heard about requests for this mode from users, so we don't know much about possible requirements. So I suggest to implement it in a pragmatical way: instead of inventing (unknown in reality) user scenarios lets develop minimal but yet well-designed functionality that suites our case. If we constrain our implementation with reasonable set of restrictions that's OK. So my idea is the following: to transit a node to maintenance user has to send special command to the node (e.g. with new command in control.sh utility or via JMX interface). Node saves maintenance request in local metastorage and waits for restart. User has to manually restart that node in order to finish moving it to maintenance mode. When node restarts and finds maintenance request it creates special type of discovery SPI that will not try to join topology at all yet node is able to start all necessary components and APIs like REST processor or JMX interface. When in maintenance, we'll be able to do defragmentation safely and remove maintenance request from metastorage only when it is completed (with all fault-tolerance logic in mind). As we don't have a mechanism (like watcher) to perform a "safe restart" (by safe I mean Ignite restart without OS-level process restart) we cannot finish maintenance mode without another manual restart but I think it is a reasonable restriction as maintenance mode shouldn't be an every-day routine and will be used quite rare. What do you think about it? On Tue, May 26, 2020 at 5:58 PM Ivan Bessonov wrote: > Hello Igniters, > > I'd like to discuss this new IEP with you: [1]. The main idea is to have a > procedure that relocates > pages to the top of the file as compact as possible which allows us to > trim the file and increase its > fill-factor. It will be configured manually and executed after the restart, > but before node joins > topology (it means any load would be impossible during defragmentation). It > is described in detail > in the IEP itself, please read it. This topic was also previously discussed > here on dev-list in [2]. > > Here I would like to list a few moments that are not as clear and require > your opinion. > > - what are your overall thoughts on the IEP? Any concerns? > > - maintenance mode - how do we communicate with the node that's not in > topology? What are >the options? As far as I know, we have no current tools like this. > > - checkpointer refactoring - these changes will involve intensive writing > of pages to the storage. >If we're going to reuse the offheap page model to perform > defragmentation then the >checkpointing mechanism will have to be adapted in some form. >Are you fine with this? Or we need a separate discussion? > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation > [2] > > http://apache-ignite-developers.2346864.n4.nabble.com/How-to-free-up-space-on-disc-after-removing-entries-from-IgniteCache-with-enabled-PDS-td39839.html > > > -- > Sincerely yours, > Ivan Bessonov >
[jira] [Created] (IGNITE-13100) ClassCastException in cache group metrics on client nodes
Alexey Goncharuk created IGNITE-13100:
-
Summary: ClassCastException in cache group metrics on client nodes
Key: IGNITE-13100
URL: https://issues.apache.org/jira/browse/IGNITE-13100
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
The following exception can be observed when reading cache group metrics on
client nodes with persistence-enabled config:
{code}
java.lang.ClassCastException:
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager
cannot be cast to
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager
at
org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.database(CacheGroupMetricsImpl.java:506)
at
org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.lambda$new$0(CacheGroupMetricsImpl.java:103)
at
org.apache.ignite.internal.util.lang.GridFunc.lambda$nonThrowableSupplier$3(GridFunc.java:3341)
at
org.apache.ignite.internal.processors.metric.impl.LongGauge.value(LongGauge.java:45)
at
org.apache.ignite.spi.metric.LongMetric.getAsString(LongMetric.java:29)
{code}
The reason is an incomplete check for persistence enabled in
{{CacheGroupMetricsImpl}}: we should also check for client nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13099) .net thin client - node selection on start up incorrect - wrong node chosen in ClientFailoverSocket GetNextSocket
david created IGNITE-13099:
--
Summary: .net thin client - node selection on start up incorrect -
wrong node chosen in ClientFailoverSocket GetNextSocket
Key: IGNITE-13099
URL: https://issues.apache.org/jira/browse/IGNITE-13099
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.8.1, 2.8
Environment: .net core 3.1 / windows server 2019 / c#
Reporter: david
To reproduce
var cfg = new IgniteClientConfiguration()
{
Endpoints = new List()
{
"localhost","ignite01","ignite02","ignite03","ignite04"
}
};
Ignition.StartClient(cfg)
Log show ignite Thin client connecting to "ignite01" and not "localhost" first
- the first elment in the array?
if Port randes are used: eg:
Endpoints = new List()
{
"localhost:10800..10810","ignite01:10800..10810","ignite02:10800..10810" //snip
}
};
logs show connecting to localhost:10801 and localhost:10800 is skipped
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
