[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Marty Jones (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108799#comment-17108799
 ] 

Marty Jones commented on IGNITE-7269:
-

You would be surprised at how many people are still using ASP.NET MVC instead 
of core for existing applications.

That being said, do you know when explicit lock support will be added into the 
.NET thin client? 

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

[Mikhail Petrov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108609#comment-17108609
 ] 

Mikhail Petrov commented on IGNITE-12894:
-

[~daradurvs], Thanks a lot for the review.

> 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.ServiceDeploymentT

[jira] [Commented] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy

[Vyacheslav Daradur (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Vyacheslav Daradur (Jira)]

 [ 
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

[Vyacheslav Daradur (Jira)]

 [ 
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

[Vyacheslav Daradur (Jira)]

 [ 
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

[Vyacheslav Daradur (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 
> org.apache.ignite.internal.processors.service.ServiceDeployme

[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

[Mikhail Petrov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108533#comment-17108533
 ] 

Mikhail Petrov commented on IGNITE-12894:
-

[~daradurvs], I've rerun TC and got the fresh visa. Could you please take a 
look?

> 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: 1h 20m
>  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.Servi

[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108531#comment-17108531
 ] 

Ignite TC Bot commented on IGNITE-12894:


{panel:title=Branch: [pull/7771/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5308533&buildTypeId=IgniteTests24Java8_RunAll]

> 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: 1h 20m
>  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)
>  

[jira] [Commented] (IGNITE-12912) Calcite integration: Add filters merge rule to the planner

[Roman Kondakov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108402#comment-17108402
 ] 

Roman Kondakov commented on IGNITE-12912:
-

[~tledkov-gridgain], looks good to me.

> Calcite integration: Add filters merge rule to the planner
> --
>
> Key: IGNITE-12912
> URL: https://issues.apache.org/jira/browse/IGNITE-12912
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Taras Ledkov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We need to add  next rules to planner
>  * FilterMergeRule
>  * FilterProjectTransposeRule
> In order to be able to make this transformation for the query:
> {noformat}
> "select name from (\n"
> + "  select *\n"
> + "  from dept\n"
> + "  where deptno = 10)\n"
> + "where deptno = 10\n"
> BEFORE=
> LogicalProject(NAME=[$1])
>   LogicalFilter(condition=[=(CAST($0):INTEGER, 10)])
> LogicalProject(DEPTNO=[$0], NAME=[$1])
>   LogicalFilter(condition=[=(CAST($0):INTEGER, 10)])
> IgniteTableScan(table=[[PUBLIC, DEPT]])
> AFTER=
> IgniteProject(NAME=[$1])
>   IgniteProject(DEPTNO=[$0], NAME=[$1])
> IgniteFilter(condition=[=(CAST($0):INTEGER, 10)])
>   IgniteTableScan(table=[[PUBLIC, DEPT]])
> {noformat}
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-12438) Extend communication protocol to establish client-server connection

[Denis A. Magda (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108388#comment-17108388
 ] 

Denis A. Magda edited comment on IGNITE-12438 at 5/15/20, 3:12 PM:
---

Ivan, thank you!

As this task's description suggests, a server will try to connect to a client 
anyway through communication SPI before requesting the client (via a discovery 
message) to establish a connection with the server instead. It means that the 
client should create a server socket even for EnvironmentType.VIRTUALIZED. At 
least that was my understanding. The issue described in 
[IGNITE-13013|https://issues.apache.org/jira/browse/IGNITE-13013] is about the 
cases when the server must not even try to connect to the client and the client 
must not open the server socket. Actually, that's the case for this bullet item 
of this ticket__ (Optionally) detect when a client has only one-way 
connectivity with the server nodes. This part should be investigated. We need 
this to avoid server nodes attempt to connect to a client and send 
communication request to the client node faster__

I'll leave it up to you, you can close IGNITE-13013 and fix the issue as part 
of this task. Or you can IGNITE-13013 as a sub-task and track those cases 
separately.



was (Author: dmagda):
Ivan, thank you!

As this task's description suggests, a server will try to connect to a client 
anyway through communication SPI before requesting the client (via a discovery 
message) to establish a connection with the server instead. It means that the 
client should create a server socket even for EnvironmentType.VIRTUALIZED. At 
least that was my understanding. The issue described in 
[IGNITE-13013|https://issues.apache.org/jira/browse/IGNITE-13013] is about the 
cases when the server must not even try to connect to the client and the client 
must not open the server socket. Actually, that's the case for this bullet item 
of this ticket_ (Optionally) detect when a client has only one-way connectivity 
with the server nodes. This part should be investigated. We need this to avoid 
server nodes attempt to connect to a client and send communication request to 
the client node faster_

I'll leave it up to you, you can close IGNITE-13013 and fix the issue as part 
of this task. Or you can IGNITE-13013 as a sub-task and track those cases 
separately.


> Extend communication protocol to establish client-server connection
> ---
>
> Key: IGNITE-12438
> URL: https://issues.apache.org/jira/browse/IGNITE-12438
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Recently there was quite a lot of questions related to thick clients 
> connectivity issues when the clients are deployed in a k8s pod [1]. The 
> general issue here is clients reporting network address which are not 
> reachable from server nodes. At the same time, the clients can connect to 
> server nodes.
> An idea of how to fix this is as follows:
>  * Make sure that think clients discovery SPI always maintains a connection 
> to a server node (this should be already implemented)
>  * (Optionally) detect when a client has only one-way connectivity with the 
> server nodes. This part should be investigated. We need this to avoid server 
> nodes attempt to connect to a client and send communication request to the 
> client node faster
>  * When a server attempts to establish a connection with a client, check if 
> client is unreachable or the previous connection attempt failed. If so, send 
> a discovery message to the client to force a client-server connection. In 
> this case, server will be able to send the original message via the newly 
> established connection.
> [1] 
> https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection

[Denis A. Magda (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108388#comment-17108388
 ] 

Denis A. Magda commented on IGNITE-12438:
-

Ivan, thank you!

As this task's description suggests, a server will try to connect to a client 
anyway through communication SPI before requesting the client (via a discovery 
message) to establish a connection with the server instead. It means that the 
client should create a server socket even for EnvironmentType.VIRTUALIZED. At 
least that was my understanding. The issue described in 
[IGNITE-13013|https://issues.apache.org/jira/browse/IGNITE-13013] is about the 
cases when the server must not even try to connect to the client and the client 
must not open the server socket. Actually, that's the case for this bullet item 
of this ticket_ (Optionally) detect when a client has only one-way connectivity 
with the server nodes. This part should be investigated. We need this to avoid 
server nodes attempt to connect to a client and send communication request to 
the client node faster_

I'll leave it up to you, you can close IGNITE-13013 and fix the issue as part 
of this task. Or you can IGNITE-13013 as a sub-task and track those cases 
separately.


> Extend communication protocol to establish client-server connection
> ---
>
> Key: IGNITE-12438
> URL: https://issues.apache.org/jira/browse/IGNITE-12438
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Recently there was quite a lot of questions related to thick clients 
> connectivity issues when the clients are deployed in a k8s pod [1]. The 
> general issue here is clients reporting network address which are not 
> reachable from server nodes. At the same time, the clients can connect to 
> server nodes.
> An idea of how to fix this is as follows:
>  * Make sure that think clients discovery SPI always maintains a connection 
> to a server node (this should be already implemented)
>  * (Optionally) detect when a client has only one-way connectivity with the 
> server nodes. This part should be investigated. We need this to avoid server 
> nodes attempt to connect to a client and send communication request to the 
> client node faster
>  * When a server attempts to establish a connection with a client, check if 
> client is unreachable or the previous connection attempt failed. If so, send 
> a discovery message to the client to force a client-server connection. In 
> this case, server will be able to send the original message via the newly 
> established connection.
> [1] 
> https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108378#comment-17108378
 ] 

Pavel Tupitsyn commented on IGNITE-7269:


As for ASP.NET, this is a legacy technology. New integrations will be for 
ASP.NET Core.

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108376#comment-17108376
 ] 

Pavel Tupitsyn commented on IGNITE-7269:


[~marty.jo...@newportgroup.com] overhead is per node. Typically you start one 
Ignite client node per process. Adding more caches does not make a big 
difference on client nodes.

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-13015) Use nano time in node failure detection.

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108348#comment-17108348
 ] 

Ivan Daschinskiy edited comment on IGNITE-13015 at 5/15/20, 2:36 PM:
-

Huge +1. {{System.currentTimeMillis()}} is backed by {{gettimeofday()}} and is 
not monotonic. Instead, {{System.nanoTime()}}, that is backed by 
{{clock_gettime(CLOCK_MONOTONIC,..)}} has monotonic guarantee with nanoseconds 
precision. Moreover, both methods are not system calls in modern Linuxes thanks 
to vDSO, so we can avoid context switches and don't worry about performance 
drop (see [here|http://man7.org/linux/man-pages/man7/vdso.7.html] for details). 


was (Author: ivandasch):
Huge +1. {{System.currentTimeMillis()}} is backed by {{gettimeofday()}} and is 
not monotonic. Instead, {{System.nanoTime()}}, that is backed by 
{{clock_gettime(CLOCK_MONOTONIC,..)}} has monotonic guarantee with nanoseconds 
precision. Moreover, both methods are not system calls in modern Linuxes thanks 
to vDSO, so we can avoid context switches and don't worry about performance 
drop. (see [here|http://man7.org/linux/man-pages/man7/vdso.7.html] for 
details). 

> Use nano time in node failure detection.
> 
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>  Labels: iep-45
>
> Make sure in node failure detection not used:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> Disadventages:
> 1)Current system time has no quarantine of strict forward movement. 
> System time can be adjusted, synchronized by NTP as example. This can lead to 
> incorrect and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-13015) Use nano time in node failure detection.

[Ivan Daschinskiy (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108348#comment-17108348
 ] 

Ivan Daschinskiy commented on IGNITE-13015:
---

Huge +1. {{System.currentTimeMillis()}} is backed by {{gettimeofday()}} and is 
not monotonic. Instead, {{System.nanoTime()}}, that is backed by 
{{clock_gettime(CLOCK_MONOTONIC,..)}} has monotonic guarantee with nanoseconds 
precision. Moreover, both methods are not system calls in modern Linuxes thanks 
to vDSO, so we can avoid context switches and don't worry about performance 
drop. (see [here|http://man7.org/linux/man-pages/man7/vdso.7.html] for 
details). 

> Use nano time in node failure detection.
> 
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>  Labels: iep-45
>
> Make sure in node failure detection not used:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> Disadventages:
> 1)Current system time has no quarantine of strict forward movement. 
> System time can be adjusted, synchronized by NTP as example. This can lead to 
> incorrect and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Marty Jones (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108341#comment-17108341
 ] 

Marty Jones commented on IGNITE-7269:
-

For now we are stuck with ASP.NET.   We have a large legacy ASP.NET MVC 
application that we want to use Ignite on.  

Do you know if the overhead of the client of 100-200 MB will be per cache?   I 
know we will need at least 2 caches so trying to judge the overhead needed.

 

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108336#comment-17108336
 ] 

Pavel Tupitsyn edited comment on IGNITE-7269 at 5/15/20, 2:28 PM:
--

[~marty.jo...@newportgroup.com]

> how large is the overhead of using the "Client" mode within an .NET 
> application

Client mode requires 100-200 MB of RAM, and startup time is around a second.

By the way, do you mean ASP.NET or ASP.NET Core?


was (Author: ptupitsyn):
> how large is the overhead of using the "Client" mode within an .NET 
> application
Client mode requires 100-200 MB of RAM, and startup time is around a second.

By the way, do you mean ASP.NET or ASP.NET Core?

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108336#comment-17108336
 ] 

Pavel Tupitsyn commented on IGNITE-7269:


> how large is the overhead of using the "Client" mode within an .NET 
> application
Client mode requires 100-200 MB of RAM, and startup time is around a second.

By the way, do you mean ASP.NET or ASP.NET Core?

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Marty Jones (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108329#comment-17108329
 ] 

Marty Jones edited comment on IGNITE-7269 at 5/15/20, 2:23 PM:
---

I am looking to use Ignite within our Asp.Net web application and will need 
distributed sessions in order to use it.   I have reviewed the source for the 
IgniteSessionStateStoreProvider and it doesn't look like a huge lift to create 
a version for the Thin client.  The only thing I am not sure about is the 
"OutInOp" method for locking/releasing.

I don't mind contributing if that would help.

That being said, how large is the overhead of using the "Client" mode within an 
.NET application?  I would need one cache for session and one to hold items we 
would cache.


was (Author: marty.jo...@newportgroup.com):
I am looking to use Ignite within our Asp.Net web application and will need 
distributed sessions in order to use it.   I have reviewed the source for the 
IgniteSessionStateStoreProvider and it doesn't look like a huge lift to create 
a version for the Thin client.  The only thing I am not sure about is the 
"OutInOp" method for locking/releasing.

I don't mind contributing if that would help.

 

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13018) Get rid of duplicated checking of failed node.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13018:
-

 Summary: Get rid of duplicated checking of failed node.
 Key: IGNITE-13018
 URL: https://issues.apache.org/jira/browse/IGNITE-13018
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


Failed node checking should be simplified to one step: ping node (send a 
message) from previous one in the ring and wait for response within 
IgniteConfiguration.failureDetectionTimeout. If node doesn't respond, we should 
consider it failed. Extra steps of connection checking may seriously delay 
failure detection, bring confusion and weird behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13018) Get rid of duplicated checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13018:
--
Labels: iep-45  (was: )

> Get rid of duplicated checking of failed node.
> --
>
> Key: IGNITE-13018
> URL: https://issues.apache.org/jira/browse/IGNITE-13018
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> Failed node checking should be simplified to one step: ping node (send a 
> message) from previous one in the ring and wait for response within 
> IgniteConfiguration.failureDetectionTimeout. If node doesn't respond, we 
> should consider it failed. Extra steps of connection checking may seriously 
> delay failure detection, bring confusion and weird behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Marty Jones (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108329#comment-17108329
 ] 

Marty Jones commented on IGNITE-7269:
-

I am looking to use Ignite within our Asp.Net web application and will need 
distributed sessions in order to use it.   I have reviewed the source for the 
IgniteSessionStateStoreProvider and it doesn't look like a huge lift to create 
a version for the Thin client.  The only thing I am not sure about is the 
"OutInOp" method for locking/releasing.

I don't mind contributing if that would help.

 

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Pavel Tupitsyn (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108325#comment-17108325
 ] 

Pavel Tupitsyn commented on IGNITE-7269:


[~marty.jo...@newportgroup.com] no plans for this so far, we are busy 
increasing core Thin Client functionality right now (Compute, Services, 
Continuous Queries, Discovery). Integrations will come later.

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13017) Remove hardcoded delay from re-marking failed node as alive.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13017:
--
Labels: iep-45  (was: )

> Remove hardcoded delay from re-marking failed node as alive.
> 
>
> Key: IGNITE-13017
> URL: https://issues.apache.org/jira/browse/IGNITE-13017
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should remove hardcoded timeout from:
> {code:java}
> boolean 
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive() {
> if (state == RingMessageSendState.FORWARD_PASS || state == 
> RingMessageSendState.BACKWARD_PASS) {
>...
> if (--failedNodes <= 0) {
> ...
> state = RingMessageSendState.STARTING_POINT;
> try {
> Thread.sleep(200);
> }
> catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> return true;
> }
> return false;
> }
> {code}
> This can bring additional 200ms to duration of failed node detection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13017) Remove hardcoded delay from re-marking failed node as alive.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13017:
--
Summary: Remove hardcoded delay from re-marking failed node as alive.  
(was: Remove delay of 200ms from re-marking failed node as alive.)

> Remove hardcoded delay from re-marking failed node as alive.
> 
>
> Key: IGNITE-13017
> URL: https://issues.apache.org/jira/browse/IGNITE-13017
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> We should remove hardcoded timeout from:
> {code:java}
> boolean 
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive() {
> if (state == RingMessageSendState.FORWARD_PASS || state == 
> RingMessageSendState.BACKWARD_PASS) {
>...
> if (--failedNodes <= 0) {
> ...
> state = RingMessageSendState.STARTING_POINT;
> try {
> Thread.sleep(200);
> }
> catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> return true;
> }
> return false;
> }
> {code}
> This can bring additional 200ms to duration of failed node detection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13017) Remove delay of 200ms from re-marking failed node as alive.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13017:
-

 Summary: Remove delay of 200ms from re-marking failed node as 
alive.
 Key: IGNITE-13017
 URL: https://issues.apache.org/jira/browse/IGNITE-13017
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


We should remove hardcoded timeout from:

{code:java}
boolean ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive() {
if (state == RingMessageSendState.FORWARD_PASS || state == 
RingMessageSendState.BACKWARD_PASS) {
   ...

if (--failedNodes <= 0) {
...

state = RingMessageSendState.STARTING_POINT;

try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}

return true;
}

return false;
}
{code}

This can bring additional 200ms to duration of failed node detection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
We should fix 3 drawbacks in the backward checking of failed node:

1) We should replace hardcoded timeout 100ms with a parameter like 
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}


2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param like failureDetectionTimeout:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout?

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}


3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}


  was:
We should fix 3 drawbacks in the backward checking of failed node:

1) We should replace hardcoded timeout 100ms with a parameter like 
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}


