[jira] [Commented] (IGNITE-14179) The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture'
[ https://issues.apache.org/jira/browse/IGNITE-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303863#comment-17303863 ] Denis Garus commented on IGNITE-14179: -- [~renni] Hi, sure. > The GridDhtTxFinishFuture has the redundant interface declaration > 'GridCacheFuture' > -- > > Key: IGNITE-14179 > URL: https://issues.apache.org/jira/browse/IGNITE-14179 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Priority: Minor > Labels: newbie > > Remove redundant interface declaration 'GridCacheFuture' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14255) Added the ability to rotate collecting performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-14255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303764#comment-17303764
]
Ignite TC Bot commented on IGNITE-14255:
{panel:title=Branch: [pull/8840/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8840/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5920089]]
* {color:#013220}IgniteBasicWithPersistenceTestSuite:
PerformanceStatisticsRotateFileTest.testRotateFile - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5920150buildTypeId=IgniteTests24Java8_RunAll]
> Added the ability to rotate collecting performance statistics
> -
>
> Key: IGNITE-14255
> URL: https://issues.apache.org/jira/browse/IGNITE-14255
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Labels: IEP-35
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Add the ability to rotate the performance statistics file using the
> control.sh and JMX.
> collection of performance statistics will continue to be written to the next
> file
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14170) Adding metrics of using WAL archive
[ https://issues.apache.org/jira/browse/IGNITE-14170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303719#comment-17303719 ] Nikolay Izhikov commented on IGNITE-14170: -- LGTM > Adding metrics of using WAL archive > --- > > Key: IGNITE-14170 > URL: https://issues.apache.org/jira/browse/IGNITE-14170 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > At the moment there is no way to estimate how many segments in the archive we > may need, for example, per day. It is proposed to add the following metrics: > * The number of bytes logged to the WAL; > * The number of compressed bytes in the WAL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14179) The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture'
[ https://issues.apache.org/jira/browse/IGNITE-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303711#comment-17303711 ] Irina Ulitina commented on IGNITE-14179: Hello! Can I take it? > The GridDhtTxFinishFuture has the redundant interface declaration > 'GridCacheFuture' > -- > > Key: IGNITE-14179 > URL: https://issues.apache.org/jira/browse/IGNITE-14179 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Priority: Minor > Labels: newbie > > Remove redundant interface declaration 'GridCacheFuture' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
Mikhail Petrov created IGNITE-14335: --- Summary: Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity Key: IGNITE-14335 URL: https://issues.apache.org/jira/browse/IGNITE-14335 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov Assignee: Mikhail Petrov It's proposed to: 1. Make an IgniteAuthenticationProcessor implement GridSecurityProcessor interface. 2. Remove duplication of security checks and leave IgniteSecurity as a single security API. 3. Remove the AuthorizationContext completely as IgniteSecurity provides an API for storing and managing the security contexts. 4. Extend GridSecurityPlugin interface with methods that provide ability to manage security users to support existing commands available for authentication processor - alter/drop/create through SQL and REST. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14254) Graceful stop rebuilding indexes when deactivating a cluster
[
https://issues.apache.org/jira/browse/IGNITE-14254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303634#comment-17303634
]
Ignite TC Bot commented on IGNITE-14254:
{panel:title=Branch: [pull/8837/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8837/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5919982]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
StopRebuildIndexTest.testInternalIndexingRebuildFuture - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
StopRebuildIndexTest.testSchemaIndexCacheCompoundFeature - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
StopRebuildIndexTest.testStopRebuildIndexesOnDeactivation - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
StopRebuildIndexTest.testStopRebuildIndexesOnStopNode - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5920015buildTypeId=IgniteTests24Java8_RunAll]
> Graceful stop rebuilding indexes when deactivating a cluster
>
>
> Key: IGNITE-14254
> URL: https://issues.apache.org/jira/browse/IGNITE-14254
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If in the process of rebuilding the indexes to deactivate the cluster, then a
> number of errors may appear, including a node fail. It is necessary to stop
> index rebuilding before stopping the cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14299) .NET: Service loses array type information
[
https://issues.apache.org/jira/browse/IGNITE-14299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14299:
-
Summary: .NET: Service loses array type information (was: .NET: Service
loses array type information in case .Net <-> .Net call)
> .NET: Service loses array type information
> --
>
> Key: IGNITE-14299
> URL: https://issues.apache.org/jira/browse/IGNITE-14299
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In case .Net -> .Net service call Ignite loses array type information.
> {code:java}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Discovery.Tcp;
> using Apache.Ignite.Core.Discovery.Tcp.Static;
> using Apache.Ignite.Core.Services;
> using Castle.DynamicProxy;
> using System;
> using System.Linq;
> using Xunit;
> namespace Ignite.ServiceReturnsArray
> {
> public class Test : IDisposable
> {
> private readonly IIgnite igniteSrv;
> private readonly IIgnite ignite;
> public Test()
> {
> IgniteConfiguration IgniteConfig(bool clientMode) => new
> IgniteConfiguration()
> {
> ClientMode = clientMode,
> IgniteInstanceName = Guid.NewGuid().ToString(),
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
> new[] { "127.0.0.1:47500" } }
> }
> };
> igniteSrv = Ignition.Start(IgniteConfig(false));
> ignite = Ignition.Start(IgniteConfig(true));
>
> ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
> ArrayFactoryService());
> }
> public void Dispose()
> {
> ignite.Dispose();
> igniteSrv.Dispose();
> }
> [Fact]
> public void ServiceReturnsArray()
> {
> var arr =
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
> false)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithReflection()
> {
> var arr =
> typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
>
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
> new object[] { 2, 1 });
> Assert.IsType(arr);
> Assert.Equal(1, ((Result[])arr)?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithCastleProxy()
> {
> var interceptor = new ServiceInterceptor(ignite,
> nameof(ArrayFactoryService));
>
> var arr = new
> ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> public sealed class Result
> {
> public int Value { get; set; }
> }
> public interface IArrayFactory
> {
> Result[] CreateArray(int size, int dlftVal);
> }
> public sealed class ArrayFactoryService : IArrayFactory, IService
> {
> public Result[] CreateArray(int size, int dfltVal)
> {
> return Enumerable.Repeat(new Result { Value = dfltVal },
> size).ToArray();
> }
> public void Cancel(IServiceContext context)
> {
> }
> public void Execute(IServiceContext context)
> {
> }
> public void Init(IServiceContext context)
> {
> }
> }
> private sealed class ServiceInterceptor : IInterceptor where T:
> class
> {
> private readonly IIgnite ignite;
> private readonly string name;
> public ServiceInterceptor(IIgnite ignite, string name)
> {
> this.ignite = ignite;
> this.name = name;
> }
> public void Intercept(IInvocation invocation)
> {
> var svc = ignite.GetServices().GetServiceProxy(name,
> false);
> invocation.ReturnValue = invocation.Method.Invoke(svc,
> invocation.Arguments);
> }
> }
> }
> }
> {code}
>
> Above test fail on type check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14334) .NET: Thin client don't support ICollection parameters
Nikolay Izhikov created IGNITE-14334: Summary: .NET: Thin client don't support ICollection parameters Key: IGNITE-14334 URL: https://issues.apache.org/jira/browse/IGNITE-14334 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Currently, we can't call .Net -> Java with ICollection parameters. Need to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14308) IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare deployable, because local node id does not correspond with class loader id
[
https://issues.apache.org/jira/browse/IGNITE-14308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14308:
-
Ignite Flags: (was: Release Notes Required)
> IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare
> deployable, because local node id does not correspond with class loader id
> -
>
> Key: IGNITE-14308
> URL: https://issues.apache.org/jira/browse/IGNITE-14308
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-12760, the following exception is seen:
> {code}
> IgnitePeerToPeerClassLoadingException
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.checkDeploymentIsCorrect(GridCacheDeploymentManager.java:717)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.prepare(GridCacheDeploymentManager.java:693)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1245)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:570)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:381)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:324)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:128)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3965)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:4013)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2958)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAllAsync0(GridNearTxLocal.java:1033)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:540)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2389)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:3830)
> ... 29 more
> {code}
> Turns out, sometimes local deployment belongs to other node id (previous
> client?). Changing behavior for local deployments was not anticipated. Let's
> change this error to warning for local deployments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14333) Zookeeper service should perform kill -9 on kill request
[ https://issues.apache.org/jira/browse/IGNITE-14333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303498#comment-17303498 ] Anton Vinogradov commented on IGNITE-14333: --- Currently, Zookeeper service may hang because of ignored kill -15. > Zookeeper service should perform kill -9 on kill request > > > Key: IGNITE-14333 > URL: https://issues.apache.org/jira/browse/IGNITE-14333 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14333) Zookeeper service should perform kill -9 on kill request
[ https://issues.apache.org/jira/browse/IGNITE-14333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-14333: - Assignee: Anton Vinogradov > Zookeeper service should perform kill -9 on kill request > > > Key: IGNITE-14333 > URL: https://issues.apache.org/jira/browse/IGNITE-14333 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14333) Zookeeper service should perform kill -9 on kill request
[ https://issues.apache.org/jira/browse/IGNITE-14333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14333: -- Summary: Zookeeper service should perform kill -9 on kill request (was: Zookeeper uses kill -1) > Zookeeper service should perform kill -9 on kill request > > > Key: IGNITE-14333 > URL: https://issues.apache.org/jira/browse/IGNITE-14333 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14333) Zookeeper uses kill -1
Anton Vinogradov created IGNITE-14333: - Summary: Zookeeper uses kill -1 Key: IGNITE-14333 URL: https://issues.apache.org/jira/browse/IGNITE-14333 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303488#comment-17303488 ] Aleksandr Polovtcev commented on IGNITE-14322: -- [~sergeychugunov] tickets has passed all steps, please review > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[
https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303486#comment-17303486
]
Ignite TC Bot commented on IGNITE-14322:
{panel:title=Branch: [pull//head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull//head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5919252]]
* {color:#013220}IgnitePdsTestSuite2:
WalArchiveSizeConfigurationTest.testNonPersistentConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
WalArchiveSizeConfigurationTest.testUnlimitedMaxArchiveSizeConfiguration -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
WalArchiveSizeConfigurationTest.testIncorrectMaxArchiveSizeConfiguration -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
WalArchiveSizeConfigurationTest.testPersistentConfiguration - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5919282buildTypeId=IgniteTests24Java8_RunAll]
> False warning about DataRegionConfiguration.maxWalArchiveSize property usage
>
>
> Key: IGNITE-14322
> URL: https://issues.apache.org/jira/browse/IGNITE-14322
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.10
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> On every non-persistent startup the following is printed:
> DataRegionConfiguration.maxWalArchiveSize instead
> DataRegionConfiguration.walHistorySize would be used for removing old archive
> wal files
> This does not make sense when persistence is totally off.
> Also, syntax should be fixed, "instead of", should be more clear what's going
> on.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13181) Ignite support for spark-3.0.0
[ https://issues.apache.org/jira/browse/IGNITE-13181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303471#comment-17303471 ] Shenson Joseph commented on IGNITE-13181: - [~vkulichenko] [~azinoviev] do you know about any plans to work on this feature? We are currently blocked due to this limitation and can't upgrade to latest spark. > Ignite support for spark-3.0.0 > -- > > Key: IGNITE-13181 > URL: https://issues.apache.org/jira/browse/IGNITE-13181 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.8.1 >Reporter: Shenson Joseph >Priority: Blocker > > feature to support apache spark-3.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12696) Remove deprecated @MXBeanParametersNames and @MXBeanParametersDescriptions annotations
[
https://issues.apache.org/jira/browse/IGNITE-12696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303452#comment-17303452
]
oleg commented on IGNITE-12696:
---
Hi. Can I take it up?
> Remove deprecated @MXBeanParametersNames and @MXBeanParametersDescriptions
> annotations
> --
>
> Key: IGNITE-12696
> URL: https://issues.apache.org/jira/browse/IGNITE-12696
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: newbie
> Fix For: 3.0
>
>
> {{@MXBeanParametersNames}} and {{@MXBeanParametersDescriptions}} annotations
> are deprecated due to the change IGNITE-10698.
> Mentioned annotations must be removed in Apache Ignite 3.0 release, **but not
> earlier**.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11668) OSGI: Self-imported package causes failure upon Karaf restart
[
https://issues.apache.org/jira/browse/IGNITE-11668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303445#comment-17303445
]
Richard Bryan commented on IGNITE-11668:
I believe this is the same error I am seeing with Ignite 2.8.1. On initial run
of karaf Ignite launches fine, but on the next run it fails with this:
09:44:30.613 ERROR [FelixDispatchQueue] FrameworkEvent ERROR
org.osgi.framework.BundleException: Unable to resolve tgcs-ignite-service-osgi
[188](R 188.0): missing requirement [tgcs-ignite-service-osgi [188](R 188.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.ignite.osgi)(version>=2.8.0)(!(version>=3.0.0)))
[caused by: Unable to resolve org.apache.ignite.ignite-osgi [130](R 130.0):
missing requirement [org.apache.ignite.ignite-osgi [130](R 130.0)]
osgi.wiring.host;
(&(osgi.wiring.host=org.apache.ignite.ignite-core)(bundle-version>=0.0.0))]
Unresolved requirements: [[tgcs-ignite-service-osgi [188](R 188.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.ignite.osgi)(version>=2.8.0)(!(version>=3.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149)
~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2119) ~[?:?]
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) ~[?:?]
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
~[?:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]
If I delete the karaf cache (/data/*) and restart, it runs
correctly again.
> OSGI: Self-imported package causes failure upon Karaf restart
> -
>
> Key: IGNITE-11668
> URL: https://issues.apache.org/jira/browse/IGNITE-11668
> Project: Ignite
> Issue Type: Bug
> Components: osgi
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Apache Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've got problem using Ignite 2.7 in Apache Karaf 4.2.0. The problem is
> caused by strange bundle meta of ignite-osgi. It exports package
> org.apache.ignite.osgi.classloaders and imports it at the same time. Here's
> extract from METADATA.MF:
> {noformat}
> Import-Package: org.apache.ignite;version="[2.7,3)",org.apache.ignite.
> configuration;version="[2.7,3)",org.apache.ignite.internal.util;versi
> on="[2.7,3)",org.apache.ignite.internal.util.tostring;version="[2.7,3
> )",org.apache.ignite.internal.util.typedef.internal;version="[2.7,3)"
> ,org.apache.ignite.osgi.classloaders,org.osgi.framework;version="[1.7
> ,2)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Fragment-Host: org.apache.ignite.ignite-core
> Export-Package: org.apache.ignite.osgi.classloaders;uses:="org.apache.
> ignite.internal.util.tostring,org.osgi.framework";version="2.7.0",org
> .apache.ignite.osgi;uses:="org.apache.ignite,org.apache.ignite.config
> uration,org.apache.ignite.osgi.classloaders,org.osgi.framework";versi
> on="2.7.0"
> {noformat}
> There is no problem with initial installation of my application into Karaf,
> although after Karaf ignite-osgi dependency is not resolved, and this
> exception in log:
> {noformat}
> org.osgi.framework.BundleException: Unable to resolve graphql-core [399](R
> 399.0): missing requirement [graphql-core [399](R 399.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))
> [caused by: Unable to resolve org.apache.ignite.ignite-osgi [432](R 432.0):
> missing requirement [org.apache.ignite.ignite-osgi [432](R 432.0)]
> osgi.wiring.host;
> (&(osgi.wiring.host=org.apache.ignite.ignite-core)(bundle-version>=0.0.0))]
> Unresolved requirements: [[graphql-core [399](R 399.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))]
> {noformat}
> *Proposed solution:*
> remove the self-import by adding instruction to bundle plugin configuration
> in modules/osgi/pom.xml
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
>
>
> org.apache.ignite.ignite-core
>
> !org.apache.ignite.osgi.classloaders,*
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14332) Update for event schedule page
[ https://issues.apache.org/jira/browse/IGNITE-14332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kseniya Romanova updated IGNITE-14332: -- Description: [~mstekl] please update [the events schedule|https://ignite.apache.org/events.html] with the following events: Distributed Java Databases Under the Hood: Main Components and Interactions Seattle Java User Group, Val Kulichenko April 20, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Learn more = [https://www.meetup.com/seajug/events/276324545/] Dealing with Network Overhead in Distributed Systems: An Effective Approach to Working with Data DOTNEXT Russia, Pavel Tupitsyn April 20, 21 Modern apps consist of many subsystems: databases, caches, event brokers. The single user request can involve multiple internal network calls. We will talk about data locality, reducing network overhead, improving performance and scalability. Benchmarks, demos, live coding, and practical examples await. Read more = [https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/] was: [~mstekl] please update [the events schedule|https://ignite.apache.org/events.html] with the following events: Distributed Java Databases Under the Hood: Main Components and Interactions Seattle Java User Group, Val Kulichenko April 20, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Learn more = [https://www.meetup.com/seajug/events/276324545/] Dealing with Network Overhead in Distributed Systems: An Effective Approach to Working with Data DOTNEXT Russia, Pavel Tupitsyn May 20, 21 Modern apps consist of many subsystems: databases, caches, event brokers. The single user request can involve multiple internal network calls. We will talk about data locality, reducing network overhead, improving performance and scalability. Benchmarks, demos, live coding, and practical examples await. Read more = [https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/] > Update for event schedule page > -- > > Key: IGNITE-14332 > URL: https://issues.apache.org/jira/browse/IGNITE-14332 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Priority: Major > > [~mstekl] please update [the events > schedule|https://ignite.apache.org/events.html] with the following events: > Distributed Java Databases Under the Hood: Main Components and Interactions > Seattle Java User Group, Val Kulichenko > April 20, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Learn more = [https://www.meetup.com/seajug/events/276324545/] > Dealing with Network Overhead in Distributed Systems: An Effective Approach > to Working with Data > DOTNEXT Russia, Pavel Tupitsyn > April 20, 21 > Modern apps consist of many subsystems: databases, caches, event brokers. > The single user request can involve multiple internal network calls. We will > talk about data locality, reducing network overhead, improving performance > and scalability. Benchmarks, demos, live coding, and practical examples await. > Read more = > [https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14332) Update for event schedule page
[ https://issues.apache.org/jira/browse/IGNITE-14332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kseniya Romanova updated IGNITE-14332: -- Description: [~mstekl] please update [the events schedule|https://ignite.apache.org/events.html] with the following events: Distributed Java Databases Under the Hood: Main Components and Interactions Seattle Java User Group, Val Kulichenko April 20, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Learn more = [https://www.meetup.com/seajug/events/276324545/] Dealing with Network Overhead in Distributed Systems: An Effective Approach to Working with Data DOTNEXT Russia, Pavel Tupitsyn May 20, 21 Modern apps consist of many subsystems: databases, caches, event brokers. The single user request can involve multiple internal network calls. We will talk about data locality, reducing network overhead, improving performance and scalability. Benchmarks, demos, live coding, and practical examples await. Read more = [https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/] was: Please update [the events schedule|https://ignite.apache.org/events.html] with the following events: Distributed Java Databases Under the Hood: Main Components and Interactions Seattle Java User Group, Val Kulichenko April 20, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Learn more = https://www.meetup.com/seajug/events/276324545/ Dealing with Network Overhead in Distributed Systems: An Effective Approach to Working with Data DOTNEXT Russia, Pavel Tupitsyn May 20, 21 Modern apps consist of many subsystems: databases, caches, event brokers. The single user request can involve multiple internal network calls. We will talk about data locality, reducing network overhead, improving performance and scalability. Benchmarks, demos, live coding, and practical examples await. Read more = https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/ > Update for event schedule page > -- > > Key: IGNITE-14332 > URL: https://issues.apache.org/jira/browse/IGNITE-14332 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Priority: Major > > [~mstekl] please update [the events > schedule|https://ignite.apache.org/events.html] with the following events: > Distributed Java Databases Under the Hood: Main Components and Interactions > Seattle Java User Group, Val Kulichenko > April 20, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Learn more = [https://www.meetup.com/seajug/events/276324545/] > Dealing with Network Overhead in Distributed Systems: An Effective Approach > to Working with Data > DOTNEXT Russia, Pavel Tupitsyn > May 20, 21 > Modern apps consist of many subsystems: databases, caches, event brokers. > The single user request can involve multiple internal network calls. We will > talk about data locality, reducing network overhead, improving performance > and scalability. Benchmarks, demos, live coding, and practical examples await. > Read more = > [https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14332) Update for event schedule page
Kseniya Romanova created IGNITE-14332: - Summary: Update for event schedule page Key: IGNITE-14332 URL: https://issues.apache.org/jira/browse/IGNITE-14332 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova Please update [the events schedule|https://ignite.apache.org/events.html] with the following events: Distributed Java Databases Under the Hood: Main Components and Interactions Seattle Java User Group, Val Kulichenko April 20, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Learn more = https://www.meetup.com/seajug/events/276324545/ Dealing with Network Overhead in Distributed Systems: An Effective Approach to Working with Data DOTNEXT Russia, Pavel Tupitsyn May 20, 21 Modern apps consist of many subsystems: databases, caches, event brokers. The single user request can involve multiple internal network calls. We will talk about data locality, reducing network overhead, improving performance and scalability. Benchmarks, demos, live coding, and practical examples await. Read more = https://dotnext-piter.ru/en/2021/spb/talks/3ar6q8gmbfi86lhbduts0k/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13374) Initial PME hangs because of multiple blinking nodes
[ https://issues.apache.org/jira/browse/IGNITE-13374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303399#comment-17303399 ] Alexander Lapin commented on IGNITE-13374: -- [~sk0x50]Could you please review the ticket? > 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 >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > *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-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
Vladimir Pligin created IGNITE-14331:
Summary: Possible distributed race related to a data streamer
flushing leading to a thread being stuck forever trying to close the streamer
Key: IGNITE-14331
URL: https://issues.apache.org/jira/browse/IGNITE-14331
Project: Ignite
Issue Type: Bug
Components: streaming
Affects Versions: 2.10
Reporter: Vladimir Pligin
It seems that a streamer could stuck forever flushing internal buffers on a
client side.
It will stay in a busy-loop forever hoping on remapping but it's possible that
it won't happen for example in case of long GC pauses on server(s) and long
timeouts.
It that case a streamer would be trapped inside this
[loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
Stack trace snippet:
{code:java}
java.lang.Thread.State: RUNNABLE at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
It becomes possible when a
IgniteSpiOperationTimeoutException
is being thrown from
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14330) Implement binary table views API.
Andrey Mashenkov created IGNITE-14330: - Summary: Implement binary table views API. Key: IGNITE-14330 URL: https://issues.apache.org/jira/browse/IGNITE-14330 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov Fix For: 3.0.0-alpha2 Implement KV and Table - binary projections over table. Implement builders for binary objects\rows. Add tests for all operations. Example class is a good start point. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13757) Investigate if generated serializers can work with GraalVM native image.
[ https://issues.apache.org/jira/browse/IGNITE-13757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13757: -- Summary: Investigate if generated serializers can work with GraalVM native image. (was: Investigate if serializers are supported with GraalVM native image.) > Investigate if generated serializers can work with GraalVM native image. > > > Key: IGNITE-13757 > URL: https://issues.apache.org/jira/browse/IGNITE-13757 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: graalvm, iep-54, ignite-3 > > GraalVM has limited support of reflection [1]. > We have to check if all serializers (see IGNITE-13618) are compatible with > GraalMV native image and/or if some additional setting are required from the > user side to make serializers work. > The goal is to have at least one compatible serializer we could fallback to. > [1] https://www.graalvm.org/reference-manual/native-image/Reflection/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14291) Implement KeyValueView API and RecordView API.
[ https://issues.apache.org/jira/browse/IGNITE-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14291: -- Summary: Implement KeyValueView API and RecordView API. (was: Implement user class mappers.) > Implement KeyValueView API and RecordView API. > -- > > Key: IGNITE-14291 > URL: https://issues.apache.org/jira/browse/IGNITE-14291 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Alexander Belyak >Priority: Major > Labels: iep-54, ignite-3 > > Implement user-class mappers for key-value view and record view and add > custom mapper support to marshallers initially implemented in IGNITE-13618. > Supposed, mappers are used for schema generation from user-classes > (annotation schema configuration) and schema validation. > Mappers might be highly coupled with marshallers\serislizers (especially > generated marshaller). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14316) Binary object API for arbitrary user objects.
[ https://issues.apache.org/jira/browse/IGNITE-14316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14316: -- Summary: Binary object API for arbitrary user objects. (was: Custom binary object API) > Binary object API for arbitrary user objects. > - > > Key: IGNITE-14316 > URL: https://issues.apache.org/jira/browse/IGNITE-14316 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > Let's create BinaryObject (BO) interface and a builder interface for it > assuming > - BO is a self-described object. Similar to Ignite-2 one with a compact > footer. > - BO is unmanaged. SchemaManager doesn't care about its schema at all. > - BO can be deserialized to user class with a specified deserializer. > - BO has a flat structure, cyclic links are not allowed. However, one can > restore links on reserialization. > - BO must not have any dependencies on Ignite internals. > - Ignite should provide some base implementation for BO and builder. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12284) When service class not found on any server nodes, service not deployed without any error
[
https://issues.apache.org/jira/browse/IGNITE-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303339#comment-17303339
]
Stanislav Lukyanov commented on IGNITE-12284:
-
I think this should be closed as Not an Issue - the old service implementation
doesn't support deployment, the new implementation shouldn't have this problem.
[~ilyak], WDYT?
> When service class not found on any server nodes, service not deployed
> without any error
>
>
> Key: IGNITE-12284
> URL: https://issues.apache.org/jira/browse/IGNITE-12284
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> When service class presents on client node but not on server node, the
> following is printed on server:
> {code}
> [17:57:43,398][SEVERE][srvc-deploy-#44][GridServiceProcessor] Failed to
> initialize service (service will not be deployed): FService
> class org.apache.ignite.IgniteCheckedException:
> com.gridgain.datetest.MyService
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10174)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.copyAndInject(GridServiceProcessor.java:1440)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:1361)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.processAssignment(GridServiceProcessor.java:1988)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1615)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:126)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1597)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2064)
> 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.binary.BinaryInvalidTypeException:
> com.gridgain.datetest.MyService
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1758)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1717)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:102)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10168)
> ... 10 more
> Caused by: java.lang.ClassNotFoundException: com.gridgain.datetest.MyService
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8775)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:349)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:698)
> ... 16 more
> {code}
> but on client, ServiceDeploymentException is not thrown. Instead, deploy
> returns normally.
> Code to reproduce:
> {code}
> public class ServiceStarterMain {
> public static void main(String[] args) {
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> ServiceConfiguration serviceConfiguration = new
> ServiceConfiguration();
> serviceConfiguration.setName("FService");
> serviceConfiguration.setMaxPerNodeCount(4);
> serviceConfiguration.setTotalCount(10);
> serviceConfiguration.setService(new MyService());
> ignite.services().deploy(serviceConfiguration); // Exception
> expected, but does not happen
> }
> }
> {code}
> against a blank Ignite node started from bin distro.
> This affects Java and
[jira] [Commented] (IGNITE-13374) Initial PME hangs because of multiple blinking nodes
[
https://issues.apache.org/jira/browse/IGNITE-13374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303334#comment-17303334
]
Ignite TC Bot commented on IGNITE-13374:
{panel:title=Branch: [pull/8850/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8850/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5919076]]
* {color:#013220}IgniteCacheTestSuite6:
ClientFastReplyCoordinatorFailureTest.testClientRepeatedReply - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5900929buildTypeId=IgniteTests24Java8_RunAll]
> 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
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *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] [Commented] (IGNITE-14281) Calcite. Colocated tables are considered non colocated
[ https://issues.apache.org/jira/browse/IGNITE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303317#comment-17303317 ] Taras Ledkov commented on IGNITE-14281: --- [~korlov], please fix minor comments. The patch is OK with me. > Calcite. Colocated tables are considered non colocated > -- > > Key: IGNITE-14281 > URL: https://issues.apache.org/jira/browse/IGNITE-14281 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently distribution trait for partitioned cache is built over 0th column > which is _KEY column. Because of this a colocated join is considered > non-colocated until _KEY columns is not used explicitly as join predicate. > Need to fix this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14329) Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST
[ https://issues.apache.org/jira/browse/IGNITE-14329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14329: -- Description: This fixes nightly run failures fixed at IGNITE-13705. (was: This fixed nightly run failures fixed at IGNITE-13705.) > Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST > -- > > Key: IGNITE-14329 > URL: https://issues.apache.org/jira/browse/IGNITE-14329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > This fixes nightly run failures fixed at IGNITE-13705. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14329) Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST
Anton Vinogradov created IGNITE-14329: - Summary: Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST Key: IGNITE-14329 URL: https://issues.apache.org/jira/browse/IGNITE-14329 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov This fixed nightly run failures fixed at IGNITE-13705. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14301) Authentication processor can hang all user management operation after server node reconnect
[ https://issues.apache.org/jira/browse/IGNITE-14301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14301: Description: First for all look at the test - AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer which is flaky - [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] The first problem with this test is that user management operations(add/update/remove) create too many discovery messages. So discovery custom message history size is not enough to properly skip duplicated custom messages that can be sent across the ring during server node reconnect. It leads to mentioned test failures due to duplication of user management operations (see GridDiscoveryManager#discoCacheHist, IGNITE_DISCOVERY_HISTORY_SIZE system property, and ServerImpl.RingMessageWorker#sendMessageAcrossRing). If the discovery history size will be increased significantly, the test stops failing and starts hanging. The steps that lead to this: 1. Client node sent UserProposedMessage across the ring while one node is offline due to reconnect. 2. Alive server nodes update their local user lists and finish the operation. 3. Reconnected node joins the ring and receives an updated user list from the coordinator. 4. Reconnected node receives duplicated UserProposedMessage that has been already handled by all nodes, handles it, and sents UserManagementOperationFinishedMessage to the coordinator and start to wait for the UserAcceptedMessage from it. But the coordinator has already finished this operation. So the thread that responsible for user management operation on the reconnected node becomes blocked (see IgniteAuthenticationProcessor.UserOperationWorker#body). 5. Client node starts the next operation that needs all alive nodes to respond with UserManagementOperationFinishedMessage. But reconnected node authentication thread is blocked. So this operation can't be completed at all. was: First for all look at the test - AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer which is flaky - [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] The first problem with this test is that user management operations(add/update/remove) create too many discovery messages. So discovery custom message history size is not enough to properly skip duplicated custom messages that can be sent across the ring during server node reconnect. It leads to test failures due to duplication of user management operations (see GridDiscoveryManager#discoCacheHist, IGNITE_DISCOVERY_HISTORY_SIZE system property, and ServerImpl.RingMessageWorker#sendMessageAcrossRing). If the discovery history size will be increased significantly, the test stops failing and starts hanging. The steps that lead to this: 1. Client node sent UserProposedMessage across the ring while one node is offline due to reconnect. 2. Alive server nodes update their local user lists and finish the operation. 3. Reconnected node joins the ring and receives an updated user list from the coordinator. 4. Reconnected node receives duplicated UserProposedMessage that has been already handled by all nodes, handles it, and sents UserManagementOperationFinishedMessage to the coordinator and start to wait for the UserAcceptedMessage from it. But the coordinator has already finished this operation. So the thread that responsible for user management operation on the reconnected node becomes blocked (see IgniteAuthenticationProcessor.UserOperationWorker#body). 5. Client node starts the next operation that needs all alive nodes to respond with UserManagementOperationFinishedMessage. But reconnected node authentication thread is blocked. So this operation can't be completed at all. > Authentication processor can hang all user management operation after server > node reconnect > --- > > Key: IGNITE-14301 > URL: https://issues.apache.org/jira/browse/IGNITE-14301 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > > First for all look at the test - > AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer > which is flaky - [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] > The first problem with this test is that user management > operations(add/update/remove) create too many discovery messages. So > discovery custom message history size is not enough to properly skip > duplicated custom messages that can be sent across the ring during server > node reconnect. It leads to
[jira] [Updated] (IGNITE-14301) Authentication processor can hang all user management operation after server node reconnect
[ https://issues.apache.org/jira/browse/IGNITE-14301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14301: Description: First for all look at the test - AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer which is flaky - [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] The first problem with this test is that user management operations(add/update/remove) create too many discovery messages. So discovery custom message history size is not enough to properly skip duplicated custom messages that can be sent across the ring during server node reconnect. It leads to test failures due to duplication of user management operations (see GridDiscoveryManager#discoCacheHist, IGNITE_DISCOVERY_HISTORY_SIZE system property, and ServerImpl.RingMessageWorker#sendMessageAcrossRing). If the discovery history size will be increased significantly, the test stops failing and starts hanging. The steps that lead to this: 1. Client node sent UserProposedMessage across the ring while one node is offline due to reconnect. 2. Alive server nodes update their local user lists and finish the operation. 3. Reconnected node joins the ring and receives an updated user list from the coordinator. 4. Reconnected node receives duplicated UserProposedMessage that has been already handled by all nodes, handles it, and sents UserManagementOperationFinishedMessage to the coordinator and start to wait for the UserAcceptedMessage from it. But the coordinator has already finished this operation. So the thread that responsible for user management operation on the reconnected node becomes blocked (see IgniteAuthenticationProcessor.UserOperationWorker#body). 5. Client node starts the next operation that needs all alive nodes to respond with UserManagementOperationFinishedMessage. But reconnected node authentication thread is blocked. So this operation can't be completed at all. was: First for all look at the test - AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer - [TC history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] The first problem with this test is that user management operations(add/update/remove) create too many discovery messages. So discovery custom message history size is not enough to properly skip duplicated custom messages that can be sent across the ring during server node reconnect. It leads to test failures due to duplication of user management operations (see GridDiscoveryManager#discoCacheHist, IGNITE_DISCOVERY_HISTORY_SIZE system property, and ServerImpl.RingMessageWorker#sendMessageAcrossRing). If the discovery history size will be increased significantly, the test stops failing and starts hanging. The steps that lead to this: 1. Client node sent UserProposedMessage across the ring while one node is offline due to reconnect. 2. Alive server nodes update their local user lists and finish the operation. 3. Reconnected node joins the ring and receives an updated user list from the coordinator. 4. Reconnected node receives duplicated UserProposedMessage that has been already handled by all nodes, handles it, and sents UserManagementOperationFinishedMessage to the coordinator and start to wait for the UserAcceptedMessage from it. But the coordinator has already finished this operation. So the thread that responsible for user management operation on the reconnected node becomes blocked (see IgniteAuthenticationProcessor.UserOperationWorker#body). 5. Client node starts the next operation that needs all alive nodes to respond with UserManagementOperationFinishedMessage. But reconnected node authentication thread is blocked. So this operation can't be completed at all. > Authentication processor can hang all user management operation after server > node reconnect > --- > > Key: IGNITE-14301 > URL: https://issues.apache.org/jira/browse/IGNITE-14301 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > > First for all look at the test - > AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer > which is flaky - [TC > history|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8873434544416175780=testDetails] > The first problem with this test is that user management > operations(add/update/remove) create too many discovery messages. So > discovery custom message history size is not enough to properly skip > duplicated custom messages that can be sent across the ring during server > node reconnect. It leads to test failures due to
[jira] [Updated] (IGNITE-14281) Calcite. Colocated tables are considered non colocated
[ https://issues.apache.org/jira/browse/IGNITE-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-14281: -- Description: Currently distribution trait for partitioned cache is built over 0th column which is _KEY column. Because of this a colocated join is considered non-colocated until _KEY columns is not used explicitly as join predicate. Need to fix this. (was: Currently distribution trait for replicated cache is built over 0th column which is _KEY column. Because of this a colocated join is considered non-colocated until _KEY columns is not used explicitly as join predicate. Need to fix this.) > Calcite. Colocated tables are considered non colocated > -- > > Key: IGNITE-14281 > URL: https://issues.apache.org/jira/browse/IGNITE-14281 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently distribution trait for partitioned cache is built over 0th column > which is _KEY column. Because of this a colocated join is considered > non-colocated until _KEY columns is not used explicitly as join predicate. > Need to fix this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13617) Provide an initial implementation for assembling/reading tuples for a given schema
[ https://issues.apache.org/jira/browse/IGNITE-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-13617. --- Resolution: Duplicate Merged within IGNITE-13618. > Provide an initial implementation for assembling/reading tuples for a given > schema > -- > > Key: IGNITE-13617 > URL: https://issues.apache.org/jira/browse/IGNITE-13617 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14214:
-
Fix Version/s: 2.11
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303261#comment-17303261
]
Amelchev Nikita commented on IGNITE-14214:
--
After a private talk, I have reassigned the issue. I have refactored changes
and added the test.
[~nizhikov], [~korlov], thanks for the review. [~YAMolochkov], thanks for the
initial contribution.
Merger to the master branch.
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303258#comment-17303258
]
Ignite TC Bot commented on IGNITE-14214:
{panel:title=Branch: [pull/8887/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8887/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5918963]]
* {color:#013220}IgniteBinaryCacheTestSuite: OracleDialectTest.testMergeQuery -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5919009buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13748) Schema configuration public API
[ https://issues.apache.org/jira/browse/IGNITE-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303246#comment-17303246 ] Alexey Goncharuk commented on IGNITE-13748: --- Looks good from my side. I think we can merge and start collecting feedback from the community. > Schema configuration public API > --- > > Key: IGNITE-13748 > URL: https://issues.apache.org/jira/browse/IGNITE-13748 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Let's implement a public API classes for initial schema declaration. > Considering next: > * It should be possible to create schema without having any Class instance, > like we do now with QueryEntity. > * -Automatic schema creation based on annotated classes, like we have in > ccfg.setIndexedTypes()- IGNITE-13749 > * -Transient fields semantic.- IGNITE-13749 > * Using builder pattern for schema configuration. > * Split type-system into internal native-types (introduced IGNITE-13617) and > public API types. The latest ones should be portable (e.g. could be used in > .Net) > * API can be extracted to separate module that will not have any dependency > on other Ignite modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13618) Provide generated and reflection-based class (de)serializers
[ https://issues.apache.org/jira/browse/IGNITE-13618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303218#comment-17303218 ] Alexey Goncharuk commented on IGNITE-13618: --- [~amashenkov] I've added a README file to the module with schema management description from the IEP. Good to merge from my side. > Provide generated and reflection-based class (de)serializers > > > Key: IGNITE-13618 > URL: https://issues.apache.org/jira/browse/IGNITE-13618 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Attachments: benchmark-results.txt > > Time Spent: 1h > Remaining Estimate: 0h > > h3. Motivation. > It may worth having generated serializer code for performance reasons. > However, this should be proved with benchmarks. > h3. Description. > Let's prototype object serializer for type-system described in IEP-54, and > benchmark them to check if generated code approach is a better one. > * As we go with Java11 then VarHandles must be used instead of Unsafe. > * For generated serializer we can use: JDK compiler + Javapoet project (Java > code generator) or Janino compiler or even Prestodb-bytecode module of > PrestoDB project > *UPD*: JDK compile is too slow, Janino doesn't support Java9+ and VarHandles, > Prestodb-bytecode has an unwanted Guava dependency. > So, forking Prestodb without Guava looks like a preferable way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14328) .NET: Array of Collections can't be used as service method parameters
[
https://issues.apache.org/jira/browse/IGNITE-14328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14328:
-
Description: Currently, array of collections (list, map) can't be used as a
service method parameter in case of .Net -> Java call. (was: Currently,
collections (list, map) can't be used as a service method parameter in case of
.Net (client node) -> .Net (server node) call.
This can be reproduced my one line modification of
{{ServicesTypeAutoResolveTest#DoTestPlatformService}}
{code:java}
///
/// Tests .Net service invocation.
///
public void DoTestPlatformService(IServices svcsForProxy)
{
const string platformSvcName = "PlatformTestService";
_grid1.GetServices().DeployClusterSingleton(platformSvcName, new
PlatformTestService());
var svc =
svcsForProxy.GetServiceProxy(platformSvcName);
DoTestService(svc);
DoTestCollections(svc); // This line was added.
_grid1.GetServices().Cancel(platformSvcName);
}
{code}
Exception:
{noformat}
Apache.Ignite.Core.Services.ServiceInvocationException : Proxy method
invocation failed with an exception. Examine InnerException for details.
> Apache.Ignite.Core.Common.IgniteException : No matching type found for
object [typeId=1552553483,
typeName=org.system.collections.generic.List`1[[org.apache.ignite.platform.model.department,
apache.ignite.core.testDepartment]]]. This usually indicates that assembly
with specified type is not loaded on a node. When using Apache.Ignite.exe, make
sure to load assemblies with -assembly parameter. Alternatively, set
IgniteConfiguration.PeerAssemblyLoadingMode to CurrentAppDomain.
{noformat})
> .NET: Array of Collections can't be used as service method parameters
> -
>
> Key: IGNITE-14328
> URL: https://issues.apache.org/jira/browse/IGNITE-14328
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>
> Currently, array of collections (list, map) can't be used as a service method
> parameter in case of .Net -> Java call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14328) .NET: Array of Collections can't be used as service method parameters
Nikolay Izhikov created IGNITE-14328:
Summary: .NET: Array of Collections can't be used as service
method parameters
Key: IGNITE-14328
URL: https://issues.apache.org/jira/browse/IGNITE-14328
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
Currently, collections (list, map) can't be used as a service method parameter
in case of
.Net (client node) -> .Net (server node) call.
This can be reproduced my one line modification of
{{ServicesTypeAutoResolveTest#DoTestPlatformService}}
{code:java}
///
/// Tests .Net service invocation.
///
public void DoTestPlatformService(IServices svcsForProxy)
{
const string platformSvcName = "PlatformTestService";
_grid1.GetServices().DeployClusterSingleton(platformSvcName, new
PlatformTestService());
var svc =
svcsForProxy.GetServiceProxy(platformSvcName);
DoTestService(svc);
DoTestCollections(svc); // This line was added.
_grid1.GetServices().Cancel(platformSvcName);
}
{code}
Exception:
{noformat}
Apache.Ignite.Core.Services.ServiceInvocationException : Proxy method
invocation failed with an exception. Examine InnerException for details.
> Apache.Ignite.Core.Common.IgniteException : No matching type found for
object [typeId=1552553483,
typeName=org.system.collections.generic.List`1[[org.apache.ignite.platform.model.department,
apache.ignite.core.testDepartment]]]. This usually indicates that assembly
with specified type is not loaded on a node. When using Apache.Ignite.exe, make
sure to load assemblies with -assembly parameter. Alternatively, set
IgniteConfiguration.PeerAssemblyLoadingMode to CurrentAppDomain.
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14322: - Reviewer: Sergey Chugunov > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14322: - Comment: was deleted (was: https://github.com/apache/ignite/pull/) > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage
[ https://issues.apache.org/jira/browse/IGNITE-14322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303200#comment-17303200 ] Aleksandr Polovtcev commented on IGNITE-14322: -- https://github.com/apache/ignite/pull/ > False warning about DataRegionConfiguration.maxWalArchiveSize property usage > > > Key: IGNITE-14322 > URL: https://issues.apache.org/jira/browse/IGNITE-14322 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > On every non-persistent startup the following is printed: > DataRegionConfiguration.maxWalArchiveSize instead > DataRegionConfiguration.walHistorySize would be used for removing old archive > wal files > This does not make sense when persistence is totally off. > Also, syntax should be fixed, "instead of", should be more clear what's going > on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303169#comment-17303169
]
Pavel Tupitsyn commented on IGNITE-14076:
-
[~zstan] looks good to me
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-14076:
Fix Version/s: (was: 2.11)
Affects Version/s: (was: 2.9.1)
2.10
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.10
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303166#comment-17303166
]
Stanilovsky Evgeny commented on IGNITE-14076:
-
[~ptupitsyn] [~sk0x50] guys can you check plz ?
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303165#comment-17303165
]
Stanilovsky Evgeny commented on IGNITE-14076:
-
I hope that no additional tests need to be here, putAll throughput speedup can
be checked locally, for example, by running:
IgnitePutAllLargeBatchSelfTest#testPutAllOptimisticOneBackupPartitioned with
appropriate change in _int keyCnt = 200;_ for example by 20_000
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14076) Quadratic putAll performance degradation in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303163#comment-17303163
]
Ignite TC Bot commented on IGNITE-14076:
{panel:title=Branch: [pull/8885/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8885/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5918009buildTypeId=IgniteTests24Java8_RunAll]
> Quadratic putAll performance degradation in transactional cache
> ---
>
> Key: IGNITE-14076
> URL: https://issues.apache.org/jira/browse/IGNITE-14076
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Pavel Tupitsyn
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{putAll}} execution time grows almost exponentially while the number of keys
> grows linearly in the following test:
> {code:java}
> public class PutAllTxTest extends GridCommonAbstractTest {
> @Test
> public void testPutAll() throws Exception {
> Ignition.start(getConfiguration("server1"));
> Ignition.start(getConfiguration("server2"));
> Ignite ignite =
> Ignition.start(getConfiguration("client").setClientMode(true));
> IgniteCache cache = ignite.createCache(
> new CacheConfiguration("c")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> int count = 5;
> Map data = new TreeMap<>();
> for (int i = 0; i < count; i++)
> data.put(i, i);
> long begin = System.nanoTime();
> cache.putAll(data);
> long dur = System.nanoTime() - begin;
> System.out.println("> " + dur / 100);
> }
> }
> {code}
> ||Entries||Seconds||
> |1000|0.4|
> |5000|1.9|
> |1|3.8|
> |2|10.7|
> |3|23.5|
> |4|41|
> |5|64|
> |6|90|
> |10|254|
> This does not reproduce with 1 server node, and does not reproduce on
> {{ATOMIC}} caches with any number of nodes.
> *Observations:*
> - Not a GC issue (it barely runs)
> - Not a memory issue (heap is under 1GB)
> - GridDhtTxPrepareFuture#localDhtPendingVersions ->
> GridCacheMapEntry.localCandidates is the bottleneck. For 1K keys,
> localCandidates gets called 123K times, 2K keys - 484K times, etc.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14308) IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare deployable, because local node id does not correspond with class loader id
[
https://issues.apache.org/jira/browse/IGNITE-14308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-14308:
-
Reviewer: Sergey Chugunov
> IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare
> deployable, because local node id does not correspond with class loader id
> -
>
> Key: IGNITE-14308
> URL: https://issues.apache.org/jira/browse/IGNITE-14308
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-12760, the following exception is seen:
> {code}
> IgnitePeerToPeerClassLoadingException
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.checkDeploymentIsCorrect(GridCacheDeploymentManager.java:717)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.prepare(GridCacheDeploymentManager.java:693)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1245)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:570)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:381)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:324)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:128)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3965)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:4013)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2958)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAllAsync0(GridNearTxLocal.java:1033)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:540)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2389)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:3830)
> ... 29 more
> {code}
> Turns out, sometimes local deployment belongs to other node id (previous
> client?). Changing behavior for local deployments was not anticipated. Let's
> change this error to warning for local deployments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14308) IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare deployable, because local node id does not correspond with class loader id
[
https://issues.apache.org/jira/browse/IGNITE-14308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303132#comment-17303132
]
Sergey Chugunov commented on IGNITE-14308:
--
[~ilyak],
Change looks good to me, please proceed with merge. Thanks!
> IgnitePeerToPeerClassLoadingException: Could not use deployment to prepare
> deployable, because local node id does not correspond with class loader id
> -
>
> Key: IGNITE-14308
> URL: https://issues.apache.org/jira/browse/IGNITE-14308
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-12760, the following exception is seen:
> {code}
> IgnitePeerToPeerClassLoadingException
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.checkDeploymentIsCorrect(GridCacheDeploymentManager.java:717)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.prepare(GridCacheDeploymentManager.java:693)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1245)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:570)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:381)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:324)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:204)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:128)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3965)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:4013)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2958)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAllAsync0(GridNearTxLocal.java:1033)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:540)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2389)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$27.op(GridCacheAdapter.java:2385)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:3830)
> ... 29 more
> {code}
> Turns out, sometimes local deployment belongs to other node id (previous
> client?). Changing behavior for local deployments was not anticipated. Let's
> change this error to warning for local deployments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita reassigned IGNITE-14214:
Assignee: Amelchev Nikita (was: Yaroslav Molochkov)
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
