[jira] [Assigned] (IGNITE-11393) Create IgniteLinkTaglet.toString() implementation for Java9+
[ https://issues.apache.org/jira/browse/IGNITE-11393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-11393: -- Assignee: Aleksey Plekhanov > Create IgniteLinkTaglet.toString() implementation for Java9+ > > > Key: IGNITE-11393 > URL: https://issues.apache.org/jira/browse/IGNITE-11393 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Aleksey Plekhanov >Priority: Major > > New implementation was added according to the new Java API for Javadoc. > But the main method kept empty, need to implement toString() to process > IgniteLink annotation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10424) CacheException thrown instead of SqlException
[
https://issues.apache.org/jira/browse/IGNITE-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin reassigned IGNITE-10424:
---
Assignee: Maksim Timonin
> CacheException thrown instead of SqlException
> -
>
> Key: IGNITE-10424
> URL: https://issues.apache.org/jira/browse/IGNITE-10424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Maksim Timonin
>Priority: Major
> Labels: sql
> Fix For: 2.9
>
>
> When running query
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> {noformat}
> Apache Ignite 2.4 threw SqlException Numeric value out of range:
> "100";
> Apache Ignite 2.5 does not wrap underlying exception and throws
> javax.cache.CacheException instead
> {noformat}
> SELECT SUM(field2*10) FROM tmp_table_age_name_wage;
> Expected error:
> Numeric value out of range
> Actual error:
> Error: javax.cache.CacheException: Failed to execute map query on remote node
> [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6, errMsg=Failed to execute SQL
> query. Numeric value out of range: "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]] (state=5,code=0)
> java.sql.SQLException: javax.cache.CacheException: Failed to execute map
> query on remote node [nodeId=76cea51c-87a3-4054-b39e-1ad6d01c0df6,
> errMsg=Failed to execute SQL query. Numeric value out of range:
> "100"; SQL statement:
> SELECT
> SUM(__Z0.FIELD2 * 10) __C0_0
> FROM PUBLIC.TMP_TABLE_AGE_NAME_WAGE __Z0 [22003-195]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:779)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:210)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:473)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114194#comment-17114194 ] Zane Hu commented on IGNITE-10959: -- As I commented before, there are two confirmed cases of memory blowup in Ignite, which are caused by too many cache update events in pending buffers since an older update event than the buffered pending events has not arrived yet. # One is per-partition TreeMap CacheContinuousQueryPartitionRecovery.pendingEvts in CacheContinuousQueryHandler.rcvs. It has a upper-bound prevention of MAX_BUFF_SIZE. # Another is per-partition ConcurrentSkipListMap CacheContinuousQueryEventBuffer.pending. It has no upper-bound prevention on CacheContinuousQueryEventBuffer.pending. Attached below is a pseudo code of the main logic flow of how they are processed in Ignite. Hope it can help people to fix the problem. They all started in CacheContinuousQueryHandler.CacheContinuousQueryListener.onEntryUpdated() when a cache entry is updated. [^Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt] > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zane Hu updated IGNITE-10959: - Attachment: Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zane Hu updated IGNITE-10959: - Attachment: Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zane Hu updated IGNITE-10959: - Attachment: Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, > Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13065) Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null
david created IGNITE-13065: -- Summary: Ignite Web Console 2.7.0 not working when scanning cache Error: Cannot read property 'length' of null Key: IGNITE-13065 URL: https://issues.apache.org/jira/browse/IGNITE-13065 Project: Ignite Issue Type: Bug Reporter: david Hi, I am using docker to host the web console and have pulled the latest image from docker. I have upgraded my ignite server to 2.8.0 but co no longer perform scans of my cache Has a new docker image for the web console been pushed to docker to support ignite 2.8.0? thank you David -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13064) Set default transaction timeout to 5 minutes
Ivan Rakov created IGNITE-13064: --- Summary: Set default transaction timeout to 5 minutes Key: IGNITE-13064 URL: https://issues.apache.org/jira/browse/IGNITE-13064 Project: Ignite Issue Type: Improvement Reporter: Ivan Rakov Let's set default TX timeout to 5 minutes (right now it's 0 = no timeout). Pros: 1. Deadlock detection procedure is triggered on timeout. In case user will get into key-level deadlock, he'll be able to discover root cause from the logs (even though load will hang for a while) and skip step with googling and debugging. 2. Almost every system with transactions has timeout enabled by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12376) Change level of "TCP client created ..." log messages to WARN
[
https://issues.apache.org/jira/browse/IGNITE-12376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-12376:
--
Description:
Log messages generated when createTcpClient takes more than
CONNECTION_ESTABLISH_THRESHOLD_MS (100 by default) has INFO level.
It seems it should be changed to WARN level and message text needs to be
changed for better understanding.
Message sample (current):
~{{2019-11-11 11:11:11.567[INFO
]tcp-comm-worker-nodename[o.a.i.s.c.tcp.TcpCommunicationSpi] TCP client created
[client=GridTcpNioCommunicationClient... ]],
duration=1234ms]}}~
Proposed format:
~{{2019-11-11 11:11:11.567[{color:#ff8b00}WARN{color}
]tcp-comm-worker-nodename[o.a.i.s.c.tcp.TcpCommunicationSpi] {color:#ff8b00}TCP
client creation took longer than expected
{color}[{color:#ff8b00}threshold=100ms{color},
client=GridTcpNioCommunicationClient... ]],
duration=1234ms]}}~
was:
Log messages generated when createTcpClient takes more than
CONNECTION_ESTABLISH_THRESHOLD_MS (100 by default) has INFO level.
It seems it should be changed to WARN level and message text needs to be
changed for better understanding.
Message sample (current):
~{{2019-11-11 11:11:11.567[INFO
]tcp-comm-worker-nodename[o.a.i.s.c.tcp.TcpCommunicationSpi] TCP client created
[client=GridTcpNioCommunicationClient... ]],
duration=1234ms]}}~
Proposed format:
~{{2019-11-11 11:11:11.567[{color:#ff8b00}WARN{color}
]tcp-comm-worker-nodename[o.a.i.s.c.tcp.TcpCommunicationSpi]
{color:#ff8b00}Long TCP client creation time{color}
[{color:#ff8b00}threshold=100ms{color}, client=GridTcpNioCommunicationClient...
]], duration=1234ms]}}~
> Change level of "TCP client created ..." log messages to WARN
> -
>
> Key: IGNITE-12376
> URL: https://issues.apache.org/jira/browse/IGNITE-12376
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ruslan Kuzmin
>Assignee: Surkov Aleksandr
>Priority: Minor
> Labels: newbie
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Log messages generated when createTcpClient takes more than
> CONNECTION_ESTABLISH_THRESHOLD_MS (100 by default) has INFO level.
> It seems it should be changed to WARN level and message text needs to be
> changed for better understanding.
> Message sample (current):
> ~{{2019-11-11 11:11:11.567[INFO
> ]tcp-comm-worker-nodename[o.a.i.s.c.tcp.TcpCommunicationSpi] TCP client
> created [client=GridTcpNioCommunicationClient... ]],
> duration=1234ms]}}~
>
> Proposed format:
> ~{{2019-11-11 11:11:11.567[{color:#ff8b00}WARN{color}
> ]tcp-comm-worker-nodename[o.a.i.s.c.tcp.TcpCommunicationSpi]
> {color:#ff8b00}TCP client creation took longer than expected
> {color}[{color:#ff8b00}threshold=100ms{color},
> client=GridTcpNioCommunicationClient... ]],
> duration=1234ms]}}~
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114107#comment-17114107 ] Grey Guo commented on IGNITE-10959: --- Similar as [~chinhodado] , we are very to close to remove Ignite from our product technology stack > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET
[
https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Kulagin reassigned IGNITE-10075:
Assignee: Nikolai Kulagin (was: Pavel Tupitsyn)
> .NET: Avoid binary configurations of Ignite Java service params and result
> when calling it from Ignite.NET
> --
>
> Key: IGNITE-10075
> URL: https://issues.apache.org/jira/browse/IGNITE-10075
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Nikolai Kulagin
>Priority: Major
> Labels: .NET, sbcf
> Attachments: MyTest.cs, ignite-10075-vs-2.8.patch
>
>
> Presently if there is an Ignite Java service taking parameters of complex
> (composite) types and returning a result of complex type then all the complex
> types must be explicitly specified in the binary configuration.
> We need to enhance Ignite not to require binary configuration assuming that
> we use the same type, package/namespace and field/property names on both the
> .NET and Java sides (or provide a custom name mapper for relaxed naming
> conventions).
> h2. Reproducer
> h3. ICalculator.java
> {code:java}
> package Sandbox.Net;
> public interface ICalculator {
> Result Calculate(Parameter p);
> }
> {code}
> h3. Parameter.java
> {code:java}
> package Sandbox.Net;
> public class Parameter {
> private int id;
> private double val;
> public int getId() {
> return id;
> }
> public Parameter setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return val;
> }
> public Parameter setValue(double val) {
> this.val = val;
> return this;
> }
> }
> {code}
> h3. Result .java
> {code:java}
> package Sandbox.Net;
> public class Result {
> private int id;
> private double value;
> public int getId() {
> return id;
> }
> public Result setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return value;
> }
> public Result setValue(double val) {
> this.value = val;
> return this;
> }
> }
> {code}
> h3. IgniteCalculatorService.java
> {code:java}
> package Sandbox.Net;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class IgniteCalculatorService implements Service, ICalculator {
> @Override public Result Calculate(Parameter p) {
> return new Result().setId(p.getId()).setValue(p.getValue() *
> p.getValue());
> }
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) {
> }
> @Override public void execute(ServiceContext ctx) {
> }
> }
> {code}
> h3. build.gradle
> {code:groovy}
> plugins {
> id 'java'
> }
> group 'sandbox.net'
> version '1.0-SNAPSHOT'
> sourceCompatibility = 1.8
> repositories {
> mavenLocal()
> mavenCentral()
> }
> def igniteVer='2.8.0'
> dependencies {
> compile group: 'org.apache.ignite', name: 'ignite-core', version:
> igniteVer
> testCompile group: 'junit', name: 'junit', version: '4.12'
> }
> {code}
> h3. ignite-config.xml
> {code:xml}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:47500
>
>
>
>
>
>
>
>
> {code}
> h3. ICalculator.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public interface ICalculator
> {
> Result Calculate(Parameter p);
> }
> }
> {code}
> h3. Parameter.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class Parameter
> {
> public int Id { get; set; }
> public double Value { get; set; }
> }
> }
> {code}
> h3. Result.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class Result
> {
> public int Id { get; set; }
>
[jira] [Updated] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13040:
--
Description:
Unused parameter
{code:java}
TcpDiscoveryAbstractMessage msg{code}
should be removed from
{code:java}
TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
byte[] data, long timeout){code}
This method seems to send raw data, not a message.
was:
Unused parameter
{code:java}
TcpDiscoveryAbstractMessage msg{code}
should be removed from
{code:java}
TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg, byte[]
data, long timeout){code}
This method seems to send raw data, not a message.
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscoverySpi.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13040:
--
Labels: newbie (was: )
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Task
> Environment:
>Reporter: Vladimir Steshin
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13040:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13040:
--
Issue Type: Improvement (was: Task)
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Improvement
> Environment:
>Reporter: Vladimir Steshin
>Priority: Trivial
> Labels: newbie
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12984) Distributed join incorrectly processed when batched:unicast on primary key is used
[
https://issues.apache.org/jira/browse/IGNITE-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114020#comment-17114020
]
Ilya Kasnacheev commented on IGNITE-12984:
--
Do you plan to merge it? I assume the test will fail.
> Distributed join incorrectly processed when batched:unicast on primary key is
> used
> --
>
> Key: IGNITE-12984
> URL: https://issues.apache.org/jira/browse/IGNITE-12984
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Taras Ledkov
>Priority: Major
> Attachments: Issue_with_Distributed_joins.pdf, forDistributedJoins.sql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see attached SQL script and userlist discussion.
> Summary :
> CASE-1 Results: Correct and as expected
> {code}
> SELECT
> __Z0.ID AS __C0_0,
> __Z0.NAME AS __C0_1,
> __Z1.BLOOD_GROUP AS __C0_2,
> __Z2.UNIVERSAL_DONOR AS __C0_3
> FROM PUBLIC.PERSON__Z0
> /* PUBLIC.PERSON_NAME_ASC_IDX_proxy */
> LEFT OUTER JOIN PUBLIC.MEDICAL_INFO __Z1
> /* batched:broadcast PUBLIC.MEDICAL_INFO_NAME_ASC_IDX: NAME = __Z0.NAME */
> ON __Z0.NAME = __Z1.NAME
> LEFT OUTER JOIN PUBLIC.BLOOD_GROUP_INFO_PJ __Z2
> /* batched:broadcast PUBLIC.BLOOD_GROUP_INFO_PJ_BLOOD_GROUP_ASC_IDX:
> BLOOD_GROUP =
> __Z1.BLOOD_GROUP */
> ON __Z1.BLOOD_GROUP = __Z2.BLOOD_GROUP
> {code}
> {code}
> Summary :
> CASE-2 Results: In-correct
> SELECT
> __Z0.ID AS __C0_0,
> __Z0.NAME AS __C0_1,
> __Z1.BLOOD_GROUP AS __C0_2,
> __Z2.UNIVERSAL_DONOR AS __C0_3
> FROM PUBLIC.PERSON __Z0
> /* PUBLIC.PERSON_ID_ASC_IDX_proxy */
> LEFT OUTER JOIN PUBLIC.MEDICAL_INFO __Z1
> /* batched:broadcast PUBLIC.MEDICAL_INFO_NAME_ASC_IDX: NAME = __Z0.NAME */
> ON __Z0.NAME = __Z1.NAME
> LEFT OUTER JOIN PUBLIC.BLOOD_GROUP_INFO_P __Z2
> /* batched:unicast PUBLIC._key_PK_proxy: BLOOD_GROUP = __Z1.BLOOD_GROUP */
> ON __Z1.BLOOD_GROUP = __Z2.BLOOD_GROUP
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114017#comment-17114017
]
Ilya Kasnacheev commented on IGNITE-10970:
--
Looks OK.
Not sure about the alias since MVCC seems to be orphaned now.
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: newbie, usability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114018#comment-17114018
]
Ignite TC Bot commented on IGNITE-10970:
{panel:title=Branch: [pull/7822/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=5326023buildTypeId=IgniteTests24Java8_RunAll]
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: newbie, usability
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET
[
https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113974#comment-17113974
]
Pavel Tupitsyn commented on IGNITE-10075:
-
[~zzzadruga] yes, please go ahead. I have not started yet.
> .NET: Avoid binary configurations of Ignite Java service params and result
> when calling it from Ignite.NET
> --
>
> Key: IGNITE-10075
> URL: https://issues.apache.org/jira/browse/IGNITE-10075
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: MyTest.cs, ignite-10075-vs-2.8.patch
>
>
> Presently if there is an Ignite Java service taking parameters of complex
> (composite) types and returning a result of complex type then all the complex
> types must be explicitly specified in the binary configuration.
> We need to enhance Ignite not to require binary configuration assuming that
> we use the same type, package/namespace and field/property names on both the
> .NET and Java sides (or provide a custom name mapper for relaxed naming
> conventions).
> h2. Reproducer
> h3. ICalculator.java
> {code:java}
> package Sandbox.Net;
> public interface ICalculator {
> Result Calculate(Parameter p);
> }
> {code}
> h3. Parameter.java
> {code:java}
> package Sandbox.Net;
> public class Parameter {
> private int id;
> private double val;
> public int getId() {
> return id;
> }
> public Parameter setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return val;
> }
> public Parameter setValue(double val) {
> this.val = val;
> return this;
> }
> }
> {code}
> h3. Result .java
> {code:java}
> package Sandbox.Net;
> public class Result {
> private int id;
> private double value;
> public int getId() {
> return id;
> }
> public Result setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return value;
> }
> public Result setValue(double val) {
> this.value = val;
> return this;
> }
> }
> {code}
> h3. IgniteCalculatorService.java
> {code:java}
> package Sandbox.Net;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class IgniteCalculatorService implements Service, ICalculator {
> @Override public Result Calculate(Parameter p) {
> return new Result().setId(p.getId()).setValue(p.getValue() *
> p.getValue());
> }
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) {
> }
> @Override public void execute(ServiceContext ctx) {
> }
> }
> {code}
> h3. build.gradle
> {code:groovy}
> plugins {
> id 'java'
> }
> group 'sandbox.net'
> version '1.0-SNAPSHOT'
> sourceCompatibility = 1.8
> repositories {
> mavenLocal()
> mavenCentral()
> }
> def igniteVer='2.8.0'
> dependencies {
> compile group: 'org.apache.ignite', name: 'ignite-core', version:
> igniteVer
> testCompile group: 'junit', name: 'junit', version: '4.12'
> }
> {code}
> h3. ignite-config.xml
> {code:xml}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:47500
>
>
>
>
>
>
>
>
> {code}
> h3. ICalculator.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public interface ICalculator
> {
> Result Calculate(Parameter p);
> }
> }
> {code}
> h3. Parameter.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class Parameter
> {
> public int Id { get; set; }
> public double Value { get; set; }
> }
> }
> {code}
> h3. Result.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class Result
> {
>
[jira] [Commented] (IGNITE-10075) .NET: Avoid binary configurations of Ignite Java service params and result when calling it from Ignite.NET
[
https://issues.apache.org/jira/browse/IGNITE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113973#comment-17113973
]
Nikolai Kulagin commented on IGNITE-10075:
--
[~ptupitsyn], are you working on this ticket? If not, can I assign it to myself?
> .NET: Avoid binary configurations of Ignite Java service params and result
> when calling it from Ignite.NET
> --
>
> Key: IGNITE-10075
> URL: https://issues.apache.org/jira/browse/IGNITE-10075
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: MyTest.cs, ignite-10075-vs-2.8.patch
>
>
> Presently if there is an Ignite Java service taking parameters of complex
> (composite) types and returning a result of complex type then all the complex
> types must be explicitly specified in the binary configuration.
> We need to enhance Ignite not to require binary configuration assuming that
> we use the same type, package/namespace and field/property names on both the
> .NET and Java sides (or provide a custom name mapper for relaxed naming
> conventions).
> h2. Reproducer
> h3. ICalculator.java
> {code:java}
> package Sandbox.Net;
> public interface ICalculator {
> Result Calculate(Parameter p);
> }
> {code}
> h3. Parameter.java
> {code:java}
> package Sandbox.Net;
> public class Parameter {
> private int id;
> private double val;
> public int getId() {
> return id;
> }
> public Parameter setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return val;
> }
> public Parameter setValue(double val) {
> this.val = val;
> return this;
> }
> }
> {code}
> h3. Result .java
> {code:java}
> package Sandbox.Net;
> public class Result {
> private int id;
> private double value;
> public int getId() {
> return id;
> }
> public Result setId(int id) {
> this.id = id;
> return this;
> }
> public double getValue() {
> return value;
> }
> public Result setValue(double val) {
> this.value = val;
> return this;
> }
> }
> {code}
> h3. IgniteCalculatorService.java
> {code:java}
> package Sandbox.Net;
> import org.apache.ignite.services.Service;
> import org.apache.ignite.services.ServiceContext;
> public class IgniteCalculatorService implements Service, ICalculator {
> @Override public Result Calculate(Parameter p) {
> return new Result().setId(p.getId()).setValue(p.getValue() *
> p.getValue());
> }
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) {
> }
> @Override public void execute(ServiceContext ctx) {
> }
> }
> {code}
> h3. build.gradle
> {code:groovy}
> plugins {
> id 'java'
> }
> group 'sandbox.net'
> version '1.0-SNAPSHOT'
> sourceCompatibility = 1.8
> repositories {
> mavenLocal()
> mavenCentral()
> }
> def igniteVer='2.8.0'
> dependencies {
> compile group: 'org.apache.ignite', name: 'ignite-core', version:
> igniteVer
> testCompile group: 'junit', name: 'junit', version: '4.12'
> }
> {code}
> h3. ignite-config.xml
> {code:xml}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>
>
> 127.0.0.1:47500
>
>
>
>
>
>
>
>
> {code}
> h3. ICalculator.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public interface ICalculator
> {
> Result Calculate(Parameter p);
> }
> }
> {code}
> h3. Parameter.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public class Parameter
> {
> public int Id { get; set; }
> public double Value { get; set; }
> }
> }
> {code}
> h3. Result.cs
> {code:c#}
> namespace Sandbox.Net
> {
> public
[jira] [Created] (IGNITE-13063) Bottom-up index rebuild
Maxim Muzafarov created IGNITE-13063: Summary: Bottom-up index rebuild Key: IGNITE-13063 URL: https://issues.apache.org/jira/browse/IGNITE-13063 Project: Ignite Issue Type: Improvement Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov As part of [IEP-22: Direct Data Load|https://cwiki.apache.org/confluence/display/IGNITE/IEP-22%3A+Direct+Data+Load] the PoC needs to be implemented for the new algorithm of rebuilding an index. Compare the approach of the bottom-up index rebuild with the default implementation (from the root). See details in the IEP-22. h4. High-level overview We will not update PK and secondary indexes during the data load, so it is necessary to rebuild them in the end. The most efficient way to build indexes is bottom-up approach, when the lowest level of BTree is built first, and the root is build last. We will need a buffer where indexed values and respective links will be sorted in index order. If the buffer is big enough and all the data fits into it, index will be created in one hop. Otherwise it is necessary to sort indexed values in several runs using an external sort. It is necessary to let users configure sort parameters - buffer size (ideally - in bytes), and the file system path where temp files will be stored. The latter is critical - typically users would like to keep temp files on a separate disk, so that WAL and checkpoint operations are not affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13062) DistributedMetaStoragePersistentTest.testJoinNodeWithLongerHistory failed
Ivan Bessonov created IGNITE-13062:
--
Summary:
DistributedMetaStoragePersistentTest.testJoinNodeWithLongerHistory failed
Key: IGNITE-13062
URL: https://issues.apache.org/jira/browse/IGNITE-13062
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
Reason is a race between transition future and cluster state that this future
modifies.
{code:java}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveStateAsync(GridClusterStateProcessor.java:333)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:295)
at
org.apache.ignite.internal.IgniteKernal.checkClusterState(IgniteKernal.java:4074)
at
org.apache.ignite.internal.IgniteKernal.internalCache(IgniteKernal.java:2692)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest$1.call(GridCommonAbstractTest.java:398)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest$1.call(GridCommonAbstractTest.java:394)
at
org.apache.ignite.testframework.junits.GridAbstractTest.executeOnLocalOrRemoteJvm(GridAbstractTest.java:2036)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.nearEnabled(GridCommonAbstractTest.java:393)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.dht(GridCommonAbstractTest.java:337)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:775)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:577)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:562)
at
org.apache.ignite.internal.processors.metastorage.DistributedMetaStoragePersistentTest.testJoinNodeWithLongerHistory(DistributedMetaStoragePersistentTest.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2127)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13061) Grid could start with one wal segment
Semyon Danilov created IGNITE-13061: --- Summary: Grid could start with one wal segment Key: IGNITE-13061 URL: https://issues.apache.org/jira/browse/IGNITE-13061 Project: Ignite Issue Type: Bug Reporter: Semyon Danilov Assignee: Semyon Danilov For now it is able to set one wal segment in grid config and grid starts fine. It could lead to strange side-effects. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13056) SchemaManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-13056: - Description: Since Ignite wants to leverage from several SQL engines we need to make work with index independent from the used SQL engine. We also should consider moving all machinery related to an index to the core module to make it available from any module that wants to use it. Requirements so far: * Ability to track indexes in several engines was: Since Ignite wants to leverage from several SQL engines we need to make work with index independent from the used SQL engine. We also should consider moving all machinery related to index to the core module to make it available from any module that wants to use it. > SchemaManager refactoring > - > > Key: IGNITE-13056 > URL: https://issues.apache.org/jira/browse/IGNITE-13056 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: calcite > > Since Ignite wants to leverage from several SQL engines we need to make work > with index independent from the used SQL engine. > We also should consider moving all machinery related to an index to the core > module to make it available from any module that wants to use it. > Requirements so far: > * Ability to track indexes in several engines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
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) 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}
3) 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}
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 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}
> 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) 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}
> 3) 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}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13059) When I activate write-behind with RDBMS Ignite isn't starting
[
https://issues.apache.org/jira/browse/IGNITE-13059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113910#comment-17113910
]
Manuel commented on IGNITE-13059:
-
Thank you very much Vyacheslav.
> When I activate write-behind with RDBMS Ignite isn't starting
> -
>
> Key: IGNITE-13059
> URL: https://issues.apache.org/jira/browse/IGNITE-13059
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
> Environment: Microsoft Windows 10
> Apache Ignite 2.8
> MariaDB 10.2
>Reporter: Manuel
>Assignee: Vyacheslav Koptilin
>Priority: Critical
> Labels: Ignite, MySQL, RDBMS, cache, store, write-behind
> Attachments: ImportedCluster3-project (2).zip
>
>
> I 've created a Ignite application for "Automatic RDBMS Support" with version
> 2.8 and when I activate write-behind functionality the Ignite cluster isn't
> working, but, with version 2.7 works perfectly. If I put write-behind to
> false then the app is works correctly. The error is:
> {code:java}
> // marcador de posición de código
> GRAVE: Exception during start processors, node will be stopped and close
> connectionsGRAVE: Exception during start processors, node will be stopped and
> close connectionsjava.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:16){code}
> {code:java}
> may 22, 2020 9:50:35 AM org.apache.ignite.logger.java.JavaLogger errorGRAVE:
> Got exception while starting (will rollback startup
> routine).java.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
>
[jira] [Created] (IGNITE-13060) Tracing: initial implementation
Alexander Lapin created IGNITE-13060: Summary: Tracing: initial implementation Key: IGNITE-13060 URL: https://issues.apache.org/jira/browse/IGNITE-13060 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Assignee: Alexander Lapin Initial tracing implementation. See [IEP-48|https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing] for details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13059) When I activate write-behind with RDBMS Ignite isn't starting
[
https://issues.apache.org/jira/browse/IGNITE-13059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-13059.
--
Resolution: Duplicate
> When I activate write-behind with RDBMS Ignite isn't starting
> -
>
> Key: IGNITE-13059
> URL: https://issues.apache.org/jira/browse/IGNITE-13059
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
> Environment: Microsoft Windows 10
> Apache Ignite 2.8
> MariaDB 10.2
>Reporter: Manuel
>Assignee: Vyacheslav Koptilin
>Priority: Critical
> Labels: Ignite, MySQL, RDBMS, cache, store, write-behind
> Attachments: ImportedCluster3-project (2).zip
>
>
> I 've created a Ignite application for "Automatic RDBMS Support" with version
> 2.8 and when I activate write-behind functionality the Ignite cluster isn't
> working, but, with version 2.7 works perfectly. If I put write-behind to
> false then the app is works correctly. The error is:
> {code:java}
> // marcador de posición de código
> GRAVE: Exception during start processors, node will be stopped and close
> connectionsGRAVE: Exception during start processors, node will be stopped and
> close connectionsjava.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:16){code}
> {code:java}
> may 22, 2020 9:50:35 AM org.apache.ignite.logger.java.JavaLogger errorGRAVE:
> Got exception while starting (will rollback startup
> routine).java.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
>
[jira] [Commented] (IGNITE-13059) When I activate write-behind with RDBMS Ignite isn't starting
[
https://issues.apache.org/jira/browse/IGNITE-13059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113871#comment-17113871
]
Vyacheslav Koptilin commented on IGNITE-13059:
--
Hi [~manueltg89],
It looks like the issue is already resolved. Please take a look at IGNITE-12805
You can try using 2.8.1 RC (which will be released soon), for instance, in
order to be sure that the issue has gone.
Dev list discussion related to 2.8.1
[http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-1-RELEASE-Time-Scope-Manager-td46452.html]
Thanks,
S.
> When I activate write-behind with RDBMS Ignite isn't starting
> -
>
> Key: IGNITE-13059
> URL: https://issues.apache.org/jira/browse/IGNITE-13059
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
> Environment: Microsoft Windows 10
> Apache Ignite 2.8
> MariaDB 10.2
>Reporter: Manuel
>Assignee: Vyacheslav Koptilin
>Priority: Critical
> Labels: Ignite, MySQL, RDBMS, cache, store, write-behind
> Attachments: ImportedCluster3-project (2).zip
>
>
> I 've created a Ignite application for "Automatic RDBMS Support" with version
> 2.8 and when I activate write-behind functionality the Ignite cluster isn't
> working, but, with version 2.7 works perfectly. If I put write-behind to
> false then the app is works correctly. The error is:
> {code:java}
> // marcador de posición de código
> GRAVE: Exception during start processors, node will be stopped and close
> connectionsGRAVE: Exception during start processors, node will be stopped and
> close connectionsjava.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:16){code}
> {code:java}
> may 22, 2020 9:50:35 AM org.apache.ignite.logger.java.JavaLogger errorGRAVE:
> Got exception while starting (will rollback startup
> routine).java.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
>
[jira] [Commented] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113872#comment-17113872
]
Nikolai Kulagin commented on IGNITE-12823:
--
[~ptupitsyn], please, review my change.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Nikolai Kulagin
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13059) When I activate write-behind with RDBMS Ignite isn't starting
[
https://issues.apache.org/jira/browse/IGNITE-13059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-13059:
Assignee: Vyacheslav Koptilin
> When I activate write-behind with RDBMS Ignite isn't starting
> -
>
> Key: IGNITE-13059
> URL: https://issues.apache.org/jira/browse/IGNITE-13059
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
> Environment: Microsoft Windows 10
> Apache Ignite 2.8
> MariaDB 10.2
>Reporter: Manuel
>Assignee: Vyacheslav Koptilin
>Priority: Critical
> Labels: Ignite, MySQL, RDBMS, cache, store, write-behind
> Attachments: ImportedCluster3-project (2).zip
>
>
> I 've created a Ignite application for "Automatic RDBMS Support" with version
> 2.8 and when I activate write-behind functionality the Ignite cluster isn't
> working, but, with version 2.7 works perfectly. If I put write-behind to
> false then the app is works correctly. The error is:
> {code:java}
> // marcador de posición de código
> GRAVE: Exception during start processors, node will be stopped and close
> connectionsGRAVE: Exception during start processors, node will be stopped and
> close connectionsjava.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:16){code}
> {code:java}
> may 22, 2020 9:50:35 AM org.apache.ignite.logger.java.JavaLogger errorGRAVE:
> Got exception while starting (will rollback startup
> routine).java.lang.NullPointerException at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
> at
> org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
>
[jira] [Created] (IGNITE-13059) When I activate write-behind with RDBMS Ignite isn't starting
Manuel created IGNITE-13059:
---
Summary: When I activate write-behind with RDBMS Ignite isn't
starting
Key: IGNITE-13059
URL: https://issues.apache.org/jira/browse/IGNITE-13059
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.8
Environment: Microsoft Windows 10
Apache Ignite 2.8
MariaDB 10.2
Reporter: Manuel
Attachments: ImportedCluster3-project (2).zip
I 've created a Ignite application for "Automatic RDBMS Support" with version
2.8 and when I activate write-behind functionality the Ignite cluster isn't
working, but, with version 2.7 works perfectly. If I put write-behind to false
then the app is works correctly. The error is:
{code:java}
// marcador de posición de código
GRAVE: Exception during start processors, node will be stopped and close
connectionsGRAVE: Exception during start processors, node will be stopped and
close connectionsjava.lang.NullPointerException at
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
org.apache.ignite.Ignition.start(Ignition.java:321) at
startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:16){code}
{code:java}
may 22, 2020 9:50:35 AM org.apache.ignite.logger.java.JavaLogger errorGRAVE:
Got exception while starting (will rollback startup
routine).java.lang.NullPointerException at
org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1374)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$CachePredicate.dataNode(GridDiscoveryManager.java:3205)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.cacheAffinityNode(GridDiscoveryManager.java:1894)
at
org.apache.ignite.internal.processors.cache.ValidationOnNodeJoinUtils.validate(ValidationOnNodeJoinUtils.java:330)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1201)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheInRecoveryMode(GridCacheProcessor.java:2291)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1700(GridCacheProcessor.java:202)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.afterBinaryMemoryRestore(GridCacheProcessor.java:5387)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreBinaryMemory(GridCacheDatabaseSharedManager.java:1075)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:2068)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1254) at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
org.apache.ignite.Ignition.start(Ignition.java:321) at
startup.ServerNodeCodeStartup.main(ServerNodeCodeStartup.java:16)
{code}
--
This
[jira] [Updated] (IGNITE-13056) SchemaManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-13056: - Description: Since Ignite wants to leverage from several SQL engines we need to make work with index independent from the used SQL engine. We also should consider moving all machinery related to index to the core module to make it available from any module that wants to use it. was: Since Ignite wants to leverage from several SQL engines we need to make SchemaManager independent from H2. We also should consider moving it to the core module to make it available from any module that wants to use it. > SchemaManager refactoring > - > > Key: IGNITE-13056 > URL: https://issues.apache.org/jira/browse/IGNITE-13056 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: calcite > > Since Ignite wants to leverage from several SQL engines we need to make work > with index independent from the used SQL engine. > We also should consider moving all machinery related to index to the core > module to make it available from any module that wants to use it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113831#comment-17113831 ] Maxim Muzafarov commented on IGNITE-10959: -- Folks, This issue was completely out of our radar. It's sad to hear that it affects so use cases. I'll try to investigate the issue shortly, right after finishing [IEP-43: Cluster snapshots|https://cwiki.apache.org/confluence/display/IGNITE/IEP-43%3A+Cluster+snapshots] retated tasks. Will keep you it touch. > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Maxim Muzafarov >Priority: Critical > Attachments: CacheContinuousQueryMemoryUsageTest.java, > CacheContinuousQueryMemoryUsageTest.result, > CacheContinuousQueryMemoryUsageTest2.java, continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12780) Deadlock between db-checkpoint-thread and checkpoint-runner
[
https://issues.apache.org/jira/browse/IGNITE-12780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113822#comment-17113822
]
Ignite TC Bot commented on IGNITE-12780:
{panel:title=Branch: [pull/7816/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=5323308buildTypeId=IgniteTests24Java8_RunAll]
> Deadlock between db-checkpoint-thread and checkpoint-runner
> ---
>
> Key: IGNITE-12780
> URL: https://issues.apache.org/jira/browse/IGNITE-12780
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Look at this run:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexing/5121878?buildTab=log=3
> {noformat}
> "db-checkpoint-thread-#46926%db.IgniteSequentialNodeCrashRecoveryTest0%"
> #55580 prio=5 os_prio=0 tid=0x7efb2000c800 nid=0x77e waiting on condition
> [0x7eff31add000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.fillCacheGroupState(GridCacheDatabaseSharedManager.java:4367)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:4147)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3728)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:3617)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
>
>
> "checkpoint-runner-#46927%db.IgniteSequentialNodeCrashRecoveryTest0%" #55581
> prio=5 os_prio=0 tid=0x7efbd4009000 nid=0x77f waiting on condition
> [0x7eff317da000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xe5c23ed8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1645)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1688)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:2061)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.lambda$fillCacheGroupState$1(GridCacheDatabaseSharedManager.java:4336)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer$$Lambda$565/253081186.run(Unknown
> Source)
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$wrapIgniteFuture$3(IgniteUtils.java:11392)
> at
> org.apache.ignite.internal.util.IgniteUtils$$Lambda$561/471384364.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I suspect this issue happening due to IgniteSequentialNodeCrashRecoveryTest
--
This message was sent by
[jira] [Commented] (IGNITE-10100) Add public Java API to call Ignite.NET services
[
https://issues.apache.org/jira/browse/IGNITE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113800#comment-17113800
]
Vyacheslav Daradur commented on IGNITE-10100:
-
[~alex_pl], please go forward if you have already reviewed the pr.
> Add public Java API to call Ignite.NET services
> ---
>
> Key: IGNITE-10100
> URL: https://issues.apache.org/jira/browse/IGNITE-10100
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, sbcf
> Fix For: 2.9
>
> Attachments: ignite-10100-vs-2.8.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Ignite wraps .NET services in PlatformDotNetServiceImpl implementing
> PlatformService interface.
> PlatformService is defined in internal Ignite package
> apache.ignite.internal.processors.platform.services. It exposes
> {{ invokeMethod(methodName, Object[] params): Object}}
> to call any service method dynamically. Right now there is no Ignite public
> API to call a PlatformService using static typing.
> We need to develop a public API to call PlatformDotNetServiceImpl using
> static typing in Java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13058) GridCommandHandlerTest.testKillHangingRemoteTransactions failed
Ivan Bessonov created IGNITE-13058:
--
Summary: GridCommandHandlerTest.testKillHangingRemoteTransactions
failed
Key: IGNITE-13058
URL: https://issues.apache.org/jira/browse/IGNITE-13058
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
Test may fail if not all clients completed local cache start routine.
{code:java}
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:712)
at org.junit.Assert.assertNotNull(Assert.java:722)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertNotNull(JUnitAssertAware.java:178)
at
org.apache.ignite.util.GridCommandHandlerTest.testKillHangingRemoteTransactions(GridCommandHandlerTest.java:1044)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2127)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