2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}


3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}



> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) We should replace hardcoded timeout 100ms with a parameter like 
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should 
> rely on configurable param like failureDetectionTimeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
> CON_CHECK_INTERVAL', not a failureDetectionTimeout?
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
We should fix 3 drawbacks in the backward checking of failed node:

1) We should replace hardcoded timeout 100ms with a parameter like 
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}


2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}


3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}


  was:
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}


2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}


3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}


> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) We should replace hardcoded timeout 100ms with a parameter like 
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should 
> rely on configurable param:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}

2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}

3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}

  was:
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}

2) Maximal interval to check previous node should be reconsidered, bound to 
configurable params:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);

   ...

   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.

  ...
}

res.previousNodeAlive(ok);
{code}

3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}


> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should 
> rely on configurable param:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}


2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}


3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}

  was:
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}

2) Maximal interval to check previous node should be reconsidered. It should 
rely on configurable param:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
   ...
   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.
  ...
}

res.previousNodeAlive(ok);
{code}

3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}


> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should 
> rely on configurable param:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
sock.connect(addr, 100);
   ...
}
{code}

2) Maximal interval to check previous node should be reconsidered, bound to 
configurable params:
{code:java}
   TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);

   ...

   // We got message from previous in less than double connection check 
interval.
   boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
CON_CHECK_INTERVAL', not a failureDetectionTimeout.

   if (ok) {
  // Check case when previous node suddenly died. This will speed up
  // node failing.

  ...
}

