[jira] [Commented] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[ https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16638380#comment-16638380 ] Dmitry Karachentsev commented on IGNITE-8766: - [~NIzhikov] it's just waiting to be merged to master as I can see. > TcpDiscoverySpi: discovery threads naming > - > > Key: IGNITE-8766 > URL: https://issues.apache.org/jira/browse/IGNITE-8766 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.8 > > > Including information about next/prev nodes into names of discovery-related > threads could be very helpful when investigating situations of network > glitches. > tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such > information in their names. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9425) NPE on index rebuild
[
https://issues.apache.org/jira/browse/IGNITE-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597200#comment-16597200
]
Dmitry Karachentsev commented on IGNITE-9425:
-
[TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F4647%2Fhead]
tests look OK.
[~agoncharuk] please review.
> NPE on index rebuild
>
>
> Key: IGNITE-9425
> URL: https://issues.apache.org/jira/browse/IGNITE-9425
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.7
>
>
> Summary:
> This issue is seen when we have two caches mapped to two different regions
> (one with persistence and one without persistence)
> The client-side config should have the cache definitions
> The server-side config should have the data regions only
> Affinity should be defined on the cache without persistence
> We need to populate the data into both the caches and then restart the server
> and clients
> The issue will be seen when the client reconnects.
> Workaround:
> Add the cache configurations (for the caches without persistence) to the
> server-side config.
> Steps to reproduce:
> Ignite server
> - region1 (with persistence)
> - region2 (without persistence)
> client
> - cache1a from region1 – with custom affinity
> - cache2a fom region2 – with custom affinity
> 1. Populate data in both cache1a and cache2a.
> 2. Restart ignite server. It knows about cache1a from the persistent store.
> It doesn’t know about cache2a.
> 3. Restart client. When it connects to ignite, the server sees a nullpointer
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1243)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1239)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.rebuildIndexesIfNeeded(GridCacheDatabaseSharedManager.java:1239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1711)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:126)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:729)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9425) NPE on index rebuild
Dmitry Karachentsev created IGNITE-9425:
---
Summary: NPE on index rebuild
Key: IGNITE-9425
URL: https://issues.apache.org/jira/browse/IGNITE-9425
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
Fix For: 2.7
Summary:
This issue is seen when we have two caches mapped to two different regions (one
with persistence and one without persistence)
The client-side config should have the cache definitions
The server-side config should have the data regions only
Affinity should be defined on the cache without persistence
We need to populate the data into both the caches and then restart the server
and clients
The issue will be seen when the client reconnects.
Workaround:
Add the cache configurations (for the caches without persistence) to the
server-side config.
Steps to reproduce:
Ignite server
- region1 (with persistence)
- region2 (without persistence)
client
- cache1a from region1 – with custom affinity
- cache2a fom region2 – with custom affinity
1. Populate data in both cache1a and cache2a.
2. Restart ignite server. It knows about cache1a from the persistent store. It
doesn’t know about cache2a.
3. Restart client. When it connects to ignite, the server sees a nullpointer
{noformat}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1243)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1239)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.rebuildIndexesIfNeeded(GridCacheDatabaseSharedManager.java:1239)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1711)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:126)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:729)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8759) TcpDiscoverySpi: detailed info about current state in MBean
[ https://issues.apache.org/jira/browse/IGNITE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8759: --- Assignee: (was: Dmitry Karachentsev) > TcpDiscoverySpi: detailed info about current state in MBean > --- > > Key: IGNITE-8759 > URL: https://issues.apache.org/jira/browse/IGNITE-8759 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Priority: Major > Labels: discovery > Fix For: 2.8 > > > When TcpDiscoverySpi is used all nodes keep information about current > topology locally. Discovery protocol is responsible of keeping this > information consistent across all nodes. > However in situations of network glitches some nodes may have different > pictures of current state and topology of the cluster. > To make it easier to monitor state of the whole cluster and identify such > nodes quicker the following information should be presented via MBean > interface on each node: > * Current topology version; > * Hash of current topology (e.g. sum of hash codes of all nodeIds) (to allow > quick matching); > * Pretty-formatted snapshot of current topology visible from the node; > * Information about nodes visible/invisible to local one; > * Other information useful to monitoring of topology state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-3471) Do not send previous value to client node for invoke() when possible
[
https://issues.apache.org/jira/browse/IGNITE-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-3471:
---
Assignee: (was: Dmitry Karachentsev)
> Do not send previous value to client node for invoke() when possible
>
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to
> near node and apply EntryProcessor locally to get a return value. This can
> induce a significant overhead when cache value is much larger than entry
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> cache.get(key); // This should actually get the current cache value from
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS
[ https://issues.apache.org/jira/browse/IGNITE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16583791#comment-16583791 ] Dmitry Karachentsev commented on IGNITE-5569: - [~dpavlov] thank you! Here is checklist status: 1.a API compatibility MUST be maintained between minor releases. No API changes. 1.b Default behavior SHOULD NOT be changed between minor releases, unless absolutely needed. Default behavior changed a bit, but it's a fix. 1.c New operation MUST be well-documented in code. Javadoc presented. 1.d API parity between Java and .NET platforms No changes needed. 1.e API parity between thin clients (Java, .NET) No changes needed. 1.f All exceptions thrown to a user SHOULD have explanation how to resolve, workaround or debug an error. Yes. 2. Compatibility. Does not affect compatibility. 3. Tests Done. 4. Codestyle. Done. [~yzhdanov] Please review. > TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a > cluster DDoS > - > > Key: IGNITE-5569 > URL: https://issues.apache.org/jira/browse/IGNITE-5569 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > A firewall configuration issue may effectively lead to a cluster DDoS. The > scheme is as follows: > 1) A node G joins the cluster, and a firewall rule forbids incoming > connection from cluster to this node > 2) Cluster successfully processes NodeAddedMesage and fires a discovery > NODE_JOINED event (not sure why?) > 4) The last node in the ring fails to connect to the newly joined node and > generates NODE_FAILED event > 5) Coordinator drops the connection, joining node attempts to connect again > The issues I see here: > 1) Neither coordinator nor joining node print out the reason why the joining > node failed / did not join. A slight hint (failed to send message to the next > node) is printed on the node with the largest order (the one that attempted > to close the ring), but the root cause (connection refused) is also not > printed > 2) The joining node attempts to connect to the cluster with the same node ID. > This violates an invariant we heavily rely on that once a node ID leaves a > cluster, this ID never comes back again > 3) Each discovery event leads to a partition exchange which blocks all cache > operations for a time interval equal at least to the full ring latency time. > If several nodes are started on a malicious host, this may lead to almost > full cluster degradation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9259) Wrong log message in IgniteKernal#ackMemoryConfiguration
Dmitry Karachentsev created IGNITE-9259: --- Summary: Wrong log message in IgniteKernal#ackMemoryConfiguration Key: IGNITE-9259 URL: https://issues.apache.org/jira/browse/IGNITE-9259 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Dmitry Karachentsev Fix For: 2.7 Message should be changed: DataStorageConfiguration.systemCacheMemorySize -> DataStorageConfiguration.systemRegionInitialSize Userlist thread: http://apache-ignite-users.70518.x6.nabble.com/System-cache-s-DataRegion-size-is-configured-to-40-MB-td23305.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9257) LOCAL cache doesn't evict entries from heap
Dmitry Karachentsev created IGNITE-9257: --- Summary: LOCAL cache doesn't evict entries from heap Key: IGNITE-9257 URL: https://issues.apache.org/jira/browse/IGNITE-9257 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Dmitry Karachentsev Fix For: 2.7 Reproducer http://apache-ignite-users.70518.x6.nabble.com/When-using-CacheMode-LOCAL-OOM-td23285.html This happens because all entries are kept in GridCacheAdapter#map. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568160#comment-16568160
]
Dmitry Karachentsev commented on IGNITE-9043:
-
[~dmekhanikov] Reviewed, looks OK for me.
> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Labels: usability
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
> fieldType=Object, assignedValueType=Map]
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
> at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}
> It would be convenient, if objects of any type could be written as {{Object}}
> without the need to specify the type explicitly in
> {{BinaryObjectBuilder.setField(...)}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-5103:
---
Assignee: (was: Dmitry Karachentsev)
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Priority: Major
> Fix For: 2.7
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev resolved IGNITE-8985. - Resolution: Won't Fix Will be fixed by IGNITE-8944, no need to change loopback address detection, there is always will be space for false positive detection, and this should not influence on overall logic. > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9038) Node join serialization defaults
[ https://issues.apache.org/jira/browse/IGNITE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550627#comment-16550627 ] Dmitry Karachentsev commented on IGNITE-9038: - [PR 4389 | https://github.com/apache/ignite/pull/4389] > Node join serialization defaults > > > Key: IGNITE-9038 > URL: https://issues.apache.org/jira/browse/IGNITE-9038 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > staticallyConfigured flag in CacheJoinNodeDiscoveryData.CacheInfo should be > true by default to keep it consistent to previous protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9038) Node join serialization defaults
Dmitry Karachentsev created IGNITE-9038: --- Summary: Node join serialization defaults Key: IGNITE-9038 URL: https://issues.apache.org/jira/browse/IGNITE-9038 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Fix For: 2.7 staticallyConfigured flag in CacheJoinNodeDiscoveryData.CacheInfo should be true by default to keep it consistent to previous protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS
[ https://issues.apache.org/jira/browse/IGNITE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547743#comment-16547743 ] Dmitry Karachentsev commented on IGNITE-5569: - [TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F2554%2Fhead] looks OK. > TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a > cluster DDoS > - > > Key: IGNITE-5569 > URL: https://issues.apache.org/jira/browse/IGNITE-5569 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > A firewall configuration issue may effectively lead to a cluster DDoS. The > scheme is as follows: > 1) A node G joins the cluster, and a firewall rule forbids incoming > connection from cluster to this node > 2) Cluster successfully processes NodeAddedMesage and fires a discovery > NODE_JOINED event (not sure why?) > 4) The last node in the ring fails to connect to the newly joined node and > generates NODE_FAILED event > 5) Coordinator drops the connection, joining node attempts to connect again > The issues I see here: > 1) Neither coordinator nor joining node print out the reason why the joining > node failed / did not join. A slight hint (failed to send message to the next > node) is printed on the node with the largest order (the one that attempted > to close the ring), but the root cause (connection refused) is also not > printed > 2) The joining node attempts to connect to the cluster with the same node ID. > This violates an invariant we heavily rely on that once a node ID leaves a > cluster, this ID never comes back again > 3) Each discovery event leads to a partition exchange which blocks all cache > operations for a time interval equal at least to the full ring latency time. > If several nodes are started on a malicious host, this may lead to almost > full cluster degradation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8759) TcpDiscoverySpi: detailed info about current state in MBean
[ https://issues.apache.org/jira/browse/IGNITE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-8759: Fix Version/s: 2.7 > TcpDiscoverySpi: detailed info about current state in MBean > --- > > Key: IGNITE-8759 > URL: https://issues.apache.org/jira/browse/IGNITE-8759 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.7 > > > When TcpDiscoverySpi is used all nodes keep information about current > topology locally. Discovery protocol is responsible of keeping this > information consistent across all nodes. > However in situations of network glitches some nodes may have different > pictures of current state and topology of the cluster. > To make it easier to monitor state of the whole cluster and identify such > nodes quicker the following information should be presented via MBean > interface on each node: > * Current topology version; > * Hash of current topology (e.g. sum of hash codes of all nodeIds) (to allow > quick matching); > * Pretty-formatted snapshot of current topology visible from the node; > * Information about nodes visible/invisible to local one; > * Other information useful to monitoring of topology state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8759) TcpDiscoverySpi: detailed info about current state in MBean
[ https://issues.apache.org/jira/browse/IGNITE-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8759: --- Assignee: Dmitry Karachentsev > TcpDiscoverySpi: detailed info about current state in MBean > --- > > Key: IGNITE-8759 > URL: https://issues.apache.org/jira/browse/IGNITE-8759 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > When TcpDiscoverySpi is used all nodes keep information about current > topology locally. Discovery protocol is responsible of keeping this > information consistent across all nodes. > However in situations of network glitches some nodes may have different > pictures of current state and topology of the cluster. > To make it easier to monitor state of the whole cluster and identify such > nodes quicker the following information should be presented via MBean > interface on each node: > * Current topology version; > * Hash of current topology (e.g. sum of hash codes of all nodeIds) (to allow > quick matching); > * Pretty-formatted snapshot of current topology visible from the node; > * Information about nodes visible/invisible to local one; > * Other information useful to monitoring of topology state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8760) TcpDiscoverySpi: validation of discovery message path on each node
[ https://issues.apache.org/jira/browse/IGNITE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8760: --- Assignee: Dmitry Karachentsev > TcpDiscoverySpi: validation of discovery message path on each node > -- > > Key: IGNITE-8760 > URL: https://issues.apache.org/jira/browse/IGNITE-8760 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > As each discovery message goes across the ring it can record all nodes it was > handled on. > It gives discovery protocol an opportunity to set up a constant monitoring of > cluster topology: each node on receiving discovery message will compare path > recorded by the message and its local picture of current topology. On > detecting any discrepancy node may at least print warning or take other > actions. > Path recording may be expensive in terms of network traffic so it is better > to add this logic to specific types of discovery messages: all topology > changing messages and (may be) heartbeats. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545174#comment-16545174 ] Dmitry Karachentsev commented on IGNITE-8985: - Added [PR 4365 | https://github.com/apache/ignite/pull/4365], but test should be rerun along with IGNITE-8944. > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9011) RendezvousAffinity.excludeNeighbors should be removed and be a default behavior
Dmitry Karachentsev created IGNITE-9011: --- Summary: RendezvousAffinity.excludeNeighbors should be removed and be a default behavior Key: IGNITE-9011 URL: https://issues.apache.org/jira/browse/IGNITE-9011 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.6 Reporter: Dmitry Karachentsev Fix For: 3.0 According to this [discussion | http://apache-ignite-developers.2346864.n4.nabble.com/Neighbors-exclusion-td32550.html], cache backup distribution should be more straightforward. Right now we have not obvious logic on how backups will be stored across nodes. For example: 1. If set nodeFilter, it will filter backup nodes and if there are not enough nodes there will be less backups... 2. If set property excludeNeighbors, it will ignore manually set backupFilter. 3. By default excludeNeighbors is false. There seems no need to keep excludeNeighbors property at all and it should be removed. Instead, node always must do the best to distribute backups to different machines. If user set backupFilter, it must be used, otherwise distribute backups to other machines if it's possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8922) Discovery message delivery guarantee can be violated
[
https://issues.apache.org/jira/browse/IGNITE-8922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545117#comment-16545117
]
Dmitry Karachentsev commented on IGNITE-8922:
-
[~dmekhanikov] in general it looks fine, but node is vulnerable for OOME or
IllegalStateException, because pending message queue could grow unlimited now.
Anyway, both cases: node hang due to lost messages or OOME are harmful, but
last is less possible. I'm OK with this change so far.
> Discovery message delivery guarantee can be violated
>
>
> Key: IGNITE-8922
> URL: https://issues.apache.org/jira/browse/IGNITE-8922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: PendingMessageResendTest.java
>
>
> Under certain circumstances discovery messages may be delivered only to a
> part of nodes.
> It happens because pending messages are not resent due to data inconsistency
> in {{ServerImpl#PendingMessages}} class. If {{discardId}} or
> {{customDiscardId}} point to a message, that is not present in the queue,
> then other messages will be skipped and won't be resent. It may happen, for
> example, when queue in {{PendingMessages}} is overflown.
> PFA test, that reproduces this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545021#comment-16545021
]
Dmitry Karachentsev commented on IGNITE-8944:
-
[TC |
https://ci.ignite.apache.org/viewLog.html?buildId=1487349&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Spi]
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8859) Open upper Java verison bounds
[ https://issues.apache.org/jira/browse/IGNITE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542768#comment-16542768 ] Dmitry Karachentsev commented on IGNITE-8859: - [~vveider] Thanks for review! I've fixed one note and answered on second one, please check. > Open upper Java verison bounds > -- > > Key: IGNITE-8859 > URL: https://issues.apache.org/jira/browse/IGNITE-8859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > JDK is going to be release twice a year and it will be always an issue for > users to start Ignite on newer Java version as we have explicit bounds. > Ignite should not disallow starting in latest JDK, but show warning that it > wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542723#comment-16542723 ] Dmitry Karachentsev commented on IGNITE-8985: - Here are few things that caused this behavior. 1. One node was killed. 2. Previous for it was unable to connect and tried to go to next of the killed. 3. As we have 60 secs of failure detection timeout, then connection check frequency will be 60 / 3 = 20 secs. So it means that previous node will be treated as failed if there was no message during 20 secs. In the other hand, recovery timeout is 10 secs. 4. Another case is that each node has two loopback addresses, when one of them 172.17.0.1:47500 is not determined as localhost and was checked. In other words node checked connection to itself. To fix it should be applied loopback check from IGNITE-8683 ticket and add IGNITE-8944 to mark node as failed faster. > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8985) Node segmented itself after connRecoveryTimeout
[ https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8985: --- Assignee: Dmitry Karachentsev > Node segmented itself after connRecoveryTimeout > --- > > Key: IGNITE-8985 > URL: https://issues.apache.org/jira/browse/IGNITE-8985 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Dmitry Karachentsev >Priority: Major > Attachments: Archive.zip > > > I can see the following message in logs: > [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect > to next nodes in a ring, it seems local node is experiencing connectivity > issues. Segmenting local node to avoid case when one node fails a big part of > cluster. To disable that behavior set > TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. > [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1] > [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node > SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, > addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, > lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, > order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, > ver=2.4.7#20180710-sha1:a48ae923, isClient=false] > I have failure detection time out 60_000 and during the test I had GC > <25secs, so I don't expect that node should be segmented. > > Logs are attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534590#comment-16534590
]
Dmitry Karachentsev commented on IGNITE-8944:
-
[PR 4320|https://github.com/apache/ignite/pull/4320]
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-8944:
---
Assignee: Dmitry Karachentsev
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[ https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534495#comment-16534495 ] Dmitry Karachentsev commented on IGNITE-8766: - [TC results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F4317%2Fhead] > TcpDiscoverySpi: discovery threads naming > - > > Key: IGNITE-8766 > URL: https://issues.apache.org/jira/browse/IGNITE-8766 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.7 > > > Including information about next/prev nodes into names of discovery-related > threads could be very helpful when investigating situations of network > glitches. > tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such > information in their names. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Labels: discovery (was: )
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Affects Version/s: 2.5
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Component/s: general
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
[
https://issues.apache.org/jira/browse/IGNITE-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8944:
Fix Version/s: 2.7
> TcpDiscoverySpi: set connection check frequency to fixed value
> --
>
> Key: IGNITE-8944
> URL: https://issues.apache.org/jira/browse/IGNITE-8944
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Now connCheckFreq value calculated by some not obvious code:
> {code:java}
> private void initConnectionCheckFrequency() {
> if (spi.failureDetectionTimeoutEnabled())
> connCheckThreshold = spi.failureDetectionTimeout();
> else
> connCheckThreshold = Math.min(spi.getSocketTimeout(),
> spi.metricsUpdateFreq);
> for (int i = 3; i > 0; i--) {
> connCheckFreq = connCheckThreshold / i;
> if (connCheckFreq > 10)
> break;
> }
> assert connCheckFreq > 0;
> if (log.isInfoEnabled())
> log.info("Connection check frequency is calculated: " +
> connCheckFreq);
> }
> {code}
> It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8944) TcpDiscoverySpi: set connection check frequency to fixed value
Dmitry Karachentsev created IGNITE-8944:
---
Summary: TcpDiscoverySpi: set connection check frequency to fixed
value
Key: IGNITE-8944
URL: https://issues.apache.org/jira/browse/IGNITE-8944
Project: Ignite
Issue Type: Improvement
Reporter: Dmitry Karachentsev
Now connCheckFreq value calculated by some not obvious code:
{code:java}
private void initConnectionCheckFrequency() {
if (spi.failureDetectionTimeoutEnabled())
connCheckThreshold = spi.failureDetectionTimeout();
else
connCheckThreshold = Math.min(spi.getSocketTimeout(),
spi.metricsUpdateFreq);
for (int i = 3; i > 0; i--) {
connCheckFreq = connCheckThreshold / i;
if (connCheckFreq > 10)
break;
}
assert connCheckFreq > 0;
if (log.isInfoEnabled())
log.info("Connection check frequency is calculated: " +
connCheckFreq);
}
{code}
It should be replaced with constant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533963#comment-16533963
]
Dmitry Karachentsev commented on IGNITE-8766:
-
Added coordinator flag. If local node is coordinator "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related
> threads could be very helpful when investigating situations of network
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such
> information in their names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533963#comment-16533963
]
Dmitry Karachentsev edited comment on IGNITE-8766 at 7/5/18 5:52 PM:
-
Added coordinator flag. If local node is coordinator, "crd" will be added to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
was (Author: dkarachentsev):
Added coordinator flag. If local node is coordinator, "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related
> threads could be very helpful when investigating situations of network
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such
> information in their names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533963#comment-16533963
]
Dmitry Karachentsev edited comment on IGNITE-8766 at 7/5/18 5:52 PM:
-
Added coordinator flag. If local node is coordinator, "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
was (Author: dkarachentsev):
Added coordinator flag. If local node is coordinator "crd" will be adder to
ring message worker thread name:
{noformat}
"tcp-disco-msg-worker-[ebd1a087 127.0.0.1:47501 crd]-#2"
{noformat}
> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related
> threads could be very helpful when investigating situations of network
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such
> information in their names.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming
[ https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8766: --- Assignee: Dmitry Karachentsev > TcpDiscoverySpi: discovery threads naming > - > > Key: IGNITE-8766 > URL: https://issues.apache.org/jira/browse/IGNITE-8766 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Sergey Chugunov >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > > Including information about next/prev nodes into names of discovery-related > threads could be very helpful when investigating situations of network > glitches. > tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such > information in their names. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8859) Open upper Java verison bounds
[ https://issues.apache.org/jira/browse/IGNITE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527660#comment-16527660 ] Dmitry Karachentsev commented on IGNITE-8859: - [PR 4281| https://github.com/apache/ignite/pull/4281] > Open upper Java verison bounds > -- > > Key: IGNITE-8859 > URL: https://issues.apache.org/jira/browse/IGNITE-8859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > JDK is going to be release twice a year and it will be always an issue for > users to start Ignite on newer Java version as we have explicit bounds. > Ignite should not disallow starting in latest JDK, but show warning that it > wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8859) Open upper Java verison bounds
[ https://issues.apache.org/jira/browse/IGNITE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-8859: Affects Version/s: 2.6 > Open upper Java verison bounds > -- > > Key: IGNITE-8859 > URL: https://issues.apache.org/jira/browse/IGNITE-8859 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.7 > > > JDK is going to be release twice a year and it will be always an issue for > users to start Ignite on newer Java version as we have explicit bounds. > Ignite should not disallow starting in latest JDK, but show warning that it > wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8858) Client node may not stop
[
https://issues.apache.org/jira/browse/IGNITE-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527645#comment-16527645
]
Dmitry Karachentsev commented on IGNITE-8858:
-
[~agoncharuk] I've checked last run, don't see fails related to fix
[TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F4247%2Fhead]
> Client node may not stop
>
>
> Key: IGNITE-8858
> URL: https://issues.apache.org/jira/browse/IGNITE-8858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.7
>
>
> There is possible case when client node is not stopped and blocked on waiting
> when SocketReader will be completed. Looks like interruption was lost, and
> the only place where it could happen is in unmarshaling message from input
> stream.
> The way to overcome/fix it is to check if InterruptedException was in cause
> of IgniteCheckedException and repeatedly interrupt reader on stop.
>
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1245)
> - locked <0x00041016a140> (a
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader)
> at java.lang.Thread.join(Thread.java:1319)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4604)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:315)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2061)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1608)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2216)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x000410065e80> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:365)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3417)
> "tcp-client-disco-sock-reader-#35%Default%" #746 prio=5 os_prio=0
> tid=0x7f6090561800 nid=0x3441 in Object.wait() [0x7f60f23d8000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader.body(ClientImpl.java:1006)
> - locked <0x00041016a2e0> (a java.lang.Object)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7163) Validate connection from a pre-previous node
[ https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527482#comment-16527482 ] Dmitry Karachentsev commented on IGNITE-7163: - [~yzhdanov] Yes, it validates, even if user set larger value, failureDetectionTimeout will be applied. It cannot be changed through mx bean, but in terms of this ticket added connection check interval. > Validate connection from a pre-previous node > > > Key: IGNITE-7163 > URL: https://issues.apache.org/jira/browse/IGNITE-7163 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.7 > > > If some pre-previous node connects to the local node with the previous node > in the message's failed nodes collection additional steps should be done: > # Connection with the previous node should be validated. > # If a message from the previous node was not received a long time ago, the > previous node should be considered as failed and the pre-previous node > connection accepted. > # If the previous node connection is alive then different scenarios possible > ## Answer with a new result code causing the pre-previous node to try to > reconnect to the previous node > ## Break connection with the pre-previous node causing to continue the > possible cluster split. > ## Check connections with nodes after pre-previous node and delay decision by > answering RES_WAIT to get more predictable split and stable topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8896) Wrong javadoc for TcpCommunicationSpi.setSlowClientQueueLimit()
Dmitry Karachentsev created IGNITE-8896:
---
Summary: Wrong javadoc for
TcpCommunicationSpi.setSlowClientQueueLimit()
Key: IGNITE-8896
URL: https://issues.apache.org/jira/browse/IGNITE-8896
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Dmitry Karachentsev
Fix For: 2.7
Javadoc for TcpCommunicationSpi.setSlowClientQueueLimit() says that is should
be set to value equal to TcpCommunicationSpi.getMessageQueueLimit().
But this is wrong, because first checks back pressure limit and sender thread
will be blocked before slow client check. Also, warning checks the value
correctly, but message should be "...greater or equal...":
{code:java}
if (slowClientQueueLimit > 0 && msgQueueLimit > 0 && slowClientQueueLimit >=
msgQueueLimit) {
U.quietAndWarn(log, "Slow client queue limit is set to a value
greater than message queue limit " +
"(slow client queue limit will have no effect) [msgQueueLimit="
+ msgQueueLimit +
", slowClientQueueLimit=" + slowClientQueueLimit + ']');
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8859) Open upper Java verison bounds
[ https://issues.apache.org/jira/browse/IGNITE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-8859: --- Assignee: Dmitry Karachentsev > Open upper Java verison bounds > -- > > Key: IGNITE-8859 > URL: https://issues.apache.org/jira/browse/IGNITE-8859 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.6 > > > JDK is going to be release twice a year and it will be always an issue for > users to start Ignite on newer Java version as we have explicit bounds. > Ignite should not disallow starting in latest JDK, but show warning that it > wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7163) Validate connection from a pre-previous node
[ https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16523481#comment-16523481 ] Dmitry Karachentsev commented on IGNITE-7163: - [~yzhdanov] I want to have ability to disable this recovery in first. And this timeout should not be greater than failureDetectionTimeout, because during recovery procedure ring remains broken. > Validate connection from a pre-previous node > > > Key: IGNITE-7163 > URL: https://issues.apache.org/jira/browse/IGNITE-7163 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.6 > > > If some pre-previous node connects to the local node with the previous node > in the message's failed nodes collection additional steps should be done: > # Connection with the previous node should be validated. > # If a message from the previous node was not received a long time ago, the > previous node should be considered as failed and the pre-previous node > connection accepted. > # If the previous node connection is alive then different scenarios possible > ## Answer with a new result code causing the pre-previous node to try to > reconnect to the previous node > ## Break connection with the pre-previous node causing to continue the > possible cluster split. > ## Check connections with nodes after pre-previous node and delay decision by > answering RES_WAIT to get more predictable split and stable topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8858) Client node may not stop
[
https://issues.apache.org/jira/browse/IGNITE-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8858:
Summary: Client node may not stop (was: Client none may not stop)
> Client node may not stop
>
>
> Key: IGNITE-8858
> URL: https://issues.apache.org/jira/browse/IGNITE-8858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.6
>
>
> There is possible case when client node is not stopped and blocked on waiting
> when SocketReader will be completed. Looks like interruption was lost, and
> the only place where it could happen is in unmarshaling message from input
> stream.
> The way to overcome/fix it is to check if InterruptedException was in cause
> of IgniteCheckedException and repeatedly interrupt reader on stop.
>
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1245)
> - locked <0x00041016a140> (a
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader)
> at java.lang.Thread.join(Thread.java:1319)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4604)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:315)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2061)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1608)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2216)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x000410065e80> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:365)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3417)
> "tcp-client-disco-sock-reader-#35%Default%" #746 prio=5 os_prio=0
> tid=0x7f6090561800 nid=0x3441 in Object.wait() [0x7f60f23d8000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader.body(ClientImpl.java:1006)
> - locked <0x00041016a2e0> (a java.lang.Object)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7163) Validate connection from a pre-previous node
[ https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520544#comment-16520544 ] Dmitry Karachentsev commented on IGNITE-7163: - [~dpavlov] thanks! I will check them. > Validate connection from a pre-previous node > > > Key: IGNITE-7163 > URL: https://issues.apache.org/jira/browse/IGNITE-7163 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Dmitry Karachentsev >Priority: Major > Labels: discovery > Fix For: 2.6 > > > If some pre-previous node connects to the local node with the previous node > in the message's failed nodes collection additional steps should be done: > # Connection with the previous node should be validated. > # If a message from the previous node was not received a long time ago, the > previous node should be considered as failed and the pre-previous node > connection accepted. > # If the previous node connection is alive then different scenarios possible > ## Answer with a new result code causing the pre-previous node to try to > reconnect to the previous node > ## Break connection with the pre-previous node causing to continue the > possible cluster split. > ## Check connections with nodes after pre-previous node and delay decision by > answering RES_WAIT to get more predictable split and stable topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520428#comment-16520428 ] Dmitry Karachentsev commented on IGNITE-8618: - Created related ticket: IGNITE-8859 > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8859) Open upper Java verison bounds
Dmitry Karachentsev created IGNITE-8859: --- Summary: Open upper Java verison bounds Key: IGNITE-8859 URL: https://issues.apache.org/jira/browse/IGNITE-8859 Project: Ignite Issue Type: Improvement Reporter: Dmitry Karachentsev Fix For: 2.6 JDK is going to be release twice a year and it will be always an issue for users to start Ignite on newer Java version as we have explicit bounds. Ignite should not disallow starting in latest JDK, but show warning that it wasn't tested against running version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8618) Support Java 10
[ https://issues.apache.org/jira/browse/IGNITE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16520421#comment-16520421 ] Dmitry Karachentsev commented on IGNITE-8618: - Probably it would be better test against Java 11 LTS, because support of 10 ends on the [September|http://www.oracle.com/technetwork/java/javase/eol-135779.html]. > Support Java 10 > --- > > Key: IGNITE-8618 > URL: https://issues.apache.org/jira/browse/IGNITE-8618 > Project: Ignite > Issue Type: Task >Affects Versions: 2.4 >Reporter: Anghel Botos >Priority: Major > > Please make required changes so that Ignite runs on Java 10. > The blocking issue I encontered is related to the usage of Unsafe: > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1459) > at org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:118) > ... 30 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @754ba872 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:360) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:589) > at java.base/java.lang.reflect.Method.invoke(Method.java:556) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1456) > ... 31 more > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8858) Client none may not stop
Dmitry Karachentsev created IGNITE-8858:
---
Summary: Client none may not stop
Key: IGNITE-8858
URL: https://issues.apache.org/jira/browse/IGNITE-8858
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
Fix For: 2.6
There is possible case when client node is not stopped and blocked on waiting
when SocketReader will be completed. Looks like interruption was lost, and the
only place where it could happen is in unmarshaling message from input stream.
The way to overcome/fix it is to check if InterruptedException was in cause of
IgniteCheckedException and repeatedly interrupt reader on stop.
{noformat}
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1245)
- locked <0x00041016a140> (a
org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader)
at java.lang.Thread.join(Thread.java:1319)
at
org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4604)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:315)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2061)
at
org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1608)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2216)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
- locked <0x000410065e80> (a
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:365)
at org.apache.ignite.Ignition.stop(Ignition.java:229)
at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3417)
"tcp-client-disco-sock-reader-#35%Default%" #746 prio=5 os_prio=0
tid=0x7f6090561800 nid=0x3441 in Object.wait() [0x7f60f23d8000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader.body(ClientImpl.java:1006)
- locked <0x00041016a2e0> (a java.lang.Object)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8852) CacheJoinNodeDiscoveryData.CacheInfo has boolean flags and long field for flags
Dmitry Karachentsev created IGNITE-8852: --- Summary: CacheJoinNodeDiscoveryData.CacheInfo has boolean flags and long field for flags Key: IGNITE-8852 URL: https://issues.apache.org/jira/browse/IGNITE-8852 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Dmitry Karachentsev Fix For: 3.0 CacheJoinNodeDiscoveryData.CacheInfo has two types of flags: boolean stored in fields and long. Latter is not used. Should be picked one approach: or boolean fields, or bitmask, not both. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8851) StoredCacheData and CacheJoinNodeDiscoveryData.CacheInfo duplicate "sql" flag
Dmitry Karachentsev created IGNITE-8851: --- Summary: StoredCacheData and CacheJoinNodeDiscoveryData.CacheInfo duplicate "sql" flag Key: IGNITE-8851 URL: https://issues.apache.org/jira/browse/IGNITE-8851 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Dmitry Karachentsev Fix For: 3.0 Node when joins cluster sends cache configurations. Configuration is wrapped into StoredCacheData, and StoredCacheData into CacheJoinNodeDiscoveryData.CacheInfo. Both CacheInfo and StoredCacheData have "sql" flag that seems means the same. It should appear only once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8813) Add ComputeJobResultPolicy to JobEvent
[ https://issues.apache.org/jira/browse/IGNITE-8813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517830#comment-16517830 ] Dmitry Karachentsev commented on IGNITE-8813: - [~agura] please review the changes. > Add ComputeJobResultPolicy to JobEvent > -- > > Key: IGNITE-8813 > URL: https://issues.apache.org/jira/browse/IGNITE-8813 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 2.5 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.6 > > > There is no way to determine on node-mapper what action would be performed on > EVT_JOB_RESULTED event, as got result could return different policies: WAIT, > REDUCE, FAILOVER. This knowledge might be critical for user if it relies on > events, and, for instance, he need to know if EVT_JOB_RESULTED is final > event, or it will be failed over and will be fired again. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8813) Add ComputeJobResultPolicy to JobEvent
Dmitry Karachentsev created IGNITE-8813: --- Summary: Add ComputeJobResultPolicy to JobEvent Key: IGNITE-8813 URL: https://issues.apache.org/jira/browse/IGNITE-8813 Project: Ignite Issue Type: Improvement Components: compute Affects Versions: 2.5 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Fix For: 2.6 There is no way to determine on node-mapper what action would be performed on EVT_JOB_RESULTED event, as got result could return different policies: WAIT, REDUCE, FAILOVER. This knowledge might be critical for user if it relies on events, and, for instance, he need to know if EVT_JOB_RESULTED is final event, or it will be failed over and will be fired again. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7163) Validate connection from a pre-previous node
[ https://issues.apache.org/jira/browse/IGNITE-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-7163: --- Assignee: Dmitry Karachentsev (was: Alexandr Kuramshin) > Validate connection from a pre-previous node > > > Key: IGNITE-7163 > URL: https://issues.apache.org/jira/browse/IGNITE-7163 > Project: Ignite > Issue Type: Sub-task > Components: general >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Dmitry Karachentsev >Priority: Major > > If some pre-previous node connects to the local node with the previous node > in the message's failed nodes collection additional steps should be done: > # Connection with the previous node should be validated. > # If a message from the previous node was not received a long time ago, the > previous node should be considered as failed and the pre-previous node > connection accepted. > # If the previous node connection is alive then different scenarios possible > ## Answer with a new result code causing the pre-previous node to try to > reconnect to the previous node > ## Break connection with the pre-previous node causing to continue the > possible cluster split. > ## Check connections with nodes after pre-previous node and delay decision by > answering RES_WAIT to get more predictable split and stable topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8500) [Cassandra] Allow dynamic cache creation with Cassandra Store
[
https://issues.apache.org/jira/browse/IGNITE-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-8500:
Description:
It's not possible for now dynamically create caches with Cassandra cache store:
{noformat}
class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7307)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2433)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.calculatedField(PojoField.java:155)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.prepareLoadStatements(PersistenceController.java:313)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.(PersistenceController.java:85)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.(CassandraCacheStore.java:106)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:59)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:34)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1437)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1945)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1864)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:674)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
... 3 more
{noformat}
PR with test https://github.com/apache/ignite/pull/4003
was:
It's not possible for now dynamically create caches with Cassandra cache store:
{noformat}
class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7307)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2433)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.calculatedField(PojoField.java:155)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.prepareLoadStatements(PersistenceController.java:313)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.(PersistenceController.java:85)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.(CassandraCacheStore.java:106)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:59)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:34)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1437)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1945)
at
org.apache.ignite.internal.processors.cache.GridCacheProc
[jira] [Created] (IGNITE-8500) [Cassandra] Allow dynamic cache creation with Cassandra Store
Dmitry Karachentsev created IGNITE-8500:
---
Summary: [Cassandra] Allow dynamic cache creation with Cassandra
Store
Key: IGNITE-8500
URL: https://issues.apache.org/jira/browse/IGNITE-8500
Project: Ignite
Issue Type: Improvement
Components: cassandra
Affects Versions: 2.5
Reporter: Dmitry Karachentsev
Fix For: 2.6
It's not possible for now dynamically create caches with Cassandra cache store:
{noformat}
class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7307)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2433)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.calculatedField(PojoField.java:155)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.prepareLoadStatements(PersistenceController.java:313)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.(PersistenceController.java:85)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.(CassandraCacheStore.java:106)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:59)
at
org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory.create(CassandraCacheStoreFactory.java:34)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1437)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1945)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1864)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:674)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
... 3 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-3164:
---
Assignee: Dmitry Karachentsev
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Major
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
> We also need to update documentation, especially provide the explanation of
> EP behavior in atomic and transactional caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-3471) Do not send previous value to client node for invoke() when possible
[
https://issues.apache.org/jira/browse/IGNITE-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-3471:
---
Assignee: Dmitry Karachentsev
> Do not send previous value to client node for invoke() when possible
>
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to
> near node and apply EntryProcessor locally to get a return value. This can
> induce a significant overhead when cache value is much larger than entry
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in
> this case.
> cache.get(key); // This should actually get the current cache value from
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7572) Local cache fails to start on client node
[
https://issues.apache.org/jira/browse/IGNITE-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379905#comment-16379905
]
Dmitry Karachentsev edited comment on IGNITE-7572 at 2/28/18 7:42 AM:
--
[~dpavlov] please review the fix. [PR
3568|https://github.com/apache/ignite/pull/3568/commits] [TC results
|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3568%2Fhead]
was (Author: dkarachentsev):
[~dpavlov] please review the fix. [TC
results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3568%2Fhead]
> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600")
[jira] [Comment Edited] (IGNITE-7572) Local cache fails to start on client node
[
https://issues.apache.org/jira/browse/IGNITE-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379905#comment-16379905
]
Dmitry Karachentsev edited comment on IGNITE-7572 at 2/28/18 7:42 AM:
--
[~dpavlov] please review the fix. [PR
3568|https://github.com/apache/ignite/pull/3568/commits] [TC
results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3568%2Fhead]
was (Author: dkarachentsev):
[~dpavlov] please review the fix. [PR
3568|https://github.com/apache/ignite/pull/3568/commits] [TC results
|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3568%2Fhead]
> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
>
[jira] [Commented] (IGNITE-7572) Local cache fails to start on client node
[
https://issues.apache.org/jira/browse/IGNITE-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379905#comment-16379905
]
Dmitry Karachentsev commented on IGNITE-7572:
-
[~dpavlov] please review the fix. [TC
results|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3568%2Fhead]
> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration("TEST");
> cacheConfiguration.setCacheMode(CacheMode.LOCAL);
> cfg.setCacheConfiguration(cacheConfiguration);
> cfg.setDiscoverySpi(new TcpDiscoverySpi
[jira] [Updated] (IGNITE-7673) Remove using of Collections.UnmodifiableCollection from GridTaskSessionImpl
[ https://issues.apache.org/jira/browse/IGNITE-7673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-7673: Fix Version/s: (was: 2.5) > Remove using of Collections.UnmodifiableCollection from GridTaskSessionImpl > --- > > Key: IGNITE-7673 > URL: https://issues.apache.org/jira/browse/IGNITE-7673 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Minor > > GridTaskWorker marshals GridTaskSessionImpl.siblings which is > UnmodifiableCollection which forces use of OptimizedMarshaller that may have > performance impact. It should be replaced with original collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7673) Remove using of Collections.UnmodifiableCollection from GridTaskSessionImpl
[ https://issues.apache.org/jira/browse/IGNITE-7673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev resolved IGNITE-7673. - Resolution: Won't Fix > Remove using of Collections.UnmodifiableCollection from GridTaskSessionImpl > --- > > Key: IGNITE-7673 > URL: https://issues.apache.org/jira/browse/IGNITE-7673 > Project: Ignite > Issue Type: Improvement > Components: compute >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Minor > Fix For: 2.5 > > > GridTaskWorker marshals GridTaskSessionImpl.siblings which is > UnmodifiableCollection which forces use of OptimizedMarshaller that may have > performance impact. It should be replaced with original collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7673) Remove using of Collections.UnmodifiableCollection from GridTaskSessionImpl
Dmitry Karachentsev created IGNITE-7673: --- Summary: Remove using of Collections.UnmodifiableCollection from GridTaskSessionImpl Key: IGNITE-7673 URL: https://issues.apache.org/jira/browse/IGNITE-7673 Project: Ignite Issue Type: Improvement Components: compute Affects Versions: 2.3 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Fix For: 2.5 GridTaskWorker marshals GridTaskSessionImpl.siblings which is UnmodifiableCollection which forces use of OptimizedMarshaller that may have performance impact. It should be replaced with original collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-6970) Error thrown from CacheStore cause cache operation hanging.
[ https://issues.apache.org/jira/browse/IGNITE-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev resolved IGNITE-6970. - Resolution: Won't Fix Won't fix, because Error means unrecoverable state and there is no reason to handle it. > Error thrown from CacheStore cause cache operation hanging. > --- > > Key: IGNITE-6970 > URL: https://issues.apache.org/jira/browse/IGNITE-6970 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Dmitry Karachentsev >Priority: Major > > If some error (e.g. NoSuchMethodError) was thrown from CacheStore > implementation during simple cache.get(), > then operation hangs as server fails and never sends NearAtomicGetResponse to > client > and never complete async future. > GridCacheAdapter.getAllAsync0 method failed on GridEmbeddedFuture creation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6970) Error thrown from CacheStore cause cache operation hanging.
[ https://issues.apache.org/jira/browse/IGNITE-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-6970: --- Assignee: Dmitry Karachentsev > Error thrown from CacheStore cause cache operation hanging. > --- > > Key: IGNITE-6970 > URL: https://issues.apache.org/jira/browse/IGNITE-6970 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Dmitry Karachentsev >Priority: Major > > If some error (e.g. NoSuchMethodError) was thrown from CacheStore > implementation during simple cache.get(), > then operation hangs as server fails and never sends NearAtomicGetResponse to > client > and never complete async future. > GridCacheAdapter.getAllAsync0 method failed on GridEmbeddedFuture creation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7572) Local cache fails to start on client node
[
https://issues.apache.org/jira/browse/IGNITE-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-7572:
---
Assignee: Dmitry Karachentsev
> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Reproducer:
>
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration("TEST");
> cacheConfiguration.setCacheMode(CacheMode.LOCAL);
> cfg.setCacheConfiguration(cacheConfiguration);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-5103:
Fix Version/s: (was: 2.4)
2.5
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS
[ https://issues.apache.org/jira/browse/IGNITE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-5569: Fix Version/s: (was: 2.4) 2.5 > TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a > cluster DDoS > - > > Key: IGNITE-5569 > URL: https://issues.apache.org/jira/browse/IGNITE-5569 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Dmitry Karachentsev >Priority: Major > Fix For: 2.5 > > > A firewall configuration issue may effectively lead to a cluster DDoS. The > scheme is as follows: > 1) A node G joins the cluster, and a firewall rule forbids incoming > connection from cluster to this node > 2) Cluster successfully processes NodeAddedMesage and fires a discovery > NODE_JOINED event (not sure why?) > 4) The last node in the ring fails to connect to the newly joined node and > generates NODE_FAILED event > 5) Coordinator drops the connection, joining node attempts to connect again > The issues I see here: > 1) Neither coordinator nor joining node print out the reason why the joining > node failed / did not join. A slight hint (failed to send message to the next > node) is printed on the node with the largest order (the one that attempted > to close the ring), but the root cause (connection refused) is also not > printed > 2) The joining node attempts to connect to the cluster with the same node ID. > This violates an invariant we heavily rely on that once a node ID leaves a > cluster, this ID never comes back again > 3) Each discovery event leads to a partition exchange which blocks all cache > operations for a time interval equal at least to the full ring latency time. > If several nodes are started on a malicious host, this may lead to almost > full cluster degradation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-1393) [Test] AssertionError when stop node executing transaction - GridCacheStopSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev resolved IGNITE-1393.
-
Resolution: Fixed
Fix Version/s: 2.1
Fixed by ab5267134966b466a2d4bfba15d0c7e3ebe91139 commit by [~sboikov]
> [Test] AssertionError when stop node executing transaction -
> GridCacheStopSelfTest
> ---
>
> Key: IGNITE-1393
> URL: https://issues.apache.org/jira/browse/IGNITE-1393
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Semen Boikov
>Assignee: Ryabov Dmitrii
> Labels: Muted_test
> Fix For: 2.1
>
>
> I fixed GridCacheStopSelfTest which was disabled for long time, now it fails
> because of asserts:
> {noformat}
> [10:53:02,362][ERROR][async-runner-1][GridNearTxLocal] Heuristic transaction
> failure.
> class
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
> Failed to locally write to cache (all transaction entries will be
> invalidated, however there was a window when entries for this transaction
> were visible to others): GridNearTxLocal [nearLocallyMapped=false,
> colocatedLocallyMapped=true, hasRemoteLocks=false,
> mappings=[009f5238-db3d-426f-b787-9a4a156e8000], super=GridDhtTxLocalAdapter
> [dhtThreadId=101, needsCompletedVers=false, nearNodes=[], dhtNodes=[],
> explicitLock=false, super=IgniteTxLocalAdapter [txMap={IgniteTxKey
> [key=KeyCacheObjectImpl [val=22, hasValBytes=true], cacheId=1]=IgniteTxEntry
> [key=KeyCacheObjectImpl [val=22, hasValBytes=true], cacheId=1,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=22, hasValBytes=true],
> cacheId=1], val=[op=CREATE, val=UserCacheObjectImpl [val=22,
> hasValBytes=true]], prevVal=[op=CREATE, val=UserCacheObjectImpl [val=22,
> hasValBytes=true]], entryProcessorsCol=null, entryProcessorCalcVal=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=GridCacheVersion [topVer=53261582, nodeOrderDrId=1,
> globalTime=1441781582327, order=1441781581691], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=22,
> mapPubSize=1, rmvQueue=GridCircularBuffer [sizeMask=31, idxGen=0],
> state=OWNING, reservations=0, empty=false, createTime=09/09/2015 10:53:02,
> mapPubSize=1], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=22, hasValBytes=true], val=CacheObjectImpl
> [val=22, hasValBytes=true], startVer=1441781581658, ver=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582327,
> order=1441781581691], hash=2018242870, extras=null, flags=2,
> prepared=false, locked=true, nodeId=009f5238-db3d-426f-b787-9a4a156e8000,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0,
> xidVer=GridCacheVersion [topVer=53261582, nodeOrderDrId=1,
> globalTime=1441781582217, order=1441781581591]]}, completedBase=null,
> sndTransformedVals=false, super=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582217,
> order=1441781581591], writeVer=GridCacheVersion [topVer=53261582,
> nodeOrderDrId=1, globalTime=1441781582327, order=1441781581691],
> implicit=false, implicitSingle=false, loc=true, threadId=101,
> startTime=1441781582212, nodeId=009f5238-db3d-426f-b787-9a4a156e8000,
> startVer=GridCacheVersion [topVer=53261582, nodeOrderDrId=1,
> globalTime=1441781582218, order=1441781581611], endVer=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582336,
> order=1441781581738], isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
> timeout=0, sysInvalidate=false, sys=false, plc=2, commitVer=GridCacheVersion
> [topVer=53261582, nodeOrderDrId=1, globalTime=1441781582217,
> order=1441781581591], finalizing=NONE, preparing=false, state=COMMITTED,
> timedOut=false, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0],
> duration=138ms, onePhaseCommit=true], size=1]]]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:1036)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.finish(GridNearTxLocal.java:654)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$3.apply(GridNearTxLocal.java:749)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$3.apply(GridNearTxLocal.java:741)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:262)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:225)
> at
> org.apache
[jira] [Updated] (IGNITE-7239) In case of not serializable cache update response, future on node requester will never complete
[ https://issues.apache.org/jira/browse/IGNITE-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-7239: Fix Version/s: 2.4 > In case of not serializable cache update response, future on node requester > will never complete > --- > > Key: IGNITE-7239 > URL: https://issues.apache.org/jira/browse/IGNITE-7239 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Minor > Fix For: 2.4 > > > To avoid such hang, if response could not be serialized, create other > response with text of the error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7340) Fix flaky GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
[
https://issues.apache.org/jira/browse/IGNITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-7340:
Fix Version/s: 2.4
> Fix flaky
> GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
> -
>
> Key: IGNITE-7340
> URL: https://issues.apache.org/jira/browse/IGNITE-7340
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
>
> {noformat}
> junit.framework.AssertionFailedError: serviceConfigEachNode expected:<4> but
> was:<3>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:277)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7340) Fix flaky GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
[
https://issues.apache.org/jira/browse/IGNITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-7340:
Description:
{noformat}
junit.framework.AssertionFailedError: serviceConfigEachNode expected:<4> but
was:<3>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.TestCase.assertEquals(TestCase.java:401)
at
org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:277)
at
org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
{noformat}
> Fix flaky
> GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
> -
>
> Key: IGNITE-7340
> URL: https://issues.apache.org/jira/browse/IGNITE-7340
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>
> {noformat}
> junit.framework.AssertionFailedError: serviceConfigEachNode expected:<4> but
> was:<3>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.checkDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:277)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest.testDeployOnEachNodeUpdateTopology(GridServiceProcessorMultiNodeConfigSelfTest.java:144)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7340) Fix flaky org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
Dmitry Karachentsev created IGNITE-7340: --- Summary: Fix flaky org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology Key: IGNITE-7340 URL: https://issues.apache.org/jira/browse/IGNITE-7340 Project: Ignite Issue Type: Bug Affects Versions: 2.3 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7340) Fix flaky GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology
[ https://issues.apache.org/jira/browse/IGNITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-7340: Summary: Fix flaky GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology (was: Fix flaky org.apache.ignite.internal.processors.service.GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology) > Fix flaky > GridServiceProcessorMultiNodeConfigSelfTest#checkDeployOnEachNodeUpdateTopology > - > > Key: IGNITE-7340 > URL: https://issues.apache.org/jira/browse/IGNITE-7340 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7239) In case of not serializable cache update response, future on node requester will never complete
[ https://issues.apache.org/jira/browse/IGNITE-7239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-7239: --- Assignee: Dmitry Karachentsev > In case of not serializable cache update response, future on node requester > will never complete > --- > > Key: IGNITE-7239 > URL: https://issues.apache.org/jira/browse/IGNITE-7239 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Minor > > To avoid such hang, if response could not be serialized, create other > response with text of the error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-7181) Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABLE_READ transaction
[ https://issues.apache.org/jira/browse/IGNITE-7181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev resolved IGNITE-7181. - Resolution: Fixed > Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABLE_READ transaction > - > > Key: IGNITE-7181 > URL: https://issues.apache.org/jira/browse/IGNITE-7181 > Project: Ignite > Issue Type: Bug >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7217) Add abilities to monitor custom thread pools
[
https://issues.apache.org/jira/browse/IGNITE-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300392#comment-16300392
]
Dmitry Karachentsev commented on IGNITE-7217:
-
Also should be added MXBeans for missed pools, for example for svcExecSvc.
> Add abilities to monitor custom thread pools
>
>
> Key: IGNITE-7217
> URL: https://issues.apache.org/jira/browse/IGNITE-7217
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
> Fix For: 2.4
>
>
> We have a periodic metrics logger that prints out different stats including
> the ones for public and system thread pools:
> {noformat}
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> {noformat}
> However, if user configures a custom thread pools via
> {{IgniteConfiguration#setExecutorConfiguration}}, stats for these thread
> pools are not added. We also do not register MBeans for these pools.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7239) In case of not serializable cache update response, future on node requester will never complete
Dmitry Karachentsev created IGNITE-7239: --- Summary: In case of not serializable cache update response, future on node requester will never complete Key: IGNITE-7239 URL: https://issues.apache.org/jira/browse/IGNITE-7239 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.3 Reporter: Dmitry Karachentsev Priority: Minor To avoid such hang, if response could not be serialized, create other response with text of the error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7206) Nodes may ping each other on stop for a failureDetectionTimeout period
Dmitry Karachentsev created IGNITE-7206: --- Summary: Nodes may ping each other on stop for a failureDetectionTimeout period Key: IGNITE-7206 URL: https://issues.apache.org/jira/browse/IGNITE-7206 Project: Ignite Issue Type: Bug Affects Versions: 2.3 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Fix For: 2.4 On communication connection breakage TcpCommunicationSpi may try to reestablish connection and if it's failed try to ping remote node. But if remote node is stopping it refuses incoming ping connections. In case of concurrent few node stopping there possible case when nodes ping each other and refuse any incoming pings. This lasts for failureDetectionTimeout or reconenctCount that checks in ServerImpl.pingNode() method. pingNode() should check if local node is stopping and interrupt pings. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7181) Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABLE_READ transaction
Dmitry Karachentsev created IGNITE-7181: --- Summary: Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABLE_READ transaction Key: IGNITE-7181 URL: https://issues.apache.org/jira/browse/IGNITE-7181 Project: Ignite Issue Type: Bug Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7159) Fix IGNITE-7086 fails IgniteCacheAtomicExpiryPolicyWithStoreTest.testGetReadThrough
[ https://issues.apache.org/jira/browse/IGNITE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-7159: --- Assignee: Dmitry Karachentsev > Fix IGNITE-7086 fails > IgniteCacheAtomicExpiryPolicyWithStoreTest.testGetReadThrough > --- > > Key: IGNITE-7159 > URL: https://issues.apache.org/jira/browse/IGNITE-7159 > Project: Ignite > Issue Type: Bug >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7159) Fix IGNITE-7086 fails IgniteCacheAtomicExpiryPolicyWithStoreTest.testGetReadThrough
Dmitry Karachentsev created IGNITE-7159: --- Summary: Fix IGNITE-7086 fails IgniteCacheAtomicExpiryPolicyWithStoreTest.testGetReadThrough Key: IGNITE-7159 URL: https://issues.apache.org/jira/browse/IGNITE-7159 Project: Ignite Issue Type: Bug Reporter: Dmitry Karachentsev -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-7086) Backups are not updated when ReadFromBackup=true and ReadThrough happens.
[ https://issues.apache.org/jira/browse/IGNITE-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev resolved IGNITE-7086. - Resolution: Fixed > Backups are not updated when ReadFromBackup=true and ReadThrough happens. > - > > Key: IGNITE-7086 > URL: https://issues.apache.org/jira/browse/IGNITE-7086 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Dmitry Karachentsev > Fix For: 2.4 > > Attachments: ReplicatedReadFromBackupWithStoreTest.java > > > Ignite Replicated cache with CacheStore and ReadThrough=true and > ReadFromBackup=true works in unexpected way from user perspective. > On backup node, get operation will always go to the primary node regardless > of ReadFromBackup=true and ReadThrough=true when entry doesn't exists in > local map. > So, Replicated cache works like a Partitioned with no backups. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7086) Backups are not updated when ReadFromBackup=true and ReadThrough happens.
[ https://issues.apache.org/jira/browse/IGNITE-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-7086: --- Assignee: Dmitry Karachentsev > Backups are not updated when ReadFromBackup=true and ReadThrough happens. > - > > Key: IGNITE-7086 > URL: https://issues.apache.org/jira/browse/IGNITE-7086 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Dmitry Karachentsev > Fix For: 2.4 > > Attachments: ReplicatedReadFromBackupWithStoreTest.java > > > Ignite Replicated cache with CacheStore and ReadThrough=true and > ReadFromBackup=true works in unexpected way from user perspective. > On backup node, get operation will always go to the primary node regardless > of ReadFromBackup=true and ReadThrough=true when entry doesn't exists in > local map. > So, Replicated cache works like a Partitioned with no backups. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4809) Cache.getAll can return partially commited results.
[ https://issues.apache.org/jira/browse/IGNITE-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-4809: --- Assignee: (was: Dmitry Karachentsev) > Cache.getAll can return partially commited results. > --- > > Key: IGNITE-4809 > URL: https://issues.apache.org/jira/browse/IGNITE-4809 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Andrew Mashenkov > Fix For: 2.4 > > Attachments: DirtyReads2.java > > > 1. Create tansactional cache with Long values and fill it with zeroes. > 2. Start thread that would increment all values in single transaction. > 3. Start thread that would check all values are same in single transaction. > Second thread will see partial commits, but shouldn't. > Seems, it is related to OPTIMISTIC concurrency level only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4809) Cache.getAll can return partially commited results.
[ https://issues.apache.org/jira/browse/IGNITE-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-4809: --- Assignee: Dmitry Karachentsev > Cache.getAll can return partially commited results. > --- > > Key: IGNITE-4809 > URL: https://issues.apache.org/jira/browse/IGNITE-4809 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Andrew Mashenkov >Assignee: Dmitry Karachentsev > Fix For: 2.4 > > Attachments: DirtyReads2.java > > > 1. Create tansactional cache with Long values and fill it with zeroes. > 2. Start thread that would increment all values in single transaction. > 3. Start thread that would check all values are same in single transaction. > Second thread will see partial commits, but shouldn't. > Seems, it is related to OPTIMISTIC concurrency level only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6818) In case of incoming communication connection ping the old one if it's alive
[ https://issues.apache.org/jira/browse/IGNITE-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247422#comment-16247422 ] Dmitry Karachentsev commented on IGNITE-6818: - [~sboikov] please review. Thanks! > In case of incoming communication connection ping the old one if it's alive > --- > > Key: IGNITE-6818 > URL: https://issues.apache.org/jira/browse/IGNITE-6818 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev >Priority: Critical > Fix For: 2.4 > > > Assume the following scenario: > 1. Client opens connection to the server. > 2. Server checks that it is a first connection to that node and accepts it. > 3. By some reason firewall starts rejecting client messages with TCP reset > flag set. > 4. Client closes connection, but server doesn't know about it. > 5. Client tries connect again. > 6. Server rejects new connection, because it already has connection to that > node. > Possible fix: on step 6 server must check old connection if it's alive by > sending some communication message and check response. If old connection is > dead - close it and accept new one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation
[ https://issues.apache.org/jira/browse/IGNITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-6248: Fix Version/s: 2.4 > Check Java 7 builds for compatibility with Ignite and update documentation > -- > > Key: IGNITE-6248 > URL: https://issues.apache.org/jira/browse/IGNITE-6248 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Dmitry Karachentsev >Priority: Major > Labels: usability > Fix For: 2.4 > > > According to these threads on SO and user list, some old Java 7 versions > doesn't compatible with Ignite since version 2.1 anymore: > http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html > https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6818) In case of incoming communication connection ping the old one if it's alive
Dmitry Karachentsev created IGNITE-6818: --- Summary: In case of incoming communication connection ping the old one if it's alive Key: IGNITE-6818 URL: https://issues.apache.org/jira/browse/IGNITE-6818 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Affects Versions: 2.3 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Priority: Critical Fix For: 2.4 Assume the following scenario: 1. Client opens connection to the server. 2. Server checks that it is a first connection to that node and accepts it. 3. By some reason firewall starts rejecting client messages with TCP reset flag set. 4. Client closes connection, but server doesn't know about it. 5. Client tries connect again. 6. Server rejects new connection, because it already has connection to that node. Possible fix: on step 6 server must check old connection if it's alive by sending some communication message and check response. If old connection is dead - close it and accept new one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation
[ https://issues.apache.org/jira/browse/IGNITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220415#comment-16220415 ] Dmitry Karachentsev commented on IGNITE-6248: - [PR 2931|https://github.com/apache/ignite/pull/2931] > Check Java 7 builds for compatibility with Ignite and update documentation > -- > > Key: IGNITE-6248 > URL: https://issues.apache.org/jira/browse/IGNITE-6248 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Dmitry Karachentsev > Labels: usability > > According to these threads on SO and user list, some old Java 7 versions > doesn't compatible with Ignite since version 2.1 anymore: > http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html > https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-4911) Fix tests #1
[ https://issues.apache.org/jira/browse/IGNITE-4911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev resolved IGNITE-4911. - Resolution: Won't Fix > Fix tests #1 > > > Key: IGNITE-4911 > URL: https://issues.apache.org/jira/browse/IGNITE-4911 > Project: Ignite > Issue Type: Bug > Components: cache, general >Reporter: Dmitry Karachentsev >Assignee: Dmitry Karachentsev > > Test that constantly failing: > IgniteServiceDynamicCachesSelfTest.testDeployCalledAfterCacheStart > IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart > IgniteCachePeekModesAbstractTest.testNonLocalPartitionSize > GridCacheDeploymentOffHeapValuesSelfTest.testDeployment > GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest.testPutAndRemove > TcpDiscoveryNodeAttributesUpdateOnReconnectTest.testReconnect -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6671) [Web Console] Wrong java type used in generated config from DB schema
Dmitry Karachentsev created IGNITE-6671:
---
Summary: [Web Console] Wrong java type used in generated config
from DB schema
Key: IGNITE-6671
URL: https://issues.apache.org/jira/browse/IGNITE-6671
Project: Ignite
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Affects Versions: 2.2
Reporter: Dmitry Karachentsev
Fix For: 2.3
We should be confident that java types in generated config are able to fit in
values from DB. For example, WC generates short for Oracle's NUMBER(5), when
short could be max 32767, but NUMBER(5) - 9.
That may produce errors like below during DB import:
{noformat}
Exception in thread "main" javax.cache.integration.CacheLoaderException:
Failed to load cache: test
at
org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore.loadCache(CacheAbstractJdbcStore.java:798)
at
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadCache(GridCacheStoreManagerAdapter.java:502)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.localLoadCache(GridDhtCacheAdapter.java:486)
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.localLoadCache(GridCacheProxyImpl.java:217)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$LoadCacheJob.localExecute(GridCacheAdapter.java:5439)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$LoadCacheJobV2.localExecute(GridCacheAdapter.java:5488)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$TopologyVersionAwareJob.execute(GridCacheAdapter.java:6103)
at
org.apache.ignite.compute.ComputeJobAdapter.call(ComputeJobAdapter.java:132)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1842)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6621)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1114)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1257)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:885)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$2100(GridIoManager.java:114)
at
org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:802)
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: javax.cache.CacheException: Failed to read binary object:
org.apache.TestModel
at
org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStore.buildBinaryObject(CacheJdbcPojoStore.java:255)
at
org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStore.buildObject(CacheJdbcPojoStore.java:136)
at
org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore$1.call(CacheAbstractJdbcStore.java:463)
at
org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore$1.call(CacheAbstractJdbcStore.java:430)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
... 3 more
Caused by: java.sql.SQLException: Numeric Overflow
at
oracle.jdbc.driver.NumberCommonAccessor.throwOverflow(NumberCommonAccessor.java:4170)
at
oracle.jdbc.driver.NumberCommonAccessor.getShort(NumberCommonAccessor.java:311)
at
oracle.jdbc.driver.GeneratedStatement.getShort(GeneratedStatement.java:305)
at
oracle.jdbc.driver.GeneratedScrollableResultSet.getShort(GeneratedScrollableResultSet.java:879)
at
org.apache.ignite.cache.store.jdbc.JdbcTypesDefaultTransformer.getColumnValue(JdbcTypesDefaultTransformer.java:84)
at
org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStore.buildBinaryObject(CacheJdbcPojoStore.java:247)
... 7 more
{noformat}
*This should be checked for all supported databases.*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5103) TcpDiscoverySpi ignores maxMissedClientHeartbeats property
[
https://issues.apache.org/jira/browse/IGNITE-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev updated IGNITE-5103:
Fix Version/s: (was: 2.3)
2.4
> TcpDiscoverySpi ignores maxMissedClientHeartbeats property
> --
>
> Key: IGNITE-5103
> URL: https://issues.apache.org/jira/browse/IGNITE-5103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 2.4
>
> Attachments: TcpDiscoveryClientSuspensionSelfTest.java
>
>
> Test scenario is the following:
> * Start one or more servers.
> * Start a client node.
> * Suspend client process using {{-SIGSTOP}} signal.
> * Wait for {{maxMissedClientHeartbeats*heartbeatFrequency}}.
> * Client node is expected to be removed from topology, but server nodes don't
> do that.
> Attached is the unit test reproducing the same by stopping the heartbeat
> sender thread on the client.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6487) During exchange affinity may return more backups than set
[ https://issues.apache.org/jira/browse/IGNITE-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-6487: Summary: During exchange affinity may return more backups than set (was: Affinity may return more backups than set during exchange) > During exchange affinity may return more backups than set > -- > > Key: IGNITE-6487 > URL: https://issues.apache.org/jira/browse/IGNITE-6487 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.1 >Reporter: Dmitry Karachentsev > Attachments: GridCacheRebalanceBackupsTest.java > > > Reproducer is in attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6487) Affinity may return more backups than set during exchange
[ https://issues.apache.org/jira/browse/IGNITE-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-6487: Summary: Affinity may return more backups than set during exchange (was: Affinity may return more backups that set during exchange) > Affinity may return more backups than set during exchange > - > > Key: IGNITE-6487 > URL: https://issues.apache.org/jira/browse/IGNITE-6487 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.1 >Reporter: Dmitry Karachentsev > Attachments: GridCacheRebalanceBackupsTest.java > > > Reproducer is in attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6487) Affinity may return more backups that set during exchange
[ https://issues.apache.org/jira/browse/IGNITE-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-6487: Attachment: GridCacheRebalanceBackupsTest.java > Affinity may return more backups that set during exchange > - > > Key: IGNITE-6487 > URL: https://issues.apache.org/jira/browse/IGNITE-6487 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.1 >Reporter: Dmitry Karachentsev > Attachments: GridCacheRebalanceBackupsTest.java > > > Reproducer is in attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6487) Affinity may return more backups that set during exchange
Dmitry Karachentsev created IGNITE-6487: --- Summary: Affinity may return more backups that set during exchange Key: IGNITE-6487 URL: https://issues.apache.org/jira/browse/IGNITE-6487 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.1 Reporter: Dmitry Karachentsev Reproducer is in attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5767) Web console: use byte array type instead of java.lang.Object for binary JDBC types
[
https://issues.apache.org/jira/browse/IGNITE-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175485#comment-16175485
]
Dmitry Karachentsev commented on IGNITE-5767:
-
Must be used `[B` type, not `byte[]`.
> Web console: use byte array type instead of java.lang.Object for binary JDBC
> types
> --
>
> Key: IGNITE-5767
> URL: https://issues.apache.org/jira/browse/IGNITE-5767
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Denis Kholodov
>Assignee: Andrey Novikov
> Fix For: 2.3
>
>
> Schema importer should use {{[B}} query entity field type instead of
> {{java.lang.Object}} for the following SQL types: {{BINARY}}, {{VARBINARY}}
> and {{LONGVARBINARY}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6431) Web Console: "Partition loss policy" field is duplicated
[ https://issues.apache.org/jira/browse/IGNITE-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-6431: Description: See attached screenshot. !web_console_part_loss.png|thumbnail! was:!web_console_part_loss.png|thumbnail! > Web Console: "Partition loss policy" field is duplicated > > > Key: IGNITE-6431 > URL: https://issues.apache.org/jira/browse/IGNITE-6431 > Project: Ignite > Issue Type: Bug > Components: UI >Affects Versions: 2.1 >Reporter: Dmitry Karachentsev >Assignee: Vasiliy Sisko > Attachments: web_console_part_loss.png > > > See attached screenshot. > !web_console_part_loss.png|thumbnail! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
