[jira] [Commented] (IGNITE-13633) thin clients cannot access the Ignite Service deployed through UriDeploymentSpi( java.lang.ClassNotFoundException)
[ https://issues.apache.org/jira/browse/IGNITE-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243913#comment-17243913 ] Vyacheslav Daradur commented on IGNITE-13633: - Merged to master. [~alex_pl], thank you for your contribution! > thin clients cannot access the Ignite Service deployed through > UriDeploymentSpi( java.lang.ClassNotFoundException) > -- > > Key: IGNITE-13633 > URL: https://issues.apache.org/jira/browse/IGNITE-13633 > Project: Ignite > Issue Type: Bug > Components: managed services, thin client >Affects Versions: 2.9 >Reporter: xingzhou >Assignee: Aleksey Plekhanov >Priority: Critical > Fix For: 2.10 > > Attachments: ignite-deploy.zip > > Original Estimate: 24h > Time Spent: 3h 10m > Remaining Estimate: 20h 50m > > When the thin client is used to call the ignite service（ use ignite-urideploy > ）, the clientserviceinvokerequest will get the service classes, the local > classloader is used, and the classes cannot be found. Therefore, the > ignite-urideploy classloader should be added -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13633) thin clients cannot access the Ignite Service deployed through UriDeploymentSpi( java.lang.ClassNotFoundException)
[ https://issues.apache.org/jira/browse/IGNITE-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242669#comment-17242669 ] Vyacheslav Daradur commented on IGNITE-13633: - [~alex_pl], the changes lgtm. Let's getting new TC-bot visa just to be sure and I'll merge it. > thin clients cannot access the Ignite Service deployed through > UriDeploymentSpi( java.lang.ClassNotFoundException) > -- > > Key: IGNITE-13633 > URL: https://issues.apache.org/jira/browse/IGNITE-13633 > Project: Ignite > Issue Type: Bug > Components: managed services, thin client >Affects Versions: 2.9 >Reporter: xingzhou >Assignee: Aleksey Plekhanov >Priority: Critical > Fix For: 2.10 > > Attachments: ignite-deploy.zip > > Original Estimate: 24h > Time Spent: 3h > Remaining Estimate: 21h > > When the thin client is used to call the ignite service（ use ignite-urideploy > ）, the clientserviceinvokerequest will get the service classes, the local > classloader is used, and the classes cannot be found. Therefore, the > ignite-urideploy classloader should be added -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13633) thin clients cannot access the Ignite Service deployed through UriDeploymentSpi( java.lang.ClassNotFoundException)
[ https://issues.apache.org/jira/browse/IGNITE-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227949#comment-17227949 ] Vyacheslav Daradur commented on IGNITE-13633: - I'll have a look next week. > thin clients cannot access the Ignite Service deployed through > UriDeploymentSpi( java.lang.ClassNotFoundException) > -- > > Key: IGNITE-13633 > URL: https://issues.apache.org/jira/browse/IGNITE-13633 > Project: Ignite > Issue Type: Bug > Components: managed services, thin client >Affects Versions: 2.9 >Reporter: xingzhou >Assignee: Aleksey Plekhanov >Priority: Critical > Fix For: 2.9.1 > > Attachments: ignite-deploy.zip > > Original Estimate: 24h > Time Spent: 10m > Remaining Estimate: 23h 50m > > When the thin client is used to call the ignite service（ use ignite-urideploy > ）, the clientserviceinvokerequest will get the service classes, the local > classloader is used, and the classes cannot be found. Therefore, the > ignite-urideploy classloader should be added -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13312) Methods of interface Binarylizable should not get access to host resources.
[ https://issues.apache.org/jira/browse/IGNITE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181850#comment-17181850 ] Vyacheslav Daradur commented on IGNITE-13312: - [~garus.d.g], lgtm, merged to master. Thank you for your contribution! > Methods of interface Binarylizable should not get access to host resources. > --- > > Key: IGNITE-13312 > URL: https://issues.apache.org/jira/browse/IGNITE-13312 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 40m > Remaining Estimate: 0h > > Methods of interface Binarylizable should not get access to host resources on > remote nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10100) Add public Java API to call Ignite.NET services
[
https://issues.apache.org/jira/browse/IGNITE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113800#comment-17113800
]
Vyacheslav Daradur commented on IGNITE-10100:
-
[~alex_pl], please go forward if you have already reviewed the pr.
> Add public Java API to call Ignite.NET services
> ---
>
> Key: IGNITE-10100
> URL: https://issues.apache.org/jira/browse/IGNITE-10100
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, sbcf
> Fix For: 2.9
>
> Attachments: ignite-10100-vs-2.8.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Ignite wraps .NET services in PlatformDotNetServiceImpl implementing
> PlatformService interface.
> PlatformService is defined in internal Ignite package
> apache.ignite.internal.processors.platform.services. It exposes
> {{ invokeMethod(methodName, Object[] params): Object}}
> to call any service method dynamically. Right now there is no Ignite public
> API to call a PlatformService using static typing.
> We need to develop a public API to call PlatformDotNetServiceImpl using
> static typing in Java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[ https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108599#comment-17108599 ] Vyacheslav Daradur commented on IGNITE-12490: - Service deployment guarantees were improved into IGNITE-12894, the described issue also fixed. > Service proxy throws "Service not found" exception right after deploy > - > > Key: IGNITE-12490 > URL: https://issues.apache.org/jira/browse/IGNITE-12490 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.8 >Reporter: Alexey Goncharuk >Priority: Major > Attachments: ServiceInvokeTest.java > > > In the following scenario: > * Start nodes A, B > * Deploy a service on A > * Create a service proxy on B > * Invoke the proxy > The proxy invocation throws a service not found exception. As per discussion > [on the dev > list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html] > this case should be handled by an automatic retry, however, it's not. > The reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[ https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-12490. - Resolution: Fixed > Service proxy throws "Service not found" exception right after deploy > - > > Key: IGNITE-12490 > URL: https://issues.apache.org/jira/browse/IGNITE-12490 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.8 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > Attachments: ServiceInvokeTest.java > > > In the following scenario: > * Start nodes A, B > * Deploy a service on A > * Create a service proxy on B > * Invoke the proxy > The proxy invocation throws a service not found exception. As per discussion > [on the dev > list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html] > this case should be handled by an automatic retry, however, it's not. > The reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[ https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-12490: Fix Version/s: 2.9 > Service proxy throws "Service not found" exception right after deploy > - > > Key: IGNITE-12490 > URL: https://issues.apache.org/jira/browse/IGNITE-12490 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.8 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > Attachments: ServiceInvokeTest.java > > > In the following scenario: > * Start nodes A, B > * Deploy a service on A > * Create a service proxy on B > * Invoke the proxy > The proxy invocation throws a service not found exception. As per discussion > [on the dev > list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html] > this case should be handled by an automatic retry, however, it's not. > The reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-12894:
Fix Version/s: 2.9
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based
> service deployment mode (but not in the default deployment mode):
> {code:java}
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET
> {{GetServiceProxy}} API does not support the service wait timeout, which is
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
> Failed to initialize service (service will not be deployed):
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while
> waiting for future to complete.
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
> at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentTask.lambda$processDeploymentActions$5(ServiceDeploymentTask.java:318)
[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108597#comment-17108597
]
Vyacheslav Daradur commented on IGNITE-12894:
-
[~PetrovMikhail], merged to master.
Thanks for your contribution!
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based
> service deployment mode (but not in the default deployment mode):
> {code:java}
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET
> {{GetServiceProxy}} API does not support the service wait timeout, which is
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
> Failed to initialize service (service will not be deployed):
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while
> waiting for future to complete.
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
> at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.redeploy(IgniteServiceProcessor.java:1188)
> at
>
[jira] [Commented] (IGNITE-10100) Add public Java API to call Ignite.NET services
[
https://issues.apache.org/jira/browse/IGNITE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108037#comment-17108037
]
Vyacheslav Daradur commented on IGNITE-10100:
-
I'll take a look next week.
> Add public Java API to call Ignite.NET services
> ---
>
> Key: IGNITE-10100
> URL: https://issues.apache.org/jira/browse/IGNITE-10100
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, sbcf
> Fix For: 2.9
>
> Attachments: ignite-10100-vs-2.8.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Ignite wraps .NET services in PlatformDotNetServiceImpl implementing
> PlatformService interface.
> PlatformService is defined in internal Ignite package
> apache.ignite.internal.processors.platform.services. It exposes
> {{ invokeMethod(methodName, Object[] params): Object}}
> to call any service method dynamically. Right now there is no Ignite public
> API to call a PlatformService using static typing.
> We need to develop a public API to call PlatformDotNetServiceImpl using
> static typing in Java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106192#comment-17106192
]
Vyacheslav Daradur commented on IGNITE-12894:
-
Hi, [~PetrovMikhail]. I can't find a link to TC-tests and TC-bot visa despite
the fact that the task is in patch-available state.
Please get TC-bot visa and link TC-tests.
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based
> service deployment mode (but not in the default deployment mode):
> {code:java}
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET
> {{GetServiceProxy}} API does not support the service wait timeout, which is
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
> Failed to initialize service (service will not be deployed):
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while
> waiting for future to complete.
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:888)
> at
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:886)
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1062)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3999)
> at
> org.apache.ignite.internal.IgniteKernal.atomicSequence(IgniteKernal.java:3985)
> at Sandbox.Net.IgniteTestService.init(IgniteTestService.java:17)
> at
>
[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17099326#comment-17099326
]
Vyacheslav Daradur commented on IGNITE-12894:
-
[~PetrovMikhail], the suggestion proposed by you makes sense, but it covers the
only case - the race between request sender state and remote node to invoke and
allows the sender to resend request.
There are several disadvantages:
- multiple requests in comparison with possible handling of the case on a
remote node (without resend requests)
- the infinite loop is possible in case of deployment failed, we should
consider a case when deployment is failed and there is no sense resend request
I think we need a mechanism of waiting for a change of service topology on
Ignite node without resending of request. The approach covers case with
statically configured service from the task's description when service is
called before deployment finished on a single node cluster. Also, the issue
with remote proxy may be solved the same way.
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false)
> .sayHello("World");
> }
> }
> }
> {code}
> h2. Workaround
> Specifying a service wait timeout solves the problem in the discovery-based
> service deployment mode (but not in the default deployment mode):
> {code:java}
>
> ignite.services().serviceProxy(IgniteTestService.class.getSimpleName(),
> Test.class, false, 1_000)
> .sayHello("World");
> {code}
> This workaround cannot be used in Ignite.NET clients since .NET
> {{GetServiceProxy}} API does not support the service wait timeout, which is
> hard-coded to 0 on the server side.
> h2. Full Exception in Discovery-Based Service Deployment Mode
> {noformat}
> [01:08:54,653][SEVERE][services-deployment-worker-#52][IgniteServiceProcessor]
> Failed to initialize service (service will not be deployed):
> IgniteTestService
> class org.apache.ignite.IgniteInterruptedException: Got interrupted while
> waiting for future to complete.
> at
>
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091560#comment-17091560
]
Vyacheslav Daradur edited comment on IGNITE-12894 at 4/24/20, 1:21 PM:
---
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registerd in cluster: wasn't present in cfg
and didn't deployed througt API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty())
return top;
// Wait using "servicesTopsUpdateMux" while service deployment finished and
the topology will not be empty
// or removed from "registeredServices" in case if deployment failure
{code}
was (Author: daradurvs):
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
if (!srvcDesc.topologySnapshot().isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091560#comment-17091560
]
Vyacheslav Daradur edited comment on IGNITE-12894 at 4/24/20, 1:16 PM:
---
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
if (!srvcDesc.topologySnapshot().isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
was (Author: daradurvs):
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business
[jira] [Issue Comment Deleted] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[
https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-12490:
Comment: was deleted
(was: Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code})
> Service proxy throws "Service not found" exception right after deploy
> -
>
> Key: IGNITE-12490
> URL: https://issues.apache.org/jira/browse/IGNITE-12490
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: ServiceInvokeTest.java
>
>
> In the following scenario:
> * Start nodes A, B
> * Deploy a service on A
> * Create a service proxy on B
> * Invoke the proxy
> The proxy invocation throws a service not found exception. As per discussion
> [on the dev
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
> this case should be handled by an automatic retry, however, it's not.
> The reproducer is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091560#comment-17091560
]
Vyacheslav Daradur commented on IGNITE-12894:
-
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
>
[jira] [Commented] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[
https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091558#comment-17091558
]
Vyacheslav Daradur commented on IGNITE-12490:
-
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Service proxy throws "Service not found" exception right after deploy
> -
>
> Key: IGNITE-12490
> URL: https://issues.apache.org/jira/browse/IGNITE-12490
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: ServiceInvokeTest.java
>
>
> In the following scenario:
> * Start nodes A, B
> * Deploy a service on A
> * Create a service proxy on B
> * Invoke the proxy
> The proxy invocation throws a service not found exception. As per discussion
> [on the dev
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
> this case should be handled by an automatic retry, however, it's not.
> The reproducer is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11905) [IEP-35] Monitoring Phase 2
[ https://issues.apache.org/jira/browse/IGNITE-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926087#comment-16926087 ] Vyacheslav Daradur commented on IGNITE-11905: - [~NIzhikov], thank you for the patch, great work! I left some minor pr comments on GitHub. > [IEP-35] Monitoring Phase 2 > -- > > Key: IGNITE-11905 > URL: https://issues.apache.org/jira/browse/IGNITE-11905 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > Phase 2 should introduce: > Ability to collect lists of some internal object Ignite manage. > Examples of such objects: > * Caches > * Queries (including continuous queries) > * Services > * Compute tasks > * Distributed Data Structures > * etc... > 1. Fields for each list should be discussed in separate tickets > 2. Metric Exporters (optionally) can support list export. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863454#comment-16863454 ] Vyacheslav Daradur commented on IGNITE-11848: - [~NIzhikov] Looks good to me. Please run tests once again before the merge, just to be sure. > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823474#comment-16823474
]
Vyacheslav Daradur commented on IGNITE-11277:
-
[~Mmuzaf], the changes merged to master.
Please mark this issue as resolved and announce on dev-list.
Thank you for contribution!
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822749#comment-16822749
]
Vyacheslav Daradur commented on IGNITE-11277:
-
[~Mmuzaf], I looked through the PR and have some question:
1. Do we really need a new dependency {{com.puppycrawl.tools}}? Looks like
{{maven-checkstyle-plugin}} [already
have|https://github.com/apache/maven-checkstyle-plugin/blob/master/pom.xml#L208]
this in dependencies.
2. Do we really need a new profile for checking? Can't we just use {{mvn
validate}} or {{mvn checkstyle:check}}?
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11127) GridDhtInvalidPartitionException not handled by GridCacheTtlManager
[
https://issues.apache.org/jira/browse/IGNITE-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804830#comment-16804830
]
Vyacheslav Daradur commented on IGNITE-11127:
-
[~roman_s], I'm a bit late :) The fix looks good to me.
One minor comment for future contributions: related to test, there is no need
to define static field {{TcpDiscoveryVmIpFinder(true)}} directly since it's set
by default in abstract class.
Thanks for your contributions!
> GridDhtInvalidPartitionException not handled by GridCacheTtlManager
> ---
>
> Key: IGNITE-11127
> URL: https://issues.apache.org/jira/browse/IGNITE-11127
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4, 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Roman Shtykh
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Leading to either message processing problems:
> {code}
> [2019-01-27 16:57:45,474][ERROR][sys-stripe-2-#3][GridCacheIoManager] Failed
> to process message [senderId=4839b5a2-a295-44cf-8a44-f0cb932b689e,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicFullUpdateRequest]
> class
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
> [part=381, msg=Adding entry to partition that is concurrently evicted
> [grp=, part=381, shouldBeMoving=, belongs=false,
> topVer=AffinityTopologyVersion [topVer=818, minorTopVer=0],
> curTopVer=AffinityTopologyVersion [topVer=818, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:917)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:794)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:952)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:943)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1047)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:835)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1093)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1066)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> or unhandled unspecified exceptions in user code (possibly violating JCache):
> {code}
> [2019-01-27 10:23:35,451][ERROR][pub-#840058][ComputeJobProcess] class
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
> [part=485, msg=Adding entry to partition that is concurrently evicted
> [grp=, part=485,
[jira] [Updated] (IGNITE-11539) Document services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-11539: Labels: iep-17 (was: ) > Document services hot redeployment via DeploymentSpi > > > Key: IGNITE-11539 > URL: https://issues.apache.org/jira/browse/IGNITE-11539 > Project: Ignite > Issue Type: Task > Components: documentation, managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document "how to use" service hot redeployment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11539) Document services hot redeployment via DeploymentSpi
Vyacheslav Daradur created IGNITE-11539: --- Summary: Document services hot redeployment via DeploymentSpi Key: IGNITE-11539 URL: https://issues.apache.org/jira/browse/IGNITE-11539 Project: Ignite Issue Type: Task Components: documentation, managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 It's necessary to document "how to use" service hot redeployment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11384) Introduce an ability of services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-11384: Labels: iep-17 (was: ) > Introduce an ability of services hot redeployment via DeploymentSpi > --- > > Key: IGNITE-11384 > URL: https://issues.apache.org/jira/browse/IGNITE-11384 > Project: Ignite > Issue Type: Sub-task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > We can integrate service processor with DeploymentSpi to introduce an > opportunity of services hot redeployment. For this change, the service > processor should try to get and use registered classloader registered for the > service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11384) Introduce an ability of services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-11384: Summary: Introduce an ability of services hot redeployment via DeploymentSpi (was: Introduce an opportunity of services hot redeployment via DeploymentSpi) > Introduce an ability of services hot redeployment via DeploymentSpi > --- > > Key: IGNITE-11384 > URL: https://issues.apache.org/jira/browse/IGNITE-11384 > Project: Ignite > Issue Type: Sub-task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > We can integrate service processor with DeploymentSpi to introduce an > opportunity of services hot redeployment. For this change, the service > processor should try to get and use registered classloader registered for the > service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11384) Introduce an opportunity of services hot redeployment via DeploymentSpi
Vyacheslav Daradur created IGNITE-11384: --- Summary: Introduce an opportunity of services hot redeployment via DeploymentSpi Key: IGNITE-11384 URL: https://issues.apache.org/jira/browse/IGNITE-11384 Project: Ignite Issue Type: Sub-task Components: managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 We can integrate service processor with DeploymentSpi to introduce an opportunity of services hot redeployment. For this change, the service processor should try to get and use registered classloader registered for the service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-6259: -- Assignee: (was: Vyacheslav Daradur) > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10021) IgniteInterruptedCheckedException: sleep interrupted in GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange
[
https://issues.apache.org/jira/browse/IGNITE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744807#comment-16744807
]
Vyacheslav Daradur commented on IGNITE-10021:
-
[~oignatenko], the issue is not actual for new service processor implemented
within IGNITE-9607. I'd suggest closing the issue.
> IgniteInterruptedCheckedException: sleep interrupted in
> GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange
> ---
>
> Key: IGNITE-10021
> URL: https://issues.apache.org/jira/browse/IGNITE-10021
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: GridServiceProcessorBatchDeploySelfTest.java,
> GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange.log
>
>
> Test {{GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange}}
> failed at TC (couldn't reproduce locally), error message:
> {noformat}
> [2018-10-23
> 15:40:25,651][ERROR][srvc-deploy-#121506%extra-node-1%][TcpCommunicationSpi]
> Failed to send message to remote node [node=TcpDiscoveryNode
> [id=ce88f2ef-5c88-46f1-83d4-50dd8163, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1540309225078, loc=false, ver=2.7.0#20181023-sha1:d09f1d47,
> isClient=false], msg=GridIoMessage [plc=5, topic=TOPIC_CACHE, topicOrd=8,
> ordered=false, timeout=0, skipOnTimeout=false, msg=GridCacheIdMessage
> [cacheId=0]GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=151789232, order=1540309225927, nodeOrder=7], committedVers=null,
> rolledbackVers=null, cnt=0, super=]GridDistributedTxPrepareRequest
> [threadId=133839, concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> writeVer=GridCacheVersion [topVer=151789232, order=1540309225928,
> nodeOrder=7], timeout=0, reads=null, writes=PredicateCollectionView
> [IgniteTxEntry [key=KeyCacheObjectImpl [part=9, val=GridServiceAssignmentsKey
> [name=testService-175], hasValBytes=true], cacheId=-2100569601,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=9,
> val=GridServiceAssignmentsKey [name=testService-175], hasValBytes=true],
> cacheId=-2100569601], val=[op=DELETE, val=null], prevVal=[op=NOOP, val=null],
> oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=true,
> entry=GridCacheMapEntry [key=KeyCacheObjectImpl [part=9,
> val=GridServiceAssignmentsKey [name=testService-175], hasValBytes=true],
> val=CacheObjectImpl [val=GridServiceAssignments
> [nodeId=bdeeb063-5558-4dab-90c3-b61b91b338f0, topVer=6,
> cfg=LazyServiceConfiguration
> [srvcClsName=org.apache.ignite.internal.processors.service.DummyService,
> svcCls=, nodeFilterCls=AttributeFilter], assigns=HashMap
> {0069f119-2516-48ee-866c-8a3ba55f8000=0,
> dcf0a942-d7d0-4574-870a-6b251740=0,
> ce88f2ef-5c88-46f1-83d4-50dd8163=1,
> 3264d65e-695f-433c-b028-7bff8b82=0,
> 4427ca0c-24c1-4e61-9f04-bbd37d11=0}], hasValBytes=true],
> ver=GridCacheVersion [topVer=151789229, order=1540309225560, nodeOrder=1],
> hash=1705888709, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=LinkedList [GridCacheMvccCandidate
> [nodeId=100f5b42-d915-409b-980c-726f1945a001, ver=GridCacheVersion
> [topVer=151789232, order=1540309225927, nodeOrder=7], threadId=133839,
> id=335933, topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0],
> reentry=null, otherNodeId=100f5b42-d915-409b-980c-726f1945a001,
> otherVer=GridCacheVersion [topVer=151789232, order=1540309225927,
> nodeOrder=7], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null, key=KeyCacheObjectImpl [part=9, val=GridServiceAssignmentsKey
> [name=testService-175], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null]], rmts=null]], flags=2]GridDistributedCacheEntry
> [super=]GridDhtCacheEntry [rdrs=ReaderId[] [], part=9, super=], prepared=1,
> locked=false, nodeId=100f5b42-d915-409b-980c-726f1945a001, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=151789232,
> order=1540309225927, nodeOrder=7]]], dhtVers=null, txSize=0, plc=5,
> txState=null, flags=retVal|last|sys, super=]GridDhtTxPrepareRequest
> [nearNodeId=100f5b42-d915-409b-980c-726f1945a001,
> futId=f0a1fb1a661-0ff0152a-8da5-4117-8c29-4ba138e30072,
[jira] [Updated] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-6259: --- Fix Version/s: (was: 2.8) > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Priority: Major > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10021) IgniteInterruptedCheckedException: sleep interrupted in GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange
[
https://issues.apache.org/jira/browse/IGNITE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-10021:
---
Assignee: (was: Vyacheslav Daradur)
> IgniteInterruptedCheckedException: sleep interrupted in
> GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange
> ---
>
> Key: IGNITE-10021
> URL: https://issues.apache.org/jira/browse/IGNITE-10021
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: GridServiceProcessorBatchDeploySelfTest.java,
> GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange.log
>
>
> Test {{GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange}}
> failed at TC (couldn't reproduce locally), error message:
> {noformat}
> [2018-10-23
> 15:40:25,651][ERROR][srvc-deploy-#121506%extra-node-1%][TcpCommunicationSpi]
> Failed to send message to remote node [node=TcpDiscoveryNode
> [id=ce88f2ef-5c88-46f1-83d4-50dd8163, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1540309225078, loc=false, ver=2.7.0#20181023-sha1:d09f1d47,
> isClient=false], msg=GridIoMessage [plc=5, topic=TOPIC_CACHE, topicOrd=8,
> ordered=false, timeout=0, skipOnTimeout=false, msg=GridCacheIdMessage
> [cacheId=0]GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=151789232, order=1540309225927, nodeOrder=7], committedVers=null,
> rolledbackVers=null, cnt=0, super=]GridDistributedTxPrepareRequest
> [threadId=133839, concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> writeVer=GridCacheVersion [topVer=151789232, order=1540309225928,
> nodeOrder=7], timeout=0, reads=null, writes=PredicateCollectionView
> [IgniteTxEntry [key=KeyCacheObjectImpl [part=9, val=GridServiceAssignmentsKey
> [name=testService-175], hasValBytes=true], cacheId=-2100569601,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=9,
> val=GridServiceAssignmentsKey [name=testService-175], hasValBytes=true],
> cacheId=-2100569601], val=[op=DELETE, val=null], prevVal=[op=NOOP, val=null],
> oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=true,
> entry=GridCacheMapEntry [key=KeyCacheObjectImpl [part=9,
> val=GridServiceAssignmentsKey [name=testService-175], hasValBytes=true],
> val=CacheObjectImpl [val=GridServiceAssignments
> [nodeId=bdeeb063-5558-4dab-90c3-b61b91b338f0, topVer=6,
> cfg=LazyServiceConfiguration
> [srvcClsName=org.apache.ignite.internal.processors.service.DummyService,
> svcCls=, nodeFilterCls=AttributeFilter], assigns=HashMap
> {0069f119-2516-48ee-866c-8a3ba55f8000=0,
> dcf0a942-d7d0-4574-870a-6b251740=0,
> ce88f2ef-5c88-46f1-83d4-50dd8163=1,
> 3264d65e-695f-433c-b028-7bff8b82=0,
> 4427ca0c-24c1-4e61-9f04-bbd37d11=0}], hasValBytes=true],
> ver=GridCacheVersion [topVer=151789229, order=1540309225560, nodeOrder=1],
> hash=1705888709, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=LinkedList [GridCacheMvccCandidate
> [nodeId=100f5b42-d915-409b-980c-726f1945a001, ver=GridCacheVersion
> [topVer=151789232, order=1540309225927, nodeOrder=7], threadId=133839,
> id=335933, topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0],
> reentry=null, otherNodeId=100f5b42-d915-409b-980c-726f1945a001,
> otherVer=GridCacheVersion [topVer=151789232, order=1540309225927,
> nodeOrder=7], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null, key=KeyCacheObjectImpl [part=9, val=GridServiceAssignmentsKey
> [name=testService-175], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null]], rmts=null]], flags=2]GridDistributedCacheEntry
> [super=]GridDhtCacheEntry [rdrs=ReaderId[] [], part=9, super=], prepared=1,
> locked=false, nodeId=100f5b42-d915-409b-980c-726f1945a001, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=151789232,
> order=1540309225927, nodeOrder=7]]], dhtVers=null, txSize=0, plc=5,
> txState=null, flags=retVal|last|sys, super=]GridDhtTxPrepareRequest
> [nearNodeId=100f5b42-d915-409b-980c-726f1945a001,
> futId=f0a1fb1a661-0ff0152a-8da5-4117-8c29-4ba138e30072, miniId=1,
> topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=151789232,
[jira] [Updated] (IGNITE-10021) IgniteInterruptedCheckedException: sleep interrupted in GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange
[
https://issues.apache.org/jira/browse/IGNITE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10021:
Fix Version/s: (was: 2.8)
> IgniteInterruptedCheckedException: sleep interrupted in
> GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange
> ---
>
> Key: IGNITE-10021
> URL: https://issues.apache.org/jira/browse/IGNITE-10021
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: GridServiceProcessorBatchDeploySelfTest.java,
> GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange.log
>
>
> Test {{GridServiceProcessorBatchDeploySelfTest#testCancelAllTopologyChange}}
> failed at TC (couldn't reproduce locally), error message:
> {noformat}
> [2018-10-23
> 15:40:25,651][ERROR][srvc-deploy-#121506%extra-node-1%][TcpCommunicationSpi]
> Failed to send message to remote node [node=TcpDiscoveryNode
> [id=ce88f2ef-5c88-46f1-83d4-50dd8163, addrs=ArrayList [127.0.0.1],
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4,
> lastExchangeTime=1540309225078, loc=false, ver=2.7.0#20181023-sha1:d09f1d47,
> isClient=false], msg=GridIoMessage [plc=5, topic=TOPIC_CACHE, topicOrd=8,
> ordered=false, timeout=0, skipOnTimeout=false, msg=GridCacheIdMessage
> [cacheId=0]GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=151789232, order=1540309225927, nodeOrder=7], committedVers=null,
> rolledbackVers=null, cnt=0, super=]GridDistributedTxPrepareRequest
> [threadId=133839, concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> writeVer=GridCacheVersion [topVer=151789232, order=1540309225928,
> nodeOrder=7], timeout=0, reads=null, writes=PredicateCollectionView
> [IgniteTxEntry [key=KeyCacheObjectImpl [part=9, val=GridServiceAssignmentsKey
> [name=testService-175], hasValBytes=true], cacheId=-2100569601,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=9,
> val=GridServiceAssignmentsKey [name=testService-175], hasValBytes=true],
> cacheId=-2100569601], val=[op=DELETE, val=null], prevVal=[op=NOOP, val=null],
> oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=true,
> entry=GridCacheMapEntry [key=KeyCacheObjectImpl [part=9,
> val=GridServiceAssignmentsKey [name=testService-175], hasValBytes=true],
> val=CacheObjectImpl [val=GridServiceAssignments
> [nodeId=bdeeb063-5558-4dab-90c3-b61b91b338f0, topVer=6,
> cfg=LazyServiceConfiguration
> [srvcClsName=org.apache.ignite.internal.processors.service.DummyService,
> svcCls=, nodeFilterCls=AttributeFilter], assigns=HashMap
> {0069f119-2516-48ee-866c-8a3ba55f8000=0,
> dcf0a942-d7d0-4574-870a-6b251740=0,
> ce88f2ef-5c88-46f1-83d4-50dd8163=1,
> 3264d65e-695f-433c-b028-7bff8b82=0,
> 4427ca0c-24c1-4e61-9f04-bbd37d11=0}], hasValBytes=true],
> ver=GridCacheVersion [topVer=151789229, order=1540309225560, nodeOrder=1],
> hash=1705888709, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=LinkedList [GridCacheMvccCandidate
> [nodeId=100f5b42-d915-409b-980c-726f1945a001, ver=GridCacheVersion
> [topVer=151789232, order=1540309225927, nodeOrder=7], threadId=133839,
> id=335933, topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0],
> reentry=null, otherNodeId=100f5b42-d915-409b-980c-726f1945a001,
> otherVer=GridCacheVersion [topVer=151789232, order=1540309225927,
> nodeOrder=7], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null,
> serOrder=null, key=KeyCacheObjectImpl [part=9, val=GridServiceAssignmentsKey
> [name=testService-175], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null]], rmts=null]], flags=2]GridDistributedCacheEntry
> [super=]GridDhtCacheEntry [rdrs=ReaderId[] [], part=9, super=], prepared=1,
> locked=false, nodeId=100f5b42-d915-409b-980c-726f1945a001, locMapped=false,
> expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0,
> serReadVer=null, xidVer=GridCacheVersion [topVer=151789232,
> order=1540309225927, nodeOrder=7]]], dhtVers=null, txSize=0, plc=5,
> txState=null, flags=retVal|last|sys, super=]GridDhtTxPrepareRequest
> [nearNodeId=100f5b42-d915-409b-980c-726f1945a001,
> futId=f0a1fb1a661-0ff0152a-8da5-4117-8c29-4ba138e30072, miniId=1,
> topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion
[jira] [Commented] (IGNITE-8656) GridServiceProcessor does re-assignment even if no assignment is changed
[ https://issues.apache.org/jira/browse/IGNITE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744797#comment-16744797 ] Vyacheslav Daradur commented on IGNITE-8656: [~mcherkasov], I'd suggest closing the issue because it has been solved within IGNITE-9607. > GridServiceProcessor does re-assignment even if no assignment is changed > > > Key: IGNITE-8656 > URL: https://issues.apache.org/jira/browse/IGNITE-8656 > Project: Ignite > Issue Type: Bug > Components: managed services >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > > GridServiceProcessor does re-assignment even if no assignment is changed and > this cause excessive transaction on system replicated cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8630) Node filter IgnitePredicate executes twice during deploying on one single node cluster
[
https://issues.apache.org/jira/browse/IGNITE-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur resolved IGNITE-8630.
Resolution: Won't Fix
I closed the issue because it is not actual since IGNITE-9607 has been merged.
I checked the issue with the following code snippet.
{CODE}
Ignite ignite = startGrid("ignite-1");
startGrid("ignite-2");
// Deploy services only on server nodes.
ignite.services().deploy(new ServiceConfiguration()
.setMaxPerNodeCount(1)
.setNodeFilter((IgnitePredicate)node -> {
System.out.println("Is local node: " + node.isLocal());
System.out.println("ignite: " + Ignition.localIgnite().name());
return true;
})
.setName("my-service")
.setService(new DummyService())
);
{CODE}
The output is:
{NOFORMAT}
Is local node: true
ignite: ignite-1
Is local node: false
ignite: ignite-1
Is local node: false
ignite: ignite-2
Is local node: true
ignite: ignite-2
Initializing service: my-service
Initializing service: my-service
[2019-01-17 11:41:53,341][INFO
][services-deployment-worker-#97%ignite-2%][IgniteServiceProcessor] Starting
service instance [name=my-service, execId=8b11d50e-8201-4754-ad4b-7922b1120772]
[2019-01-17 11:41:53,341][INFO
][services-deployment-worker-#48%ignite-1%][IgniteServiceProcessor] Starting
service instance [name=my-service, execId=7e9b9730-d880-4483-bbe6-ff98cb031a9d]
Executing service: my-service
Executing service: my-service
{NOFORMAT}
> Node filter IgnitePredicate executes twice during deploying on one single
> node cluster
> --
>
> Key: IGNITE-8630
> URL: https://issues.apache.org/jira/browse/IGNITE-8630
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> Next code:
> {code:java}
> Ignite ignite =
> IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ?
> null : filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Produces next output:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1{code}
> In case if we will increase the cluster size to 2 then we will have:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> We will get:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> So we have additional execution:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1{code}
> So Ignite executes apply method several times (2 times for 1 server, 6 times
> for 2 servers). This behavior should be documented or fixed because at the
[jira] [Assigned] (IGNITE-8630) Node filter IgnitePredicate executes twice during deploying on one single node cluster
[
https://issues.apache.org/jira/browse/IGNITE-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur reassigned IGNITE-8630:
--
Assignee: Vyacheslav Daradur
> Node filter IgnitePredicate executes twice during deploying on one single
> node cluster
> --
>
> Key: IGNITE-8630
> URL: https://issues.apache.org/jira/browse/IGNITE-8630
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> Next code:
> {code:java}
> Ignite ignite =
> IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ?
> null : filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Produces next output:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1{code}
> In case if we will increase the cluster size to 2 then we will have:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> We will get:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> So we have additional execution:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1{code}
> So Ignite executes apply method several times (2 times for 1 server, 6 times
> for 2 servers). This behavior should be documented or fixed because at the
> moment it's could be unexpected for the user.
> You can see the same behaviour during deploying of the caches with nodeFilter
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-2907) GridServiceNotFoundException is not descriptive
[ https://issues.apache.org/jira/browse/IGNITE-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-2907: -- Assignee: (was: Vyacheslav Daradur) > GridServiceNotFoundException is not descriptive > --- > > Key: IGNITE-2907 > URL: https://issues.apache.org/jira/browse/IGNITE-2907 > Project: Ignite > Issue Type: Bug > Components: managed services >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Priority: Minor > > "Service node found" message does not make sense. > * Message should be fixed > * More details should be added (why is this situation possible, how to fix it) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10116) Document implemented design of Service Grid (redesign phase 1)
[ https://issues.apache.org/jira/browse/IGNITE-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-10116. - Resolution: Done The article has been updated according to merged solution IGNITE-9607. > Document implemented design of Service Grid (redesign phase 1) > -- > > Key: IGNITE-10116 > URL: https://issues.apache.org/jira/browse/IGNITE-10116 > Project: Ignite > Issue Type: Task > Components: documentation, managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document implemented design of Service Grid and publish in > wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741384#comment-16741384
]
Vyacheslav Daradur commented on IGNITE-10899:
-
[~EdShangGG], could you review the solution, please?
"ZooKeeper (Discovery) 2" was executed [15 times in a
row|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ZooKeeperDiscovery2_IgniteTests24Java8=pull%2F5812%2Fhead=buildTypeStatusDiv]
without "Execution timeout".
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
> blocks busyLock and not release it intentionally.
> The issue has been found on TeamCity in [Zookeeper's
> suite|https://ci.ignite.apache.org/viewLog.html?buildId=2768270=IgniteTests24Java8_ZooKeeperDiscovery2]
> with the following stack trace:
> {code:java}
> disco-notifier-worker-#569118%client4%"
> #609288
> prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
> sleeping[0x7f9383efd000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
> at
> org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
> at
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
> - locked <0xf7ecdfa0> (a java.lang.Object)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
> Source)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10888) .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail rate
[
https://issues.apache.org/jira/browse/IGNITE-10888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741382#comment-16741382
]
Vyacheslav Daradur commented on IGNITE-10888:
-
[~avinogradov], could you help with review and merge, please?
Details are in a comment above.
The test passes [15 times in a
row|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5112880895244239466=%3Cdefault%3E=testDetails_IgniteTests24Java8=pull%2F5804%2Fhead].
> .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail
> rate
> ---
>
> Key: IGNITE-10888
> URL: https://issues.apache.org/jira/browse/IGNITE-10888
> Project: Ignite
> Issue Type: Task
> Components: managed services, platforms
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Looks like {{ServicesTest.TestGetServiceProxy(False)}} became flaky after
> IGNITE-9607.
> The problem is in a flag "executed" of platforms proxy. Need to investigate a
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10910) GridTaskProcessor#onKernalStop may lead to a deadlock and execution timeout in "SPI" TC build-plan
Vyacheslav Daradur created IGNITE-10910:
---
Summary: GridTaskProcessor#onKernalStop may lead to a deadlock and
execution timeout in "SPI" TC build-plan
Key: IGNITE-10910
URL: https://issues.apache.org/jira/browse/IGNITE-10910
Project: Ignite
Issue Type: Task
Affects Versions: 2.7
Reporter: Vyacheslav Daradur
Fix For: 2.8
In rare cases calling of {{GridTaskProcessor#onKernalStop}} may lead to a
deadlock with the following stack trace:
{code:java}
"node-stopper" #225287 prio=5 os_prio=0 tid=0x7f224057a800 nid=0x233aae
waiting on condition [0x7f24607ef000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.GridSpinReadWriteLock.tryWriteLock(GridSpinReadWriteLock.java:347)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.onKernalStop(GridTaskProcessor.java:198)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2305)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2253)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2614)
- locked <0x9f42a970> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2577)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379)
at
org.apache.ignite.failure.StopNodeFailureHandler$1.run(StopNodeFailureHandler.java:36)
at java.lang.Thread.run(Thread.java:748)
{code}
It's the cause of execution timeout of "SPI" build-plan on TC:
[https://ci.ignite.apache.org/viewLog.html?buildId=2698887]
[https://ci.ignite.apache.org/viewLog.html?buildId=2689621]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10899:
Description:
In a rare case {{onDisconneced}} may be called during node stopping and
deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
blocks busyLock and not release it intentionally.
The issue has been found on TeamCity in Zookeeper's suite with the following
stack trace:
{code:java}
disco-notifier-worker-#569118%client4%"
#609288
prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
sleeping[0x7f9383efd000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
at
org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
at
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
- locked <0xf7ecdfa0> (a java.lang.Object)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
Source)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
was:
In a rare case, when {{onDisconneced}} may be called during node stopping
deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
blocks busyLock and not release it intended.
The issue found on TeamCity Zookeeper suite with the following stack trace:
{CODE}
disco-notifier-worker-#569118%client4%"
#609288
prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
sleeping[0x7f9383efd000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
at
org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
at
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
- locked <0xf7ecdfa0> (a java.lang.Object)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
Source)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{CODE}
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
> blocks busyLock and not release it intentionally.
> The issue has been found on TeamCity in Zookeeper's suite
[jira] [Updated] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10899:
Description:
In a rare case {{onDisconneced}} may be called during node stopping and
deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
blocks busyLock and not release it intentionally.
The issue has been found on TeamCity in [Zookeeper's
suite|https://ci.ignite.apache.org/viewLog.html?buildId=2768270=IgniteTests24Java8_ZooKeeperDiscovery2]
with the following stack trace:
{code:java}
disco-notifier-worker-#569118%client4%"
#609288
prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
sleeping[0x7f9383efd000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
at
org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
at
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
- locked <0xf7ecdfa0> (a java.lang.Object)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
Source)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
was:
In a rare case {{onDisconneced}} may be called during node stopping and
deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
blocks busyLock and not release it intentionally.
The issue has been found on TeamCity in Zookeeper's suite with the following
stack trace:
{code:java}
disco-notifier-worker-#569118%client4%"
#609288
prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
sleeping[0x7f9383efd000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
at
org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
at
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
- locked <0xf7ecdfa0> (a java.lang.Object)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
Source)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
> Service Grid: disconnecting during node stop may lead to deadlock
> -
>
> Key: IGNITE-10899
> URL: https://issues.apache.org/jira/browse/IGNITE-10899
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> In a rare case {{onDisconneced}} may be called during node stopping and
> deadlock may occur because of
[jira] [Created] (IGNITE-10899) Service Grid: disconnecting during node stop may lead to deadlock
Vyacheslav Daradur created IGNITE-10899:
---
Summary: Service Grid: disconnecting during node stop may lead to
deadlock
Key: IGNITE-10899
URL: https://issues.apache.org/jira/browse/IGNITE-10899
Project: Ignite
Issue Type: Task
Components: managed services
Affects Versions: 2.7
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Fix For: 2.8
In a rare case, when {{onDisconneced}} may be called during node stopping
deadlock may occur because of {{ServiceDeploymentManage#stopProcessong}}
blocks busyLock and not release it intended.
The issue found on TeamCity Zookeeper suite with the following stack trace:
{CODE}
disco-notifier-worker-#569118%client4%"
#609288
prio=5 os_prio=0 tid=0x7f905b440800 nid=0x3f6fbd
sleeping[0x7f9383efd000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:204)
at
org.apache.ignite.internal.util.GridSpinBusyLock.block(GridSpinBusyLock.java:76)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:137)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onDisconnected(IgniteServiceProcessor.java:429)
at
org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:4010)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:819)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:602)
- locked <0xf7ecdfa0> (a java.lang.Object)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4$$Lambda$25/2087171109.run(Unknown
Source)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2696)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2734)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{CODE}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10888) .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail rate
[
https://issues.apache.org/jira/browse/IGNITE-10888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740211#comment-16740211
]
Vyacheslav Daradur commented on IGNITE-10888:
-
*Summary:*
In the .NET tests is checked that {{Service#execute}} has been called during
deployment. This check is possible because of {{UnmanagedCallbacks.cs}}
registered and called for services deployed from .Net client. See for details
{{PlatformCallbackGateway.java, PlatformAbstractService.java}} for details.
But API (Service interface) does not guarantee the execution of
{{Service#execute}} once deployment process is finished, the only guarantee is
the execution of {{Service#init}}.
The test became flaky because of speedup deployment after IGNITE-9607, also
{{Services#GetServiceDescriptors()}} became faster because of access to a local
variable instead of distributed selection. That means sometimes callback has
not been called before the check, it confirms with the fact that
{{Assert.IsTrue(prx.Initialized)}} passes well all the times.
There are 2 options to fix the test:
1. Remove the check {{Assert.IsTrue(prx.Executed)}} because of lack guarantees
2. Introduce timeout to wait of the method's execution
> .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail
> rate
> ---
>
> Key: IGNITE-10888
> URL: https://issues.apache.org/jira/browse/IGNITE-10888
> Project: Ignite
> Issue Type: Task
> Components: managed services, platforms
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Looks like {{ServicesTest.TestGetServiceProxy(False)}} became flaky after
> IGNITE-9607.
> The problem is in a flag "executed" of platforms proxy. Need to investigate a
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10888) .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail rate
[
https://issues.apache.org/jira/browse/IGNITE-10888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10888:
Labels: MakeTeamcityGreenAgain Muted_test (was: MakeTeamcityGreenAgain)
> .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail
> rate
> ---
>
> Key: IGNITE-10888
> URL: https://issues.apache.org/jira/browse/IGNITE-10888
> Project: Ignite
> Issue Type: Task
> Components: managed services, platforms
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.8
>
>
> Looks like {{ServicesTest.TestGetServiceProxy(False)}} became flaky after
> IGNITE-9607.
> The problem is in a flag "executed" of platforms proxy. Need to investigate a
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10888) .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail rate
Vyacheslav Daradur created IGNITE-10888:
---
Summary: .NET: ServicesTest.TestGetServiceProxy(False) became
flaky with high fail rate
Key: IGNITE-10888
URL: https://issues.apache.org/jira/browse/IGNITE-10888
Project: Ignite
Issue Type: Task
Components: managed services, platforms
Affects Versions: 2.7
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Fix For: 2.8
Looks like {{ServicesTest.TestGetServiceProxy(False)}} became flaky after
IGNITE-9607.
The problem is in a flag "executed" of platforms proxy. Need to investigate a
reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10888) .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail rate
[
https://issues.apache.org/jira/browse/IGNITE-10888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10888:
Labels: MakeTeamcityGreenAgain (was: )
> .NET: ServicesTest.TestGetServiceProxy(False) became flaky with high fail
> rate
> ---
>
> Key: IGNITE-10888
> URL: https://issues.apache.org/jira/browse/IGNITE-10888
> Project: Ignite
> Issue Type: Task
> Components: managed services, platforms
>Affects Versions: 2.7
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> Looks like {{ServicesTest.TestGetServiceProxy(False)}} became flaky after
> IGNITE-9607.
> The problem is in a flag "executed" of platforms proxy. Need to investigate a
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10862) Introduce tool to free up space on a disc of unused memory pages
Vyacheslav Daradur created IGNITE-10862: --- Summary: Introduce tool to free up space on a disc of unused memory pages Key: IGNITE-10862 URL: https://issues.apache.org/jira/browse/IGNITE-10862 Project: Ignite Issue Type: Improvement Components: persistence Affects Versions: 2.7 Reporter: Vyacheslav Daradur Fix For: 2.8 At the current time, Ignite is not able to release occupied disc space even if a significant amount of data was removed from IgniteCache. It disturbs our users because they can't use hardware effectively, also it increases TCO. *Use-cases:* Let's imagine that we have used IgniteCache with enabled PDS during the time: - hardware disc space has been occupied during growing up of an amount of data, e.g. 100Gb; - then, we removed non-actual data, e.g 50Gb, which became useless for us; - disc space stopped growing up with new data, but it was not released, and still took 100Gb, instead of expected 50Gb; Another use case: - a user extracts data from IgniteCache to store it in separate IgniteCache or another store; - disc still is occupied and the user is not able to store data in the different cache at the same cluster because of disc limitation; *Possible solutions:* Introduce some kind of mechanics which will be able to shrink data in IgniteCache and to free up space on a disc of mapped free memory pages. A solution should take into account possible concurrent reads and updates of data and indexes to maintain consistency. Maybe, it makes sense to implement a tool to be offline at the first step that means concurrent operations will be prohibited. Strongly recommended discussing design on dev-list with Ignite experts before the start of implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10811) Add new TC build-config to test Service Grid new and old implementations
[ https://issues.apache.org/jira/browse/IGNITE-10811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16730051#comment-16730051 ] Vyacheslav Daradur commented on IGNITE-10811: - [~NIzhikov], could you review the prepared solution, please? > Add new TC build-config to test Service Grid new and old implementations > > > Key: IGNITE-10811 > URL: https://issues.apache.org/jira/browse/IGNITE-10811 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to add new build configuration on TeamCity (after merge > IGNITE-9607) to have ability testing new and old implementations of the > service processor. > In general, new build plan should contain 2 test suites: > 1) To place Service Grid related tests which *do not depend on* service > processor's implementation (like classic unit tests) and *should be executed > once*; > 2) To place Service Grid related tests which *depend* *on* service > processor's implementation and *should be executed twice* in the new mode and > old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10830) Return back semantic of GridServiceProcessor$ServiceTopologyCallable to avoid possible serialization issues
[
https://issues.apache.org/jira/browse/IGNITE-10830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10830:
Summary: Return back semantic of
GridServiceProcessor$ServiceTopologyCallable to avoid possible serialization
issues (was: Return back semantic of
GridServiceProcessor#ServiceTopologyCallable to avoid possible serialization
issues)
> Return back semantic of GridServiceProcessor$ServiceTopologyCallable to avoid
> possible serialization issues
> ---
>
> Key: IGNITE-10830
> URL: https://issues.apache.org/jira/browse/IGNITE-10830
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> It's necessary to revert changes of
> {{GridServiceProcessor#ServiceTopologyCallable}} introduced within
> IGNITE-9607.
> This may lead to serialization issues in some cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10830) Return back semantic of GridServiceProcessor$ServiceTopologyCallable to avoid possible serialization issues
[
https://issues.apache.org/jira/browse/IGNITE-10830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10830:
Description:
It's necessary to revert changes of
{{GridServiceProcessor$ServiceTopologyCallable}} introduced within IGNITE-9607.
This may lead to serialization issues in some cases.
was:
It's necessary to revert changes of
{{GridServiceProcessor#ServiceTopologyCallable}} introduced within IGNITE-9607.
This may lead to serialization issues in some cases.
> Return back semantic of GridServiceProcessor$ServiceTopologyCallable to avoid
> possible serialization issues
> ---
>
> Key: IGNITE-10830
> URL: https://issues.apache.org/jira/browse/IGNITE-10830
> Project: Ignite
> Issue Type: Task
> Components: managed services
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> It's necessary to revert changes of
> {{GridServiceProcessor$ServiceTopologyCallable}} introduced within
> IGNITE-9607.
> This may lead to serialization issues in some cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10830) Return back semantic of GridServiceProcessor#ServiceTopologyCallable to avoid possible serialization issues
Vyacheslav Daradur created IGNITE-10830:
---
Summary: Return back semantic of
GridServiceProcessor#ServiceTopologyCallable to avoid possible serialization
issues
Key: IGNITE-10830
URL: https://issues.apache.org/jira/browse/IGNITE-10830
Project: Ignite
Issue Type: Task
Components: managed services
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Fix For: 2.8
It's necessary to revert changes of
{{GridServiceProcessor#ServiceTopologyCallable}} introduced within IGNITE-9607.
This may lead to serialization issues in some cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729455#comment-16729455 ] Vyacheslav Daradur commented on IGNITE-6259: [~dmekhanikov], the issue has been resolved in the new service processor. Should we close the ticket or the issue should be fixed in deprecated implementation too? > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-3392) Propagate service deployment results from assigned nodes to initiator
[
https://issues.apache.org/jira/browse/IGNITE-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur resolved IGNITE-3392.
Resolution: Done
The task has been implemented within IGNITE-9607.
> Propagate service deployment results from assigned nodes to initiator
> -
>
> Key: IGNITE-3392
> URL: https://issues.apache.org/jira/browse/IGNITE-3392
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: iep-17
> Fix For: 2.8
>
> Attachments: Test.java
>
>
> Test that demonstrates the issue is attached. If exception is thrown from the
> {{Service.init()}} method, it's only printed out on the server not propagated
> to the client. If client then tries to get the proxy, it goes to infinite
> loop.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9075) Service Grid: Lifecycle of affinity deployed service should be reworked
[ https://issues.apache.org/jira/browse/IGNITE-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-9075. Resolution: Done The task has been implemented within IGNITE-9607. > Service Grid: Lifecycle of affinity deployed service should be reworked > --- > > Key: IGNITE-9075 > URL: https://issues.apache.org/jira/browse/IGNITE-9075 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > The main question shoud be clarified: > Should we automatically undeploy services, which had been deployed using > #deployKeyAffinitySingleton, on destroying of related IgniteCache? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-1478) Service cannot be used on remote node immediately after deployment.
[ https://issues.apache.org/jira/browse/IGNITE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-1478. Resolution: Fixed The issue has been solved within IGNITE-9607. > Service cannot be used on remote node immediately after deployment. > --- > > Key: IGNITE-1478 > URL: https://issues.apache.org/jira/browse/IGNITE-1478 > Project: Ignite > Issue Type: Task > Components: cache, managed services >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur >Priority: Minor > Labels: iep-17 > Fix For: 2.8 > > > Consider the following scenario: > 1) Two nodes: A and B. > 2) Node A deploys cluster-wide service through IgniteServices.deploy(); > 3) Once we exited deploy() method we are trying to get the service on the > node B in any way (invoke it, get proxy, get descriptor, whatever). > Step 3 might fail. This happens because > GridServiceProcessor.AssignmentListener is not notified synchronously when > service cache is update in transaction. > As a result, transacion ends, node A informs us about successful service > deployment, but it is still not usable on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8363) Handle topology changes during service deployment
[ https://issues.apache.org/jira/browse/IGNITE-8363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-8363. Resolution: Done The task has been implemented within IGNITE-9607. > Handle topology changes during service deployment > - > > Key: IGNITE-8363 > URL: https://issues.apache.org/jira/browse/IGNITE-8363 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > Topology changes should be handled correctly during service deployment > process. > Assignments recalculation should be triggered when necessary. > Special attention should be paid to cases, when a coordinator or assigned > nodes fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8362) Collect service deployment results asynchronously on coordinator
[ https://issues.apache.org/jira/browse/IGNITE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-8362. Resolution: Done The task has been implemented within IGNITE-9607. > Collect service deployment results asynchronously on coordinator > > > Key: IGNITE-8362 > URL: https://issues.apache.org/jira/browse/IGNITE-8362 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > When service deployment discovery message is sent, assigned nodes should > start the deployment asynchronously outside the discovery thread. > Deployment results should be sent to the coordinator over communication. > Deployment should be considered finished once all deployment result are > collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8361) Use discovery messages for service deployment
[ https://issues.apache.org/jira/browse/IGNITE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur resolved IGNITE-8361. Resolution: Done The task has been implemented within IGNITE-9607. > Use discovery messages for service deployment > - > > Key: IGNITE-8361 > URL: https://issues.apache.org/jira/browse/IGNITE-8361 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > Service deployment should be based on discovery messages distribution. > The procedure is as follows: > # Deploying node sends a message with a service configuration. > # Coordinator calculates the assignments and sends them in another message. > # Nodes check, whether they are assigned to deploy any services, and do so, > if they are. > Utility cache won't be needed after these changes are made. All its mentions > should be removed from the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9607) Service Grid redesign - phase 1
[
https://issues.apache.org/jira/browse/IGNITE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728758#comment-16728758
]
Vyacheslav Daradur commented on IGNITE-9607:
The method {{onLocalJoin}} has been moved in {{ServiceProcessorAdapter}} and
now we use 'instanceof' only when should use deprecated GridServiceProcessor
with cache related logic, that means these places will be removed with
{{GridServiceProcessor}} in future releases.
> Service Grid redesign - phase 1
> ---
>
> Key: IGNITE-9607
> URL: https://issues.apache.org/jira/browse/IGNITE-9607
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> This is an umbrella ticket for tasks which should be implemented atomically
> in phase #1 of Service Grid redesign.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9607) Service Grid redesign - phase 1
[
https://issues.apache.org/jira/browse/IGNITE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728749#comment-16728749
]
Vyacheslav Daradur commented on IGNITE-9607:
[~agoncharuk], thank you for the notes!
{quote}1) Not sure if it was discussed with other community members, but I
think it may be better to get rid of various {{instanceof}} statements in the
code and have a common interface for both service processor implementations
(possibly, noop)
{quote}
Previously such approach has been used, but it has been reworked during a
review. In the main code base (not in tests) we use 'instance of' in rare
operations, mostly at startup of kernal or its components and on local join
event, such checks are not called in heavy loaded places.
Also, we can't get-rid 'instance of' completely, e.g. 'onActivate' and
'onDeactive' should be called in different places depending on service
processor implementation. I'd like to leave it as is if you don't mind.
{quote}2) Should we narrow down the generic type of ServiceDeploymentFuture to
Serializable?
{quote}
Makes perfect sense to me. Done.
{quote}3) In IgniteServiceProcessor#stopProcessor() we need to wrap
fut.onDone(stopError) in a try-catch block. We recently discovered that
onDone() call can re-throw the exception to the caller, which prevents correct
node stop
{quote}
Done.
{quote}4) I think we should add (maybe in a separate ticket) some diagnostic
mechanics to dump pending deployment futures. The best option is to use
existing PME diagnostic mechanics
{quote}
I've filled a task IGNITE-10817
> Service Grid redesign - phase 1
> ---
>
> Key: IGNITE-9607
> URL: https://issues.apache.org/jira/browse/IGNITE-9607
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> This is an umbrella ticket for tasks which should be implemented atomically
> in phase #1 of Service Grid redesign.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10817) Service Grid: Introduce diagnostic tool to dump pending deployment tasks
Vyacheslav Daradur created IGNITE-10817: --- Summary: Service Grid: Introduce diagnostic tool to dump pending deployment tasks Key: IGNITE-10817 URL: https://issues.apache.org/jira/browse/IGNITE-10817 Project: Ignite Issue Type: Task Components: managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 It's necessary to introduce some kind of diagnostic tools to dump service deployments task which are pending in the queue in a log. If possible, existing PME diagnostic mechanics should be reused. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10715) Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests
[
https://issues.apache.org/jira/browse/IGNITE-10715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728699#comment-16728699
]
Vyacheslav Daradur commented on IGNITE-10715:
-
The ticket has been reopened because of failure
\{{IgniteClientConnectTest#testClientConnectToBigTopology}}.
The fix prepared already: [https://github.com/apache/ignite/pull/5739]
Waiting for tests result.
> Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests
>
>
> Key: IGNITE-10715
> URL: https://issues.apache.org/jira/browse/IGNITE-10715
> Project: Ignite
> Issue Type: Task
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Minor
> Fix For: 2.8
>
>
> It's necessary to remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in
> tests since this is default IP finder in tests after IGNITE-10555.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10811) Add new TC build-config to test Service Grid new and old implementations
[ https://issues.apache.org/jira/browse/IGNITE-10811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10811: Description: It's necessary to add new build configuration on TeamCity (after merge IGNITE-9607) to have ability testing new and old implementations of the service processor. In general, new build plan should contain 2 test suites: 1) To place Service Grid related tests which *do not depend on* service processor's implementation (like classic unit tests) and *should be executed once*; 2) To place Service Grid related tests which *depend* *on* service processor's implementation and *should be executed twice* in the new mode and old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) was: It's necessary to add new build configuration on TeamCity (after merge IGNITE-9607) to have ability testing new and old implementations of the service processor. In general, new build plan we should contain 2 test suites: 1) To place Service Grid related tests which *do not depend on* service processor's implementation (like classic unit tests) and *should be executed once*; 2) To place Service Grid related tests which *depend* *on* service processor's implementation and *should be executed twice* in the new mode and old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) > Add new TC build-config to test Service Grid new and old implementations > > > Key: IGNITE-10811 > URL: https://issues.apache.org/jira/browse/IGNITE-10811 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to add new build configuration on TeamCity (after merge > IGNITE-9607) to have ability testing new and old implementations of the > service processor. > In general, new build plan should contain 2 test suites: > 1) To place Service Grid related tests which *do not depend on* service > processor's implementation (like classic unit tests) and *should be executed > once*; > 2) To place Service Grid related tests which *depend* *on* service > processor's implementation and *should be executed twice* in the new mode and > old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10811) Add new TC build-config to test Service Grid new and old implementations
[ https://issues.apache.org/jira/browse/IGNITE-10811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10811: Description: It's necessary to add new build configuration on TeamCity (after merge IGNITE-9607) to have ability testing new and old implementations of the service processor. In general, new build plan we should contain 2 test suites: 1) To place Service Grid related tests which *do not depend on* service processor's implementation (like classic unit tests) and *should be executed once*; 2) To place Service Grid related tests which *depend* *on* service processor's implementation and *should be executed twice* in the new mode and old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) was: It's necessary to add new build configuration on TeamCity (after merge IGNITE-9607) to have ability testing new and old implementations of the service processor. In general, new build plan we should contain 2 test suites: 1) To place Service Grid related tests which *do not depend on* service processor's implementation (like classic unit tests) and *should be executed once*; 2) To place Service Grid related tests which *depend* on service processor's implementation and *should be executed twice* in the new mode and old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) > Add new TC build-config to test Service Grid new and old implementations > > > Key: IGNITE-10811 > URL: https://issues.apache.org/jira/browse/IGNITE-10811 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to add new build configuration on TeamCity (after merge > IGNITE-9607) to have ability testing new and old implementations of the > service processor. > In general, new build plan we should contain 2 test suites: > 1) To place Service Grid related tests which *do not depend on* service > processor's implementation (like classic unit tests) and *should be executed > once*; > 2) To place Service Grid related tests which *depend* *on* service > processor's implementation and *should be executed twice* in the new mode and > old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10811) Add new TC build-config to test Service Grid new and old implementations
Vyacheslav Daradur created IGNITE-10811: --- Summary: Add new TC build-config to test Service Grid new and old implementations Key: IGNITE-10811 URL: https://issues.apache.org/jira/browse/IGNITE-10811 Project: Ignite Issue Type: Task Components: managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 It's necessary to add new build configuration on TeamCity (after merge IGNITE-9607) to have ability testing new and old implementations of the service processor. In general, new build plan we should contain 2 test suites: 1) To place Service Grid related tests which *do not depend on* service processor's implementation (like classic unit tests) and *should be executed once*; 2) To place Service Grid related tests which *depend* on service processor's implementation and *should be executed twice* in the new mode and old mode (-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=false) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10715) Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests
[ https://issues.apache.org/jira/browse/IGNITE-10715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725665#comment-16725665 ] Vyacheslav Daradur commented on IGNITE-10715: - [~avinogradov], could you review the PR, please? > Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests > > > Key: IGNITE-10715 > URL: https://issues.apache.org/jira/browse/IGNITE-10715 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > It's necessary to remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in > tests since this is default IP finder in tests after IGNITE-10555. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10715) Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests
Vyacheslav Daradur created IGNITE-10715: --- Summary: Remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests Key: IGNITE-10715 URL: https://issues.apache.org/jira/browse/IGNITE-10715 Project: Ignite Issue Type: Task Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 It's necessary to remove boilerplate of settings 'TcpDiscoveryVmIpFinder' in tests since this is default IP finder in tests after IGNITE-10555. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10705) Wrong check of test's compatible 'dataMode' in IgniteConfigVariationsAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10705:
Description:
Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
incorrectly.
Here is the actual code:
{code:java}
protected boolean isCompatible() throws Exception {
switch (dataMode) {
case BINARILIZABLE:
case PLANE_OBJECT:
return !(getConfiguration().getMarshaller() instanceof
JdkMarshaller);
}
return false;
}
{code}
It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE,
EXTERNALIZABLE], but they are main modes which are supported by any marshaller.
*That means a set of tests which should be executed will be skipped instead.*
Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
{{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
was:
Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
incorrectly.
Here is the actual code:
{code:java}
protected boolean isCompatible() throws Exception {
switch (dataMode) {
case BINARILIZABLE:
case PLANE_OBJECT:
return !(getConfiguration().getMarshaller() instanceof
JdkMarshaller);
}
return false;
}
{code}
It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE,
EXTERNALIZABLE], but this is main modes which are supported by any marshaller.
*That means a set of tests which should be executed will be skipped instead.*
Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
{{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
> Wrong check of test's compatible 'dataMode' in
> IgniteConfigVariationsAbstractTest
> -
>
> Key: IGNITE-10705
> URL: https://issues.apache.org/jira/browse/IGNITE-10705
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Daradur
>Priority: Major
>
> Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
> incorrectly.
> Here is the actual code:
> {code:java}
> protected boolean isCompatible() throws Exception {
> switch (dataMode) {
> case BINARILIZABLE:
> case PLANE_OBJECT:
> return !(getConfiguration().getMarshaller() instanceof
> JdkMarshaller);
> }
> return false;
> }
> {code}
> It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE,
> EXTERNALIZABLE], but they are main modes which are supported by any
> marshaller.
> *That means a set of tests which should be executed will be skipped instead.*
> Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
> {{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10705) Wrong check of test's compatible 'dataMode' in IgniteConfigVariationsAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-10705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10705:
Description:
Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
incorrectly.
Here is the actual code:
{code:java}
protected boolean isCompatible() throws Exception {
switch (dataMode) {
case BINARILIZABLE:
case PLANE_OBJECT:
return !(getConfiguration().getMarshaller() instanceof
JdkMarshaller);
}
return false;
}
{code}
It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE,
EXTERNALIZABLE], but this is main modes which are supported by any marshaller.
*That means a set of tests which should be executed will be skipped instead.*
Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
{{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
was:
Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
incorrectly.
Here is the actual code:
{code:java}
protected boolean isCompatible() throws Exception {
switch (dataMode) {
case BINARILIZABLE:
case PLANE_OBJECT:
return !(getConfiguration().getMarshaller() instanceof
JdkMarshaller);
}
return false;
}
{code}
It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE], but
this is main modes which are supported by any marshaller.
*That means a set of tests which should be executed will be skipped instead.*
Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
{{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
> Wrong check of test's compatible 'dataMode' in
> IgniteConfigVariationsAbstractTest
> -
>
> Key: IGNITE-10705
> URL: https://issues.apache.org/jira/browse/IGNITE-10705
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Daradur
>Priority: Major
>
> Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
> incorrectly.
> Here is the actual code:
> {code:java}
> protected boolean isCompatible() throws Exception {
> switch (dataMode) {
> case BINARILIZABLE:
> case PLANE_OBJECT:
> return !(getConfiguration().getMarshaller() instanceof
> JdkMarshaller);
> }
> return false;
> }
> {code}
> It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE,
> EXTERNALIZABLE], but this is main modes which are supported by any marshaller.
> *That means a set of tests which should be executed will be skipped instead.*
> Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
> {{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10705) Wrong check of test's compatible 'dataMode' in IgniteConfigVariationsAbstractTest
Vyacheslav Daradur created IGNITE-10705:
---
Summary: Wrong check of test's compatible 'dataMode' in
IgniteConfigVariationsAbstractTest
Key: IGNITE-10705
URL: https://issues.apache.org/jira/browse/IGNITE-10705
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Daradur
Found that method {{IgniteConfigVariationsAbstractTest#isCompatible}} works
incorrectly.
Here is the actual code:
{code:java}
protected boolean isCompatible() throws Exception {
switch (dataMode) {
case BINARILIZABLE:
case PLANE_OBJECT:
return !(getConfiguration().getMarshaller() instanceof
JdkMarshaller);
}
return false;
}
{code}
It returns {{false}} if a test mode is [SERIALIZABLE, CUSTOM_SERIALIZABLE], but
this is main modes which are supported by any marshaller.
*That means a set of tests which should be executed will be skipped instead.*
Also, modes {{BINARILIZABLE}} and {{PLANE_OBJECT}} are supported only by
{{BinaryMarshaller}} and {{OptimizedMarshaller.setRequireSerializable(false)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10615) Ignite Compatibility: fix arguments' checking in the node runner
[
https://issues.apache.org/jira/browse/IGNITE-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-10615:
Issue Type: Bug (was: Improvement)
> Ignite Compatibility: fix arguments' checking in the node runner
>
>
> Key: IGNITE-10615
> URL: https://issues.apache.org/jira/browse/IGNITE-10615
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Minor
> Fix For: 2.8
>
>
> There is the checking of arguments number In
> {{IgniteCompatibilityNodeRunner#main}}, which expected at least 3 arguments,
> but in actual code at least 5 arguments are required.
> The checking should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10615) Ignite Compatibility: fix arguments' checking in the node runner
Vyacheslav Daradur created IGNITE-10615:
---
Summary: Ignite Compatibility: fix arguments' checking in the node
runner
Key: IGNITE-10615
URL: https://issues.apache.org/jira/browse/IGNITE-10615
Project: Ignite
Issue Type: Improvement
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Fix For: 2.8
There is the checking of arguments number In
{{IgniteCompatibilityNodeRunner#main}}, which expected at least 3 arguments,
but in actual code at least 5 arguments are required.
The checking should be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10555) Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder'
[ https://issues.apache.org/jira/browse/IGNITE-10555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713924#comment-16713924 ] Vyacheslav Daradur commented on IGNITE-10555: - The "Hibernate 1" test suite fails in master also. > Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of > 'TcpDiscoveryMulticastIpFinder' > -- > > Key: IGNITE-10555 > URL: https://issues.apache.org/jira/browse/IGNITE-10555 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > Most of our tests starting Ignite nodes in the same JVM, that allows > us using shared 'TcpDiscoveryVmIpFinder'. > There are following main advantages of using 'TcpDiscoveryVmIpFinder': > * reducing possible conflicts in the development environment, when > nodes from different clusters may find each other; > * speedup of nodes initial discovery, especially on Windows; > * avoiding of overwriting 'getConfiguration' and copypasta only to set > up static IP finder in tests; > We should change the default IP finder in tests to > 'TcpDiscoveryVmIpFinder' as the first step and remove related > boilerplate as the second step. > Once the first step of the change will be finished then we should fill a > separate task for removing related boilerplate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10555) Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder'
Vyacheslav Daradur created IGNITE-10555: --- Summary: Set 'TcpDiscoveryVmIpFinder' as default IP finder for tests instead of 'TcpDiscoveryMulticastIpFinder' Key: IGNITE-10555 URL: https://issues.apache.org/jira/browse/IGNITE-10555 Project: Ignite Issue Type: Improvement Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 Most of our tests starting Ignite nodes in the same JVM, that allows us using shared 'TcpDiscoveryVmIpFinder'. There are following main advantages of using 'TcpDiscoveryVmIpFinder': * reducing possible conflicts in the development environment, when nodes from different clusters may find each other; * speedup of nodes initial discovery, especially on Windows; * avoiding of overwriting 'getConfiguration' and copypasta only to set up static IP finder in tests; We should change the default IP finder in tests to 'TcpDiscoveryVmIpFinder' as the first step and remove related boilerplate as the second step. Once the first step of the change will be finished then we should fill a separate task for removing related boilerplate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10442) Failed checks on successful tasks canceling
[ https://issues.apache.org/jira/browse/IGNITE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10442: Ignite Flags: (was: Docs Required) > Failed checks on successful tasks canceling > --- > > Key: IGNITE-10442 > URL: https://issues.apache.org/jira/browse/IGNITE-10442 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > Fix For: 2.8 > > > Test on checks that tasks canceling does not lead to node failure > [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] > seems flaky. > One of the reason - "Possible thread pool starvation detected": there are 16 > NUM_TASKS, which invoke in separate threads. Default size of ignite thread > pool is 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10442) Failed checks on successful tasks canceling
[ https://issues.apache.org/jira/browse/IGNITE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10442: Fix Version/s: 2.8 > Failed checks on successful tasks canceling > --- > > Key: IGNITE-10442 > URL: https://issues.apache.org/jira/browse/IGNITE-10442 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > Fix For: 2.8 > > > Test on checks that tasks canceling does not lead to node failure > [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] > seems flaky. > One of the reason - "Possible thread pool starvation detected": there are 16 > NUM_TASKS, which invoke in separate threads. Default size of ignite thread > pool is 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[
https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709833#comment-16709833
]
Vyacheslav Daradur commented on IGNITE-9023:
[~DmitriyGovorukhin], thank you for the review!
Regarding your questions:
bq. Why do you use a custom topic? Can we do a test with standard P2P topic?
Custom topic has been used to test explicit behaviour, and to be sure that we
received the response as a reaction on our broken request. If we use P2P topic
our test may be affected by environment and other internal modules during
Ignite's lifecycle.
bq. Why test was added in kernel test suite but not in p2p?
I thought in this way:
1. The test is related to deployment infrastructure more than to testing of p2p
behaviour;
2. {{GridDeploymentCommunication}} affected by changes is used in
{{GridDeploymentManager}} which is part of kernal;
3. In test we use {{GridDeploymentRequest}} and {{GridDeploymentResponse}}
which have package private access, so we had to use
{{org.apache.ignite.internal.managers.deployment}} package for test and other
tests in the package have been placed in {{IgniteKernalSelfTestSuite}}.
If you think that the test is more suitable to be placed in a different
test-suite, please let me know, I will fix this quickly.
I've fixed all your notes, please, have a look.
Thanks in advance!
> LinkageError or ClassNotFoundException should not be swollen by
> GridDeploymentCommunication during processing deployment request.
> -
>
> Key: IGNITE-9023
> URL: https://issues.apache.org/jira/browse/IGNITE-9023
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Vyacheslav Daradur
>Priority: Minor
> Fix For: 2.8
>
>
> In current implementation any error, that is thrown in
> GridDeploymentCommunication#processResourceRequest, is ignored silently.
> Any error should be logged and send to client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10523) Ignite Compatibility: add check that started node is of expected version
[ https://issues.apache.org/jira/browse/IGNITE-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16708903#comment-16708903 ] Vyacheslav Daradur commented on IGNITE-10523: - [~dpavlov], please, have a look at the prepared PR. > Ignite Compatibility: add check that started node is of expected version > > > Key: IGNITE-10523 > URL: https://issues.apache.org/jira/browse/IGNITE-10523 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > It's necessary to check that node started in separate JVM is of a specified > version to avoid unexpected behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10523) Ignite Compatibility: add check that started node is of expected version
[ https://issues.apache.org/jira/browse/IGNITE-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10523: Fix Version/s: 2.8 > Ignite Compatibility: add check that started node is of expected version > > > Key: IGNITE-10523 > URL: https://issues.apache.org/jira/browse/IGNITE-10523 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > It's necessary to check that node started in separate JVM is of a specified > version to avoid unexpected behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10523) Ignite Compatibility: add check that started node is of expected version
Vyacheslav Daradur created IGNITE-10523: --- Summary: Ignite Compatibility: add check that started node is of expected version Key: IGNITE-10523 URL: https://issues.apache.org/jira/browse/IGNITE-10523 Project: Ignite Issue Type: Improvement Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur It's necessary to check that node started in separate JVM is of a specified version to avoid unexpected behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8379) Add maven-surefire-plugin support for PDS Compatibility tests
[
https://issues.apache.org/jira/browse/IGNITE-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699283#comment-16699283
]
Vyacheslav Daradur commented on IGNITE-8379:
[~dpavlov], there is no reason to run RunAll because the changes relate to
Compatibility module only.
> Add maven-surefire-plugin support for PDS Compatibility tests
> -
>
> Key: IGNITE-8379
> URL: https://issues.apache.org/jira/browse/IGNITE-8379
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> In continuation of the works on PDS Compatibility test suite, it is required
> to add support for {{maven-surefire-plugin}} in Compatibility Framework.
> See IGNITE-8275 for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[ https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-9023: -- Assignee: Vyacheslav Daradur (was: ruchir choudhry) > LinkageError or ClassNotFoundException should not be swollen by > GridDeploymentCommunication during processing deployment request. > - > > Key: IGNITE-9023 > URL: https://issues.apache.org/jira/browse/IGNITE-9023 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > In current implementation any error, that is thrown in > GridDeploymentCommunication#processResourceRequest, is ignored silently. > Any error should be logged and send to client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[
https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698236#comment-16698236
]
Vyacheslav Daradur commented on IGNITE-9023:
I reassigned the issue myself because there is no answer from Ruchir.
I researched the issue, summary: we can't just respond with an error in case of
{{LinkageError}} or {{ClassNotFoundException}} because resource name is able
not to be class name and we should try to load it from resources. (this
behavior is covered by {{IgniteExplicitImplicitDeploymentSelfTest}})
So, I added {{LinkageError}} to catch block with the corresponding comment,
also logging was added.
Test to check logging and receiving of response in case of an error also has
been added.
Tests look good, the inspection failure doesn't relate to the PR.
[~ivandasch], could you review the prepared solution, please?
> LinkageError or ClassNotFoundException should not be swollen by
> GridDeploymentCommunication during processing deployment request.
> -
>
> Key: IGNITE-9023
> URL: https://issues.apache.org/jira/browse/IGNITE-9023
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: ruchir choudhry
>Priority: Minor
> Fix For: 2.8
>
>
> In current implementation any error, that is thrown in
> GridDeploymentCommunication#processResourceRequest, is ignored silently.
> Any error should be logged and send to client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697280#comment-16697280 ] Vyacheslav Daradur commented on IGNITE-7441: [~dmekhanikov], thanks! [~NIzhikov], could you help with the merge, please? > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697170#comment-16697170 ] Vyacheslav Daradur commented on IGNITE-7441: The tests marked as possible blockers fail in the master branch too, so look like the tests have not been affected by changes. > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-1478) Service cannot be used on remote node immediately after deployment.
[ https://issues.apache.org/jira/browse/IGNITE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-1478: --- Component/s: managed services > Service cannot be used on remote node immediately after deployment. > --- > > Key: IGNITE-1478 > URL: https://issues.apache.org/jira/browse/IGNITE-1478 > Project: Ignite > Issue Type: Task > Components: cache, managed services >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > Consider the following scenario: > 1) Two nodes: A and B. > 2) Node A deploys cluster-wide service through IgniteServices.deploy(); > 3) Once we exited deploy() method we are trying to get the service on the > node B in any way (invoke it, get proxy, get descriptor, whatever). > Step 3 might fail. This happens because > GridServiceProcessor.AssignmentListener is not notified synchronously when > service cache is update in transaction. > As a result, transacion ends, node A informs us about successful service > deployment, but it is still not usable on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-1478) Service cannot be used on remote node immediately after deployment.
[ https://issues.apache.org/jira/browse/IGNITE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-1478: --- Labels: iep-17 (was: ) > Service cannot be used on remote node immediately after deployment. > --- > > Key: IGNITE-1478 > URL: https://issues.apache.org/jira/browse/IGNITE-1478 > Project: Ignite > Issue Type: Task > Components: cache, managed services >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur >Priority: Minor > Labels: iep-17 > Fix For: 2.8 > > > Consider the following scenario: > 1) Two nodes: A and B. > 2) Node A deploys cluster-wide service through IgniteServices.deploy(); > 3) Once we exited deploy() method we are trying to get the service on the > node B in any way (invoke it, get proxy, get descriptor, whatever). > Step 3 might fail. This happens because > GridServiceProcessor.AssignmentListener is not notified synchronously when > service cache is update in transaction. > As a result, transacion ends, node A informs us about successful service > deployment, but it is still not usable on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-1478) Service cannot be used on remote node immediately after deployment.
[ https://issues.apache.org/jira/browse/IGNITE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-1478: --- Fix Version/s: 2.8 > Service cannot be used on remote node immediately after deployment. > --- > > Key: IGNITE-1478 > URL: https://issues.apache.org/jira/browse/IGNITE-1478 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > Consider the following scenario: > 1) Two nodes: A and B. > 2) Node A deploys cluster-wide service through IgniteServices.deploy(); > 3) Once we exited deploy() method we are trying to get the service on the > node B in any way (invoke it, get proxy, get descriptor, whatever). > Step 3 might fail. This happens because > GridServiceProcessor.AssignmentListener is not notified synchronously when > service cache is update in transaction. > As a result, transacion ends, node A informs us about successful service > deployment, but it is still not usable on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-1478) Service cannot be used on remote node immediately after deployment.
[ https://issues.apache.org/jira/browse/IGNITE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-1478: -- Assignee: Vyacheslav Daradur > Service cannot be used on remote node immediately after deployment. > --- > > Key: IGNITE-1478 > URL: https://issues.apache.org/jira/browse/IGNITE-1478 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vyacheslav Daradur >Priority: Minor > > Consider the following scenario: > 1) Two nodes: A and B. > 2) Node A deploys cluster-wide service through IgniteServices.deploy(); > 3) Once we exited deploy() method we are trying to get the service on the > node B in any way (invoke it, get proxy, get descriptor, whatever). > Step 3 might fail. This happens because > GridServiceProcessor.AssignmentListener is not notified synchronously when > service cache is update in transaction. > As a result, transacion ends, node A informs us about successful service > deployment, but it is still not usable on remote nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-7441: --- Fix Version/s: 2.8 > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
[ https://issues.apache.org/jira/browse/IGNITE-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-7441: --- Component/s: managed services > Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property > --- > > Key: IGNITE-7441 > URL: https://issues.apache.org/jira/browse/IGNITE-7441 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Denis Mekhanikov >Assignee: Vyacheslav Daradur >Priority: Minor > Fix For: 2.8 > > > IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to > configure backward compatibility mode for service configuration classes. But > since it was done in 1.9 and current version is completely incompatible with > it, there is no point in keeping this property. > Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8379) Add maven-surefire-plugin support for PDS Compatibility tests
[
https://issues.apache.org/jira/browse/IGNITE-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693214#comment-16693214
]
Vyacheslav Daradur commented on IGNITE-8379:
[~vveider], thank you for help with testing.
[~dpavlov], could you please review the solution, please?
> Add maven-surefire-plugin support for PDS Compatibility tests
> -
>
> Key: IGNITE-8379
> URL: https://issues.apache.org/jira/browse/IGNITE-8379
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> In continuation of the works on PDS Compatibility test suite, it is required
> to add support for {{maven-surefire-plugin}} in Compatibility Framework.
> See IGNITE-8275 for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9023) LinkageError or ClassNotFoundException should not be swollen by GridDeploymentCommunication during processing deployment request.
[ https://issues.apache.org/jira/browse/IGNITE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693081#comment-16693081 ] Vyacheslav Daradur commented on IGNITE-9023: Hi, [~ruchirc], would you mind if I assign the task to myself and go forward? > LinkageError or ClassNotFoundException should not be swollen by > GridDeploymentCommunication during processing deployment request. > - > > Key: IGNITE-9023 > URL: https://issues.apache.org/jira/browse/IGNITE-9023 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: ruchir choudhry >Priority: Minor > Fix For: 2.8 > > > In current implementation any error, that is thrown in > GridDeploymentCommunication#processResourceRequest, is ignored silently. > Any error should be logged and send to client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8379) Add maven-surefire-plugin support for PDS Compatibility tests
[
https://issues.apache.org/jira/browse/IGNITE-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689849#comment-16689849
]
Vyacheslav Daradur commented on IGNITE-8379:
Hi, [~vveider], I added support running tests from precompiled artifacts.
I've tested this locally, both {{mvn:tes}} and {{surefire:test}} works well on
source code and on precompiled artifacts.
Please, check if it works in a target environment.
> Add maven-surefire-plugin support for PDS Compatibility tests
> -
>
> Key: IGNITE-8379
> URL: https://issues.apache.org/jira/browse/IGNITE-8379
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Peter Ivanov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> In continuation of the works on PDS Compatibility test suite, it is required
> to add support for {{maven-surefire-plugin}} in Compatibility Framework.
> See IGNITE-8275 for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9607) Service Grid redesign - phase 1
[ https://issues.apache.org/jira/browse/IGNITE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-9607: --- Comment: was deleted (was: I attached a description of the implemented solution: [^Service Grid phase 1 - implementation details.docx]) > Service Grid redesign - phase 1 > --- > > Key: IGNITE-9607 > URL: https://issues.apache.org/jira/browse/IGNITE-9607 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > Attachments: Service Grid phase 1 - implementation details.docx > > > This is an umbrella ticket for tasks which should be implemented atomically > in phase #1 of Service Grid redesign. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10116) Document implemented design of Service Grid (redesign phase 1)
[ https://issues.apache.org/jira/browse/IGNITE-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678339#comment-16678339 ] Vyacheslav Daradur commented on IGNITE-10116: - I published documentation in wiki: [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584] > Document implemented design of Service Grid (redesign phase 1) > -- > > Key: IGNITE-10116 > URL: https://issues.apache.org/jira/browse/IGNITE-10116 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document implemented design of Service Grid and publish in > wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10116) Document implemented design of Service Grid (redesign phase 1)
[ https://issues.apache.org/jira/browse/IGNITE-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10116: Attachment: (was: Service Grid phase 1 - implementation details.docx) > Document implemented design of Service Grid (redesign phase 1) > -- > > Key: IGNITE-10116 > URL: https://issues.apache.org/jira/browse/IGNITE-10116 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document implemented design of Service Grid and publish in > wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10116) Document implemented design of Service Grid (redesign phase 1)
[ https://issues.apache.org/jira/browse/IGNITE-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-10116: Comment: was deleted (was: I attached a prepared document to the issue. Also, I've asked the community if it's necessary to publish this to the wiki.) > Document implemented design of Service Grid (redesign phase 1) > -- > > Key: IGNITE-10116 > URL: https://issues.apache.org/jira/browse/IGNITE-10116 > Project: Ignite > Issue Type: Task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > It's necessary to document implemented design of Service Grid and publish in > wiki. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