res.previousNodeAlive(ok);
{code}

3) Any negative result of the connection checking should be considered as node 
failed. Currently, we look only at refused connection. Any other exceptions, 
including a timeout, are treated as living connection: 

{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
   ...
   catch (ConnectException e) {
  return true;
   }
   catch (IOException e) {
  return false;//Why a timeout doesn't mean lost connection?
   }

   return false;
}
{code}

  was:
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}

return false;
}
{code}

2) Maximal interval to check previous node in the ring is:

{code:java}
TcpDiscoveryHandshakeResponse res =
new TcpDiscoveryHandshakeResponse(...);

...

// We got message from previous in less than double 
connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;

if (ok) {
// Check case when previous node suddenly died. 
This will speed up
// node failing.
...

}

res.previousNodeAlive(ok);
{code}




> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered, bound to 
> configurable params:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check 
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 * 
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
>   // Check case when previous node suddenly died. This will speed up
>   // node failing.
>   ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as 
> node failed. Currently, we look only at refused connection. Any other 
> exceptions, including a timeout, are treated as living connection: 
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
>   return true;
>}
>catch (IOException e) {
>   return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12996) Remote listener of IgniteEvents has to run inside the Ignite Sandbox.

[Denis Garus (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Garus reassigned IGNITE-12996:


Assignee: Denis Garus

> Remote listener of IgniteEvents has to run inside the Ignite Sandbox.
> -
>
> Key: IGNITE-12996
> URL: https://issues.apache.org/jira/browse/IGNITE-12996
> Project: Ignite
>  Issue Type: Task
>  Components: security
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>  Labels: iep-38
>
> Remote listener of IgniteEvents has to run on a remote node inside the Ignite 
> Sandbox if it is turned on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
We should fix 3 drawbacks in the backward checking of failed node:

1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}

return false;
}
{code}

