[jira] [Commented] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762738#comment-17762738
]
Alexandr Shapkin commented on IGNITE-18302:
---
[~anovikov] LGTM in general, please fix a couple of minor things in PR before
merging.
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Affects Versions: 2.15
>Reporter: Alexandr Shapkin
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.16
>
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache,
> but it’s an internal non-static class, having a reference to the parent
> [\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
> Hence, during the serialization Ignite also writes {{{}name=this$0,
> type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
> {{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
> * we are serializing and saving internal utility data, like}} Ignite
> ignite{}}}, {{private IndexResolver indexResolver}} etc
> * one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
> {{IgniteCache sessions}} that basically keeps every
> session so far leading to a StackOverflow error after some time.
>
> {code:java}
> [2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
> Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
> msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
> topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
> ~[ignite-core-8.8.22.jar:8.8.22] 4 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
> ~[ignite-core-8.8.22.jar:8.8.22] 5 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
> ~[ignite-core-8.8.22.jar:8.8.22] 6 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 7 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
> ~[ignite-core-8.8.22.jar:8.8.22] 10 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
> ~[ignite-core-8.8.22.jar:8.8.22] 11 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
> ~[ignite-core-8.8.22.jar:8.8.22] 12 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
> ~[ignite-core-8.8.22.jar:8.8.22] 13 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 14 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
> 17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
> system error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.StackOverflowError]]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin reassigned IGNITE-18302:
-
Assignee: Andrey Novikov (was: Alexandr Shapkin)
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Alexandr Shapkin
>Assignee: Andrey Novikov
>Priority: Major
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache,
> but it’s an internal non-static class, having a reference to the parent
> [\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
> Hence, during the serialization Ignite also writes {{{}name=this$0,
> type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
> {{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
> * we are serializing and saving internal utility data, like}} Ignite
> ignite{}}}, {{private IndexResolver indexResolver}} etc
> * one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
> {{IgniteCache sessions}} that basically keeps every
> session so far leading to a StackOverflow error after some time.
>
> {code:java}
> [2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
> Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
> msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
> topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
> ~[ignite-core-8.8.22.jar:8.8.22] 4 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
> ~[ignite-core-8.8.22.jar:8.8.22] 5 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
> ~[ignite-core-8.8.22.jar:8.8.22] 6 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 7 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
> ~[ignite-core-8.8.22.jar:8.8.22] 10 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
> ~[ignite-core-8.8.22.jar:8.8.22] 11 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
> ~[ignite-core-8.8.22.jar:8.8.22] 12 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
> ~[ignite-core-8.8.22.jar:8.8.22] 13 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 14 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
> 17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
> system error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.StackOverflowError]]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-20139: -- Description: We tried to use machine learning capabilities, and discovered a bug in implementation of Random Forest. When comparing Ignite's output with python prototype (scikit-learn lib), we noticed that Ignite's predictions have much lower accuracy despite using the same data set and model parameters. Further investigation showed that Ignite generates decision trees that kinda "loop". The tree starts checking the same condition over and over until it reaches the maximum tree depth. I've attached a standalone reproducer which uses a small excerpt of our data set. It loads data from the csv file, then performs the training of the model for just 1 tree. Then the reproducer finds one of the looping branches and prints it. You will see that every single node in the branch uses the same feature, value and has then same calculated impurity. On my machine the code reproduces this issue 100% of time. I've also attached an example of the tree generated by python's scikit-learn on the same data set with the same parameters. In python the tree usually doesn't get deeper than 20 nodes. was: We tried to use GridGain's machine learning capabilities, and discovered a bug in GG's implementation of Random Forest. When comparing GG's output with python prototype (scikit-learn lib), we noticed that GG's predictions have much lower accuracy despite using the same data set and model parameters. Further investigation showed that GridGain generates decision trees that kinda "loop". The tree starts checking the same condition over and over until it reaches the maximum tree depth. I've attached a standalone reproducer which uses a small excerpt of our data set. It loads data from the csv file, then performs the training of the model for just 1 tree. Then the reproducer finds one of the looping branches and prints it. You will see that every single node in the branch uses the same feature, value and has then same calculated impurity. On my machine the code reproduces this issue 100% of time. I've also attached an example of the tree generated by python's scikit-learn on the same data set with the same parameters. In python the tree usually doesn't get deeper than 20 nodes. > RandomForestClassifierTrainer accuracy issue > > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Assignee: Igor Belyakov >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use machine learning capabilities, and discovered a bug in > implementation of Random Forest. When comparing Ignite's output with python > prototype (scikit-learn lib), we noticed that Ignite's predictions have much > lower accuracy despite using the same data set and model parameters. > Further investigation showed that Ignite generates decision trees that kinda > "loop". The tree starts checking the same condition over and over until it > reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750303#comment-17750303 ] Alexandr Shapkin commented on IGNITE-20139: --- [~zaleslaw] could you please take a look? Seems to be a valid issue alongside the attached reproducer. > RandomForestClassifierTrainer accuracy issue > > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use GridGain's machine learning capabilities, and discovered a > bug in GG's implementation of Random Forest. When comparing GG's output with > python prototype (scikit-learn lib), we noticed that GG's predictions have > much lower accuracy despite using the same data set and model parameters. > Further investigation showed that GridGain generates decision trees that > kinda "loop". The tree starts checking the same condition over and over until > it reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer accuracy issue
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-20139: -- Summary: RandomForestClassifierTrainer accuracy issue (was: RandomForestClassifierTrainer is checking the same conditions) > RandomForestClassifierTrainer accuracy issue > > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use GridGain's machine learning capabilities, and discovered a > bug in GG's implementation of Random Forest. When comparing GG's output with > python prototype (scikit-learn lib), we noticed that GG's predictions have > much lower accuracy despite using the same data set and model parameters. > Further investigation showed that GridGain generates decision trees that > kinda "loop". The tree starts checking the same condition over and over until > it reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20139) RandomForestClassifierTrainer is checking the same conditions
[ https://issues.apache.org/jira/browse/IGNITE-20139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-20139: -- Attachment: random-forest.zip TreeSample2_Portfolio_Change.png > RandomForestClassifierTrainer is checking the same conditions > - > > Key: IGNITE-20139 > URL: https://issues.apache.org/jira/browse/IGNITE-20139 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.15 >Reporter: Alexandr Shapkin >Priority: Major > Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip > > > We tried to use GridGain's machine learning capabilities, and discovered a > bug in GG's implementation of Random Forest. When comparing GG's output with > python prototype (scikit-learn lib), we noticed that GG's predictions have > much lower accuracy despite using the same data set and model parameters. > Further investigation showed that GridGain generates decision trees that > kinda "loop". The tree starts checking the same condition over and over until > it reaches the maximum tree depth. > I've attached a standalone reproducer which uses a small excerpt of our data > set. > It loads data from the csv file, then performs the training of the model for > just 1 tree. Then the reproducer finds one of the looping branches and prints > it. You will see that every single node in the branch uses the same feature, > value and has then same calculated impurity. > On my machine the code reproduces this issue 100% of time. > I've also attached an example of the tree generated by python's scikit-learn > on the same data set with the same parameters. In python the tree usually > doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20139) RandomForestClassifierTrainer is checking the same conditions
Alexandr Shapkin created IGNITE-20139: - Summary: RandomForestClassifierTrainer is checking the same conditions Key: IGNITE-20139 URL: https://issues.apache.org/jira/browse/IGNITE-20139 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.15 Reporter: Alexandr Shapkin Attachments: TreeSample2_Portfolio_Change.png, random-forest.zip We tried to use GridGain's machine learning capabilities, and discovered a bug in GG's implementation of Random Forest. When comparing GG's output with python prototype (scikit-learn lib), we noticed that GG's predictions have much lower accuracy despite using the same data set and model parameters. Further investigation showed that GridGain generates decision trees that kinda "loop". The tree starts checking the same condition over and over until it reaches the maximum tree depth. I've attached a standalone reproducer which uses a small excerpt of our data set. It loads data from the csv file, then performs the training of the model for just 1 tree. Then the reproducer finds one of the looping branches and prints it. You will see that every single node in the branch uses the same feature, value and has then same calculated impurity. On my machine the code reproduces this issue 100% of time. I've also attached an example of the tree generated by python's scikit-learn on the same data set with the same parameters. In python the tree usually doesn't get deeper than 20 nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19203) NPE on inserting data concurrently with table deletion
[
https://issues.apache.org/jira/browse/IGNITE-19203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-19203:
--
Description:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{code:java}
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748){code}
test code：
{code:java}
public class StartServer {
public static void main(String[] args)
{ Ignite ignite = Ignition.start(); } }{code}
{code:java}
public class StartClient01 {
public static void main(String[] args) {
Ignition.setClientMode(true);
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache("dummy");
cache.query(new SqlFieldsQuery("CREATE TABLE PRODUCT (" +
" ID INT(11)," +
" NAME CHAR(35)," +
" PRODUCTCODE CHAR(10)," +
" DISTRICT CHAR(100)," +
" NUMBER INT(11)," +
" PRIMARY KEY (ID)" +
") WITH \"TEMPLATE=REPLICATED, CACHE_NAME=PRODUCT\";"));
for (int i = 1; i <= 100; ++i) {
cache.query(new SqlFieldsQuery("INSERT INTO PRODUCT (ID, NAME,
PRODUCTCODE, DISTRICT, NUMBER) VALUES (?, ?, ?, ?, ?);")
.setArgs(i, "product" + i, "p" + i, "a product",
100)).getAll();
System.out.println(i);
}
}
} {code}
{code:java}
public class StartClient02 {
public static void main(String[] args) {
Ignition.setClientMode(true);
[jira] [Updated] (IGNITE-19203) NPE on inserting data concurrently with table deletion
[
https://issues.apache.org/jira/browse/IGNITE-19203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-19203:
--
Description:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{code:java}
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748){code}
test code：
{code:java}
public class StartServer {
public static void main(String[] args)
{ Ignite ignite = Ignition.start(); } }{code}
{code:java}
public class StartClient01 {
public static void main(String[] args) {
Ignition.setClientMode(true);
Ignite ignite = Ignition.start();
IgniteCache cache = ignite.getOrCreateCache("dummy");
cache.query(new SqlFieldsQuery("CREATE TABLE PRODUCT (" +
" ID INT(11)," +
" NAME CHAR(35)," +
" PRODUCTCODE CHAR(10)," +
" DISTRICT CHAR(100)," +
" NUMBER INT(11)," +
" PRIMARY KEY (ID)" +
") WITH \"TEMPLATE=REPLICATED, CACHE_NAME=PRODUCT\";"));
for (int i = 1; i <= 100; ++i) {
cache.query(new SqlFieldsQuery("INSERT INTO PRODUCT (ID, NAME,
PRODUCTCODE, DISTRICT, NUMBER) VALUES (?, ?, ?, ?, ?);")
.setArgs(i, "product" + i, "p" + i, "a product",
100)).getAll();
System.out.println(i);
}
}
} {code}
{{}}
{code:java}
public class StartClient02 {
public static void main(String[] args) {
[jira] [Updated] (IGNITE-19203) NPE on inserting data concurrently with table deletion
[
https://issues.apache.org/jira/browse/IGNITE-19203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-19203:
--
Description:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{code:java}
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748){code}
test code：
{{}}
{code:java}
public class StartServer {
public static void main(String[] args)
{ Ignite ignite = Ignition.start(); } }{code}
{{}}
was:
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{{}}
{code:java}
{code}
{{四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
[jira] [Created] (IGNITE-19203) NPE on inserting data concurrently with table deletion
Alexandr Shapkin created IGNITE-19203:
-
Summary: NPE on inserting data concurrently with table deletion
Key: IGNITE-19203
URL: https://issues.apache.org/jira/browse/IGNITE-19203
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Alexandr Shapkin
Occasionally, the following errors can be reproduced: The program that executes
the Insert statement does not report an error, The server node reported the
following error:
{{}}
{code:java}
{code}
{{四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Received message without registered handler (will ignore) [futId=2,
writeVer=null, msg=GridNearAtomicSingleUpdateFilterRequest
[filter=[o.a.i.i.processors.cache.CacheEntrySerializablePredicate@6ff66670],
parent=GridNearAtomicSingleUpdateRequest [key=null,
parent=GridNearAtomicAbstractSingleUpdateRequest [nodeId=null, futId=2,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2],
parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=needRes|keepBinary, node=01ece6ae-c041-4325-ae6a-810233d0a684,
locTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
msgTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], desc=null]
Registered listeners:
95945896=[GridNearAtomicAbstractUpdateRequest handler [msgIdx=0],
GridNearAtomicUpdateResponse handler [msgIdx=1], GridDhtAtomicUpdateRequest
handler [msgIdx=2], GridDhtAtomicUpdateResponse handler [msgIdx=3],
GridDhtAtomicDeferredUpdateResponse handler [msgIdx=4],
GridDhtAtomicNearResponse handler [msgIdx=5], GridNearAtomicCheckUpdateRequest
handler [msgIdx=6]]
四月 03, 2023 5:27:43 下午 org.apache.ignite.logger.java.JavaLogger error
严重: Failed to process failed message: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.prepareMarshal(UpdateErrors.java:134)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.prepareMarshal(GridNearAtomicUpdateResponse.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onSend(GridCacheIoManager.java:1239)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1274)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendResponseOnFailedMessage(GridCacheIoManager.java:652)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:1065)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:403)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1332)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4800(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1217)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:564)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748) }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin reassigned IGNITE-18302:
-
Assignee: Alexandr Shapkin
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Major
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache,
> but it’s an internal non-static class, having a reference to the parent
> [\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
> Hence, during the serialization Ignite also writes {{{}name=this$0,
> type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
> {{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
> * we are serializing and saving internal utility data, like}} Ignite
> ignite{}}}, {{private IndexResolver indexResolver}} etc
> * one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
> {{IgniteCache sessions}} that basically keeps every
> session so far leading to a StackOverflow error after some time.
>
> {code:java}
> [2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
> Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
> msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
> topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
> ~[ignite-core-8.8.22.jar:8.8.22] 4 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
> ~[ignite-core-8.8.22.jar:8.8.22] 5 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
> ~[ignite-core-8.8.22.jar:8.8.22] 6 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 7 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
> ~[ignite-core-8.8.22.jar:8.8.22] 10 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
> ~[ignite-core-8.8.22.jar:8.8.22] 11 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
> ~[ignite-core-8.8.22.jar:8.8.22] 12 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
> ~[ignite-core-8.8.22.jar:8.8.22] 13 at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
> ~[ignite-core-8.8.22.jar:8.8.22] 14 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
> 17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
> system error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.StackOverflowError]]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18427) .NET: Platform cache is not updated when ReadFromBackup is true
[ https://issues.apache.org/jira/browse/IGNITE-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652820#comment-17652820 ] Alexandr Shapkin commented on IGNITE-18427: --- [~ptupitsyn], looks good to me, thanks! > .NET: Platform cache is not updated when ReadFromBackup is true > --- > > Key: IGNITE-18427 > URL: https://issues.apache.org/jira/browse/IGNITE-18427 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.14 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ise > Fix For: 2.15 > > Attachments: IgniteReproducer.csproj, Test.cs > > > See attached reproducer. Client 2 has stale value when *ReadFromBackup = > true*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18247) .NET: Thin 3.0: LINQ: Operators and functions
[ https://issues.apache.org/jira/browse/IGNITE-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652485#comment-17652485 ] Alexandr Shapkin commented on IGNITE-18247: --- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: LINQ: Operators and functions > - > > Key: IGNITE-18247 > URL: https://issues.apache.org/jira/browse/IGNITE-18247 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Implement support for operators and functions in LINQ: > * Logic and arithmetic: ! + - * / = != % > * String functions: ToLower, ToUpper, Trim, Contains, etc (see > *MethodVisitor*) > * Date functions (see *MethodVisitor*) > * Math (Abs, Exp, Log, Pow, etc - see *MethodVisitor*) > * Regex -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17724) .NET: TestPrimaryNodeLeaveClearsPlatformCache is flaky
[ https://issues.apache.org/jira/browse/IGNITE-17724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652294#comment-17652294 ] Alexandr Shapkin commented on IGNITE-17724: --- LGTM > .NET: TestPrimaryNodeLeaveClearsPlatformCache is flaky > -- > > Key: IGNITE-17724 > URL: https://issues.apache.org/jira/browse/IGNITE-17724 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Apache.Ignite.Core.Tests.Cache.Platform.PlatformCacheTopologyChangeTest.TestPrimaryNodeLeaveClearsPlatformCache > is flaky. > https://ci.ignite.apache.org/test/-4466167631530075752?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18189) Merge ignite-spark 3.2 and 2.4 extensions into a single module
[ https://issues.apache.org/jira/browse/IGNITE-18189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-18189: -- Fix Version/s: 2.14 > Merge ignite-spark 3.2 and 2.4 extensions into a single module > -- > > Key: IGNITE-18189 > URL: https://issues.apache.org/jira/browse/IGNITE-18189 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.14 > > > We need to do the following > a) release ignite-spark 1.0.0 extension > b) merge ignite-spark and ignite-spark-3.2 modules > c) release ignite-spark 2.0.0 extension (with spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18315) [Extensions] Release Ignite Spring Extensions
[ https://issues.apache.org/jira/browse/IGNITE-18315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin reassigned IGNITE-18315: - Component/s: extensions Assignee: Alexandr Shapkin Description: We need to release Ithe following Ignite Spring extensions: - 2.0.0 (Spark 2.4) - 3.0.0 (Spark 3.2) > [Extensions] Release Ignite Spring Extensions > -- > > Key: IGNITE-18315 > URL: https://issues.apache.org/jira/browse/IGNITE-18315 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > > We need to release Ithe following Ignite Spring extensions: > - 2.0.0 (Spark 2.4) > - 3.0.0 (Spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18315) [Extensions] Release Ignite Spring Extensions
Alexandr Shapkin created IGNITE-18315: - Summary: [Extensions] Release Ignite Spring Extensions Key: IGNITE-18315 URL: https://issues.apache.org/jira/browse/IGNITE-18315 Project: Ignite Issue Type: Task Reporter: Alexandr Shapkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
[
https://issues.apache.org/jira/browse/IGNITE-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-18302:
--
Description:
In short, there is a bug in ignite-spring-session-ext implementation.
We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache, but
it’s an internal non-static class, having a reference to the parent
[\{{{}IgniteIndexedSessionRepository{}}}] indirectly.
Hence, during the serialization Ignite also writes {{{}name=this$0,
type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
{{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
* we are serializing and saving internal utility data, like}} Ignite
ignite{}}}, {{private IndexResolver indexResolver}} etc
* one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
{{IgniteCache sessions}} that basically keeps every
session so far leading to a StackOverflow error after some time.
{code:java}
[2022-11-25T17:27:29,268][ERROR][sys-stripe-0-#1%USERS_IGNITE%][GridCacheIoManager]
Failed processing message [senderId=0f0ca915-d6cd-4580-92a3-1fbc3d2a5722,
msg=GridNearSingleGetResponse [futId=1669397231378, res=-547701325,
topVer=null, err=null, flags=0]] 2java.lang.StackOverflowError: null 3 at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:328)
~[ignite-core-8.8.22.jar:8.8.22] 4 at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:273)
~[ignite-core-8.8.22.jar:8.8.22] 5 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:354)
~[ignite-core-8.8.22.jar:8.8.22] 6 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
~[ignite-core-8.8.22.jar:8.8.22] 7 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 8 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 9 at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.readExternal(GridCacheProxyImpl.java:1662)
~[ignite-core-8.8.22.jar:8.8.22] 10 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:569)
~[ignite-core-8.8.22.jar:8.8.22] 11 at
org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:979)
~[ignite-core-8.8.22.jar:8.8.22] 12 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:359)
~[ignite-core-8.8.22.jar:8.8.22] 13 at
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:211)
~[ignite-core-8.8.22.jar:8.8.22] 14 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:480) ~[?:?] 15 at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:447) ~[?:?] 16...
17[2022-11-25T17:27:29,276][ERROR][sys-stripe-0-#1%USERS_IGNITE%][] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR,
err=java.lang.StackOverflowError]]{code}
was:
In short, there is a bug in ignite-spring-session-ext implementation.
We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache, but
it’s an internal non-static class, having a reference to the parent
[{{{}IgniteIndexedSessionRepository{}}}] indirectly.
Hence, during the serialization Ignite also writes {{{}name=this$0,
type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
{{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
* we are serializing and saving internal utility data, like{{{} Ignite
ignite{}}}, {{private IndexResolver indexResolver}} etc
* one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
{{IgniteCache sessions}} that basically keeps every
session so far leading to a StackOverflow error after some time.
> ignite-spring-sessions: IgniteSession serialization drags its parent class
> --
>
> Key: IGNITE-18302
> URL: https://issues.apache.org/jira/browse/IGNITE-18302
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Alexandr Shapkin
>Priority: Major
>
> In short, there is a bug in ignite-spring-session-ext implementation.
> We store IgniteIndexedSessionRepository${{{}IgniteSession{}}}
[jira] [Created] (IGNITE-18302) ignite-spring-sessions: IgniteSession serialization drags its parent class
Alexandr Shapkin created IGNITE-18302:
-
Summary: ignite-spring-sessions: IgniteSession serialization drags
its parent class
Key: IGNITE-18302
URL: https://issues.apache.org/jira/browse/IGNITE-18302
Project: Ignite
Issue Type: Bug
Components: extensions
Reporter: Alexandr Shapkin
In short, there is a bug in ignite-spring-session-ext implementation.
We store IgniteIndexedSessionRepository${{{}IgniteSession{}}} in the cache, but
it’s an internal non-static class, having a reference to the parent
[{{{}IgniteIndexedSessionRepository{}}}] indirectly.
Hence, during the serialization Ignite also writes {{{}name=this$0,
type=Object, fieldId=0xCBDD23AA (-874699862){}}}, which is the reference to
{{{}IgniteIndexedSessionRepository{}}}. That leads to the following issues:
* we are serializing and saving internal utility data, like{{{} Ignite
ignite{}}}, {{private IndexResolver indexResolver}} etc
* one of the IgniteIndexedSessionRepository’s fields is IgniteCache itself -
{{IgniteCache sessions}} that basically keeps every
session so far leading to a StackOverflow error after some time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18189) Merge ignite-spark 3.2 and 2.4 extensions into a single module
Alexandr Shapkin created IGNITE-18189: - Summary: Merge ignite-spark 3.2 and 2.4 extensions into a single module Key: IGNITE-18189 URL: https://issues.apache.org/jira/browse/IGNITE-18189 Project: Ignite Issue Type: Task Components: extensions Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin We need to do the following a) release ignite-spark 1.0.0 extension b) merge ignite-spark and ignite-spark-3.2 modules c) release ignite-spark 2.0.0 extension (with spark 3.2) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17147) Ignite should not talk to kubernetes default service to get its own IP
[ https://issues.apache.org/jira/browse/IGNITE-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557442#comment-17557442 ] Alexandr Shapkin commented on IGNITE-17147: --- [~laptimus] Could you please elaborate on this task? What's you improvement suggestion? Am I right that you are referring to this configuration: [https://www.gridgain.com/sdk/latest/javadoc/org/apache/ignite/kubernetes/configuration/KubernetesConnectionConfiguration.html#setMasterUrl-java.lang.String-] and its default value - 'https://kubernetes.default.svc.cluster.local:443'? > Ignite should not talk to kubernetes default service to get its own IP > -- > > Key: IGNITE-17147 > URL: https://issues.apache.org/jira/browse/IGNITE-17147 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.11.1 > Environment: Kubernetes >Reporter: laptimus >Priority: Major > > Ignite should not talk to kubernetes default service to get its own IP > We have kubernetes cluster with calico network policies and seems like ignite > is the only application in our cluster that needs access to kubernetes > default service > I see this as a security risk > Please implement an alternative way in IP Finder as that the class that talks > to kubernetes default service to know pod IP address > > thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528345#comment-17528345
]
Alexandr Shapkin commented on IGNITE-16124:
---
[~NSAmelchev] Thanks for the clarification!
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Michael Reiche
>Assignee: Andrey Belyaev
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
>
> If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
> deleteAll is flagged
> java: name clash: deleteAll(java.lang.Iterable com.example.ignite.EmployeeDTO>) in
> org.springframework.data.repository.CrudRepository and
> deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository have the same
> erasure, yet neither overrides the other
> And 2.2-ext gives the following:
> org.apache.ignite
> ignite-spring-data-2.2-ext
> 1.0.0
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata22.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
> package com.example.ignite;
> import org.apache.ignite.springdata.repository.IgniteRepository;
> import org.apache.ignite.springdata.repository.config.RepositoryConfig;
> @RepositoryConfig(cacheName = "myCache")
> public interface EmployeeRepository extends
> IgniteRepository
> { EmployeeDTO getEmployeeDTOById(ID id); }
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528337#comment-17528337
]
Alexandr Shapkin commented on IGNITE-16124:
---
[~NSAmelchev] [~Mmuzaf] guys, do you know if there are any plans on release?
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Michael Reiche
>Assignee: Andrey Belyaev
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
>
> If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
> deleteAll is flagged
> java: name clash: deleteAll(java.lang.Iterable com.example.ignite.EmployeeDTO>) in
> org.springframework.data.repository.CrudRepository and
> deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository have the same
> erasure, yet neither overrides the other
> And 2.2-ext gives the following:
> org.apache.ignite
> ignite-spring-data-2.2-ext
> 1.0.0
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata22.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
> package com.example.ignite;
> import org.apache.ignite.springdata.repository.IgniteRepository;
> import org.apache.ignite.springdata.repository.config.RepositoryConfig;
> @RepositoryConfig(cacheName = "myCache")
> public interface EmployeeRepository extends
> IgniteRepository
> { EmployeeDTO getEmployeeDTOById(ID id); }
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16568) Kubernetes cluster might split apart on initialization
[ https://issues.apache.org/jira/browse/IGNITE-16568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16568: -- Description: The issue is mostly about Kubernetes/Openshift deployment but could also affect other scenarios relying on external services (AWS?). Consider the following case: multiple nodes (PODs) were started simultaneously and all of them are trying to locate if there are other nodes available using *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered IPs. Since there is no delay or retry attempt, all nodes could be returned with an empty IPs list and decide to be a coordinator, i.e. to start multiple independent grids. Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a configurable delay or repetitions counter to check if there is a non-empty list of available IPs. was: The issue is mostly about Kubernetes/Openshift deployment but could also be true for other scenarios relying on external services (AWS?). Consider the following case: multiple nodes (PODs) were started simultaneously and all of them are trying to locate if there are other nodes available using *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered IPs. Since there is no delay or retry attempt, all nodes could be returned with an empty IPs list and decide to be a coordinator, i.e. to start multiple independent grids. Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a configurable delay or repetitions counter to check if there is a non-empty list of available IPs. > Kubernetes cluster might split apart on initialization > -- > > Key: IGNITE-16568 > URL: https://issues.apache.org/jira/browse/IGNITE-16568 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.11.1 >Reporter: Alexandr Shapkin >Priority: Major > Labels: Kubernetes > > The issue is mostly about Kubernetes/Openshift deployment but could also > affect other scenarios relying on external services (AWS?). > Consider the following case: multiple nodes (PODs) were started > simultaneously and all of them are trying to locate if there are other nodes > available using > *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered > IPs. Since there is no delay or retry attempt, all nodes could be returned > with an empty IPs list and decide to be a coordinator, i.e. to start multiple > independent grids. > > Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a > configurable delay or repetitions counter to check if there is a non-empty > list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16568) Kubernetes cluster might split apart on initialization
[ https://issues.apache.org/jira/browse/IGNITE-16568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16568: -- External issue URL: https://stackoverflow.com/questions/71118869/openshift-k8s-issue-with-project-pods-not-joining-same-grid-but-rather-create-m Labels: Kubernetes (was: ) > Kubernetes cluster might split apart on initialization > -- > > Key: IGNITE-16568 > URL: https://issues.apache.org/jira/browse/IGNITE-16568 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Alexandr Shapkin >Priority: Major > Labels: Kubernetes > > The issue is mostly about Kubernetes/Openshift deployment but could also be > true for other scenarios relying on external services (AWS?). > Consider the following case: multiple nodes (PODs) were started > simultaneously and all of them are trying to locate if there are other nodes > available using > *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered > IPs. Since there is no delay or retry attempt, all nodes could be returned > with an empty IPs list and decide to be a coordinator, i.e. to start multiple > independent grids. > > Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a > configurable delay or repetitions counter to check if there is a non-empty > list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16568) Kubernetes cluster might split apart on initialization
[ https://issues.apache.org/jira/browse/IGNITE-16568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16568: -- Affects Version/s: 2.11.1 > Kubernetes cluster might split apart on initialization > -- > > Key: IGNITE-16568 > URL: https://issues.apache.org/jira/browse/IGNITE-16568 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.11.1 >Reporter: Alexandr Shapkin >Priority: Major > Labels: Kubernetes > > The issue is mostly about Kubernetes/Openshift deployment but could also be > true for other scenarios relying on external services (AWS?). > Consider the following case: multiple nodes (PODs) were started > simultaneously and all of them are trying to locate if there are other nodes > available using > *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered > IPs. Since there is no delay or retry attempt, all nodes could be returned > with an empty IPs list and decide to be a coordinator, i.e. to start multiple > independent grids. > > Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a > configurable delay or repetitions counter to check if there is a non-empty > list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16568) Kubernetes cluster might split apart on initialization
Alexandr Shapkin created IGNITE-16568: - Summary: Kubernetes cluster might split apart on initialization Key: IGNITE-16568 URL: https://issues.apache.org/jira/browse/IGNITE-16568 Project: Ignite Issue Type: Bug Components: networking Reporter: Alexandr Shapkin The issue is mostly about Kubernetes/Openshift deployment but could also be true for other scenarios relying on external services (AWS?). Consider the following case: multiple nodes (PODs) were started simultaneously and all of them are trying to locate if there are other nodes available using *_TcpDiscoveryKubernetesIpFinder._* that just returns a set of registered IPs. Since there is no delay or retry attempt, all nodes could be returned with an empty IPs list and decide to be a coordinator, i.e. to start multiple independent grids. Proposed changes: extend TcpDiscoveryKubernetesIpFinder with either a configurable delay or repetitions counter to check if there is a non-empty list of available IPs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16435) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-16435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin resolved IGNITE-16435. --- Resolution: Fixed [~hoter] Thanks for the contribution! > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-16435 > URL: https://issues.apache.org/jira/browse/IGNITE-16435 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Trivial > > Please add an event to [https://ignite.apache.org/events.html] > Event Date: February, 16 > h1. Apache Ignite Community Gathering: Ignite 3 Alpha 4 > During this community gathering, we will discuss the latest Ignite releases: > - Apache Ignite 2.12 overview > - Apache Ignite 3 Alpha 4: The Next Milestone > - Transactions API in Apache Ignite 3 > ___ > Maxim Timonin, Apache Ignite Committer and Software Engineer at SberTech will > present a brief overview of the Apache Ignite 2.12 release. > Apache Ignite 3 Alpha 4: The Next Milestone > Apache Ignite 3 is the next generation of the Apache Ignite platform. Ignite > 3 modernizes and improves Ignite’s usability while retaining its power and > flexibility. The Alpha 4 build is the latest release of the Ignite 3 project. > Val Kulichenko, Apache Ignite PMC member and the Ignite 3.0 Release manager, > will present the Ignite 3 Alpha 4 overview, including new features Object > Mappings for Table Views and DDL. > Transactions API in Ignite 3 > Alexey Scherbakov, Apache Ignite Committer, and architect at GridGain will > show Ignite 3 just released in Alpha 4 build transactional API. We will take > a glance over: > - a transaction lifecycle > - how to manage transactions > - examples of synchronous and asynchronous transactions > Learn more: > [https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/283606359] > Сhange the text on the banner [Apache Ignite Documentation | Ignite > Documentation|https://ignite.apache.org/docs/latest/] > from: > [Ignite Summit: Сloud Edition | Using Ignite In The Cloud - Watch On Demand > →|https://ignite-summit.org/] > to: > Apache Ignite Community Gathering: Ignite 3 Alpha 4. Join us! (link to > [Apache Ignite Community Gathering: Ignite 3 Alpha 4 | > Meetup|https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/283606359]) > h1. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452420#comment-17452420 ] Alexandr Shapkin commented on IGNITE-16038: --- Aleksey, thanks a lot for sorting this out! > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452408#comment-17452408 ] Alexandr Shapkin commented on IGNITE-16038: --- Wow, that sounds good. Could you please share a ticket number with the planned compactFooter change? If it has not been created yet, we might use this ticket for that change. > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452403#comment-17452403 ] Alexandr Shapkin commented on IGNITE-16038: --- [~alex_pl] Yes, that's correct, it is a potential compatibility break. I also find the case when a client can't read a value inserted by a thick client or vice versa counterintuitive. We just don't have any warnings or reasons that explain the problem with having different compact footers. Consider this: * a user starts a vanilla server node and performs cache#put(myKey, myVal) * then it starts a default thin client and is trying to get a value with thinCache.get(myKey) * ??? why there is no value found, seems like Ignite is broken... In a very safe implementation, we might yield a WARN in a client's (java version don't have it yet if I remember correctly) or server's logs with respect to the binary configuration mismatch and provide a user with the right direction on how to fix that. But I'd say we need to implement the change just like it's written in IEP and set compactFooter=serverValue. Well, we might add just another Ignite property to disable this feature and some announcements in release docs are welcome. Anyway, my biggest concern is that - it's very confusing for the end-users. WDYT? > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452403#comment-17452403 ] Alexandr Shapkin edited comment on IGNITE-16038 at 12/2/21, 1:16 PM: - [~alex_pl] Yes, that's correct, it is a potential compatibility break. I also find the case when a client can't read a value inserted by a thick client or vice versa counterintuitive. We just don't have any warnings or reasons that explain the problem with having different compact footers. Consider this: * a user starts a vanilla server node and performs cache#put(myKey, myVal) [compactFooter=true] * then it starts a default thin client and is trying to get a value with thinCache.get(myKey) [compactFooter=false] * ??? why there is no value found, seems like Ignite is broken... In a very safe implementation, we might yield a WARN in a client's (java version don't have it yet if I remember correctly) or server's logs with respect to the binary configuration mismatch and provide a user with the right direction on how to fix that. But I'd say we need to implement the change just like it's written in IEP and set compactFooter=serverValue. Well, we might add just another Ignite property to disable this feature and some announcements in release docs are welcome. Anyway, my biggest concern is that - it's very confusing for the end-users. WDYT? was (Author: ashapkin): [~alex_pl] Yes, that's correct, it is a potential compatibility break. I also find the case when a client can't read a value inserted by a thick client or vice versa counterintuitive. We just don't have any warnings or reasons that explain the problem with having different compact footers. Consider this: * a user starts a vanilla server node and performs cache#put(myKey, myVal) * then it starts a default thin client and is trying to get a value with thinCache.get(myKey) * ??? why there is no value found, seems like Ignite is broken... In a very safe implementation, we might yield a WARN in a client's (java version don't have it yet if I remember correctly) or server's logs with respect to the binary configuration mismatch and provide a user with the right direction on how to fix that. But I'd say we need to implement the change just like it's written in IEP and set compactFooter=serverValue. Well, we might add just another Ignite property to disable this feature and some announcements in release docs are welcome. Anyway, my biggest concern is that - it's very confusing for the end-users. WDYT? > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from server
[ https://issues.apache.org/jira/browse/IGNITE-16038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-16038: -- Summary: Java Thin Client: Retrieve binary configuration from server (was: Java Thin Client: Retrieve binary configuration from serve) > Java Thin Client: Retrieve binary configuration from server > --- > > Key: IGNITE-16038 > URL: https://issues.apache.org/jira/browse/IGNITE-16038 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11 >Reporter: Alexandr Shapkin >Priority: Major > > Thin clients require manual binary configuration currently. Settings like > compact footer and simple/full name mapper should be set to match the cluster > settings. Extend the protocol to retrieve those settings automatically on > start. > > I.e. it's impossible to read a value inserted by a thick client with java > thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16038) Java Thin Client: Retrieve binary configuration from serve
Alexandr Shapkin created IGNITE-16038: - Summary: Java Thin Client: Retrieve binary configuration from serve Key: IGNITE-16038 URL: https://issues.apache.org/jira/browse/IGNITE-16038 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.11 Reporter: Alexandr Shapkin Thin clients require manual binary configuration currently. Settings like compact footer and simple/full name mapper should be set to match the cluster settings. Extend the protocol to retrieve those settings automatically on start. I.e. it's impossible to read a value inserted by a thick client with java thin client without specifying compactFooter=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15542) walTotalSize incorrectly reported when wal archiving is turned off.
[ https://issues.apache.org/jira/browse/IGNITE-15542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418596#comment-17418596 ] Alexandr Shapkin commented on IGNITE-15542: --- Merged to master f9bd7b73682ff9dd2865fdb559816367fc2d65b8 > walTotalSize incorrectly reported when wal archiving is turned off. > --- > > Key: IGNITE-15542 > URL: https://issues.apache.org/jira/browse/IGNITE-15542 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.11 >Reporter: Alexander Korenshteyn >Assignee: Alexander Korenshteyn >Priority: Major > Fix For: 2.12 > > Attachments: walTotalSize-Metric.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > to reproduce > disable wal archive by setting the wal path the same as the wal archive path. > In this case the walTotalSize will incorrectly add all files present in wal > archive dir. > > picture of affected metric attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15542) walTotalSize incorrectly reported when wal archiving is turned off.
[ https://issues.apache.org/jira/browse/IGNITE-15542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-15542: -- Reviewer: Alexandr Shapkin > walTotalSize incorrectly reported when wal archiving is turned off. > --- > > Key: IGNITE-15542 > URL: https://issues.apache.org/jira/browse/IGNITE-15542 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.11 >Reporter: Alexander Korenshteyn >Assignee: Alexander Korenshteyn >Priority: Major > Fix For: 2.12 > > Attachments: walTotalSize-Metric.png > > Time Spent: 10m > Remaining Estimate: 0h > > to reproduce > disable wal archive by setting the wal path the same as the wal archive path. > In this case the walTotalSize will incorrectly add all files present in wal > archive dir. > > picture of affected metric attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
[ https://issues.apache.org/jira/browse/IGNITE-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391488#comment-17391488 ] Alexandr Shapkin commented on IGNITE-15204: --- Yes, that's doable, we can also adjust the protocol to include them. But the thing is - for 3.0 this is going to work out of the box if I get it right. Either way, yes, it looks like not a big deal. > SQL exception to be handled by thin clients [CPP] > - > > Key: IGNITE-15204 > URL: https://issues.apache.org/jira/browse/IGNITE-15204 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Alexandr Shapkin >Priority: Major > > It would be nice to have meaningful error descriptions (like using ODBC) > instead of general ones. > For sample, working with SQL from a thin client it's impossible to get these > errors: > Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, > Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > > Looks like the easiest way would be to wait for Ignite 3.0 release with the > new thin client protocol, but I think we can make some extension to the 2.x > protocol as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
[ https://issues.apache.org/jira/browse/IGNITE-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-15204: -- Description: It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND Looks like the easiest way would be to wait for Ignite 3.0 release with the new thin clint protocol, but I think we can make some extension to the 2.x protocol as well. was: It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > SQL exception to be handled by thin clients [CPP] > - > > Key: IGNITE-15204 > URL: https://issues.apache.org/jira/browse/IGNITE-15204 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Alexandr Shapkin >Priority: Major > > It would be nice to have meningful error descriptions (like using ODBC) > instead of general ones. > For sample, working with SQL from a thin client it's impossible to get these > errors: > Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, > Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > > Looks like the easiest way would be to wait for Ignite 3.0 release with the > new thin clint protocol, but I think we can make some extension to the 2.x > protocol as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
[ https://issues.apache.org/jira/browse/IGNITE-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-15204: -- Description: It would be nice to have meaningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND Looks like the easiest way would be to wait for Ignite 3.0 release with the new thin client protocol, but I think we can make some extension to the 2.x protocol as well. was: It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND Looks like the easiest way would be to wait for Ignite 3.0 release with the new thin clint protocol, but I think we can make some extension to the 2.x protocol as well. > SQL exception to be handled by thin clients [CPP] > - > > Key: IGNITE-15204 > URL: https://issues.apache.org/jira/browse/IGNITE-15204 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Alexandr Shapkin >Priority: Major > > It would be nice to have meaningful error descriptions (like using ODBC) > instead of general ones. > For sample, working with SQL from a thin client it's impossible to get these > errors: > Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, > Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > > Looks like the easiest way would be to wait for Ignite 3.0 release with the > new thin client protocol, but I think we can make some extension to the 2.x > protocol as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
Alexandr Shapkin created IGNITE-15204: - Summary: SQL exception to be handled by thin clients [CPP] Key: IGNITE-15204 URL: https://issues.apache.org/jira/browse/IGNITE-15204 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Alexandr Shapkin It would be nice to have meningful error descriptions (like using ODBC) instead of general ones. For sample, working with SQL from a thin client it's impossible to get these errors: Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15197) Incorrect code snippet for Azure Kubernetes Deployment
Alexandr Shapkin created IGNITE-15197:
-
Summary: Incorrect code snippet for Azure Kubernetes Deployment
Key: IGNITE-15197
URL: https://issues.apache.org/jira/browse/IGNITE-15197
Project: Ignite
Issue Type: Bug
Components: documentation
Reporter: Alexandr Shapkin
Assignee: Nikita Safonov
See the docs: [
https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment|https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment]
h3. Creating ConfigMap for Node Configuration File
Two tabs: Configuration without persistence and Configuration with persistence
Need to fix "node-configuration.xml" to be a valid XML file, like this one for
"Configuration without persistence"
{code:java}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
I.e. all code samples have to include
{code:java}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
...
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15113) CPP: Thin Client Compute
Alexandr Shapkin created IGNITE-15113: - Summary: CPP: Thin Client Compute Key: IGNITE-15113 URL: https://issues.apache.org/jira/browse/IGNITE-15113 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Alexandr Shapkin Add Compute to C++Thin Client. See IGNITE-12853. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15073) C++ Extend platforms API to call Java versioned entry processor
[
https://issues.apache.org/jira/browse/IGNITE-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-15073:
--
Affects Version/s: 2.11
> C++ Extend platforms API to call Java versioned entry processor
> ---
>
> Key: IGNITE-15073
> URL: https://issues.apache.org/jira/browse/IGNITE-15073
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.11
>Reporter: Alexandr Shapkin
>Priority: Major
>
> In case of a mixed cluster (Java server and C++ client for sample) it's not
> possible to use an entry processor since it requires a native
> platform-specific implementation to be defined on both sides.
> Let's extend platforms interop API to have a new methods
> cache.invokeJava("key", "java_task_name", args) similar to
> compute.ExecuteJavaTask.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15073) C++ Extend platforms API to call Java versioned entry processor
Alexandr Shapkin created IGNITE-15073:
-
Summary: C++ Extend platforms API to call Java versioned entry
processor
Key: IGNITE-15073
URL: https://issues.apache.org/jira/browse/IGNITE-15073
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Alexandr Shapkin
In case of a mixed cluster (Java server and C++ client for sample) it's not
possible to use an entry processor since it requires a native platform-specific
implementation to be defined on both sides.
Let's extend platforms interop API to have a new methods
cache.invokeJava("key", "java_task_name", args) similar to
compute.ExecuteJavaTask.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
[ https://issues.apache.org/jira/browse/IGNITE-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-14324: -- Release Note: Fixed an issue that prevented a node from startup in case it can't obtain IP addresses to connect to > EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s > > > Key: IGNITE-14324 > URL: https://issues.apache.org/jira/browse/IGNITE-14324 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Labels: discovery > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Scenario: > Kubernetes world, a server node, a k8s service, and a thick client. The > client is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected > to the server node. > When a service goes down alongside the server, no > EVT_CLIENT_NODE_DISCONNECTED is caught and the client reports only about a > socket exception and inability to resolve IP addresses from the services, > cause k8s resource is not available. The DEBUG logs (attached) show that > discovery is constantly trying to use KubernetesIpFinder and restore the > connection. > Expected: > Discovery realizes that a client is disconnected, no more reconnection > attempts happen and EVT_CLIENT_NODE_DISCONNECTED is thrown. > Solution: > Count resolution attempts and if it’s more than the threshold (2 if > failuredetectiontimeout is not configured, otherwise #reconnCount) give up > and invoke disconnection logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
[ https://issues.apache.org/jira/browse/IGNITE-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17323802#comment-17323802 ] Alexandr Shapkin commented on IGNITE-14324: --- [~ibessonov] could you please take a look? > EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s > > > Key: IGNITE-14324 > URL: https://issues.apache.org/jira/browse/IGNITE-14324 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Labels: discovery > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Scenario: > Kubernetes world, a server node, a k8s service, and a thick client. The > client is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected > to the server node. > When a service goes down alongside the server, no > EVT_CLIENT_NODE_DISCONNECTED is caught and the client reports only about a > socket exception and inability to resolve IP addresses from the services, > cause k8s resource is not available. The DEBUG logs (attached) show that > discovery is constantly trying to use KubernetesIpFinder and restore the > connection. > Expected: > Discovery realizes that a client is disconnected, no more reconnection > attempts happen and EVT_CLIENT_NODE_DISCONNECTED is thrown. > Solution: > Count resolution attempts and if it’s more than the threshold (2 if > failuredetectiontimeout is not configured, otherwise #reconnCount) give up > and invoke disconnection logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
Alexandr Shapkin created IGNITE-14324: - Summary: EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s Key: IGNITE-14324 URL: https://issues.apache.org/jira/browse/IGNITE-14324 Project: Ignite Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.11 Scenario: Kubernetes world, a server node, a k8s service, and a thick client. The client is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected to the server node. When a service goes down alongside the server, no EVT_CLIENT_NODE_DISCONNECTED is caught and the client reports only about a socket exception and inability to resolve IP addresses from the services, cause k8s resource is not available. The DEBUG logs (attached) show that discovery is constantly trying to use KubernetesIpFinder and restore the connection. Expected: Discovery realizes that a client is disconnected, no more reconnection attempts happen and EVT_CLIENT_NODE_DISCONNECTED is thrown. Solution: Count resolution attempts and if it’s more than the threshold (2 if failuredetectiontimeout is not configured, otherwise #reconnCount) give up and invoke disconnection logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12090) .NET: logger throws KeyNotFound on creating cache with nullable 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262292#comment-17262292
]
Alexandr Shapkin commented on IGNITE-12090:
---
[~ptupitsyn] thanks, can you merge the changes?
> .NET: logger throws KeyNotFound on creating cache with nullable 'sbyte?' field
> --
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Attachments: a.cs
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> Logger throws KeyNotFound exception if NetToJava[type] doesn't have a _type_
> key.
> Looks like we need to replace it with NetToJava[directType].
> {code:java}
> public static void LogIndirectMappingWarning(Type type, ILogger log, string
> logInfo)
> {
> if (type == null)
> return;
> var directType = GetDirectlyMappedType(type);
> if (directType == type)
> return;
> log.Warn("{0}: Type '{1}' maps to Java type '{2}' using unchecked conversion.
> " +
> "This may cause issues in SQL queries. " +
> "You can use '{3}' instead to achieve direct mapping.",
> logInfo, type, NetToJava[type], directType);
> }
> {code}
>
> Steps to reproduce:
> Define a QueryEntity with a sbyte? nullable field, try to create a cache. The
> reproducer is attached.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12090) .NET: logger throws KeyNotFound on creating cache with nullable 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-12090:
--
Summary: .NET: logger throws KeyNotFound on creating cache with nullable
'sbyte?' field (was: .NET logging exception when creating cache with nullable
'sbyte?' field)
> .NET: logger throws KeyNotFound on creating cache with nullable 'sbyte?' field
> --
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Attachments: a.cs
>
>
>
> Logger throws KeyNotFound exception if NetToJava[type] doesn't have a _type_
> key.
> Looks like we need to replace it with NetToJava[directType].
> {code:java}
> public static void LogIndirectMappingWarning(Type type, ILogger log, string
> logInfo)
> {
> if (type == null)
> return;
> var directType = GetDirectlyMappedType(type);
> if (directType == type)
> return;
> log.Warn("{0}: Type '{1}' maps to Java type '{2}' using unchecked conversion.
> " +
> "This may cause issues in SQL queries. " +
> "You can use '{3}' instead to achieve direct mapping.",
> logInfo, type, NetToJava[type], directType);
> }
> {code}
>
> Steps to reproduce:
> Define a QueryEntity with a sbyte? nullable field, try to create a cache. The
> reproducer is attached.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13908) ODBC driver should show real nullability info
[ https://issues.apache.org/jira/browse/IGNITE-13908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254830#comment-17254830 ] Alexandr Shapkin commented on IGNITE-13908: --- [~isapego] LGTM > ODBC driver should show real nullability info > - > > Key: IGNITE-13908 > URL: https://issues.apache.org/jira/browse/IGNITE-13908 > Project: Ignite > Issue Type: Improvement > Components: odbc >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > > Currently, it always return SQL_NULLABLE_UNKNOWN on request of nullability > type of the column. > Let's provide that information to the user of ODBC driver -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13900) CPP: Fix test flaky Affinity tests
[ https://issues.apache.org/jira/browse/IGNITE-13900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254490#comment-17254490 ] Alexandr Shapkin commented on IGNITE-13900: --- [~isapego] LGTM > CPP: Fix test flaky Affinity tests > -- > > Key: IGNITE-13900 > URL: https://issues.apache.org/jira/browse/IGNITE-13900 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Some CPP affinity tests are flaky on TC. For example, > IgniteAffinityMapPartitionsToNodes, IgniteAffinityCall, > IgniteAffinityCallAsync. Need to fix them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13822) NPE in SQL query [with xxx as (select xxx)]
Alexandr Shapkin created IGNITE-13822:
-
Summary: NPE in SQL query [with xxx as (select xxx)]
Key: IGNITE-13822
URL: https://issues.apache.org/jira/browse/IGNITE-13822
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.9
Reporter: Alexandr Shapkin
We use '*with xxx as (select xxx)* ', which works very fine in 2.8.1 and other
past release versions. After we upgrade to 2.9.0, such SQL starts to throw an
exception.
Note, the SQL works fine while Ignite just started. The error happens after
Ignite runs a while. And after that, the error seems to happen every time.
{code:java}
args=Object[] [], stmtType=SELECT_STATEMENT_TYPE, autoCommit=true,
partResReq=false, super=JdbcRequest [type=2, reqId=790418]]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
to parse query. General error: "java.lang.NullPointerException" [5-197]
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:194)
at
org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:355)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:222)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1071)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2779)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2775)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3338)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$2(GridQueryProcessor.java:2795)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2833)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2769)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2727)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:647)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:320)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:257)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:202)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:56)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
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)
Caused by: org.h2.jdbc.JdbcSQLException: General error:
"java.lang.NullPointerException" [5-197]
at
org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:168)
at org.h2.message.DbException.convert(DbException.java:307)
at
org.h2.message.DbException.toSQLException(DbException.java:280)
at org.h2.message.TraceObject.logAndConvert(TraceObject.java:357)
at
org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:697)
at
org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
... 26 more
Caused by: java.lang.NullPointerException
at
[jira] [Commented] (IGNITE-10655) .NET client should have peerClassLoading property in IgniteConfiguration class
[ https://issues.apache.org/jira/browse/IGNITE-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243529#comment-17243529 ] Alexandr Shapkin commented on IGNITE-10655: --- [~ptupitsyn] fixed, thanks! Could you, please, help with merging the PR? > .NET client should have peerClassLoading property in IgniteConfiguration class > -- > > Key: IGNITE-10655 > URL: https://issues.apache.org/jira/browse/IGNITE-10655 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In case if java server nodes in a cluster were set up with peerClassLoading > set to true then there is no way to start node via .NET client using > IgniteConfiguration (because the default value is false). > The only way to do it is using of the XML configuration. > Possibility to set this property from .Net client programmatically should be > added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10655) .NET client should have peerClassLoading property in IgniteConfiguration class
[ https://issues.apache.org/jira/browse/IGNITE-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin reassigned IGNITE-10655: - Assignee: Alexandr Shapkin (was: Vladimir Pligin) > .NET client should have peerClassLoading property in IgniteConfiguration class > -- > > Key: IGNITE-10655 > URL: https://issues.apache.org/jira/browse/IGNITE-10655 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > In case if java server nodes in a cluster were set up with peerClassLoading > set to true then there is no way to start node via .NET client using > IgniteConfiguration (because the default value is false). > The only way to do it is using of the XML configuration. > Possibility to set this property from .Net client programmatically should be > added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199559#comment-17199559
]
Alexandr Shapkin commented on IGNITE-13453:
---
I think we might start with the docker deployment and init a separate
discussion about the default behavior in ignite.sh script for the next release.
Anyway prior to the 2.9 there is no chance of disabling it. Though I agree that
different defaults could be confusing.
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
> --illegal-access=permit \
> ${JVM_OPTS}"
> fi
> DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d
> "=" -f 2)
> if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
>
[jira] [Commented] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199457#comment-17199457
]
Alexandr Shapkin commented on IGNITE-13453:
---
[~sdarlington] Could you please take a look?
With the new run.sh JMX is disabled by default and the original issue from
https://issues.apache.org/jira/browse/IGNITE-11715 should be gone. If you need
to configure it, then instead of configuring -NO_JMX option it's required to
set JVM options explicitly, something like:
Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49113
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
I think it's ok in general, but now we have different defaults for running
thought ignite.sh and run.sh.
We can make additional changes and keep it in sync with ignite.sh (enabled by
default).
WDYT?
+[~imurchenko]
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
>
[jira] [Commented] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198412#comment-17198412
]
Alexandr Shapkin commented on IGNITE-13453:
---
[~alex_pl] This change replaces
https://issues.apache.org/jira/browse/IGNITE-11715 as Ilya explained, so we
won't need to have the extra parameter IGNITE_OPTIONS
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
> --illegal-access=permit \
> ${JVM_OPTS}"
> fi
> DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d
> "=" -f 2)
> if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
> JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
> fi
> #
> # Start Ignite node
> #
> if [ -z "${CONFIG_URI}" ]; then
>
[jira] [Commented] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198236#comment-17198236
]
Alexandr Shapkin commented on IGNITE-13453:
---
[~ilyak]/[~isapego] Could you please help with the merge?
The change is only about the docker-related run.sh script, no other files
affected.
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
> --illegal-access=permit \
> ${JVM_OPTS}"
> fi
> DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d
> "=" -f 2)
> if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
> JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
> fi
> #
> # Start Ignite node
> #
> if [ -z "${CONFIG_URI}" ]; then
> exec "${JAVA}"
[jira] [Updated] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-13453:
--
Release Note: Replaced ignite.sh invocation with the direct JVM call for
Docker deployment
Reviewer: Peter Ivanov
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
> --illegal-access=permit \
> ${JVM_OPTS}"
> fi
> DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d
> "=" -f 2)
> if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
> JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
> fi
> #
> # Start Ignite node
> #
> if [ -z "${CONFIG_URI}" ]; then
> exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
>
[jira] [Updated] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-13453:
--
Description:
ignite.sh is cumbersome in Docker as it creates the hassle with signals not
being propagated but adds little value as most of what ignite.sh discovers
about the system is known beforehand for our Docker images.
Let's replace ignite.sh call with direct java invocation.
{code:bash}
#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
source "${IGNITE_HOME}"/bin/include/functions.sh
#
# Discover path to Java executable and check it's version.
#
checkJava
#
# Set IGNITE_LIBS.
#
source "${IGNITE_HOME}"/bin/include/setenv.sh
CP="${IGNITE_LIBS}"
DEFAULT_CONFIG=config/default-config.xml
#
# Add optional libs to classpath
#
if [ -n "${OPTION_LIBS}" ]; then
IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
for lib in ${LIBS_LIST[@]}; do
LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
"${JARS[*]}")
if [ -z "${USER_LIBS}" ]; then
export USER_LIBS="${LIBS}"
else
export USER_LIBS="${USER_LIBS}:${LIBS}"
fi
done
fi
#
# Add external libs to classpath
#
if [ -n "${EXTERNAL_LIBS}" ]; then
IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
for lib in "${LIBS_LIST[@]}"; do
echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
done
wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
"${IGNITE_HOME}"/libs/external
rm "${IGNITE_HOME}"/work/external_libs
fi
#
# Define classpath
#
if [ "${USER_LIBS:-}" != "" ]; then
IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
fi
CP="${IGNITE_LIBS}"
unset IFS
#
# Define default Java options
#
if [ -z "${JVM_OPTS}" ] ; then
JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
fi
#
# Add Java extra option
#
if [ "${version}" -eq 8 ] ; then
JVM_OPTS="\
-XX:+AggressiveOpts \
${JVM_OPTS}"
elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
JVM_OPTS="\
-XX:+AggressiveOpts \
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--illegal-access=permit \
--add-modules=java.xml.bind \
${JVM_OPTS}"
elif [ "${version}" -ge 11 ] ; then
JVM_OPTS="\
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
--illegal-access=permit \
${JVM_OPTS}"
fi
DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d "="
-f 2)
if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
fi
#
# Start Ignite node
#
if [ -z "${CONFIG_URI}" ]; then
exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
org.apache.ignite.startup.cmdline.CommandLineStartup "${DEFAULT_CONFIG}"
else
exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
org.apache.ignite.startup.cmdline.CommandLineStartup "${CONFIG_URI}"
fi
{code}
was:
ignite.sh is cumbersome in Docker as it creates the hassle with signals not
being propagated but adds little value as most of what ignite.sh discovers
about the system is known beforehand for our Docker images.
Let's replace ignite.sh call with direct java invocation.
{code:bash}
#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the
[jira] [Commented] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196960#comment-17196960
]
Alexandr Shapkin commented on IGNITE-13453:
---
[~alexpl] can we include this ticket into the 2.9 release?
We are working on Apache Ignite Operator and this change is vital for it.
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Assignee: Ilya Murchenko
>Priority: Critical
> Fix For: 2.9
>
>
> ignite.sh is cumbersome in Docker as it creates the hassle with signals not
> being propagated but adds little value as most of what ignite.sh discovers
> about the system is known beforehand for our Docker images.
> Let's replace ignite.sh call with direct java invocation.
> {code:bash}
> #!/bin/bash
> #
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
> #
> source "${IGNITE_HOME}"/bin/include/functions.sh
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Set IGNITE_LIBS.
> #
> source "${IGNITE_HOME}"/bin/include/setenv.sh
> CP="${IGNITE_LIBS}"
> DEFAULT_CONFIG=config/default-config.xml
> #
> # Add optional libs to classpath
> #
> if [ -n "${OPTION_LIBS}" ]; then
> IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
> for lib in ${LIBS_LIST[@]}; do
> LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
> "${JARS[*]}")
> if [ -z "${USER_LIBS}" ]; then
> export USER_LIBS="${LIBS}"
> else
> export USER_LIBS="${USER_LIBS}:${LIBS}"
> fi
> done
> fi
> #
> # Add external libs to classpath
> #
> if [ -n "${EXTERNAL_LIBS}" ]; then
> IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
> for lib in "${LIBS_LIST[@]}"; do
> echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
> done
> wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
> "${IGNITE_HOME}"/libs/external
> rm "${IGNITE_HOME}"/work/external_libs
> fi
> #
> # Get License file
> #
> if [ -n "${LICENCE_URL}" ]; then
> wget -O "${IGNITE_HOME}"/work/gridgain-license.xml "${LICENCE_URL}"
> fi
> #
> # Define classpath
> #
> if [ "${USER_LIBS:-}" != "" ]; then
> IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
> fi
> CP="${IGNITE_LIBS}"
> unset IFS
> #
> # Define default Java options
> #
> if [ -z "${JVM_OPTS}" ] ; then
> JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
> fi
> #
> # Add Java extra option
> #
> if [ "${version}" -eq 8 ] ; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> ${JVM_OPTS}"
> elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
> JVM_OPTS="\
> -XX:+AggressiveOpts \
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --illegal-access=permit \
> --add-modules=java.xml.bind \
> ${JVM_OPTS}"
> elif [ "${version}" -ge 11 ] ; then
> JVM_OPTS="\
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
> --add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
> --add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
>
> --add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
> --illegal-access=permit \
> ${JVM_OPTS}"
> fi
> DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d
> "=" -f 2)
> if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
> JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
> fi
> #
[jira] [Updated] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-13453:
--
Description:
ignite.sh is cumbersome in Docker as it creates the hassle with signals not
being propagated but adds little value as most of what ignite.sh discovers
about the system is known beforehand for our Docker images.
Let's replace ignite.sh call with direct java invocation.
{code:bash}
#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
source "${IGNITE_HOME}"/bin/include/functions.sh
#
# Discover path to Java executable and check it's version.
#
checkJava
#
# Set IGNITE_LIBS.
#
source "${IGNITE_HOME}"/bin/include/setenv.sh
CP="${IGNITE_LIBS}"
DEFAULT_CONFIG=config/default-config.xml
#
# Add optional libs to classpath
#
if [ -n "${OPTION_LIBS}" ]; then
IFS=, LIBS_LIST=("$(tr -d '[:space:]' <<< ${OPTION_LIBS})")
for lib in ${LIBS_LIST[@]}; do
LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
"${JARS[*]}")
if [ -z "${USER_LIBS}" ]; then
export USER_LIBS="${LIBS}"
else
export USER_LIBS="${USER_LIBS}:${LIBS}"
fi
done
fi
#
# Add external libs to classpath
#
if [ -n "${EXTERNAL_LIBS}" ]; then
IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
for lib in "${LIBS_LIST[@]}"; do
echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
done
wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
"${IGNITE_HOME}"/libs/external
rm "${IGNITE_HOME}"/work/external_libs
fi
#
# Get License file
#
if [ -n "${LICENCE_URL}" ]; then
wget -O "${IGNITE_HOME}"/work/gridgain-license.xml "${LICENCE_URL}"
fi
#
# Define classpath
#
if [ "${USER_LIBS:-}" != "" ]; then
IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
fi
CP="${IGNITE_LIBS}"
unset IFS
#
# Define default Java options
#
if [ -z "${JVM_OPTS}" ] ; then
JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
fi
#
# Add Java extra option
#
if [ "${version}" -eq 8 ] ; then
JVM_OPTS="\
-XX:+AggressiveOpts \
${JVM_OPTS}"
elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
JVM_OPTS="\
-XX:+AggressiveOpts \
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--illegal-access=permit \
--add-modules=java.xml.bind \
${JVM_OPTS}"
elif [ "${version}" -ge 11 ] ; then
JVM_OPTS="\
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
--illegal-access=permit \
${JVM_OPTS}"
fi
DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d "="
-f 2)
if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
fi
#
# Start GridGain node
#
if [ -z "${CONFIG_URI}" ]; then
exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
org.apache.ignite.startup.cmdline.CommandLineStartup "${DEFAULT_CONFIG}"
else
exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
org.apache.ignite.startup.cmdline.CommandLineStartup "${CONFIG_URI}"
fi
{code}
was:
ignite.sh is cumbersome in Docker as it creates the hassle with signals not
being propagated but adds little value as most of what ignite.sh discovers
about the system is known beforehand for our Docker images.
Let's replace ignite.sh call with direct java invocation.
{code:bash}
#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for
[jira] [Updated] (IGNITE-13453) Docker: Change run.sh to call java directly
[
https://issues.apache.org/jira/browse/IGNITE-13453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-13453:
--
Description:
ignite.sh is cumbersome in Docker as it creates the hassle with signals not
being propagated but adds little value as most of what ignite.sh discovers
about the system is known beforehand for our Docker images.
Let's replace ignite.sh call with direct java invocation.
{code:bash}
#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
source "${IGNITE_HOME}"/bin/include/functions.sh
#
# Discover path to Java executable and check it's version.
#
checkJava
#
# Set IGNITE_LIBS.
#
source "${IGNITE_HOME}"/bin/include/setenv.sh
CP="${IGNITE_LIBS}"
DEFAULT_CONFIG=config/default-config.xml
#
# Add optional libs to classpath
#
if [ -n "${OPTION_LIBS}" ]; then
IFS=, LIBS_LIST=("${OPTION_LIBS}")
for lib in "${LIBS_LIST[@]}"; do
LIBS=$(JARS=("${IGNITE_HOME}/libs/optional/${lib}"/*); IFS=:; echo
"${JARS[*]}")
if [ -z "${USER_LIBS}" ]; then
export USER_LIBS="${LIBS}"
else
export USER_LIBS="${USER_LIBS}:${LIBS}"
fi
done
fi
#
# Add external libs to classpath
#
if [ -n "${EXTERNAL_LIBS}" ]; then
IFS=, LIBS_LIST=("${EXTERNAL_LIBS}")
for lib in "${LIBS_LIST[@]}"; do
echo "${lib}" >> "${IGNITE_HOME}"/work/external_libs
done
wget --content-disposition -i "${IGNITE_HOME}"/work/external_libs -P
"${IGNITE_HOME}"/libs/external
rm "${IGNITE_HOME}"/work/external_libs
fi
#
# Get License file
#
if [ -n "${LICENCE_URL}" ]; then
wget -O "${IGNITE_HOME}"/work/gridgain-license.xml "${LICENCE_URL}"
fi
#
# Define classpath
#
if [ "${USER_LIBS:-}" != "" ]; then
IGNITE_LIBS=${USER_LIBS:-}:${IGNITE_LIBS}
fi
CP="${IGNITE_LIBS}"
unset IFS
#
# Define default Java options
#
if [ -z "${JVM_OPTS}" ] ; then
JVM_OPTS="-Xms1g -Xmx1g -server -XX:MaxMetaspaceSize=256m"
fi
#
# Add Java extra option
#
if [ "${version}" -eq 8 ] ; then
JVM_OPTS="\
-XX:+AggressiveOpts \
${JVM_OPTS}"
elif [ "${version}" -gt 8 ] && [ "${version}" -lt 11 ]; then
JVM_OPTS="\
-XX:+AggressiveOpts \
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--illegal-access=permit \
--add-modules=java.xml.bind \
${JVM_OPTS}"
elif [ "${version}" -ge 11 ] ; then
JVM_OPTS="\
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED \
--add-exports=java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED \
--add-exports=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED \
--add-exports=java.base/sun.reflect.generics.reflectiveObjects=ALL-UNNAMED \
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED \
--illegal-access=permit \
${JVM_OPTS}"
fi
DIGNITE_QUIET=$(printenv JVM_OPTS | grep -o 'IGNITE_QUIET=[^ ,]\+' | cut -d "="
-f 2)
if [ "${IGNITE_QUIET}" == "false" -o "${DIGNITE_QUIET}" == "false" ]; then
JVM_OPTS="${JVM_OPTS} -DIGNITE_QUIET=false"
fi
#
# Start GridGain node
#
if [ -z "${CONFIG_URI}" ]; then
exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
org.apache.ignite.startup.cmdline.CommandLineStartup "${DEFAULT_CONFIG}"
else
exec "${JAVA}" ${JVM_OPTS} -DIGNITE_HOME="${IGNITE_HOME}" -cp "${CP}"
org.apache.ignite.startup.cmdline.CommandLineStartup "${CONFIG_URI}"
fi
{code}
was:
ignite.sh is cumbersome in Docker as it creates the hassle with signals not
being propagated but adds little value as most of what ignite.sh discovers
about the system is known beforehand for our Docker images.
Let's replace ignite.sh call with direct java invocation.
> Docker: Change run.sh to call java directly
> ---
>
> Key: IGNITE-13453
> URL: https://issues.apache.org/jira/browse/IGNITE-13453
>
[jira] [Created] (IGNITE-13453) Docker: Change run.sh to call java directly
Alexandr Shapkin created IGNITE-13453: - Summary: Docker: Change run.sh to call java directly Key: IGNITE-13453 URL: https://issues.apache.org/jira/browse/IGNITE-13453 Project: Ignite Issue Type: Improvement Affects Versions: 2.8.1 Reporter: Alexandr Shapkin Assignee: Ilya Murchenko Fix For: 2.9 ignite.sh is cumbersome in Docker as it creates the hassle with signals not being propagated but adds little value as most of what ignite.sh discovers about the system is known beforehand for our Docker images. Let's replace ignite.sh call with direct java invocation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12863) NPE while initializing Cassandra Store
[
https://issues.apache.org/jira/browse/IGNITE-12863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193223#comment-17193223
]
Alexandr Shapkin commented on IGNITE-12863:
---
[~alex504], [~zstan], guys, could you please take a look at
[https://stackoverflow.com/questions/63818061/on-ignite-2-8-1-upgrade-startup-is-crashing-with-npe-for-cassandra-persistence]
Seems like enrichedFields might be null that's not suitable for
Collections.unmodifiableList
> NPE while initializing Cassandra Store
> --
>
> Key: IGNITE-12863
> URL: https://issues.apache.org/jira/browse/IGNITE-12863
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alex Serbin
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When trying to create a simple cache with Cassandra store and have value
> persistence strategy POJO, the following exception occurs
> {code:java}
> Caused by: java.lang.NullPointerException: nullCaused by:
> java.lang.NullPointerException: null at
> org.apache.ignite.cache.store.cassandra.persistence.PojoField.calculatedField(PojoField.java:155)
> ~[ignite-cassandra-store-2.8.0.jar:2.8.0] at
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.prepareLoadStatements(PersistenceController.java:311)
> ~[ignite-cassandra-store-2.8.0.jar:2.8.0] at
> org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.(PersistenceController.java:85)
> ~[ignite-cassandra-store-2.8.0.jar:2.8.0] at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.(CassandraCacheStore.java:106)
> ~[ignite-cassandra-store-2.8.0.jar:2.8.0] at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:59)
> ~[ignite-cassandra-store-2.8.0.jar:2.8.0] at
> org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:34)
> ~[ignite-cassandra-store-2.8.0.jar:2.8.0] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCacheContext(GridCacheProcessor.java:1199)
> ~[ignite-core-2.8.0.jar:2.8.0] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:1995)
> ~[ignite-core-2.8.0.jar:2.8.0] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$null$6a5b31b9$1(GridCacheProcessor.java:1830)
> ~[ignite-core-2.8.0.jar:2.8.0] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$8(GridCacheProcessor.java:1754)
> ~[ignite-core-2.8.0.jar:2.8.0] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$926b6886$1(GridCacheProcessor.java:1827)
> ~[ignite-core-2.8.0.jar:2.8.0] at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:11138)
> ~[ignite-core-2.8.0.jar:2.8.0] at
> java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> ~[na:1.8.0_181] at java.util.concurrent.FutureTask.run(FutureTask.java)
> ~[na:1.8.0_181] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_181] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[na:1.8.0_181] at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_181]
> {code}
> It looks like that recent changes of IGNITE-1903 are leading to this issue,
> as we are starting to serialize {{CacheStoreFactory}}, which contains
> {{PojoFiled}}, which in its turn has transient field accessor. This leads to
> accessor being null after deserialization. Note, that this happens only when
> passing {{persistenceSettings}} (not {{persistenceSettingsBean}})
> Works fine with Ignite 2.7.6.
> Probably related to IGNITE-8500
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13369) .NET: Local node info is not updated on client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180437#comment-17180437
]
Alexandr Shapkin commented on IGNITE-13369:
---
[~ptupitsyn] LGTM
> .NET: Local node info is not updated on client reconnect
>
>
> Key: IGNITE-13369
> URL: https://issues.apache.org/jira/browse/IGNITE-13369
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Ignite._locNode}} field caches local node information, and this cache info
> is not updated on client reconnect. We should remove cached info on every
> disconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-2890) .NET: Add CacheConfiguration.NodeFilter
[ https://issues.apache.org/jira/browse/IGNITE-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin reassigned IGNITE-2890: Assignee: Alexandr Shapkin > .NET: Add CacheConfiguration.NodeFilter > --- > > Key: IGNITE-2890 > URL: https://issues.apache.org/jira/browse/IGNITE-2890 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .net > > See ServiceConfiguration.NodeFilter > * Caches start earlier than platform => need to pass pointer for static > CacheConfigurations > * For dynamic cache start, no need for pointers -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152983#comment-17152983 ] Alexandr Shapkin commented on IGNITE-6982: -- [~alex_pl], no, it's still in the backlog. I don't think we need it for 2.9 > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.9 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13160) .NET: wrong affinity key registration with AffinityKeyMapped attribute
[
https://issues.apache.org/jira/browse/IGNITE-13160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-13160:
--
Description:
When QueryEntities is set alongside a custom key that utilizes the
AffinityKeyMapped attribute, the field won't be taken into account for some
reason. When QueryEntities configuration gets removed, all works fine, setting
KeyConfiguration manually helps as well. At the same time, the BinaryType
registration itself looks fine.
After the investigation, it turned out that affinityKey field is not being
registered on cache registration, and null is being cached instead. Later on
Ignite correctly tries to register a custom class as a key, but it's never
being updated internally case the real value is already cached.
NOTE: there is a workaround - you need to specify the key configuration
explicitly:
cacheConfiguration.KeyConfiguration = new List(1)
{code:java}
{
//affinityKey should be auto adjusted with Reflection
new CacheKeyConfiguration(typeof(MyKey))
};
{code}
Reproducer (add to the AffinityTest.cs):
{code:java}
///
/// Tests AffinityKeyMapped attribute should map to the same partitions
/// for the same field value.
///
[Test]
public void TestCustomAffinity()
{
IIgnite g = Ignition.GetIgnite("grid-0");
var cacheCfg = new CacheConfiguration("mycache")
{
// Without QueryEntities tests passes.
QueryEntities = new List()
{
new QueryEntity(typeof(MyKey), typeof(int))
}
};
g.GetOrCreateCache(cacheCfg);
var key1 = new MyKey {Data = "data1", AffinityKey = 1};
var key2 = new MyKey {Data = "data2", AffinityKey = 1};
ICacheAffinity aff = g.GetAffinity(cacheCfg.Name);
Assert.AreEqual(aff.GetPartition(key1), aff.GetPartition(key2));
}
public class MyKey
{
[QuerySqlField]
public string Data { get; set; }
[AffinityKeyMapped]
public long AffinityKey { get; set; }
}
{code}
was:
When QueryEntities is set alongside a custom key that utilizes the
AffinityKeyMapped attribute, the field won't be taken into account for some
reason. When QueryEntities configuration gets removed, all works fine, setting
KeyConfiguration manually helps as well. At the same time, the BinaryType
registration itself looks fine.
After the investigation, it turned out that affinityKey field is not being
registered on cache registration, and null is being cached instead. Later on
Ignite correctly tries to register a custom class as a key, but it's never
being updated internally case the real value is already cached.
Reproducer (add to the AffinityTest.cs):
{code:java}
///
/// Tests AffinityKeyMapped attribute should map to the same partitions
/// for the same field value.
///
[Test]
public void TestCustomAffinity()
{
IIgnite g = Ignition.GetIgnite("grid-0");
var cacheCfg = new CacheConfiguration("mycache")
{
// Without QueryEntities tests passes.
QueryEntities = new List()
{
new QueryEntity(typeof(MyKey), typeof(int))
}
};
g.GetOrCreateCache(cacheCfg);
var key1 = new MyKey {Data = "data1", AffinityKey = 1};
var key2 = new MyKey {Data = "data2", AffinityKey = 1};
ICacheAffinity aff = g.GetAffinity(cacheCfg.Name);
Assert.AreEqual(aff.GetPartition(key1), aff.GetPartition(key2));
}
public class MyKey
{
[QuerySqlField]
public string Data { get; set; }
[AffinityKeyMapped]
public long AffinityKey { get; set; }
}
{code}
> .NET: wrong affinity key registration with AffinityKeyMapped attribute
> --
>
> Key: IGNITE-13160
> URL: https://issues.apache.org/jira/browse/IGNITE-13160
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Priority: Major
>
> When QueryEntities is set alongside a custom key that utilizes the
> AffinityKeyMapped attribute, the field won't be taken into account for some
> reason. When QueryEntities configuration gets removed, all works fine,
> setting KeyConfiguration manually helps as well. At the same time, the
> BinaryType registration itself looks fine.
> After the investigation, it turned out that affinityKey field is not being
> registered on cache registration, and null is being cached instead. Later
[jira] [Comment Edited] (IGNITE-5795) Binary metadata is not registered during start of cache
[
https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138881#comment-17138881
]
Alexandr Shapkin edited comment on IGNITE-5795 at 6/17/20, 10:34 PM:
-
[~akalashnikov] the fix doesn't work for other platforms like .NET, C++ and all
thin clients except Java.
That's because other platforms don't have the Java classes and they do operate
on their own abstraction and the following check will not work as a meta
registration:
{code:java}
private void registerBinaryMetadata(CacheConfiguration ccfg, QuerySchema
schema) throws BinaryObjectException {
...
Class keyCls = U.box(U.classForName(qryEntity.findKeyType(), null, true));
Class valCls = U.box(U.classForName(qryEntity.findValueType(), null,
It seems that in practice we do have all required information and a binaryt
{code}
The platforms may not operate Java objects directly and it seems redundant
building a meta on a Java side one more time, keeping in mind that we actually
do have the required binaryMeta proper to cache startup (at least for the .NET
thick node)
I've created a separate ticket -
https://issues.apache.org/jira/browse/IGNITE-13160 with an explanation of a
problem from .NET side
was (Author: ashapkin):
[~akalashnikov] the fix doesn't work for other platforms like .NET, C++ and all
thin clients except Java.
That's because other platforms don't have the Java classes and they do operate
on their own abstraction and the following check will not work as a meta
registration:
{code:java}
private void registerBinaryMetadata(CacheConfiguration ccfg, QuerySchema
schema) throws BinaryObjectException {
...
Class keyCls = U.box(U.classForName(qryEntity.findKeyType(), null, true));
Class valCls = U.box(U.classForName(qryEntity.findValueType(), null,
It seems that in practice we do have all required information and a binaryt
{code}
The platforms may not operate Java objects directly and it seems redundant
building a meta on a Java side one more time, keeping in mind that we actually
do have the required binaryMeta proper to cache startup (at least for the .NET
thick node)
> Binary metadata is not registered during start of cache
> ---
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
> Issue Type: Bug
> Components: binary, sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When cache configured with QueryEntity and used key type with
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated.
> This happens because QueryEntity processing precedes key type registering in
> binary meta cache. On that step
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it
> will force registering key.
> *Root cause of this behaviour* is that in during cache registration
> registration of metadata doesn't happen. It lead to exchange messages like
> (MappingProposedMessage, MetadataRequestMessage etc.) which are often
> redundant and also lead to behaviour described above(unhandled
> AffinityKeyMapped).
> Main idea to fix this problem it is registration of metadata locally in
> during cache start on each node without messages exchange.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-5795) Binary metadata is not registered during start of cache
[
https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138881#comment-17138881
]
Alexandr Shapkin commented on IGNITE-5795:
--
[~akalashnikov] the fix doesn't work for other platforms like .NET, C++ and all
thin clients except Java.
That's because other platforms don't have the Java classes and they do operate
on their own abstraction and the following check will not work as a meta
registration:
{code:java}
private void registerBinaryMetadata(CacheConfiguration ccfg, QuerySchema
schema) throws BinaryObjectException {
...
Class keyCls = U.box(U.classForName(qryEntity.findKeyType(), null, true));
Class valCls = U.box(U.classForName(qryEntity.findValueType(), null,
It seems that in practice we do have all required information and a binaryt
{code}
The platforms may not operate Java objects directly and it seems redundant
building a meta on a Java side one more time, keeping in mind that we actually
do have the required binaryMeta proper to cache startup (at least for the .NET
thick node)
> Binary metadata is not registered during start of cache
> ---
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
> Issue Type: Bug
> Components: binary, sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When cache configured with QueryEntity and used key type with
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated.
> This happens because QueryEntity processing precedes key type registering in
> binary meta cache. On that step
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it
> will force registering key.
> *Root cause of this behaviour* is that in during cache registration
> registration of metadata doesn't happen. It lead to exchange messages like
> (MappingProposedMessage, MetadataRequestMessage etc.) which are often
> redundant and also lead to behaviour described above(unhandled
> AffinityKeyMapped).
> Main idea to fix this problem it is registration of metadata locally in
> during cache start on each node without messages exchange.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13160) .NET: wrong affinity key registration with AffinityKeyMapped attribute
Alexandr Shapkin created IGNITE-13160:
-
Summary: .NET: wrong affinity key registration with
AffinityKeyMapped attribute
Key: IGNITE-13160
URL: https://issues.apache.org/jira/browse/IGNITE-13160
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Alexandr Shapkin
When QueryEntities is set alongside a custom key that utilizes the
AffinityKeyMapped attribute, the field won't be taken into account for some
reason. When QueryEntities configuration gets removed, all works fine, setting
KeyConfiguration manually helps as well. At the same time, the BinaryType
registration itself looks fine.
After the investigation, it turned out that affinityKey field is not being
registered on cache registration, and null is being cached instead. Later on
Ignite correctly tries to register a custom class as a key, but it's never
being updated internally case the real value is already cached.
Reproducer (add to the AffinityTest.cs):
{code:java}
///
/// Tests AffinityKeyMapped attribute should map to the same partitions
/// for the same field value.
///
[Test]
public void TestCustomAffinity()
{
IIgnite g = Ignition.GetIgnite("grid-0");
var cacheCfg = new CacheConfiguration("mycache")
{
// Without QueryEntities tests passes.
QueryEntities = new List()
{
new QueryEntity(typeof(MyKey), typeof(int))
}
};
g.GetOrCreateCache(cacheCfg);
var key1 = new MyKey {Data = "data1", AffinityKey = 1};
var key2 = new MyKey {Data = "data2", AffinityKey = 1};
ICacheAffinity aff = g.GetAffinity(cacheCfg.Name);
Assert.AreEqual(aff.GetPartition(key1), aff.GetPartition(key2));
}
public class MyKey
{
[QuerySqlField]
public string Data { get; set; }
[AffinityKeyMapped]
public long AffinityKey { get; set; }
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13160) .NET: wrong affinity key registration with AffinityKeyMapped attribute
[
https://issues.apache.org/jira/browse/IGNITE-13160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-13160:
--
Component/s: platforms
> .NET: wrong affinity key registration with AffinityKeyMapped attribute
> --
>
> Key: IGNITE-13160
> URL: https://issues.apache.org/jira/browse/IGNITE-13160
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Alexandr Shapkin
>Priority: Major
>
> When QueryEntities is set alongside a custom key that utilizes the
> AffinityKeyMapped attribute, the field won't be taken into account for some
> reason. When QueryEntities configuration gets removed, all works fine,
> setting KeyConfiguration manually helps as well. At the same time, the
> BinaryType registration itself looks fine.
> After the investigation, it turned out that affinityKey field is not being
> registered on cache registration, and null is being cached instead. Later on
> Ignite correctly tries to register a custom class as a key, but it's never
> being updated internally case the real value is already cached.
>
> Reproducer (add to the AffinityTest.cs):
> {code:java}
> ///
> /// Tests AffinityKeyMapped attribute should map to the same
> partitions
> /// for the same field value.
> ///
> [Test]
> public void TestCustomAffinity()
> {
> IIgnite g = Ignition.GetIgnite("grid-0");
> var cacheCfg = new CacheConfiguration("mycache")
> {
> // Without QueryEntities tests passes.
> QueryEntities = new List()
> {
> new QueryEntity(typeof(MyKey), typeof(int))
> }
> };
> g.GetOrCreateCache(cacheCfg);
> var key1 = new MyKey {Data = "data1", AffinityKey = 1};
> var key2 = new MyKey {Data = "data2", AffinityKey = 1};
> ICacheAffinity aff = g.GetAffinity(cacheCfg.Name);
> Assert.AreEqual(aff.GetPartition(key1), aff.GetPartition(key2));
> }
> public class MyKey
> {
> [QuerySqlField]
> public string Data { get; set; }
> [AffinityKeyMapped]
> public long AffinityKey { get; set; }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124785#comment-17124785 ] Alexandr Shapkin edited comment on IGNITE-13095 at 6/3/20, 9:55 AM: [~ptupitsyn] LGTM, please check the failed test - TestExecuteJavaTaskAsyncCancellation was (Author: ashapkin): [~ptupitsyn] LGTM > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 10m > Remaining Estimate: 2h 50m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13095) .NET: Thin Client Compute does not cancel task on server when cancelled on client
[ https://issues.apache.org/jira/browse/IGNITE-13095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124785#comment-17124785 ] Alexandr Shapkin commented on IGNITE-13095: --- [~ptupitsyn] LGTM > .NET: Thin Client Compute does not cancel task on server when cancelled on > client > - > > Key: IGNITE-13095 > URL: https://issues.apache.org/jira/browse/IGNITE-13095 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Original Estimate: 3h > Time Spent: 10m > Remaining Estimate: 2h 50m > > Client should call OP_RESOURCE_CLOSE to cancel the task on server side. > Test this by reading server logs, "Job was cancelled" should be there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12932) Thin client cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102369#comment-17102369 ] Alexandr Shapkin commented on IGNITE-12932: --- [~ptupitsyn] Looks good to me. > Thin client cluster discovery > - > > Key: IGNITE-12932 > URL: https://issues.apache.org/jira/browse/IGNITE-12932 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.9 > > Original Estimate: 336h > Time Spent: 20m > Remaining Estimate: 3h 50m > > Thin clients should be able to discover all server nodes automatically when > connected to any of them, and maintain an up to date list of servers at all > times. > See > [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery] > for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12676) .NET: Add partition-based AffinityCall and AffinityRun overloads
[ https://issues.apache.org/jira/browse/IGNITE-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088533#comment-17088533 ] Alexandr Shapkin commented on IGNITE-12676: --- [~ptupitsyn] Looks good to me, thanks! > .NET: Add partition-based AffinityCall and AffinityRun overloads > > > Key: IGNITE-12676 > URL: https://issues.apache.org/jira/browse/IGNITE-12676 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Time Spent: 10m > Remaining Estimate: 0h > > Add partition-based AffinityCall and AffinityRun overloads to ICompute.See > corresponding methods in Java (IgniteCompute). > Additionally, current affinity methods work through PlatformAbstractTask, > which does not lock partitions. We should refactor existing AffinityCall and > AffinityRun overloads to call corresponding IgniteCompute APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12090) .NET logging exception when creating cache from code if value has 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-12090:
--
Description:
Logger throws KeyNotFound exception if NetToJava[type] doesn't have a _type_
key.
Looks like we need to replace it with NetToJava[directType].
{code:java}
public static void LogIndirectMappingWarning(Type type, ILogger log, string
logInfo)
{
if (type == null)
return;
var directType = GetDirectlyMappedType(type);
if (directType == type)
return;
log.Warn("{0}: Type '{1}' maps to Java type '{2}' using unchecked conversion. "
+
"This may cause issues in SQL queries. " +
"You can use '{3}' instead to achieve direct mapping.",
logInfo, type, NetToJava[type], directType);
}
{code}
Steps to reproduce:
Define a QueryEntity with a sbyte? nullable field, try to create a cache. The
reproducer is attached.
was:
Ignite.NET.
Using 'sbyte?' field for value causes KeyNotFound exception during cache
creation (field's type validation), when Ignite attempts to print type's name
into log.
# {{I don't really understand why .Net's sbyte is considered not directly
mappable to java.byte
([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L54)]
? }}{{Also it is not consistent with other indirect mapping (usigned ->
signed)}}
# {{Access to NetToJava dictionary
([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L109])
should be safeguarded (NetToJava doesn't have entries for nullable types)}}
{{Code example in attachment}}
> .NET logging exception when creating cache from code if value has 'sbyte?'
> field
>
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Assignee: Alexandr Shapkin
>Priority: Critical
> Labels: .NET
> Attachments: a.cs
>
>
>
> Logger throws KeyNotFound exception if NetToJava[type] doesn't have a _type_
> key.
> Looks like we need to replace it with NetToJava[directType].
> {code:java}
> public static void LogIndirectMappingWarning(Type type, ILogger log, string
> logInfo)
> {
> if (type == null)
> return;
> var directType = GetDirectlyMappedType(type);
> if (directType == type)
> return;
> log.Warn("{0}: Type '{1}' maps to Java type '{2}' using unchecked conversion.
> " +
> "This may cause issues in SQL queries. " +
> "You can use '{3}' instead to achieve direct mapping.",
> logInfo, type, NetToJava[type], directType);
> }
> {code}
>
> Steps to reproduce:
> Define a QueryEntity with a sbyte? nullable field, try to create a cache. The
> reproducer is attached.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12090) .NET logging exception when creating cache with nullable 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-12090:
--
Summary: .NET logging exception when creating cache with nullable 'sbyte?'
field (was: .NET logging exception when creating cache from code if value has
'sbyte?' field)
> .NET logging exception when creating cache with nullable 'sbyte?' field
> ---
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Assignee: Alexandr Shapkin
>Priority: Critical
> Labels: .NET
> Attachments: a.cs
>
>
>
> Logger throws KeyNotFound exception if NetToJava[type] doesn't have a _type_
> key.
> Looks like we need to replace it with NetToJava[directType].
> {code:java}
> public static void LogIndirectMappingWarning(Type type, ILogger log, string
> logInfo)
> {
> if (type == null)
> return;
> var directType = GetDirectlyMappedType(type);
> if (directType == type)
> return;
> log.Warn("{0}: Type '{1}' maps to Java type '{2}' using unchecked conversion.
> " +
> "This may cause issues in SQL queries. " +
> "You can use '{3}' instead to achieve direct mapping.",
> logInfo, type, NetToJava[type], directType);
> }
> {code}
>
> Steps to reproduce:
> Define a QueryEntity with a sbyte? nullable field, try to create a cache. The
> reproducer is attached.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12090) .NET logging exception when creating cache from code if value has 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin reassigned IGNITE-12090:
-
Assignee: Alexandr Shapkin
> .NET logging exception when creating cache from code if value has 'sbyte?'
> field
>
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Assignee: Alexandr Shapkin
>Priority: Critical
> Labels: .NET
> Attachments: a.cs
>
>
> Ignite.NET.
> Using 'sbyte?' field for value causes KeyNotFound exception during cache
> creation (field's type validation), when Ignite attempts to print type's name
> into log.
> # {{I don't really understand why .Net's sbyte is considered not directly
> mappable to java.byte
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L54)]
> ? }}{{Also it is not consistent with other indirect mapping (usigned ->
> signed)}}
> # {{Access to NetToJava dictionary
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L109])
> should be safeguarded (NetToJava doesn't have entries for nullable types)}}
>
> {{Code example in attachment}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12090) .NET logging exception when creating cache from code if value has 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-12090:
--
Priority: Critical (was: Major)
> .NET logging exception when creating cache from code if value has 'sbyte?'
> field
>
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Priority: Critical
> Labels: .NET
> Attachments: a.cs
>
>
> Ignite.NET.
> Using 'sbyte?' field for value causes KeyNotFound exception during cache
> creation (field's type validation), when Ignite attempts to print type's name
> into log.
> # {{I don't really understand why .Net's sbyte is considered not directly
> mappable to java.byte
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L54)]
> ? }}{{Also it is not consistent with other indirect mapping (usigned ->
> signed)}}
> # {{Access to NetToJava dictionary
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L109])
> should be safeguarded (NetToJava doesn't have entries for nullable types)}}
>
> {{Code example in attachment}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12090) .NET logging exception when creating cache from code if value has 'sbyte?' field
[
https://issues.apache.org/jira/browse/IGNITE-12090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Shapkin updated IGNITE-12090:
--
Summary: .NET logging exception when creating cache from code if value has
'sbyte?' field (was: KeyNotFound exception when creating cache from code if
value has 'sbyte?' field)
> .NET logging exception when creating cache from code if value has 'sbyte?'
> field
>
>
> Key: IGNITE-12090
> URL: https://issues.apache.org/jira/browse/IGNITE-12090
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.7.5
>Reporter: Denis Zakharov
>Priority: Major
> Labels: .NET
> Attachments: a.cs
>
>
> Ignite.NET.
> Using 'sbyte?' field for value causes KeyNotFound exception during cache
> creation (field's type validation), when Ignite attempts to print type's name
> into log.
> # {{I don't really understand why .Net's sbyte is considered not directly
> mappable to java.byte
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L54)]
> ? }}{{Also it is not consistent with other indirect mapping (usigned ->
> signed)}}
> # {{Access to NetToJava dictionary
> ([https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/JavaTypes.cs#L109])
> should be safeguarded (NetToJava doesn't have entries for nullable types)}}
>
> {{Code example in attachment}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12471) .NET Thin Client: WithExpiryPolicy crashes client connection on old servers
[
https://issues.apache.org/jira/browse/IGNITE-12471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17005300#comment-17005300
]
Alexandr Shapkin commented on IGNITE-12471:
---
[~ptupitsyn] Looks good to me, please, check a couple of comments in PR
> .NET Thin Client: WithExpiryPolicy crashes client connection on old servers
> ---
>
> Key: IGNITE-12471
> URL: https://issues.apache.org/jira/browse/IGNITE-12471
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ICacheClient.WithExpiryPolicy does not check protocol version and causes
> exception and disconnect:
> * Run Ignite 2.7.6 server node
> * Connect thin client from master branch
> * {{cache.WithExpiryPolicy(..).Put(1, 2)}}:
> {code}
> Unhandled exception. System.Net.Sockets.SocketException (10053): An
> established connection was aborted by the software in your host machine.
>at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)
>at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveMessage()
>at Apache.Ignite.Core.Impl.Client.ClientSocket.SendRequest(RequestMessage&
> reqMsg)
>at Apache.Ignite.Core.Impl.Client.ClientSocket.DoOutInOp[T](ClientOp opId,
> Action`1 writeAction, Func`2 readFunc, Func`3 errorFunc)
>at
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.DoOutInOpAffinity[T,TKey](ClientOp
> opId, Action`1 writeAction, Func`2 readFunc, Int32 cacheId, TKey key, Func`3
> errorFunc)
>at
> Apache.Ignite.Core.Impl.Client.Cache.CacheClient`2.DoOutInOpAffinity[T](ClientOp
> opId, TK key, TV val, Func`2 readFunc)
>at
> Apache.Ignite.Core.Impl.Client.Cache.CacheClient`2.DoOutOpAffinity(ClientOp
> opId, TK key, TV val)
>at Apache.Ignite.Core.Impl.Client.Cache.CacheClient`2.Put(TK key, TV val)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12385) .NET Thin Client: introduce ClusterGroup API
[ https://issues.apache.org/jira/browse/IGNITE-12385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003598#comment-17003598 ] Alexandr Shapkin commented on IGNITE-12385: --- [~ptupitsyn] please, check > .NET Thin Client: introduce ClusterGroup API > > > Key: IGNITE-12385 > URL: https://issues.apache.org/jira/browse/IGNITE-12385 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.7.6 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to implement IClusterGroup API for thin clients. > Let's start with following methods: > * IClusterGroup.ForDotNet() > * IClusterGroup.ForAttributes() > * IClusterGroup.GetNodes() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12387) .NET Thin Client: Handle unsupported features on older server nodes gracefully
[ https://issues.apache.org/jira/browse/IGNITE-12387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999067#comment-16999067 ] Alexandr Shapkin commented on IGNITE-12387: --- [~ptupitsyn] looks good to me, thanks! > .NET Thin Client: Handle unsupported features on older server nodes gracefully > -- > > Key: IGNITE-12387 > URL: https://issues.apache.org/jira/browse/IGNITE-12387 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Right now we don't check server version before doing requests for newer > features like Affinity Awareness and Cluster API. This causes exceptions like > "Invalid re > quest op code: 5000", which are cryptic for the user. > Fix this: > * Affinity Awareness: disable it automatically if there is no server support; > log a warning to the log (add logging by adding > IgniteClientConfiguration.Logger property) > * Individual methods and features like Cluster API - throw an exception with > user-friendly explanation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12381) QueryParser: propagate H2 ErrorCode to IgniteSQLException
[ https://issues.apache.org/jira/browse/IGNITE-12381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16995768#comment-16995768 ] Alexandr Shapkin commented on IGNITE-12381: --- Hello [~oleg_bonar], I just realized, that there is a big incoming feature about replacing H2 with Calcite. [https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine] I think it's worth to start a separate topic at dev list (d...@ignite.apache.org) and discuss the details. > QueryParser: propagate H2 ErrorCode to IgniteSQLException > - > > Key: IGNITE-12381 > URL: https://issues.apache.org/jira/browse/IGNITE-12381 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7.6 >Reporter: Alexandr Shapkin >Priority: Major > Labels: newbie > > QueryParser#parseH2 method generalizes all h2 error codes as > IgniteQueryErrorCode.PARSING > Whereas the actual error code could be more specific, like > [TABLE_OR_VIEW_NOT_FOUND_1|https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html#c42102] > = 42102 > Let's try to convert those codes into the appropriate IgniteQueryErrorCode > values as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12385) .NET Thin Client: introduce ClusterGroup API
Alexandr Shapkin created IGNITE-12385: - Summary: .NET Thin Client: introduce ClusterGroup API Key: IGNITE-12385 URL: https://issues.apache.org/jira/browse/IGNITE-12385 Project: Ignite Issue Type: New Feature Components: thin client Affects Versions: 2.7.6 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Fix For: 2.9 We need to implement IClusterGroup API for thin clients. Let's start with following methods: * IClusterGroup.ForDotNet() * IClusterGroup.ForAttributes() * IClusterGroup.GetNodes() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12381) QueryParser: propagate H2 ErrorCode to IgniteSQLException
[ https://issues.apache.org/jira/browse/IGNITE-12381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-12381: -- Labels: newbie (was: ) > QueryParser: propagate H2 ErrorCode to IgniteSQLException > - > > Key: IGNITE-12381 > URL: https://issues.apache.org/jira/browse/IGNITE-12381 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7.6 >Reporter: Alexandr Shapkin >Priority: Major > Labels: newbie > > QueryParser#parseH2 method generalizes all h2 error codes as > IgniteQueryErrorCode.PARSING > Whereas the actual error code could be more specific, like > [TABLE_OR_VIEW_NOT_FOUND_1|https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html#c42102] > = 42102 > Let's try to convert those codes into the appropriate IgniteQueryErrorCode > values as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12381) QueryParser: propagate H2 ErrorCode to IgniteSQLException
Alexandr Shapkin created IGNITE-12381: - Summary: QueryParser: propagate H2 ErrorCode to IgniteSQLException Key: IGNITE-12381 URL: https://issues.apache.org/jira/browse/IGNITE-12381 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.7.6 Reporter: Alexandr Shapkin QueryParser#parseH2 method generalizes all h2 error codes as IgniteQueryErrorCode.PARSING Whereas the actual error code could be more specific, like [TABLE_OR_VIEW_NOT_FOUND_1|https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html#c42102] = 42102 Let's try to convert those codes into the appropriate IgniteQueryErrorCode values as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
[ https://issues.apache.org/jira/browse/IGNITE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970313#comment-16970313 ] Alexandr Shapkin commented on IGNITE-9033: -- [~ptupitsyn] Thanks! Could you proceed, then? > .NET: specify expiry policy when creating cache using thin client > - > > Key: IGNITE-9033 > URL: https://issues.apache.org/jira/browse/IGNITE-9033 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Need to add ability to create dynamic caches specifying expiry policy with > thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
[ https://issues.apache.org/jira/browse/IGNITE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-9033: - Ignite Flags: Docs Required,Release Notes Required Release Note: - Added the new thin client protocol version - 1.6.0 - Added expiry policy property to thin client cache configuration - Added withExpiryPolicy method to the .NET client cache API > .NET: specify expiry policy when creating cache using thin client > - > > Key: IGNITE-9033 > URL: https://issues.apache.org/jira/browse/IGNITE-9033 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Need to add ability to create dynamic caches specifying expiry policy with > thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
[ https://issues.apache.org/jira/browse/IGNITE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970112#comment-16970112 ] Alexandr Shapkin commented on IGNITE-9033: -- [~ptupitsyn] PR is ready, please, have a look. > .NET: specify expiry policy when creating cache using thin client > - > > Key: IGNITE-9033 > URL: https://issues.apache.org/jira/browse/IGNITE-9033 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Need to add ability to create dynamic caches specifying expiry policy with > thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968410#comment-16968410 ] Alexandr Shapkin commented on IGNITE-6982: -- [~ptupitsyn], deal, I will check it. > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.9 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-6982: - Fix Version/s: (was: 2.4) 2.9 > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.9 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968389#comment-16968389 ] Alexandr Shapkin commented on IGNITE-6982: -- [~ptupitsyn] I think it's time to review this issue. Probably we could benefit from the new parallel test execution concept. > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.4 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin reopened IGNITE-6982: -- Ignite Flags: Release Notes Required Assignee: Alexandr Shapkin (was: Pavel Tupitsyn) > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.4 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
[ https://issues.apache.org/jira/browse/IGNITE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963111#comment-16963111 ] Alexandr Shapkin commented on IGNITE-9033: -- [~mmuzaf], I returned 2.8, should be completed prior December. > .NET: specify expiry policy when creating cache using thin client > - > > Key: IGNITE-9033 > URL: https://issues.apache.org/jira/browse/IGNITE-9033 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > > Need to add ability to create dynamic caches specifying expiry policy with > thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9033) .NET: specify expiry policy when creating cache using thin client
[ https://issues.apache.org/jira/browse/IGNITE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandr Shapkin updated IGNITE-9033: - Fix Version/s: (was: 2.9) 2.8 > .NET: specify expiry policy when creating cache using thin client > - > > Key: IGNITE-9033 > URL: https://issues.apache.org/jira/browse/IGNITE-9033 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Igor Sapego >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > > Need to add ability to create dynamic caches specifying expiry policy with > thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11761) Normalize encoding for Ignite .NET test file
[ https://issues.apache.org/jira/browse/IGNITE-11761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960978#comment-16960978 ] Alexandr Shapkin commented on IGNITE-11761: --- It turned out that the PR was merged with a wrong message, without IGNITE-XXX prefix. We need to exclude this ticket from consistency check > Normalize encoding for Ignite .NET test file > > > Key: IGNITE-11761 > URL: https://issues.apache.org/jira/browse/IGNITE-11761 > Project: Ignite > Issue Type: Task >Reporter: Dmitry Pavlov >Assignee: Alexandr Shapkin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > It is encoded in UTF-16, but all other files are UTF-8 > Idea blocks me from changing encoding because of BOM exists. > https://stackoverflow.com/questions/32986445/remove-a-bom-character-in-a-file -- This message was sent by Atlassian Jira (v8.3.4#803005)
