[jira] [Assigned] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.
[ https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saikat Maitra reassigned IGNITE-8697: - Assignee: Saikat Maitra > Flink sink throws java.lang.IllegalArgumentException when running in flink > cluster mode. > > > Key: IGNITE-8697 > URL: https://issues.apache.org/jira/browse/IGNITE-8697 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Ray >Assignee: Saikat Maitra >Priority: Blocker > > if I submit the Application to the Flink Cluster using Ignite flink sink I > get this error > > java.lang.ExceptionInInitializerError > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201) > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175) > at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165) > at > org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52) > at > org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657) > at > org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51) > at > org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97) > at > org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1) > at > org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657) > at > org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104) > at > org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110) > at > org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87) > at > org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56) > at > org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99) > at > org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306) > at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: > Cache name must not be null or empty. > at > org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581) > at > org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284) > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.java:183) > ... 27 more -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.
[ https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546002#comment-16546002 ] Saikat Maitra commented on IGNITE-8697: --- Hi [~ldz], Thank you for validating the changes, I see that in cluster mode when I am checking the IgniteSink it is working as desired. In stand alone mode I can see we are getting the exception class org.apache.ignite.IgniteException: Default Ignite instance has already been started. Please take a look into this sample application https://github.com/samaitra/streamers which I used to run it with flink in cluster mode. I am considering if I should make changes to run the IgniteSink in client mode similar to the ways flink connector for redis and flume were implemented in Apache Bahir https://github.com/apache/bahir-flink I will share update soon. Regards, Saikat > Flink sink throws java.lang.IllegalArgumentException when running in flink > cluster mode. > > > Key: IGNITE-8697 > URL: https://issues.apache.org/jira/browse/IGNITE-8697 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4, 2.5 >Reporter: Ray >Priority: Blocker > > if I submit the Application to the Flink Cluster using Ignite flink sink I > get this error > > java.lang.ExceptionInInitializerError > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201) > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175) > at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165) > at > org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52) > at > org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657) > at > org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51) > at > org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97) > at > org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1) > at > org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535) > at > org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679) > at > org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657) > at > org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104) > at > org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110) > at > org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87) > at > org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56) > at > org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99) > at > org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306) > at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: > Cache name must not be null or empty. > at > org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581) > at > org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284) > at > org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.ja
[jira] [Comment Edited] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.
[
https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545977#comment-16545977
]
Ray edited comment on IGNITE-8697 at 7/17/18 3:09 AM:
--
[~samaitra]
I tried your newest code and wrote a simple word count application to test
the sink.
It appears there's still problems.
Here's my code.
{code:java}
import org.apache.flink.api.scala._
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.streaming.api.scala.extensions._
import org.apache.flink.configuration.Configuration
import org.apache.ignite.Ignition
import org.apache.ignite.configuration.CacheConfiguration
import scala.collection.JavaConverters._
object WordCount {
def main(args: Array[String]) {
val env = StreamExecutionEnvironment.getExecutionEnvironment
val igniteSink = new IgniteSink[java.util.Map[String, Int]]("aaa",
"ignite.xml")
igniteSink.setAllowOverwrite(false)
igniteSink.setAutoFlushFrequency(1)
igniteSink.open(new Configuration)
// get input data
val text = env.fromElements(
"To be, or not to be,--that is the question:--",
"Whether 'tis nobler in the mind to suffer",
"The slings and arrows of outrageous fortune",
"Or to take arms against a sea of troubles,")
val counts = text
// split up the lines in pairs (2-tuples) containing: (word,1)
.flatMap(_.toLowerCase.split("\\W+"))
.filter(_.nonEmpty)
.map((_, 1))
// group by the tuple field "0" and sum up tuple field "1"
.keyBy(0)
.sum(1)
// Convert to key/value format before ingesting to Ignite
.mapWith { case (k: String, v: Int) => Map(k -> v).asJava }
.addSink(igniteSink)
try
env.execute("Streaming WordCount1")
catch {
case e: Exception =>
// Exception handling.
} finally igniteSink.close()
}
}
{code}
I tried running this application in Idea and the error log snippet is as
follows
07/16/2018 11:05:30 aggregation -> Map -> Sink: Unnamed(4/8) switched to
FAILED
class org.apache.ignite.IgniteException: Default Ignite instance has already
been started.
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:990)
at org.apache.ignite.Ignition.start(Ignition.java:355)
at IgniteSink.open(IgniteSink.java:135)
at
org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36)
at
org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:111)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:376)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:253)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:702)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Default Ignite
instance has already been started.
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1134)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:693)
at org.apache.ignite.Ignition.start(Ignition.java:352)
... 7 more
07/16/2018 11:05:30 Job execution switched to status FAILING.
was (Author: ldz):
[~samaitra]
I tried your newest code and wrote a simple word count application to test
the sink.
It appears there's still problems.
Here's my code.
import org.apache.flink.api.scala._
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.streaming.api.scala.extensions._
import org.apache.flink.configuration.Configuration
import org.apache.ignite.Ignition
import org.apache.ignite.configuration.CacheConfiguration
import scala.collection.JavaConverters._
object WordCount {
def main(args: Array[String])
{
val env = StreamExecutionEnvironment.getExecutionEnvironment
val igniteSink = new IgniteSink[java.util.Map[String, Int]]("aaa", "ignite.xml")
igniteSink.setAllowOverwrite(false)
igniteSink.setAutoFlushFrequency(1)
igniteSink.open(new Configuration)
// get input data
val text = env.fromElements(
"To be, or not to be,--that is the question:--",
"Whether 'tis nobler in the mind to suffer",
"The slings and arrows of outrageous fortune",
"Or to take arms against a sea of troubles,")
val count
[jira] [Comment Edited] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.
[
https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545977#comment-16545977
]
Ray edited comment on IGNITE-8697 at 7/17/18 3:07 AM:
--
[~samaitra]
I tried your newest code and wrote a simple word count application to test
the sink.
It appears there's still problems.
Here's my code.
import org.apache.flink.api.scala._
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.streaming.api.scala.extensions._
import org.apache.flink.configuration.Configuration
import org.apache.ignite.Ignition
import org.apache.ignite.configuration.CacheConfiguration
import scala.collection.JavaConverters._
object WordCount {
def main(args: Array[String])
{
val env = StreamExecutionEnvironment.getExecutionEnvironment
val igniteSink = new IgniteSink[java.util.Map[String, Int]]("aaa", "ignite.xml")
igniteSink.setAllowOverwrite(false)
igniteSink.setAutoFlushFrequency(1)
igniteSink.open(new Configuration)
// get input data
val text = env.fromElements(
"To be, or not to be,--that is the question:--",
"Whether 'tis nobler in the mind to suffer",
"The slings and arrows of outrageous fortune",
"Or to take arms against a sea of troubles,")
val counts = text
// split up the lines in pairs (2-tuples) containing: (word,1)
.flatMap(_.toLowerCase.split("\\W+"))
.filter(_.nonEmpty)
.map((_, 1))
// group by the tuple field "0" and sum up tuple field "1"
.keyBy(0)
.sum(1)
// Convert to key/value format before ingesting to Ignite
.mapWith \{ case (k: String, v: Int) => Map(k -> v).asJava }
.addSink(igniteSink)
try
env.execute("Streaming WordCount1")
catch {
case e: Exception =>
// Exception handling.
} finally igniteSink.close()
}
}
I tried running this application in Idea and the error log snippet is as
follows
07/16/2018 11:05:30 aggregation -> Map -> Sink: Unnamed(4/8) switched to
FAILED
class org.apache.ignite.IgniteException: Default Ignite instance has already
been started.
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:990)
at org.apache.ignite.Ignition.start(Ignition.java:355)
at IgniteSink.open(IgniteSink.java:135)
at
org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36)
at
org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:111)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:376)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:253)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:702)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Default Ignite
instance has already been started.
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1134)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:693)
at org.apache.ignite.Ignition.start(Ignition.java:352)
... 7 more
07/16/2018 11:05:30 Job execution switched to status FAILING.
was (Author: ldz):
[~samaitra]
I tried your newest code and wrote a simple word count application to test
the sink.
It appears there's still problems.
Here's my code.
import org.apache.flink.api.scala._
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.streaming.api.scala.extensions._
import org.apache.flink.configuration.Configuration
import org.apache.ignite.Ignition
import org.apache.ignite.configuration.CacheConfiguration
import scala.collection.JavaConverters._
object WordCount {
def main(args: Array[String]) {
val ignite = Ignition.start("ignite.xml")
val cacheConfig = new CacheConfiguration[Any, Any]()
ignite.destroyCache("aaa")
cacheConfig.setName("aaa")
cacheConfig.setSqlSchema("PUBLIC")
ignite.createCache(cacheConfig)
ignite.close()
// set up the execution environment
val env = StreamExecutionEnvironment.getExecutionEnvironment
val igniteSink = new IgniteSink[java.util.Map[String,
Int]]("aaa",
"ignite.xml")
igniteSink.setAllowOverwrite(false)
igniteSink.setAutoFlushFrequency(1)
[jira] [Commented] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.
[
https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545977#comment-16545977
]
Ray commented on IGNITE-8697:
-
[~samaitra]
I tried your newest code and wrote a simple word count application to test
the sink.
It appears there's still problems.
Here's my code.
import org.apache.flink.api.scala._
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.streaming.api.scala.extensions._
import org.apache.flink.configuration.Configuration
import org.apache.ignite.Ignition
import org.apache.ignite.configuration.CacheConfiguration
import scala.collection.JavaConverters._
object WordCount {
def main(args: Array[String]) {
val ignite = Ignition.start("ignite.xml")
val cacheConfig = new CacheConfiguration[Any, Any]()
ignite.destroyCache("aaa")
cacheConfig.setName("aaa")
cacheConfig.setSqlSchema("PUBLIC")
ignite.createCache(cacheConfig)
ignite.close()
// set up the execution environment
val env = StreamExecutionEnvironment.getExecutionEnvironment
val igniteSink = new IgniteSink[java.util.Map[String,
Int]]("aaa",
"ignite.xml")
igniteSink.setAllowOverwrite(false)
igniteSink.setAutoFlushFrequency(1)
igniteSink.open(new Configuration)
// get input data
val text = env.fromElements(
"To be, or not to be,--that is the question:--",
"Whether 'tis nobler in the mind to suffer",
"The slings and arrows of outrageous fortune",
"Or to take arms against a sea of troubles,")
val counts = text
// split up the lines in pairs (2-tuples) containing:
(word,1)
.flatMap(_.toLowerCase.split("\\W+"))
.filter(_.nonEmpty)
.map((_, 1))
// group by the tuple field "0" and sum up tuple field
"1"
.keyBy(0)
.sum(1)
// Convert to key/value format before ingesting to
Ignite
.mapWith \{ case (k: String, v: Int) => Map(k ->
v).asJava }
.addSink(igniteSink)
try
env.execute("Streaming WordCount1")
catch {
case e: Exception =>
// Exception handling.
} finally igniteSink.close()
}
}
I tried running this application in Idea and the error log snippet is as
follows
07/16/2018 11:05:30 aggregation -> Map -> Sink: Unnamed(4/8) switched to
FAILED
class org.apache.ignite.IgniteException: Default Ignite instance has already
been started.
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:990)
at org.apache.ignite.Ignition.start(Ignition.java:355)
at IgniteSink.open(IgniteSink.java:135)
at
org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36)
at
org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:111)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:376)
at
org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:253)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:702)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Default Ignite
instance has already been started.
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1134)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1069)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:955)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:854)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:724)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:693)
at org.apache.ignite.Ignition.start(Ignition.java:352)
... 7 more
07/16/2018 11:05:30 Job execution switched to status FAILING.
> Flink sink throws java.lang.IllegalArgumentException when running in flink
> cluster mode.
>
>
> Key: IGNITE-8697
> URL: https://issues.apache.org/jira/browse/IGNITE-8697
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Re
[jira] [Closed] (IGNITE-8653) Elaborate on split brain and failures handling with ZooKeeper Discovery
[ https://issues.apache.org/jira/browse/IGNITE-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8653. --- > Elaborate on split brain and failures handling with ZooKeeper Discovery > --- > > Key: IGNITE-8653 > URL: https://issues.apache.org/jira/browse/IGNITE-8653 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > Attachments: Zookeeper Discovery SPI - Split Brain 2.png, Zookeeper > Discovery SPI - Split Brain.png, Zookeeper Discovery SPI - ZooKeeper > Cluster.png > > > Split-brain and failures handling section don't do a good job explaining how > these scenarios are handled: > https://apacheignite.readme.io/docs/zookeeper-discovery#section-failures-and-split-brain-handling > This needs to be improved. Consider using the graphics attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8653) Elaborate on split brain and failures handling with ZooKeeper Discovery
[ https://issues.apache.org/jira/browse/IGNITE-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-8653: --- Assignee: Denis Magda (was: Prachi Garg) > Elaborate on split brain and failures handling with ZooKeeper Discovery > --- > > Key: IGNITE-8653 > URL: https://issues.apache.org/jira/browse/IGNITE-8653 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > Attachments: Zookeeper Discovery SPI - Split Brain 2.png, Zookeeper > Discovery SPI - Split Brain.png, Zookeeper Discovery SPI - ZooKeeper > Cluster.png > > > Split-brain and failures handling section don't do a good job explaining how > these scenarios are handled: > https://apacheignite.readme.io/docs/zookeeper-discovery#section-failures-and-split-brain-handling > This needs to be improved. Consider using the graphics attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8653) Elaborate on split brain and failures handling with ZooKeeper Discovery
[ https://issues.apache.org/jira/browse/IGNITE-8653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545703#comment-16545703 ] Prachi Garg commented on IGNITE-8653: - Looks Good. Thanks [~Artem Budnikov]. > Elaborate on split brain and failures handling with ZooKeeper Discovery > --- > > Key: IGNITE-8653 > URL: https://issues.apache.org/jira/browse/IGNITE-8653 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.7 > > Attachments: Zookeeper Discovery SPI - Split Brain 2.png, Zookeeper > Discovery SPI - Split Brain.png, Zookeeper Discovery SPI - ZooKeeper > Cluster.png > > > Split-brain and failures handling section don't do a good job explaining how > these scenarios are handled: > https://apacheignite.readme.io/docs/zookeeper-discovery#section-failures-and-split-brain-handling > This needs to be improved. Consider using the graphics attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8994: --- Assignee: Denis Magda (was: Ilya Murchenko) > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > Attachments: yaml.zip > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8993: --- Assignee: Denis Magda (was: Ilya Murchenko) > Configuring sticky LoadBalancer for Ignite Service with Kubernetes > -- > > Key: IGNITE-8993 > URL: https://issues.apache.org/jira/browse/IGNITE-8993 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > Attachments: ignite-service.yaml > > > Ignite service used for Ignite pods auto-discovery and access to the cluster > from remote applications is deployed as LoadBalancer: > https://apacheignite.readme.io/docs/ignite-service > This might lead to problems when a stateful session is needed between an app > and the cluster. For instance, Ignite JDBC driver preserves the state of an > opened connection meaning that once LoadBalancer connects the driver to an > Ignite pod, all the queries have to be redirected to that Ignite pod only > (unless the pod is down). > We need to show how to configure a sticky LoadBalancer that will assign a > client connection to a specific pod and won't change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-9013:
-
Assignee: Eduard Shangareev
> Node stop hangs if there was cache activities in Service Processor
> --
>
> Key: IGNITE-9013
> URL: https://issues.apache.org/jira/browse/IGNITE-9013
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> I have found this issue while running
> IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
> And test hanged with:
> {code}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
> at
> org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0x273d> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> {code}
> "srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
> tid=0x3d9 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove(GridCacheAdapter.java:2932)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1897)
>
[jira] [Updated] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9013:
--
Labels: MakeTeamcityGreenAgain (was: )
> Node stop hangs if there was cache activities in Service Processor
> --
>
> Key: IGNITE-9013
> URL: https://issues.apache.org/jira/browse/IGNITE-9013
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> I have found this issue while running
> IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
> And test hanged with:
> {code}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
> at
> org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
> - locked <0x273d> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {code}
> {code}
> "srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
> tid=0x3d9 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove(GridCacheAdapter.java:2932)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1897)
> at
> org.apache.ignite.intern
[jira] [Updated] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
[
https://issues.apache.org/jira/browse/IGNITE-9013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9013:
--
Description:
I have found this issue while running
IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
And test hanged with:
{code}
"main@1" prio=5 tid=0x1 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
at
java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
at
org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
- locked <0x273d> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
at
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{code}
{code}
"srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
tid=0x3d9 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove(GridCacheAdapter.java:2932)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1897)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2076)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
was:
I have found this issue while running
IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
And test hanged with:
{code}
"main@1" prio=5 tid=0x1 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.loc
[jira] [Updated] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9012:
--
Labels: MakeTeamcityGreenAgain (was: )
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9013) Node stop hangs if there was cache activities in Service Processor
Eduard Shangareev created IGNITE-9013:
-
Summary: Node stop hangs if there was cache activities in Service
Processor
Key: IGNITE-9013
URL: https://issues.apache.org/jira/browse/IGNITE-9013
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
I have found this issue while running
IgniteServiceReassignmentTest#testZombieAssignmentsCleanup.
And test hanged with:
{code}
"main@1" prio=5 tid=0x1 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at
java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
at
java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:675)
at
org.apache.ignite.internal.util.IgniteUtils.shutdownNow(IgniteUtils.java:4749)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStop(GridServiceProcessor.java:327)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2130)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2077)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2595)
- locked <0x273d> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2558)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:374)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1088)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1131)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1109)
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.afterTest(IgniteServiceReassignmentTest.java:82)
at
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
at
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:54)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{code}
{code}
"srvc-deploy-#811%service.IgniteServiceReassignmentTest2%@5000" prio=5
tid=0x3d9 nid=NA waiting
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$37.op(GridCacheAdapter.java:2959)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4150)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove0(GridCacheAdapter.java:2948)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAndRemove(GridCacheAdapter.java:2932)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1897)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2076)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6500) POJO fields of java wrapper type are not retaining null values from Cassandra persistent store, while using ignite's CassandraCacheStoreFactory
[
https://issues.apache.org/jira/browse/IGNITE-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545478#comment-16545478
]
Dmitriy Pavlov commented on IGNITE-6500:
Hi [~irudyak], it seems stuck in our review process. Could you advice somebody
who can pick up and finalize review?
> POJO fields of java wrapper type are not retaining null values from Cassandra
> persistent store, while using ignite's CassandraCacheStoreFactory
> ---
>
> Key: IGNITE-6500
> URL: https://issues.apache.org/jira/browse/IGNITE-6500
> Project: Ignite
> Issue Type: Bug
> Components: cassandra
>Affects Versions: 2.1
>Reporter: Yashasvi Kotamraju
>Assignee: Yashasvi Kotamraju
>Priority: Minor
> Labels: patch
> Fix For: 2.7
>
>
> While using ignite's CassandraCacheStoreFactory(part of
> ignite-cassandra-store.jar) as cacheStoreFactory for a cache, if a POJO field
> is of wrapper class type, and the column value mapped in Cassandra persistent
> store is null then the POJO field is getting set to default primitive type
> instead of null.
> For Example: Assume a table 'person' in a Cassandra persistent store with the
> following structure and data.
> *table person:*
> *column*person_no(int)phno(text) address(text) age(int)
> name(text)
> *data* 1 12353 null
> nullyash
> person_no is the PRIMARY_KEY.
> This table is mapped to person POJO for ignite cache.
> public class person{
> private int person_no;
> private String name;
> private Integer age=null;
> private String phno;
> private String address;
> .getters and setters etc..
> }
> Now we load the row from Cassandra into ignite cache using cache.get(1) or
> cache.load(..) And we are using ignite's CassandraCacheStoreFactory for this
> cache.
> Let person p1 = cache.get(1);
> now p1.getName returns "yash", p1.getAddress returns null.
> But p1.getAge returns 0 instead of null. It is expected null value since the
> value is null in Cassandra persistent store.
> Hence if the value is 0 for the age field there is no way differentiate if it
> was null or it was actually 0. The similar problem exists for other wrapper
> types -> Long, Float, Double, Boolean.
> This problem cause is as follows.
> In
> org.apache.ignite.cache.store.cassandra.persistence.PojoField.setValueFromRow(..)
> method first the Cassandra field value is obtained by using the method
> PropertyMappingHelper.getCassandraColumnValue(..). This method calls DataStax
> Driver methods Row.getInt() or Row.getFloat() or Row.getDouble() etc..
> depending upon the column. This value obtained from this method is then set
> to the respective POJO field. But According to Datastax documentation getInt
> returns 0 if column value is null and similarly getLong returns 0L ,
> getDouble return 0.0 etc. Hence PropertyMappingHelper.
> getCassandraColumnValue returns 0 or 0L or 0.0 or false even if the value is
> null. And then this value is set to the wrapper type POJO fields. The problem
> only persists with the primitive data types in Cassandra mapped to wrapper
> type fields in POJO. For other types like String , Date etc.. the null values
> are retained in the POJO fields.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7165) Re-balancing is cancelled if client node joins
[ https://issues.apache.org/jira/browse/IGNITE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545429#comment-16545429 ] ASF GitHub Bot commented on IGNITE-7165: GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/4368 IGNITE-7165 Rebalance control version holds by exchange thread You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite av-ignit-7165-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4368.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4368 commit e7a80e64da07af5c43c15fd5a7b1abe14d387057 Author: Maxim Muzafarov Date: 2018-05-30T16:46:06Z IGNITE-7165: add fix by suggestions AV commit 9f7551c15ff62c187422095c0626200245c36a36 Author: Maxim Muzafarov Date: 2018-05-30T16:49:01Z IGNITE-7165: revert some commit 0ab2d301bd5a100f8dcf1ef964786264ebee6b0a Author: Maxim Muzafarov Date: 2018-05-30T17:39:04Z IGNITE-7165: changes due to else if commit 0d37670990f6546202771313ba0869bd2b709ad4 Author: Maxim Muzafarov Date: 2018-06-07T12:56:45Z Merge branch 'master' into av-ignite-7165 commit 7673f1afdb7eaa79d4e03ee16083ee5ea4b92290 Author: Maxim Muzafarov Date: 2018-06-07T14:29:51Z IGNITE-7165: add assignments calculations compare commit ce2ea0b397f416a764681259911adf04fa397d61 Author: Maxim Muzafarov Date: 2018-06-07T20:28:09Z IGNITE-7165: hasPendingExchanges flag to start rebalance commit 9f5d9f7871ba9cff079a76097bb4f269fd7f7a5b Author: Maxim Muzafarov Date: 2018-06-07T20:30:39Z IGNITE-7165: rename rebalance assingns needs commit 4dcb6270d026f36fb7b3ae2b904ce36bc633ac55 Author: Maxim Muzafarov Date: 2018-06-07T20:35:29Z IGNITE-7165: javadoc commit cccdd69b86ebcce1626dfc9416f32f88e708d4e9 Author: Maxim Muzafarov Date: 2018-06-08T15:06:39Z IGNITE-7165: remove skip rebalance twice commit 3410aaca6298be1b3b26c5202b43a1b787123396 Author: Maxim Muzafarov Date: 2018-06-10T13:50:00Z IGNITE-7165: calculate assigns on last running topology version commit 5f98a480a07d2c0504a60763da482c2792540719 Author: Maxim Muzafarov Date: 2018-06-19T11:00:32Z Merge branch 'master' into av-ignite-7165 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPreloader.java commit cfb9574d65f64660f36689789b0090ef0be50fcb Author: Maxim Muzafarov Date: 2018-06-20T16:48:28Z IGNITE-7165: keep last rebalance topology version commit d15515f3ee83455697dead6ff39e75dafebcfd76 Author: Maxim Muzafarov Date: 2018-06-20T17:10:11Z IGNITE-7165: return last rebalance topology version commit d0d47eb0eda31165f5c8f1e53ef92ecf82d9c548 Author: Maxim Muzafarov Date: 2018-06-21T10:29:15Z IGNITE-7165: default value for rebalance topVer should be null commit 68d53d7c317ee676c08d45b6a4be360bb4659fb7 Author: Maxim Muzafarov Date: 2018-06-21T10:30:56Z Merge branch 'master' into av-ignite-7165 commit 4cf7c72e9db55d47a305f93c649d29e6557354e2 Author: Maxim Muzafarov Date: 2018-06-21T10:33:55Z IGNITE-7165: debug messages for update topology version commit 7bd0be89c66bf5bf78f88c5e30d32c70c79a5fcd Author: Maxim Muzafarov Date: 2018-06-22T09:11:33Z ignite-7165: skip if null commit 4b2e232c0d97452986fe79f6c33ec62e5b9ad9a7 Author: Maxim Muzafarov Date: 2018-06-22T09:46:34Z ignite-7165: java doc update commit 682194b1597a91a86c4b3546a8f3726bdae07254 Author: Maxim Muzafarov Date: 2018-06-22T12:20:11Z ignite-7165: move latest ver to rebalance future commit d9fbea3af09478332347181c3f2b330541a7e7b5 Author: Maxim Muzafarov Date: 2018-06-22T14:29:06Z ignite-7165: use get topology version method commit 15d90b01535c9e199286b6cd5cdd16e0eb28e76e Author: Maxim Muzafarov Date: 2018-06-22T14:39:21Z ignite-7165: fix javadoc exchange commit 9568763143cf136cfc4e15ab4076f654c9f78131 Author: Maxim Muzafarov Date: 2018-06-22T14:47:16Z ignite-7165: remove unnecessary topology check commit 648ab2df71f4a06e59843371181ba0c075efed2f Author: Maxim Muzafarov Date: 2018-06-22T14:51:34Z ignite-7165: java doc fix 2 commit 84d4cfa4b08226f8d2ad8cb163dd3015675692ec Author: Maxim Muzafarov Date: 2018-06-22T15:00:04Z ignite-7165: force rebalance routine commit 38218eeea65574c8d3965fddaf2b037e60127ac9 Author: Maxim Muzafarov Date: 2018-06-22T15:01:36Z ignite-7165: force rebalance 2 commit aa21fd2133b0fca74a135795bbab1393ec56fb87 Author: Maxim Muzafarov Date: 2018-06-22T15:05:38Z ignite-7165: simplify topology changed conditions commit 66b5f76c15cb67b60adeca864a21fdad39acf6f7 Author: Maxim Muzafarov Date: 2018-06-22T15:10:43Z
[jira] [Commented] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545425#comment-16545425
]
Dmitriy Pavlov commented on IGNITE-9004:
I've failed 2 tests with link to this ticket:
testStopPrimaryAndActivateFromClientNode() and testFailGetLock()
> Failed to move temp file during segment creation
>
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
> temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
> 7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
> r.java:1862)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.nio.file.Files.move(Files.java:1395)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
> [13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6639) Ignite node can try to join to itself
[ https://issues.apache.org/jira/browse/IGNITE-6639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545424#comment-16545424 ] ASF GitHub Bot commented on IGNITE-6639: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4109 > Ignite node can try to join to itself > - > > Key: IGNITE-6639 > URL: https://issues.apache.org/jira/browse/IGNITE-6639 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545409#comment-16545409 ] ASF GitHub Bot commented on IGNITE-602: --- Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1558 > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.7 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7827) Adopt kNN regression to the new Partitioned Dataset
[ https://issues.apache.org/jira/browse/IGNITE-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-7827. -- Resolution: Fixed > Adopt kNN regression to the new Partitioned Dataset > --- > > Key: IGNITE-7827 > URL: https://issues.apache.org/jira/browse/IGNITE-7827 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7828) Adopt yardstick tests for the new version of kNN regression algorithm
[ https://issues.apache.org/jira/browse/IGNITE-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-7828. -- Resolution: Won't Fix > Adopt yardstick tests for the new version of kNN regression algorithm > - > > Key: IGNITE-7828 > URL: https://issues.apache.org/jira/browse/IGNITE-7828 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8669) Model estimation
[ https://issues.apache.org/jira/browse/IGNITE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-8669. -- Resolution: Fixed > Model estimation > > > Key: IGNITE-8669 > URL: https://issues.apache.org/jira/browse/IGNITE-8669 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > > We want to have the common mechanism for model estimation. > For estimation we want to have: > * Accuracy/precision/recall > * F score > * TPR/FRP -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko updated IGNITE-8994: --- Attachment: yaml.zip > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > Attachments: yaml.zip > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545312#comment-16545312
]
ASF GitHub Bot commented on IGNITE-9012:
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/4367
IGNITE-9012 Test IgniteServiceReassignmentTest.testZombieAssignmentsC…
…leanup fails
Signed-off-by: EdShangGG
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9012
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4367.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4367
commit 63a9aa7d8ae55aeaed98e36aec55854789bbba9e
Author: EdShangGG
Date: 2018-07-16T13:23:45Z
IGNITE-9012 Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup
fails
Signed-off-by: EdShangGG
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545299#comment-16545299 ] ASF GitHub Bot commented on IGNITE-8820: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4217 > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.7 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko updated IGNITE-8994: --- Attachment: (was: yaml.zip) > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545297#comment-16545297
]
Anton Vinogradov commented on IGNITE-8783:
--
[~ilantukh],
4 problems related to ExchangeLatch hang found:
1) pendingAcks was ignored at client latch recreation on coordinator change.
+Fixed+.
{noformat}
// There is final ack for created latch.
if (pendingAcks.containsKey(latchId)) {
{noformat}
was replaced with
{noformat}
Set nodeIds = pendingAcks.get(latchId);
// There is final ack for created latch.
if (nodeIds != null && nodeIds.contains(coordinator)) {
{noformat}
2) Topology change could cause coordinator change even in case coordinator node
not failed. +Fixed+.
added sorting by order to {{getLatchCoordinator}}
{noformat}
.sorted(Comparator.comparing(ClusterNode::order))
{noformat}
Now coordinator is alwais oldest node.
3) Sometimes Latch fails on message send in case connection was not established
yet.
{noformat}
[2018-07-13
19:06:43,910][ERROR][exchange-worker-#233015%partitioned.GridCachePartitionedDataStructuresFailoverSelfTest4%][TcpCommunicationSpi]
Failed to send message to remote node [node=TcpDiscoveryNode
[id=3838f6ed-1b4d-484d-9773-df449370, addrs=[127.0.0.1],
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
lastExchangeTime=1531498003891, loc=false, ver=2.6.0#19700101-sha1:,
isClient=false], msg=GridIoMessage [plc=2, topic=TOPIC_EXCHANGE, topicOrd=31,
ordered=false, timeout=0, skipOnTimeout=false,
msg=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.LatchAckMessage@77e7c81f]]
class org.apache.ignite.IgniteCheckedException: Failed to connect to node (is
node still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=3838f6ed-1b4d-484d-9773-df449370, addrs=[/127.0.0.1:45010]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3449)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2977)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2860)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2703)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2662)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager$ClientLatch.sendAck(ExchangeLatchManager.java:624)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager$ClientLatch.countDown(ExchangeLatchManager.java:642)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1406)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1177)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:732)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2477)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2357)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
connect to address [addr=/127.0.0.1:45010, err=Address already in use: no
further information]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3452)
... 15 more
Caused by: java.net.BindException: Address already in use: no further
information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3289)
... 15 more
[2018-07-13 19:06:43,911][INFO
][exchange-worker-#233015%p
[jira] [Commented] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545296#comment-16545296
]
Eduard Shangareev commented on IGNITE-9012:
---
[~NSAmelchev] Thank you, I've closed it as duplicate.
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9000) [Test Failed] IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev resolved IGNITE-9000.
---
Resolution: Duplicate
> [Test Failed] IgniteServiceReassignmentTest.testZombieAssignmentsCleanup
> fails sometimes.
> -
>
> Key: IGNITE-9000
> URL: https://issues.apache.org/jira/browse/IGNITE-9000
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> IgniteServiceReassignmentTest.testZombieAssignmentsCleanup has flaky failures
> on TC:
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-4702193284623513465&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=__all_branches__&itemsCount=50
> Typical output:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> {noformat}
> Exception that triggers an assertion error:
> {noformat}
> java.lang.IllegalStateException: Getting affinity for topology version
> earlier than affinity is calculated [locNode=TcpDiscoveryNode
> [id=dc037d7a-2882-478c-a944-56c66131, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1531485137994, loc=true, ver=2.7.0#19700101-sha1:,
> isClient=false], grp=ignite-sys-cache, topVer=AffinityTopologyVersion
> [topVer=3, minorTopVer=0], head=AffinityTopologyVersion [topVer=4,
> minorTopVer=0], history=[AffinityTopologyVersion [topVer=2, minorTopVer=0],
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion
> [topVer=4, minorTopVer=0]]]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:694)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:594)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:225)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:261)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:252)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:276)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1879)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2066)
> 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}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8820) Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting for pending transactions.
[ https://issues.apache.org/jira/browse/IGNITE-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545292#comment-16545292 ] Ivan Rakov commented on IGNITE-8820: [~ivandasch], thanks, merged to master. > Add ability to accept changing txTimeoutOnPartitionMapExchange while waiting > for pending transactions. > -- > > Key: IGNITE-8820 > URL: https://issues.apache.org/jira/browse/IGNITE-8820 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Minor > Fix For: 2.7 > > > Currently, if ExchangeFuture waits whith old value of > txTimeoutOnPartitionMapExchange, new value is not accepted until next > exchange starts. Sometimes it's very usefull (while timeout is too long and > must be shorter applied immediatelly) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-3624) Provide API to get the size of the cache in bytes
[
https://issues.apache.org/jira/browse/IGNITE-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev resolved IGNITE-3624.
---
Resolution: Duplicate
> Provide API to get the size of the cache in bytes
> -
>
> Key: IGNITE-3624
> URL: https://issues.apache.org/jira/browse/IGNITE-3624
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Alisher Alimov
>Priority: Major
>
> Sometimes it's useful to know how much memory cache objects consume. We can
> add {{memorySize()}} method to {{CacheMetrics}} and calculate the value in
> the same way as we do in {{LruEvictionPolicy}}. This works only when cache
> statistics are enabled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545269#comment-16545269 ] Dmitriy Pavlov commented on IGNITE-1094: IgniteChangeGlobalStateTest.testActivateAfterFailGetLock(IgniteChangeGlobalStateTest.java:550) is failed with link to this issue. Should this test pass now? Can I unfail test. One more thing, this issue is marked with muted test, who will unmute test ? > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9004:
---
Priority: Critical (was: Major)
> Failed to move temp file during segment creation
>
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
> temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
> 7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
> r.java:1862)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.nio.file.Files.move(Files.java:1395)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
> [13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9004:
---
Labels: MakeTeamcityGreenAgain (was: )
> Failed to move temp file during segment creation
>
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
> temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
> 7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
> r.java:1862)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.nio.file.Files.move(Files.java:1395)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
> [13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8923) Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
[
https://issues.apache.org/jira/browse/IGNITE-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543024#comment-16543024
]
Ilya Murchenko edited comment on IGNITE-8923 at 7/16/18 2:32 PM:
-
Added a step by step guide for Google Kubernetes Engine Deployment in Markdown
format.
Also please update
[example-kube.xml|https://raw.githubusercontent.com/apache/ignite/master/modules/kubernetes/config/example-kube.xml]
from example-kube.xml file in attachments.
was (Author: imurchenko):
Added step by step guide for Google Kubernetes Engine Deployment in Markdown
format.
Also please update
[example-kube.xml|https://raw.githubusercontent.com/apache/ignite/master/modules/kubernetes/config/example-kube.xml]
from example-kube.xml file in attachments.
> Add step-by-step guide - Google Cloud Engine Deployment (Kubernetes)
>
>
> Key: IGNITE-8923
> URL: https://issues.apache.org/jira/browse/IGNITE-8923
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Roman Guseinov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: config.zip, example-kube.xml,
> google_cloud_engine_deployment.zip, yaml.zip
>
>
> We have such documentation for Microsoft Azure
> [https://apacheignite.readme.io/docs/microsoft-azure-deployment]
> It would be great to publish the same for GCE.
> Here are steps which I used to deploy cluster (stateless, stateful) and web
> console:
> {code:java}
> ## Start Ignite Cluster
> 1. Grant cluster-admin role to current google user (to allow create roles):
> $ kubectl create clusterrolebinding myname2-cluster-admin-binding \
> --clusterrole=cluster-admin \
> --user=
> 2. Create service account and grant permissions:
> $ kubectl create -f sa.yaml
> $ kubectl create -f role.yaml
> $ kubectl create -f rolebind.yaml
> 3. Create a grid service:
> $ kubectl create -f service.yaml
> 4. Deploy Ignite Cluster:
> $ kubectl create -f grid.yaml
> ## Enable Ignite Persistence
> 5. Deploy Ignite StatefulSet with enabled Persistence (instead of step 4).
> $ kubectl create -f grid-pds.yaml
> 6. Connect to the Ignite node and activate cluster:
> $ kubectl exec -it ignite-cluster-0 -- /bin/bash
> $ cd /opt/ignite/apache-ignite-*
> $ ./bin/control.sh --activate
> ## Deploy Web Console:
> 7. Create a volume to keep web console data:
> $ kubectl create -f console-volume.yaml
> 8. Create load balancer to expose HTTP port and make web console available by
> service DNS-name (web-console.default.svc.cluster.local) inside Kuberntes
> enviroment:
> $ kubectl create -f console-service.yaml
> 9. Deploy Web Console:
> $ kubectl create -f console.yaml
> 10. Check external IP:
> $ kubectl get service web-console
> 11. Open Web Console in a web browser and Sign Up.
> 12. Move to User Profile page (Settings > Profile) and copy security token.
> 13. Insert security token into web-agent.yaml (TOKENS environment variable).
> 14. Deploy Web Agent:
> $ kubectl create -f web-agent.yaml
> {code}
> YAML and configs are attached.
> Creating a public Docker-image for Web Agent in progress:
> https://issues.apache.org/jira/browse/IGNITE-8526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9004) Failed to move temp file during segment creation
[
https://issues.apache.org/jira/browse/IGNITE-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9004:
---
Fix Version/s: 2.7
> Failed to move temp file during segment creation
>
>
> Key: IGNITE-9004
> URL: https://issues.apache.org/jira/browse/IGNITE-9004
> Project: Ignite
> Issue Type: Test
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Reproduced by Activate/Deactivate suit, for example
> IgniteChangeGlobalStateTest#testStopPrimaryAndActivateFromClientNode
> {noformat}
> class org.apache.ignite.internal.pagemem.wal.StorageException: Failed to move
> temp file to a regular WAL segment file: /data/teamcity/work/c182b70f2dfa650
> 7/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1446)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:2269)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.access$4500(FileWriteAheadLogManager.java:143)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.allocateRemainingFiles(FileWriteAheadLogManage
> r.java:1862)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1606)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> [13:56:05]W: [org.apache.ignite:ignite-core] Caused by:
> java.nio.file.NoSuchFileException:
> /data/teamcity/work/c182b70f2dfa6507/work/IgniteChangeGlobalStateTest/db/wal/node1/0002.wal.tmp
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> java.nio.file.Files.move(Files.java:1395)
> [13:56:05]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.createFile(FileWriteAheadLogManager.java:1442)
> [13:56:05]W: [org.apache.ignite:ignite-core] ... 6 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[
https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545247#comment-16545247
]
Ilya Murchenko edited comment on IGNITE-8993 at 7/16/18 2:24 PM:
-
To enable session affinity we need to modify the Ignite Load Balancer Service:
{code:java}
#Add "sessionAffinity: ClientIP" property to "spec" section
spec:
type: LoadBalancer
...
sessionAffinity: ClientIP
{code}
{code:java}
1. Deploy Ignite Load Balancer Service
$ kubectl create -f ignite-statefulset.yaml
{code}
ignite-service.yaml configuration file is attached.
was (Author: imurchenko):
To enable session affinity we need to modify the Ignite load balancer service:
{code:java}
spec:
type: LoadBalancer
...
sessionAffinity: ClientIP
{code}
Configuration file (YAML) is attached.
> Configuring sticky LoadBalancer for Ignite Service with Kubernetes
> --
>
> Key: IGNITE-8993
> URL: https://issues.apache.org/jira/browse/IGNITE-8993
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Magda
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: ignite-service.yaml
>
>
> Ignite service used for Ignite pods auto-discovery and access to the cluster
> from remote applications is deployed as LoadBalancer:
> https://apacheignite.readme.io/docs/ignite-service
> This might lead to problems when a stateful session is needed between an app
> and the cluster. For instance, Ignite JDBC driver preserves the state of an
> opened connection meaning that once LoadBalancer connects the driver to an
> Ignite pod, all the queries have to be redirected to that Ignite pod only
> (unless the pod is down).
> We need to show how to configure a sticky LoadBalancer that will assign a
> client connection to a specific pod and won't change it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8897) Node with longer BaselineHistory joining the cluster causes cluster stopping
[
https://issues.apache.org/jira/browse/IGNITE-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545251#comment-16545251
]
Dmitriy Pavlov commented on IGNITE-8897:
[~sergey-chugunov], could you please add javadoc for new
InterceptingCommunicationSpi. And probably it coudl be good idea to simplify
code in equals without if-else here:
https://github.com/apache/ignite/pull/4357/files#diff-941e32139ff37a3ce02e29d0615582a2R964
> Node with longer BaselineHistory joining the cluster causes cluster stopping
>
>
> Key: IGNITE-8897
> URL: https://issues.apache.org/jira/browse/IGNITE-8897
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.7
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> There is no array index boundary check in code verifying BaselineHistory on
> new node join so it may end up with ArrayIndexOutOfBoundsException, exception
> stack trace looks like this (failure handler is configured):
> {noformat}
> [org.apache.ignite.Ignite] Critical system error detected. Will be handled
> accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IndexOutOfBoundsException:
> Index: 17, Size: 17]]
> java.lang.IndexOutOfBoundsException: Index: 17, Size: 17
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.isCompatibleWith(BaselineTopologyHistory.java:97)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode(GridClusterStateProcessor.java:981)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> We need to check bltHistory size and if node joins with incorrect bltHistory
> we should refuse the join.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8745) Add ability to monitor TCP discovery ring information
[ https://issues.apache.org/jira/browse/IGNITE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545250#comment-16545250 ] ASF GitHub Bot commented on IGNITE-8745: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4256 > Add ability to monitor TCP discovery ring information > - > > Key: IGNITE-8745 > URL: https://issues.apache.org/jira/browse/IGNITE-8745 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Fix For: 2.7 > > Time Spent: 16h > Remaining Estimate: 0h > > We should add the following modifications: > 1) Add a method on TCP discovery MBean to dump the ring structure on local > node and on all nodes in the grid > 2) Make tcp-disco-worker thread name reflect the node to which the local node > is connected > 3) Add a method on TCP discovery MBean to return current topology version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8745) Add ability to monitor TCP discovery ring information
[ https://issues.apache.org/jira/browse/IGNITE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-8745: --- Fix Version/s: 2.7 > Add ability to monitor TCP discovery ring information > - > > Key: IGNITE-8745 > URL: https://issues.apache.org/jira/browse/IGNITE-8745 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Fix For: 2.7 > > Time Spent: 16h > Remaining Estimate: 0h > > We should add the following modifications: > 1) Add a method on TCP discovery MBean to dump the ring structure on local > node and on all nodes in the grid > 2) Make tcp-disco-worker thread name reflect the node to which the local node > is connected > 3) Add a method on TCP discovery MBean to return current topology version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[
https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545247#comment-16545247
]
Ilya Murchenko commented on IGNITE-8993:
To enable session affinity we need to modify the Ignite load balancer service:
{code:java}
spec:
type: LoadBalancer
...
sessionAffinity: ClientIP
{code}
Configuration file (YAML) is attached.
> Configuring sticky LoadBalancer for Ignite Service with Kubernetes
> --
>
> Key: IGNITE-8993
> URL: https://issues.apache.org/jira/browse/IGNITE-8993
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Magda
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: ignite-service.yaml
>
>
> Ignite service used for Ignite pods auto-discovery and access to the cluster
> from remote applications is deployed as LoadBalancer:
> https://apacheignite.readme.io/docs/ignite-service
> This might lead to problems when a stateful session is needed between an app
> and the cluster. For instance, Ignite JDBC driver preserves the state of an
> opened connection meaning that once LoadBalancer connects the driver to an
> Ignite pod, all the queries have to be redirected to that Ignite pod only
> (unless the pod is down).
> We need to show how to configure a sticky LoadBalancer that will assign a
> client connection to a specific pod and won't change it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8745) Add ability to monitor TCP discovery ring information
[ https://issues.apache.org/jira/browse/IGNITE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545246#comment-16545246 ] Ivan Rakov commented on IGNITE-8745: [~ezagumennov], thanks for contribution! Merged to master. > Add ability to monitor TCP discovery ring information > - > > Key: IGNITE-8745 > URL: https://issues.apache.org/jira/browse/IGNITE-8745 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Evgenii Zagumennov >Priority: Major > Time Spent: 16h > Remaining Estimate: 0h > > We should add the following modifications: > 1) Add a method on TCP discovery MBean to dump the ring structure on local > node and on all nodes in the grid > 2) Make tcp-disco-worker thread name reflect the node to which the local node > is connected > 3) Add a method on TCP discovery MBean to return current topology version -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8993) Configuring sticky LoadBalancer for Ignite Service with Kubernetes
[ https://issues.apache.org/jira/browse/IGNITE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko updated IGNITE-8993: --- Attachment: ignite-service.yaml > Configuring sticky LoadBalancer for Ignite Service with Kubernetes > -- > > Key: IGNITE-8993 > URL: https://issues.apache.org/jira/browse/IGNITE-8993 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > Attachments: ignite-service.yaml > > > Ignite service used for Ignite pods auto-discovery and access to the cluster > from remote applications is deployed as LoadBalancer: > https://apacheignite.readme.io/docs/ignite-service > This might lead to problems when a stateful session is needed between an app > and the cluster. For instance, Ignite JDBC driver preserves the state of an > opened connection meaning that once LoadBalancer connects the driver to an > Ignite pod, all the queries have to be redirected to that Ignite pod only > (unless the pod is down). > We need to show how to configure a sticky LoadBalancer that will assign a > client connection to a specific pod and won't change it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[
https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545239#comment-16545239
]
Ilya Murchenko commented on IGNITE-8994:
Here are steps which I used to deploy Ignite StatefulSet with dedicated volumes
for WAL and Data:
{code:java}
##Create Ignite StatefulSet deployment with dedicated volumes for WAL and Data
1. Specify a Volume Type in storage-class-wal-.yaml and
storage-class-persistence-.yaml configuration templates.
2. Create a StorageClass for AWS or GKE
#AWS:
$ kubectl create -f storage-class-wal-aws.yaml
#GKE:
$ kubectl create -f storage-class-wal-gke.yaml
3. Create a PersistentVolumeClaim for AWS or GKE
#AWS:
$ kubectl create -f storage-class-persistence-aws.yaml
#GKE:
$ kubectl create -f storage-class-persistence-gke.yaml
4. Deploy Ignite StatefulSet with dedicated volumes for WAL and Data
$ kubectl create -f ignite-statefulset.yaml
{code}
Configuration templates (YAML) are attached.
> Configuring dedicated volumes for WAL and data with Kuberenetes
> ---
>
> Key: IGNITE-8994
> URL: https://issues.apache.org/jira/browse/IGNITE-8994
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Magda
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: yaml.zip
>
>
> The current StatefulSet documentation request only one persistent volume for
> both WAL and data/index files:
> https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment
> However, according to Ignite performance guide the WAL has to be located on a
> dedicated volume:
> https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal
> Provide StatefulSet configuration that shows how to request separate volumes
> for the WAL and data/index files. If needed, provide YAML configs for
> StorageClass and volume claims.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko updated IGNITE-8994: --- Attachment: (was: yaml.zip) > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > Attachments: yaml.zip > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko updated IGNITE-8994: --- Attachment: yaml.zip > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > Attachments: yaml.zip > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1094) Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization
[ https://issues.apache.org/jira/browse/IGNITE-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545223#comment-16545223 ] Andrey Gura commented on IGNITE-1094: - Thanks! Merged to master branch. > Ignite.createCache(CacheConfiguration) hangs if some exception occurs during > cache initialization > - > > Key: IGNITE-1094 > URL: https://issues.apache.org/jira/browse/IGNITE-1094 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Sergey Evdokimov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: Muted_test > Fix For: 2.7 > > > User can pass broken configuration, for example, store factory that throws > exception from create() method. I created test to demonstrate the problem. > See IgniteDynamicCacheStartSelfTest#testBrokenStoreFactory in 'ignite-1094' > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8994) Configuring dedicated volumes for WAL and data with Kuberenetes
[ https://issues.apache.org/jira/browse/IGNITE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Murchenko updated IGNITE-8994: --- Attachment: yaml.zip > Configuring dedicated volumes for WAL and data with Kuberenetes > --- > > Key: IGNITE-8994 > URL: https://issues.apache.org/jira/browse/IGNITE-8994 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.7 > > Attachments: yaml.zip > > > The current StatefulSet documentation request only one persistent volume for > both WAL and data/index files: > https://apacheignite.readme.io/docs/stateful-deployment#section-statefulset-deployment > However, according to Ignite performance guide the WAL has to be located on a > dedicated volume: > https://apacheignite.readme.io/docs/durable-memory-tuning#section-separate-disk-device-for-wal > Provide StatefulSet configuration that shows how to request separate volumes > for the WAL and data/index files. If needed, provide YAML configs for > StorageClass and volume claims. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8975) Invalid initialization of compressed archived WAL segment when WAL compression is switched off.
[
https://issues.apache.org/jira/browse/IGNITE-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545207#comment-16545207
]
Ivan Rakov commented on IGNITE-8975:
Folks, I'll take a look.
> Invalid initialization of compressed archived WAL segment when WAL
> compression is switched off.
> ---
>
> Key: IGNITE-8975
> URL: https://issues.apache.org/jira/browse/IGNITE-8975
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.7
>
>
> After restarting node with WAL compression disabled and when compressed wal
> archive
> presentd, current implementation of FileWriteAheadLogManager ignores
> presenting compressed wal segment and initalizes empty brand new one. This
> causes following error:
> {code:java}
> 2018-07-05 16:14:25.761
> [ERROR][exchange-worker-#153%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.c.CheckpointHistory]
> Failed to process checkpoint: CheckpointEntry
> [id=8dc4b1cc-dedd-4a57-8748-f5a7ecfd389d, timestamp=1530785506909,
> ptr=FileWALPointer [idx=4520, fileOff=860507725, len=691515]]
> org.apache.ignite.IgniteCheckedException: Failed to find checkpoint record at
> the given WAL pointer: FileWALPointer [idx=4520, fileOff=860507725,
> len=691515]
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.initIfNeeded(CheckpointEntry.java:346)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.access$300(CheckpointEntry.java:231)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.initIfNeeded(CheckpointEntry.java:123)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.groupState(CheckpointEntry.java:105)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.isCheckpointApplicableForGroup(CheckpointHistory.java:377)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.searchAndReserveCheckpoints(CheckpointHistory.java:304)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.reserveHistoryForExchange(GridCacheDatabaseSharedManager.java:1614)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:724)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2477)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2357)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8774) Daemon moves cluster to compatibility mode when joins
[
https://issues.apache.org/jira/browse/IGNITE-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545205#comment-16545205
]
ASF GitHub Bot commented on IGNITE-8774:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4243
> Daemon moves cluster to compatibility mode when joins
> -
>
> Key: IGNITE-8774
> URL: https://issues.apache.org/jira/browse/IGNITE-8774
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.7
>
>
> When a daemon node joins the cluster seems to switch to compatibility mode
> (allowing nodes without baseline support). It prevents baseline nodes from
> being restarted.
> Example:
> {code}
> Ignite ignite1 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv1");
> Ignite ignite2 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> ignite2.cluster().active(true);
> IgnitionEx.setClientMode(true);
> IgnitionEx.setDaemon(true);
> Ignite daemon =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "daemon");
> IgnitionEx.setClientMode(false);
> IgnitionEx.setDaemon(false);
> ignite2.close();
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> {code}
> The attempt to restart ignite2 throws an exception:
> {code}
> [2018-06-11 18:45:25,766][ERROR][tcp-disco-msg-worker-#39%srv2%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteException: Node with BaselineTopology cannot join mixed cluster
> running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:714)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:883)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4354)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8774) Daemon moves cluster to compatibility mode when joins
[
https://issues.apache.org/jira/browse/IGNITE-8774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545200#comment-16545200
]
Dmitriy Pavlov commented on IGNITE-8774:
Remaining test failures seems to come from reasons not related to the issue:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8689176344607253190&branch=pull%2F4243%2Fhead&tab=testDetails&branch_IgniteTests24Java8=__all_branches__
Failed without changes
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=9042263396020992120&branch=pull%2F4243%2Fhead&tab=testDetails
seems to be fixed recently and unmuted
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4219534437120988940&branch=pull%2F4243%2Fhead&tab=testDetails
came from obolete suite, which will be removed soon.
So I think TC status can be considered as OK.
> Daemon moves cluster to compatibility mode when joins
> -
>
> Key: IGNITE-8774
> URL: https://issues.apache.org/jira/browse/IGNITE-8774
> Project: Ignite
> Issue Type: Bug
>Reporter: Stanislav Lukyanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.7
>
>
> When a daemon node joins the cluster seems to switch to compatibility mode
> (allowing nodes without baseline support). It prevents baseline nodes from
> being restarted.
> Example:
> {code}
> Ignite ignite1 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv1");
> Ignite ignite2 =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> ignite2.cluster().active(true);
> IgnitionEx.setClientMode(true);
> IgnitionEx.setDaemon(true);
> Ignite daemon =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "daemon");
> IgnitionEx.setClientMode(false);
> IgnitionEx.setDaemon(false);
> ignite2.close();
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "srv2");
> {code}
> The attempt to restart ignite2 throws an exception:
> {code}
> [2018-06-11 18:45:25,766][ERROR][tcp-disco-msg-worker-#39%srv2%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteException: Node with BaselineTopology cannot join mixed cluster
> running in compatibility mode]]
> class org.apache.ignite.IgniteException: Node with BaselineTopology cannot
> join mixed cluster running in compatibility mode
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onGridDataReceived(GridClusterStateProcessor.java:714)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:883)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4354)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-9012:
-
Assignee: Eduard Shangareev
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545185#comment-16545185
]
Amelchev Nikita commented on IGNITE-9012:
-
[~EdShangGG], seems this test reported in
[IGNITE-9000|https://issues.apache.org/jira/browse/IGNITE-9000]
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
[
https://issues.apache.org/jira/browse/IGNITE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-9012:
--
Description:
Example:
https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
{code}
[2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
at java.lang.Thread.run(Thread.java:748)
{code}
was:
Example:
https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
{test}
[2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
at java.lang.Thread.run(Thread.java:748)
{test}
> Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
> --
>
> Key: IGNITE-9012
> URL: https://issues.apache.org/jira/browse/IGNITE-9012
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Priority: Major
>
> Example:
> https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
> {code}
> [2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertFalse(Assert.java:39)
> at junit.framework.Assert.assertFalse(Assert.java:47)
> at junit.framework.TestCase.assertFalse(TestCase.java:219)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
> 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 junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9012) Test IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
Eduard Shangareev created IGNITE-9012:
-
Summary: Test
IgniteServiceReassignmentTest.testZombieAssignmentsCleanup fails
Key: IGNITE-9012
URL: https://issues.apache.org/jira/browse/IGNITE-9012
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
Example:
https://ci.ignite.apache.org/viewLog.html?buildId=1499947&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Basic1#testNameId4751597304481704825
{test}
[2018-07-16 10:50:03,888][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.Assert.assertFalse(Assert.java:47)
at junit.framework.TestCase.assertFalse(TestCase.java:219)
at
org.apache.ignite.internal.processors.service.IgniteServiceReassignmentTest.testZombieAssignmentsCleanup(IgniteServiceReassignmentTest.java:237)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
at java.lang.Thread.run(Thread.java:748)
{test}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545174#comment-16545174 ] Dmitry Karachentsev commented on IGNITE-8985: - Added [PR 4365 | https://github.com/apache/ignite/pull/4365], but test should be rerun along with IGNITE-8944. > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545173#comment-16545173 ] ASF GitHub Bot commented on IGNITE-8985: GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/4365 IGNITE-8985 - Node segmented itself after connRecoveryTimeout. Improv… …ed loopback resolving from IGNITE-8683. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8985 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4365.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4365 commit a61635b306d3e7a3977708ec027ab31c67f8ad1a Author: dkarachentsev Date: 2018-07-16T12:50:32Z IGNITE-8985 - Node segmented itself after connRecoveryTimeout. Improved loopback resolving from IGNITE-8683. > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9011) RendezvousAffinity.excludeNeighbors should be removed and be a default behavior
Dmitry Karachentsev created IGNITE-9011: --- Summary: RendezvousAffinity.excludeNeighbors should be removed and be a default behavior Key: IGNITE-9011 URL: https://issues.apache.org/jira/browse/IGNITE-9011 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.6 Reporter: Dmitry Karachentsev Fix For: 3.0 According to this [discussion | http://apache-ignite-developers.2346864.n4.nabble.com/Neighbors-exclusion-td32550.html], cache backup distribution should be more straightforward. Right now we have not obvious logic on how backups will be stored across nodes. For example: 1. If set nodeFilter, it will filter backup nodes and if there are not enough nodes there will be less backups... 2. If set property excludeNeighbors, it will ignore manually set backupFilter. 3. By default excludeNeighbors is false. There seems no need to keep excludeNeighbors property at all and it should be removed. Instead, node always must do the best to distribute backups to different machines. If user set backupFilter, it must be used, otherwise distribute backups to other machines if it's possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545150#comment-16545150
]
kcheng.mvp commented on IGNITE-9005:
[~dpavlov],
I checked the source code and found that this issue may be caused by this line
org.apache.ignite.internal.processors.cache.GridCacheProcessor #1452
*CacheEvictionManager evictMgr = (nearEnabled || cfg.isOnheapCacheEnabled()) ?
new GridCacheEvictionManager() : new CacheOffheapEvictionManager();*
as in this case a new *CacheOffheapEvictionManager()* will return, but this
implementation does not do any eviction bean register/unregister, as there are
no any policy.
are my findings wrong?
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: kcheng.mvp
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7246907407546697403&branch=%3Cdefault%3E&tab=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545140#comment-16545140 ] Ilya Kasnacheev commented on IGNITE-8060: - [~tledkov-gridgain] please review the proposed fix. It also fixes two likewise tickets. > Sqline creating tables on client nodes works incorrect in case of node's > shutdown > - > > Key: IGNITE-8060 > URL: https://issues.apache.org/jira/browse/IGNITE-8060 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.7 > > Attachments: ignite-76cc6387.log, ignite-a1c90af9.log > > > For reproducing (master branch) > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 2)Create new table on client node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Drop the client node > 5)Create new client node > 6)Connect to new client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 7)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > 8)Try to drop the table: > DROP TABLE City; > java.sql.SQLException: Table doesn't exist: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > at sqlline.Commands.execute(Commands.java:823) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > 9)Try to create new table: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > java.sql.SQLException: Table already exists: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > at sqlline.Commands.execute(Commands.java:823) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > Update: > Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done. > !tables doen\t work even after SELECT > SELECT works OK. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9010) Move web-console build to dedicated root directory
Peter Ivanov created IGNITE-9010:
Summary: Move web-console build to dedicated root directory
Key: IGNITE-9010
URL: https://issues.apache.org/jira/browse/IGNITE-9010
Project: Ignite
Issue Type: Task
Reporter: Peter Ivanov
Assignee: Ilya Murchenko
# Move web-console docker image build (web-console, frontend and backend) to
{{/docker}} directory.
# Prepare README.md file in root of {{/docker}} directory with instructions on
how to build corresponding image. Remove obsolete per-image README's from
Dockerfile directories.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9009) Local continuous query listeners may be called on partition reassignment
Denis Mekhanikov created IGNITE-9009: Summary: Local continuous query listeners may be called on partition reassignment Key: IGNITE-9009 URL: https://issues.apache.org/jira/browse/IGNITE-9009 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Fix For: 2.7 Attachments: ContinuousQueryReassignmentTest.java When a node becomes primary for some partitions, then local continuous query listeners receive updates on entries from that partitions. Such invocations shouldn't happen. Attached test class demonstrates this behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8922) Discovery message delivery guarantee can be violated
[
https://issues.apache.org/jira/browse/IGNITE-8922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545117#comment-16545117
]
Dmitry Karachentsev commented on IGNITE-8922:
-
[~dmekhanikov] in general it looks fine, but node is vulnerable for OOME or
IllegalStateException, because pending message queue could grow unlimited now.
Anyway, both cases: node hang due to lost messages or OOME are harmful, but
last is less possible. I'm OK with this change so far.
> Discovery message delivery guarantee can be violated
>
>
> Key: IGNITE-8922
> URL: https://issues.apache.org/jira/browse/IGNITE-8922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: PendingMessageResendTest.java
>
>
> Under certain circumstances discovery messages may be delivered only to a
> part of nodes.
> It happens because pending messages are not resent due to data inconsistency
> in {{ServerImpl#PendingMessages}} class. If {{discardId}} or
> {{customDiscardId}} point to a message, that is not present in the queue,
> then other messages will be skipped and won't be resent. It may happen, for
> example, when queue in {{PendingMessages}} is overflown.
> PFA test, that reproduces this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8897) Node with longer BaselineHistory joining the cluster causes cluster stopping
[
https://issues.apache.org/jira/browse/IGNITE-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545101#comment-16545101
]
Anton Kalashnikov commented on IGNITE-8897:
---
Looks good for me. Tests also looks permissible. It can be merged.
> Node with longer BaselineHistory joining the cluster causes cluster stopping
>
>
> Key: IGNITE-8897
> URL: https://issues.apache.org/jira/browse/IGNITE-8897
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.5
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.7
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> There is no array index boundary check in code verifying BaselineHistory on
> new node join so it may end up with ArrayIndexOutOfBoundsException, exception
> stack trace looks like this (failure handler is configured):
> {noformat}
> [org.apache.ignite.Ignite] Critical system error detected. Will be handled
> accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IndexOutOfBoundsException:
> Index: 17, Size: 17]]
> java.lang.IndexOutOfBoundsException: Index: 17, Size: 17
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.isCompatibleWith(BaselineTopologyHistory.java:97)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode(GridClusterStateProcessor.java:981)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> We need to check bltHistory size and if node joins with incorrect bltHistory
> we should refuse the join.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9008) CPP Thin: Implement benchmark for C++ thin
Igor Sapego created IGNITE-9008: --- Summary: CPP Thin: Implement benchmark for C++ thin Key: IGNITE-9008 URL: https://issues.apache.org/jira/browse/IGNITE-9008 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.7 We need a benchmark for C++ thin to understand how is its performance compares to to other clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7700) SQL system view for list of nodes
[ https://issues.apache.org/jira/browse/IGNITE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545092#comment-16545092 ] Dmitriy Pavlov commented on IGNITE-7700: Hi [~vozerov], could you please take a look to this change? > SQL system view for list of nodes > - > > Key: IGNITE-7700 > URL: https://issues.apache.org/jira/browse/IGNITE-7700 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13, sql > Fix For: 2.7 > > > Implement SQL system view to show list of nodes in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8783) Failover tests periodically cause hanging of the whole Data Structures suite on TC
[
https://issues.apache.org/jira/browse/IGNITE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545072#comment-16545072
]
ASF GitHub Bot commented on IGNITE-8783:
GitHub user anton-vinogradov opened a pull request:
https://github.com/apache/ignite/pull/4364
IGNITE-8783
Signed-off-by: Anton Vinogradov
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/ignite ignite-8783
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4364.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4364
commit 87acce74295d483e27794aee2c5e1493b665ee2a
Author: Anton Vinogradov
Date: 2018-07-13T12:38:26Z
IGNITE-8783
Signed-off-by: Anton Vinogradov
> Failover tests periodically cause hanging of the whole Data Structures suite
> on TC
> --
>
> Key: IGNITE-8783
> URL: https://issues.apache.org/jira/browse/IGNITE-8783
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Ivan Rakov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> History of suite runs:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_DataStructures&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E
> Chance of suite hang is 18% in master (based on previous 50 runs).
> Hang is always caused by one of the following failover tests:
> {noformat}
> GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange
> GridCachePartitionedDataStructuresFailoverSelfTest#testFairReentrantLockConstantTopologyChangeNonFailoverSafe
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545065#comment-16545065
]
Sergey Chugunov commented on IGNITE-8957:
-
[~Mmuzaf],
I totally support your efforts to make code cleaner and cover additional cases.
At the same time merging this sooner rather than later also makes sense as it
eliminates incorrect assertion that causes timeouts and possibly hides other
problems.
So lets apply your suggestions in the IGNITE-9003.
As per TC status you're right: even though it was a minor change in logging and
it didn't touch functional logic TC results should have been provided here.
> testFailGetLock() constantly fails. Last entry checkpoint history can be empty
> --
>
> Key: IGNITE-8957
> URL: https://issues.apache.org/jira/browse/IGNITE-8957
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Andrew Medvedev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> IgniteChangeGlobalStateTest#testFailGetLock constantly fails with exception:
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.onCheckpointFinished(CheckpointHistory.java:205)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointEnd(GridCacheDatabaseSharedManager.java:3654)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3178)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2953)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> As Sergey Chugunov
> [mentioned|https://issues.apache.org/jira/browse/IGNITE-8737?focusedCommentId=16535062&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16535062],
> issue can be solved different ways:
> {quote}
> It seems we missed a case when lastEntry may be empty. We may choose here
> from two options:
> * Check if histMap is empty inside onCheckpointFinished. If it is just don't
> log anything (it was the very first checkpoint).
> * Check in caller that there is no history, calculate necessary index in
> caller and pass it to onCheckpointFinished to prepare correct log
> message.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-4435) Discovery data distribution process optimization
[
https://issues.apache.org/jira/browse/IGNITE-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545063#comment-16545063
]
Ryabov Dmitrii commented on IGNITE-4435:
[~sergey-chugunov], looks like ticket wasn't finished -
{{filterDuplicatedData}} wasn't removed and still contains
[TODO|https://github.com/apache/ignite/blob/0d82f1004c72dd3881e453e555e9803ecd889c74/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/internal/DiscoveryDataPacket.java#L324]
comment with link to this ticket.
> Discovery data distribution process optimization
>
>
> Key: IGNITE-4435
> URL: https://issues.apache.org/jira/browse/IGNITE-4435
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Priority: Major
>
> h2. Notes
> Previously upon new node joining topology grid components on each node has
> been collecting discovery data independently from the same components on
> other nodes.
> This lead to a situation when *TcpDiscoveryNodeAddedMessage* and
> *TcpDiscoveryNodeAddFinishedMessage* carried a lot of duplicated data wasting
> network traffic.
> Refactoring done within
> [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] introduced a
> way to reduce duplication, but only *GridMarshallerMappingProcessor*
> component took advantage of it.
> h2. Acceptance Criteria
> * Identify all components needed to be optimized in terms of discovery data
> collection.
> * Refactor them to reduce duplication of discovery data.
> * Remove *filterDuplicatedData* method as obsolete from
> *DiscoveryDataContainer* when refactoring is done.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9007) cache.invoke() fails because of UnregisteredClassException
Roman Guseinov created IGNITE-9007:
--
Summary: cache.invoke() fails because of
UnregisteredClassException
Key: IGNITE-9007
URL: https://issues.apache.org/jira/browse/IGNITE-9007
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.5
Reporter: Roman Guseinov
Assignee: Mikhail Cherkasov
Attachments: ClientNode.java, CustomEnum.java, CustomObj.java,
Reproducer.java, ServerNode.java
Here is a stack trace:
{code:java}
[2018-07-16 18:07:30,624][ERROR][main][BinaryContext] Failed to serialize
object [typeName=o.a.i.reproducers.fd7776.CustomObj]
class org.apache.ignite.binary.BinaryObjectException: Failed to write field
[name=obj]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:159)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:807)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:216)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:402)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:386)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:881)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:831)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1802)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:5350)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4705)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4515)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1726)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1306)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:381)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1761)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:827)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1417)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCach
[jira] [Commented] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545021#comment-16545021
]
Dmitry Karachentsev commented on IGNITE-8944:
-
[TC |
https://ci.ignite.apache.org/viewLog.html?buildId=1487349&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Spi]
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8957) testFailGetLock() constantly fails. Last entry checkpoint history can be empty
[
https://issues.apache.org/jira/browse/IGNITE-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544215#comment-16544215
]
Maxim Muzafarov edited comment on IGNITE-8957 at 7/16/18 9:58 AM:
--
*Folks,*
I still don't understand you.
# Why we are merging PR when a lot of questions remains? You are answering the
questions after merge is it right from your point? Is it friendly for community
members?
# As you may know we have [Review
Checklist|https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist].
Please, look at {{3.с}}. You are fixing WAL component which is used in whole
presistece. I don't see any TC runs on your PR – [Run :: All -
pull/4334/head|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=pull%2F4334%2Fhead&tab=buildTypeStatusDiv].
Is it corret?
Current issue is the result of hastily merge of IGNITE-8737. And here we are
hurry again, why? You may heared that whole community are working on
[#MakeTeamCityGreenAgain|https://cwiki.apache.org/confluence/display/IGNITE/Make+Teamcity+Green+Again]
and whole progrees of this activity can be eliminatad by inaccurately code
changes. I'm a bit upset here.
I whish Ignite to be an example for other projects.
*About code.*
My vision is around like this:
# We should create reusable method for getting index
{code:java}
/**
* @param cpEntry Historical entry to evaluate.
* @return An {@link FileWALPointer#index()} or {@code -1} if there is no
checkpoint information.
*/
private long getCheckpointMarkIdx(@Nullable Map.Entry cpEntry) {
if (cpEntry == null)
return -1;
final WALPointer wal = cpEntry.getValue().checkpointMark();
return wal instanceof FileWALPointer ? ((FileWALPointer)wal).index() :
-1;
}
{code}
# Reuse it for calculation WAL covered segments
{code:java}
/**
* Logs and clears checkpoint history after checkpoint finish.
*
* @return List of checkpoints removed from history.
*/
public List
onCheckpointFinished(GridCacheDatabaseSharedManager.Checkpoint chp, boolean
truncateWal) {
chp.walSegmentsCovered(
getCheckpointMarkIdx(
Optional.ofNullable(histMap.lastEntry())
.map(e -> histMap.lowerEntry(e.getKey()))
.orElse(null)
),
getCheckpointMarkIdx(histMap.lastEntry())
);
...
}
{code}
[~sergey-chugunov], as you can see code became cleaner and shorter.
was (Author: mmuzaf):
*Folks,*
I still don't understand you.
# Why we are merging PR when a lot of questions remains? You are answering the
questions after merge is it right from your point? Is it friendly for community
members?
# As you may know we have [Review
Checklist|https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches].
Please, look at {{3.с}}. You are fixing WAL component which is used in whole
presistece. I don't see any TC runs on your PR – [Run :: All -
pull/4334/head|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=pull%2F4334%2Fhead&tab=buildTypeStatusDiv].
Is it corret?
Current issue is the result of hastily merge of IGNITE-8737. And here we are
hurry again, why? You may heared that whole community are working on
[#MakeTeamCityGreenAgain|https://cwiki.apache.org/confluence/display/IGNITE/Make+Teamcity+Green+Again]
and whole progrees of this activity can be eliminatad by inaccurately code
changes. I'm a bit upset here.
I whish Ignite to be an example for other projects.
*About code.*
My vision is around like this:
# We should create reusable method for getting index
{code:java}
/**
* @param cpEntry Historical entry to evaluate.
* @return An {@link FileWALPointer#index()} or {@code -1} if there is no
checkpoint information.
*/
private long getCheckpointMarkIdx(@Nullable Map.Entry cpEntry) {
if (cpEntry == null)
return -1;
final WALPointer wal = cpEntry.getValue().checkpointMark();
return wal instanceof FileWALPointer ? ((FileWALPointer)wal).index() :
-1;
}
{code}
# Reuse it for calculation WAL covered segments
{code:java}
/**
* Logs and clears checkpoint history after checkpoint finish.
*
* @return List of checkpoints removed from history.
*/
public List
onCheckpointFinished(GridCacheDatabaseSharedManager.Checkpoint chp, boolean
truncateWal) {
chp.walSegmentsCovered(
getCheckpointMarkIdx(
Optional.ofNullable(histMap.lastEntry())
.map(e -> histMap.lowerEntry(e.getKey()))
.orElse(null)
),
getCheckpointMarkIdx(histMap.lastEntry())
);
...
}
{code}
[~sergey-chugunov], as you can see
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545013#comment-16545013 ] Alexey Goncharuk commented on IGNITE-602: - Fair enough, will merge the PR shortly. > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.7 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6888) Cache involved tables set for statement
[
https://issues.apache.org/jira/browse/IGNITE-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-6888:
Assignee: Ivan Pavlukhin
> Cache involved tables set for statement
> ---
>
> Key: IGNITE-6888
> URL: https://issues.apache.org/jira/browse/IGNITE-6888
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Igor Seliverstov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Currently we have to create AST from {{PreparedStatement}} to collect and
> process all involved
> in the query caches (See IgniteH2Indexing#mvccTracker}}). It makes sense to
> cache parse results per statements by analogy with statements itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8582) MVCC TX: Cache store read-through support
[ https://issues.apache.org/jira/browse/IGNITE-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-8582: Assignee: Ivan Pavlukhin > MVCC TX: Cache store read-through support > - > > Key: IGNITE-8582 > URL: https://issues.apache.org/jira/browse/IGNITE-8582 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: mvcc, sql > > Add support for read-through cache store for mvcc caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8971) GridRestProcessor should propagate error message
[ https://issues.apache.org/jira/browse/IGNITE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544991#comment-16544991 ] Sergey Kosarev commented on IGNITE-8971: [~andmed], looks good now. > GridRestProcessor should propagate error message > > > Key: IGNITE-8971 > URL: https://issues.apache.org/jira/browse/IGNITE-8971 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > > GridRestProcessor should propagate error message (stack trace) for handling > disk full error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9006) Add per-call tracing capabilities for IgniteCache#{get, getAll} methods
[
https://issues.apache.org/jira/browse/IGNITE-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-9006:
Assignee: Ilya Lantukh
> Add per-call tracing capabilities for IgniteCache#{get, getAll} methods
> ---
>
> Key: IGNITE-9006
> URL: https://issues.apache.org/jira/browse/IGNITE-9006
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.6
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.7
>
>
> As an experimental feature to debug objects visibility issues, we should add
> an API method {{IgniteCache#withTrace()}} which will enable per-call API
> calls tracing.
> I think we can start with reads tracing, as a simplest change. We need to
> introduce an additional flag mask to {{NearSingleGetRequest}},
> {{NearGetRequest}}, {{Near...Response}} to identify such requests, and when
> processing, print out all message processing path (send, receive), entry
> swap/unswap, versions and values read, {{GridCacheEntryRemovedException}}s
> encountered, etc. For transactional caches, I think it also makes sense to
> print out all pending transactions that touch the key being read.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9006) Add per-call tracing capabilities for IgniteCache#{get, getAll} methods
Alexey Goncharuk created IGNITE-9006:
Summary: Add per-call tracing capabilities for IgniteCache#{get,
getAll} methods
Key: IGNITE-9006
URL: https://issues.apache.org/jira/browse/IGNITE-9006
Project: Ignite
Issue Type: New Feature
Affects Versions: 2.6
Reporter: Alexey Goncharuk
Fix For: 2.7
As an experimental feature to debug objects visibility issues, we should add an
API method {{IgniteCache#withTrace()}} which will enable per-call API calls
tracing.
I think we can start with reads tracing, as a simplest change. We need to
introduce an additional flag mask to {{NearSingleGetRequest}},
{{NearGetRequest}}, {{Near...Response}} to identify such requests, and when
processing, print out all message processing path (send, receive), entry
swap/unswap, versions and values read, {{GridCacheEntryRemovedException}}s
encountered, etc. For transactional caches, I think it also makes sense to
print out all pending transactions that touch the key being read.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8031) MVCC TX: TxLog does not support partitions rebalance at the moment. We need to implement it.
[ https://issues.apache.org/jira/browse/IGNITE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-8031. -- Resolution: Fixed > MVCC TX: TxLog does not support partitions rebalance at the moment. We need > to implement it. > > > Key: IGNITE-8031 > URL: https://issues.apache.org/jira/browse/IGNITE-8031 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > Labels: mvcc, sql > > When new node joins to the cluster after the partitions rebalance it has > empty TxLog. And therefore all transactions committed before this join are > considered as uncommitted by this node. > Solution: > # introduce a special hint bits (most significant bits in operation > counter) which will be actualized whenever it is possible. > # such bits should be updated via CAS operation and the page, which > contains the data, should be marked as dirty even under read lock > # rebalance iterator returns only COMMITTED versions of row (the row must > have committed start version) with actualized hint bits for both create and > update versions. > # during force keys requests both COMMITTED rows and pending changes (rows > having ACTIVE start version) should be sent with actualized hint bits for > both create and update versions (if applicable). > # all readers check hint bits before checking with TxLog. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8371) MVCC TX: Force key request during rebalance may cause error on backups.
[ https://issues.apache.org/jira/browse/IGNITE-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-8371. -- Resolution: Fixed > MVCC TX: Force key request during rebalance may cause error on backups. > --- > > Key: IGNITE-8371 > URL: https://issues.apache.org/jira/browse/IGNITE-8371 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > Labels: mvcc > > When backup is updating during rebalance and the key to be updated in TX is > not supplied yet from the previous partition owner, backup makes force key > request in order to obtain this key and all its versions. But later this key > can be send to this backup from the previous owner once again as a part of > standard rebalance process. And this causes write conflict: we have to write > this key on the backup once again. > Solution: do not update key when it has already been written before (during > rebalance or force key request process). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8971) GridRestProcessor should propagate error message
[ https://issues.apache.org/jira/browse/IGNITE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544964#comment-16544964 ] Andrew Medvedev commented on IGNITE-8971: - [~skosarev] thank you for your comments, fixed > GridRestProcessor should propagate error message > > > Key: IGNITE-8971 > URL: https://issues.apache.org/jira/browse/IGNITE-8971 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Medvedev >Assignee: Andrew Medvedev >Priority: Major > > GridRestProcessor should propagate error message (stack trace) for handling > disk full error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544954#comment-16544954
]
Aleksey Plekhanov commented on IGNITE-602:
--
[~agoncharuk], I agreed with [~SomeFire]. {{SBLimitedLength}} and
{{IdentityHashMap}} used for different purposes. There is no place in code
where these two fields are used together. In my opinion combining them will not
make code cleaner.
> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by
> infinite recursion
>
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> See test
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
> and related TODO in same source file.
> Also take a look at
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