2) Maximal interval to check previous node in the ring is:

{code:java}
TcpDiscoveryHandshakeResponse res =
new TcpDiscoveryHandshakeResponse(...);

...

// We got message from previous in less than double 
connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;

if (ok) {
// Check case when previous node suddenly died. 
This will speed up
// node failing.
...

}

res.previousNodeAlive(ok);
{code}



  was:
Backward checking of failed node rely on hardcoced timeout 100ms:

{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}

return false;
}
{code}

We should make it bound to configurable params like 
IgniteConfiguration.failureDetectionTimeout.

Also, the maximal interval to chech previous node is 


Summary: Fix backward checking of failed node.  (was: Remove hardcoded 
values/timeouts from backward checking of failed node.)

> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
> try (Socket sock = new Socket()) {
> sock.connect(addr, 100);
> }
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> return false;
> }
> {code}
> 2) Maximal interval to check previous node in the ring is:
> {code:java}
> TcpDiscoveryHandshakeResponse res =
> new TcpDiscoveryHandshakeResponse(...);
> ...
> // We got message from previous in less than double 
> connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
> if (ok) {
> // Check case when previous node suddenly died. 
> This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Remove hardcoded values/timeouts from backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Description: 
Backward checking of failed node rely on hardcoced timeout 100ms:

{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}

return false;
}
{code}

We should make it bound to configurable params like 
IgniteConfiguration.failureDetectionTimeout.

Also, the maximal interval to chech previous node is 


  was:
Backward checking of failed node rely on hardcoced timeout 100ms:

{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}

return false;
}
{code}

We should make it bound to configurable params like 
IgniteConfiguration.failureDetectionTimeout



> Remove hardcoded values/timeouts from backward checking of failed node.
> ---
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> Backward checking of failed node rely on hardcoced timeout 100ms:
> {code:java}
> private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
> try (Socket sock = new Socket()) {
> sock.connect(addr, 100);
> }
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> return false;
> }
> {code}
> We should make it bound to configurable params like 
> IgniteConfiguration.failureDetectionTimeout.
> Also, the maximal interval to chech previous node is 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13016) Remove hardcoded values/timeouts from backward checking of failed node.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13016:
--
Labels: iep-45  (was: )

> Remove hardcoded values/timeouts from backward checking of failed node.
> ---
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> Backward checking of failed node rely on hardcoced timeout 100ms:
> {code:java}
> private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
> try (Socket sock = new Socket()) {
> sock.connect(addr, 100);
> }
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> return false;
> }
> {code}
> We should make it bound to configurable params like 
> IgniteConfiguration.failureDetectionTimeout



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13016) Remove hardcoded values/timeouts from backward checking of failed node.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13016:
-

 Summary: Remove hardcoded values/timeouts from backward checking 
of failed node.
 Key: IGNITE-13016
 URL: https://issues.apache.org/jira/browse/IGNITE-13016
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


Backward checking of failed node rely on hardcoced timeout 100ms:

{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}

return false;
}
{code}

We should make it bound to configurable params like 
IgniteConfiguration.failureDetectionTimeout




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12938) control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108254#comment-17108254
 ] 

Ignite TC Bot commented on IGNITE-12938:


{panel:title=Branch: [pull/7743/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5308663&buildTypeId=IgniteTests24Java8_RunAll]

> control.sh utility commands: IdleVerify and ValidateIndexes use eventual 
> payload check.
> ---
>
> Key: IGNITE-12938
> URL: https://issues.apache.org/jira/browse/IGNITE-12938
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {noformat}
> "--cache idle_verify" and "--cache validate_indexes"
> {noformat}
>  commands of *control.sh*  utility use eventual payload check during  
> execution. This can lead to execution concurrently with active payload and no 
> errors like : "Checkpoint with dirty pages started! Cluster not idle"  will 
> be triggered. Additionally current functional miss check on caches without 
> persistence.  Remove old functionality from PageMemory and move it into 
> update counters usage. Running this checks with active rebalance or active 
> payload may give erroneous results in cases of out of order update messages 
> will be processed or some gaps eventually arises, more info [1]. This fix 
> covers such problems.
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13007) JDBC: Introduce feature flags for JDBC thin

[Taras Ledkov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov updated IGNITE-13007:
--
Fix Version/s: 2.9

> JDBC: Introduce feature flags for JDBC thin
> ---
>
> Key: IGNITE-13007
> URL: https://issues.apache.org/jira/browse/IGNITE-13007
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Motivation the same as for https://issues.apache.org/jira/browse/IGNITE-12853
> The thin client & JDBC, ODBC have different protocol specific and may require 
> implement different features.
> Each client (thin cli, thin JDBC, ODBC) should have its own feature flags set.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-11147) Re-balance cancellation occur by non-affected event

[Vladislav Pyatkov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-11147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladislav Pyatkov updated IGNITE-11147:
---
Description: 
Re-balance cancels by non-affected events, for examples:
 1) joining non affinity node
 2) starting snapshot
 3) starting/stopping other cache

Try to skip as much as possible events instead of cancellation.

After solved several issues appearing during this testing, I decided to add 
specific property allowing on/off rebalance's optimization. (see 
{{IgniteSystemProperties#IGNITE_DISABLE_REBALANCING_CANCELLATION_OPTIMIZATION}} 
by default false).

  was:
Re-balance cancels by non-affected events, for examples:
1) joining non affinity node
2) stating snapshot
3) starting/stopping other cache

Try to skip as more as possible events instead of cancellation.

After solved several issues appearing during this testing, I decided to add 
specific property allowing on/off rebalance's optimization. (see 
{{IgniteSystemProperties#IGNITE_DISABLE_REBALANCING_CANCELLATION_OPTIMIZATION}} 
by default false).



> Re-balance cancellation occur by non-affected event
> ---
>
> Key: IGNITE-11147
> URL: https://issues.apache.org/jira/browse/IGNITE-11147
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Re-balance cancels by non-affected events, for examples:
>  1) joining non affinity node
>  2) starting snapshot
>  3) starting/stopping other cache
> Try to skip as much as possible events instead of cancellation.
> After solved several issues appearing during this testing, I decided to add 
> specific property allowing on/off rebalance's optimization. (see 
> {{IgniteSystemProperties#IGNITE_DISABLE_REBALANCING_CANCELLATION_OPTIMIZATION}}
>  by default false).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-7269) .NET: Thin ASP.NET Session State Store Provider

[Marty Jones (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108215#comment-17108215
 ] 

Marty Jones commented on IGNITE-7269:
-

Any idea on when this feature will be implemented?

> .NET: Thin ASP.NET Session State Store Provider
> ---
>
> Key: IGNITE-7269
> URL: https://issues.apache.org/jira/browse/IGNITE-7269
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ASP.NET
>
> IGNITE-3199 introduced session store provider which works via full .NET API 
> that starts JVM in process.
> Introduce {{IgniteThinSessionStateStoreProvider}} that uses thin client API.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-13007) JDBC: Introduce feature flags for JDBC thin

[Konstantin Orlov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108216#comment-17108216
 ] 

Konstantin Orlov commented on IGNITE-13007:
---

[~tledkov-gridgain], fixed. Take a look again please.

> JDBC: Introduce feature flags for JDBC thin
> ---
>
> Key: IGNITE-13007
> URL: https://issues.apache.org/jira/browse/IGNITE-13007
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Motivation the same as for https://issues.apache.org/jira/browse/IGNITE-12853
> The thin client & JDBC, ODBC have different protocol specific and may require 
> implement different features.
> Each client (thin cli, thin JDBC, ODBC) should have its own feature flags set.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13015) Use nano time in node failure detection.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13015:
--
Labels: iep-45  (was: )

> Use nano time in node failure detection.
> 
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>  Labels: iep-45
>
> Make sure in node failure detection not used:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> Disadventages:
> 1)Current system time has no quarantine of strict forward movement. 
> System time can be adjusted, synchronized by NTP as example. This can lead to 
> incorrect and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13012:
--
Description: 
Current noted-to-node connection checking has several drawbacks:

1)  Minimal connection checking interval is not bound to failure detection 
parameters: 
static int ServerImpls.CON_CHECK_INTERVAL = 500;

2)  Connection checking isn't based on time of the last message sent.  
TcpDiscoveryConnectionCheckMessage is bound to own time (ServerImpl. 
RingMessageWorker.lastTimeConnCheckMsgSent). This is weird because any 
discovery message actually checks connection. And 
TpDiscoveryConnectionCheckMessage is just an addition when message queue is 
empty for a long time.

3)  Period of Node-to-Node connection checking can be sometimes shortened 
for strange reason: if no sent or received message appears within 
failureDetectionTimeout. Here, despite we have minimal period of connection 
checking (ServerImpls.CON_CHECK_INTERVAL), we can also send 
TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this 
premature node ping relies also on the time of last received message. Imagine: 
if node 2 receives no message from node 1 within some time it decides to do 
extra ping node 3 not waiting for regular ping interval. Such behavior makes 
confusion and gives no additional guaranties.

4)  If #3 happens, node writes in the log on INFO: “Local node seems to be 
disconnected from topology …” whereas it is not actually disconnected. User can 
see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like 
seeing INFO in a log saying a node is might be disconnected. This sounds like 
some troubles raised in network. But not as everything is OK. 

Suggestions:
1)  Make connection check interval be based on failureDetectionTimeout or 
similar params.
2)  Make connection check interval rely on common time of last sent 
message. Not on dedicated time.
3)  Remove additional, random, quickened connection checking.
4)  Do not worry user with “Node disconnected” when everything is OK.

  was:
Current noted-to-node connection checking has several drawbacks:

1)  Minimal connection checking interval is not bound to failure detection 
parameters: 
static int ServerImpls.CON_CHECK_INTERVAL = 500;

2)  Connection checking is made as ability of periodical message sending 
(TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. 
RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent 
message. This is weird because any discovery message actually checks 
connection. And TpDiscoveryConnectionCheckMessage is just an addition when 
message queue is empty for a long time.

3)  Period of Node-to-Node connection checking can be sometimes shortened 
for strange reason: if no sent or received message appears within 
failureDetectionTimeout. Here, despite we have minimal period of connection 
checking (ServerImpls.CON_CHECK_INTERVAL), we can also send 
TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this 
premature node ping relies also on time of last received message. Imagine: if 
node 2 receives no message from node 1 within some time it decides to do extra 
ping node 3 not waiting for regular ping interval. Such behavior makes 
confusion and gives no additional guaranties.

4)  If #3 happens, node writes in the log on INFO: “Local node seems to be 
disconnected from topology …” whereas it is not actually disconnected. User can 
see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like 
seeing INFO in a log saying a node is might be disconnected. This sounds like 
some troubles raised in network. But not as everything is OK. 

Suggestions:
1)  Make connection check interval be based on failureDetectionTimeout or 
similar params.
2)  Make connection check interval rely on common time of last sent 
message. Not on dedicated time.
3)  Remove additional, random, quickened connection checking.
4)  Do not worry user with “Node disconnected” when everything is OK.


> Make node connection checking rely on the configuration. Simplify node ping 
> routine.
> 
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
>
> Current noted-to-node connection checking has several drawbacks:
> 1)Minimal connection checking interval is not bound to failure detection 
> parameters: 
> static int ServerImpls.CON_CHECK_INTERVAL = 500;
> 2)Connection checking isn't based on time of the last message sent.  
> TcpDiscov

[jira] [Commented] (IGNITE-11147) Re-balance cancellation occur by non-affected event

[Alexey Scherbakov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108162#comment-17108162
 ] 

Alexey Scherbakov commented on IGNITE-11147:


[~v.pyatkov]

LGTM, merged to master
#a6d3f52e41dfe602a3654cc67c59f460fd0dfd4e.

Thanks for a contribution.

> Re-balance cancellation occur by non-affected event
> ---
>
> Key: IGNITE-11147
> URL: https://issues.apache.org/jira/browse/IGNITE-11147
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Fix For: 2.9
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Re-balance cancels by non-affected events, for examples:
> 1) joining non affinity node
> 2) stating snapshot
> 3) starting/stopping other cache
> Try to skip as more as possible events instead of cancellation.
> After solved several issues appearing during this testing, I decided to add 
> specific property allowing on/off rebalance's optimization. (see 
> {{IgniteSystemProperties#IGNITE_DISABLE_REBALANCING_CANCELLATION_OPTIMIZATION}}
>  by default false).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13015) Use nano time in node failure detection.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13015:
--
Summary: Use nano time in node failure detection.  (was: Use nono time in 
node failure detection.)

> Use nano time in node failure detection.
> 
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> Make sure in node failure detection not used:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> Disadventages:
> 1)Current system time has no quarantine of strict forward movement. 
> System time can be adjusted, synchronized by NTP as example. This can lead to 
> incorrect and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13015) Use nono time in node failure detection.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13015:
--
Priority: Minor  (was: Major)

> Use nono time in node failure detection.
> 
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> Make sure in node failure detection not used:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> Disadventages:
> 1)Current system time has no quarantine of strict forward movement. 
> System time can be adjusted, synchronized by NTP as example. This can lead to 
> incorrect and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13015) Use nono time in node failure detection.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13015:
--
Summary: Use nono time in node failure detection.  (was: Use nono time 
instead of currentMills() in node failure ddetection.)

> Use nono time in node failure detection.
> 
>
> Key: IGNITE-13015
> URL: https://issues.apache.org/jira/browse/IGNITE-13015
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> Make sure in node failure detection not used:
> {code:java}
> System.currentTimeMillis()
> and
> IgniteUtils.currentTimeMillis()
> {code}
> Disadventages:
> 1)Current system time has no quarantine of strict forward movement. 
> System time can be adjusted, synchronized by NTP as example. This can lead to 
> incorrect and negative delays.
> 2) IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13015) Use nono time instead of currentMills() in node failure ddetection.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13015:
-

 Summary: Use nono time instead of currentMills() in node failure 
ddetection.
 Key: IGNITE-13015
 URL: https://issues.apache.org/jira/browse/IGNITE-13015
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


Make sure in node failure detection not used:
{code:java}
System.currentTimeMillis()
and
IgniteUtils.currentTimeMillis()
{code}

Disadventages:

1)  Current system time has no quarantine of strict forward movement. 
System time can be adjusted, synchronized by NTP as example. This can lead to 
incorrect and negative delays.

2)   IgniteUtils.currentTimeMillis() is granulated by 10ms



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-12617) PME-free switch should wait for recovery only at affected nodes.

[Anton Vinogradov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108152#comment-17108152
 ] 

Anton Vinogradov commented on IGNITE-12617:
---

Merged to master.

> PME-free switch should wait for recovery only at affected nodes.
> 
>
> Key: IGNITE-12617
> URL: https://issues.apache.org/jira/browse/IGNITE-12617
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>  Labels: iep-45
> Fix For: 2.9
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since IGNITE-9913, new-topology operations allowed immediately after 
> cluster-wide recovery finished.
> But is there any reason to wait for a cluster-wide recovery if only one node 
> failed?
> In this case, we should recover only the failed node's backups.
> Unfortunately, {{RendezvousAffinityFunction}} tends to spread the node's 
> backup partitions to the whole cluster. In this case, we, obviously, have to 
> wait for cluster-wide recovery on switch.
> But what if only some nodes will be the backups for every primary?
> In case nodes combined into virtual cells where, for each partition, backups 
> located at the same cell with primaries, it's possible to finish the switch 
> outside the affected cell before tx recovery finish.
> This optimization will allow us to start and even finish new operations 
> outside the failed cell without a cluster-wide switch finish (broken cell 
> recovery) waiting.
> In other words, switch (when left/fail + baseline + rebalanced) will have 
> little effect on the operation's (not related to failed cell) latency.
> In other words
> - We should wait for tx recovery before finishing the switch only on a broken 
> cell.
> - We should wait for replicated caches tx recovery everywhere since every 
> node is a backup of a failed one.
> - Upcoming operations related to the broken cell (including all replicated 
> caches operations) will require a cluster-wide switch finish to be processed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Description: 
For the present, we have double checking of node availability. This prolongs 
node failure detection and gives no additional benefits. There are mesh and 
hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Node 3 may try to check node 2 too. Or may not.

Proposal:
Do not check failed node second time. Keep failure detection within expected 
timeouts (IgniteConfiguration.failureDetectionTimeout).


Drawbacks:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
{code}

If ‘ok == true’ node 3 checks node 2.

3)  Several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}

Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

4) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
try (Socket sock = new Socket()) {
   sock.connect(addr, 100);
}
catch (ConnectException e) {
   return true;
}
catch (IOException e) {
   return false; //Consideres as OK.
}
{code}


  was:
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
{code}

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}

4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

5) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
try (Socket sock = new Socket()) {
   sock.connect(addr, 100);
}
catch (ConnectException e) {
   return true;
}
catch (IOException e) {
   return false; //Consideres as OK.
}
{code}



> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have double checking of node availability. This prolongs 
> node failure detection and gives no additional benefits. There are mesh and 
> hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Node 3 may try to check node 2 too. Or may not.
> Proposal:
> Do not check failed node second time. Keep failure detection within expected 
> timeouts (IgniteConfiguration.failureDetectionTimeout).
> Drawbacks:
> 1)Possible long detection of nod

[jira] [Commented] (IGNITE-13009) NoopTimeBag should be used if logging disabled

[Ignite TC Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108138#comment-17108138
 ] 

Ignite TC Bot commented on IGNITE-13009:


{panel:title=Branch: [pull/7802/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5306775&buildTypeId=IgniteTests24Java8_RunAll]

> NoopTimeBag should be used if logging disabled
> --
>
> Key: IGNITE-13009
> URL: https://issues.apache.org/jira/browse/IGNITE-13009
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TimeBag uses performs useless operations on finishGlobalStage if logging 
> disabled.
> Better case is to use no-op realization instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Description: 
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
{code}

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}

4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

5) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
try (Socket sock = new Socket()) {
   sock.connect(addr, 100);
}
catch (ConnectException e) {
   return true;
}
catch (IOException e) {
   return false; //Consideres as OK.
}
{code}


  was:
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

5) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
try (Socket sock = new Socket()) {
   sock.connect(addr, 100);
}
catch (ConnectException e) {
   return true;
}
catch (IOException e) {
   return false; //Consideres as OK.
}
{code}



> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Description: 
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

5) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
try (Socket sock = new Socket()) {
   sock.connect(addr, 100);
}
catch (ConnectException e) {
   return true;
}
catch (IOException e) {
   return false; //Consideres as OK.
}
{code}


  was:
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

5) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
 try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}



> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout 

[jira] [Commented] (IGNITE-13007) JDBC: Introduce feature flags for JDBC thin

[Taras Ledkov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-13007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108133#comment-17108133
 ] 

Taras Ledkov commented on IGNITE-13007:
---

[~korlov], the patch is OK with me. Please take a loot at the one comment about 
empty code block at the new test 
{{JdbcThinConnectionSelfTest#testDisabledFeatures}}

> JDBC: Introduce feature flags for JDBC thin
> ---
>
> Key: IGNITE-13007
> URL: https://issues.apache.org/jira/browse/IGNITE-13007
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Motivation the same as for https://issues.apache.org/jira/browse/IGNITE-12853
> The thin client & JDBC, ODBC have different protocol specific and may require 
> implement different features.
> Each client (thin cli, thin JDBC, ODBC) should have its own feature flags set.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Description: 
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See 
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
   Thread.sleep(200);
}
catch (InterruptedException e) {
   Thread.currentThread().interrupt();
}
{code}

5) Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused():

{code:java}
 try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}


  was:
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused().


> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable decision to check availability of previous 
> node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
> If ‘ok == true’ node 3 checks node 2.
> 3)Double node checking brings several not-configurable hardcoded delays:
> Node 3 checks node 2 with 

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Labels: iep-45  (was: )

> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable decision to check availability of previous 
> node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
> If ‘ok == true’ node 3 checks node 2.
> 3)Double node checking brings several not-configurable hardcoded delays:
> Node 3 checks node 2 with hardcoded timeout 100ms:
> ServerImpl.isConnectionRefused():
> sock.connect(addr, 100);
> Checking availability of previous node considers any exception but 
> ConnectionException (connection refused) as existing connection. Even a 
> timeout. See ServerImpl.isConnectionRefused().



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Attachment: WostCase.txt

> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable decision to check availability of previous 
> node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
> If ‘ok == true’ node 3 checks node 2.
> 3)Double node checking brings several not-configurable hardcoded delays:
> Node 3 checks node 2 with hardcoded timeout 100ms:
> ServerImpl.isConnectionRefused():
> sock.connect(addr, 100);
> Checking availability of previous node considers any exception but 
> ConnectionException (connection refused) as existing connection. Even a 
> timeout. See ServerImpl.isConnectionRefused().



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Description: 
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.

Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 


Disadvantages:

1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused().

  was:
For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 
Disadvantages:
1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused().


> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable decision to check availability of previous 
> node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
> If ‘ok == true’ node 3 checks node 2.
> 3)Double node checking brings several not-configurable hardcoded delays:
> Node 3 checks node 2 with hardcoded timeout 100ms:
> ServerImpl.isConnectionRefused():
> sock.connect(addr, 100);
> Checking availability of previous node considers any exception but 
> ConnectionException (connection refused) as existing connection. Even a 
> timeout. See ServerImpl.isConnectionRefused().



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13014) Remove long, double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-13014:
-

 Summary: Remove long, double checking of node availability. Fix 
hardcoded values.
 Key: IGNITE-13014
 URL: https://issues.apache.org/jira/browse/IGNITE-13014
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


For the present, we have duplicated checking of node availability. This 
prolongs node failure detection and gives no additional benefits. There are 
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
node 2 and asks Node 3 to establish permanent connection instead of node 2. 
Despite node 2 has been already pinged within configured timeouts, node 3 try 
to connect to node 2 too. 
Disadvantages:
1)  Possible long detection of node failure up to 
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout 
+ 300ms. See ‘WostCase.txt’

2)  Unexpected, not-configurable decision to check availability of previous 
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:

// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 

If ‘ok == true’ node 3 checks node 2.

3)  Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():

sock.connect(addr, 100);

Checking availability of previous node considers any exception but 
ConnectionException (connection refused) as existing connection. Even a 
timeout. See ServerImpl.isConnectionRefused().



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.

[Vladimir Steshin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-13014:
--
Summary: Remove double checking of node availability. Fix hardcoded values. 
 (was: Remove long, double checking of node availability. Fix hardcoded values.)

> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> For the present, we have duplicated checking of node availability. This 
> prolongs node failure detection and gives no additional benefits. There are 
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping 
> node 2 and asks Node 3 to establish permanent connection instead of node 2. 
> Despite node 2 has been already pinged within configured timeouts, node 3 try 
> to connect to node 2 too. 
> Disadvantages:
> 1)Possible long detection of node failure up to 
> ServerImpl.CON_CHECK_INTERVAL + 2 * 
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable decision to check availability of previous 
> node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; 
> If ‘ok == true’ node 3 checks node 2.
> 3)Double node checking brings several not-configurable hardcoded delays:
> Node 3 checks node 2 with hardcoded timeout 100ms:
> ServerImpl.isConnectionRefused():
> sock.connect(addr, 100);
> Checking availability of previous node considers any exception but 
> ConnectionException (connection refused) as existing connection. Even a 
> timeout. See ServerImpl.isConnectionRefused().



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-12900:


Assignee: (was: Nikolay Izhikov)

> Calcite integration. Use RowHandler to access fields.
> -
>
> Key: IGNITE-12900
> URL: https://issues.apache.org/jira/browse/IGNITE-12900
> Project: Ignite
>  Issue Type: Task
>Reporter: Igor Seliverstov
>Priority: Major
>
> Currently only Object[] can be used as a row because most of execution nodes 
> require Object[] as a row type. Let's use generic row types with appropriate 
> RowHandler in execution nodes and compiled expressions to get more 
> flexibility.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-12900:


Assignee: Nikolay Izhikov

> Calcite integration. Use RowHandler to access fields.
> -
>
> Key: IGNITE-12900
> URL: https://issues.apache.org/jira/browse/IGNITE-12900
> Project: Ignite
>  Issue Type: Task
>Reporter: Igor Seliverstov
>Assignee: Nikolay Izhikov
>Priority: Major
>
> Currently only Object[] can be used as a row because most of execution nodes 
> require Object[] as a row type. Let's use generic row types with appropriate 
> RowHandler in execution nodes and compiled expressions to get more 
> flexibility.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.

[Nikolay Izhikov (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-12900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov reassigned IGNITE-12900:


Assignee: (was: Nikolay Izhikov)

> Calcite integration. Use RowHandler to access fields.
> -
>
> Key: IGNITE-12900
> URL: https://issues.apache.org/jira/browse/IGNITE-12900
> Project: Ignite
>  Issue Type: Task
>Reporter: Igor Seliverstov
>Priority: Major
>
> Currently only Object[] can be used as a row because most of execution nodes 
> require Object[] as a row type. Let's use generic row types with appropriate 
> RowHandler in execution nodes and compiled expressions to get more 
> flexibility.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-13009) NoopTimeBag should be used if logging disabled

[Nikolay Izhikov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108057#comment-17108057
 ] 

Nikolay Izhikov commented on IGNITE-13009:
--

LGTM

> NoopTimeBag should be used if logging disabled
> --
>
> Key: IGNITE-13009
> URL: https://issues.apache.org/jira/browse/IGNITE-13009
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TimeBag uses performs useless operations on finishGlobalStage if logging 
> disabled.
> Better case is to use no-op realization instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IGNITE-10100) Add public Java API to call Ignite.NET services

[Vyacheslav Daradur (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-12886) Introduce separate SQL configuration

[Konstantin Orlov (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108028#comment-17108028
 ] 

Konstantin Orlov commented on IGNITE-12886:
---

[~tledkov-gridgain], LGTM.

> Introduce separate SQL configuration
> 
>
> Key: IGNITE-12886
> URL: https://issues.apache.org/jira/browse/IGNITE-12886
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> A lot of SQL-related configuration parameter are placed at the root of the 
> {{IgniteConfiguration}}.
> It would be better to move them to a separate configuration class, e.g. 
> {{SqlConfiguration}}.
> Thread on [Ignite developers 
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Introduce-separate-SQL-configuration-td46636.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)