[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840672#comment-16840672
]
Ignite TC Bot commented on IGNITE-11837:
{panel:title=--> Run :: Basic Tests: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3846699]]
* IgniteBasicTestSuite: BPlusTreeReuseSelfTest.testMassiveRemove2_true - 0,0%
fails in last 182 master runs.
{panel}
[TeamCity *--> Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3846707&buildTypeId=IgniteTests24Java8_RunBasicTests]
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11821) Deprecate rebalance properties at CacheConfiguration and move them to IgniteConfiguration level
[
https://issues.apache.org/jira/browse/IGNITE-11821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-11821:
-
Reviewer: Anton Vinogradov
> Deprecate rebalance properties at CacheConfiguration and move them to
> IgniteConfiguration level
> ---
>
> Key: IGNITE-11821
> URL: https://issues.apache.org/jira/browse/IGNITE-11821
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-16, rebalance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The set of cluster rebalancing properties below must be maintained and
> provided by {{IgniteConfiguration}}, so an administrator will be able to tune
> the cluster rebalance behaviour depending on used hardware (e.g. the
> different hardware can have different maximum transmission unit (MTU) and
> it's strongly recommended to use specific rebalanceBatchSize for each cluster
> environment).
> Currently, there is no way to change these properties for already created
> persistent caches.
> {code:java|title=CacheConfiguration.java}
> /** Rebalance timeout. */
> private long rebalanceTimeout = DFLT_REBALANCE_TIMEOUT;
> /** Rebalance batch size. */
> private int rebalanceBatchSize = DFLT_REBALANCE_BATCH_SIZE;
> /** Rebalance batches prefetch count. */
> private long rebalanceBatchesPrefetchCnt =
> DFLT_REBALANCE_BATCHES_PREFETCH_COUNT;
> /** Time in milliseconds to wait between rebalance messages to avoid
> overloading CPU. */
> private long rebalanceThrottle = DFLT_REBALANCE_THROTTLE;
> {code}
> _*Documentation must be updated.*_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11633) Fix errors in WAL disabled archive mode documentation
[ https://issues.apache.org/jira/browse/IGNITE-11633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840591#comment-16840591 ] Garrett commented on IGNITE-11633: -- Updated the documentation. Should be set to go. > Fix errors in WAL disabled archive mode documentation > - > > Key: IGNITE-11633 > URL: https://issues.apache.org/jira/browse/IGNITE-11633 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > > In > https://apacheignite.readme.io/docs/write-ahead-log#section-disabling-wal-archiving > there is an error. The documentation says that " instead, it will overwrite > the active segments in a cyclical order". In fact, when walWork == > walArchive, the whole folder behaves as a sequential log, where new files are > sequentially created (0, 1, 2, 3, ...) and old files are eventually > truncated. Also, need to clarify the wal size setting in this mode. > Ask [~dpavlov] and [~akalashnikov] for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11788) Fix issues related to IGNITE-10896
[
https://issues.apache.org/jira/browse/IGNITE-11788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840586#comment-16840586
]
Eduard Shangareev commented on IGNITE-11788:
Looks good! Thank you for contribution.
> Fix issues related to IGNITE-10896
> --
>
> Key: IGNITE-11788
> URL: https://issues.apache.org/jira/browse/IGNITE-11788
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Both following cases related to executing commands in control.sh
> 1. New boolean field *succeeded* {color:#33}in
> {color}*org.apache.ignite.internal.processors.cache.verify.**IdleVerifyResultV2*
> is not serialized. It may affect the case when there are no caches matching
> idle_verify command filters: possibly user can get odd output message.
> 2. Cache name parsing now assumes that cache names can be given as regexps -
> it may affect the case when cache name contains regexp special characters:
> user can get error message about incorrect regular expression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11432) Add ability to specify auto-generated consistent ID in IgniteConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11432:
Reviewer: Alexey Goncharuk
> Add ability to specify auto-generated consistent ID in IgniteConfiguration
> --
>
> Key: IGNITE-11432
> URL: https://issues.apache.org/jira/browse/IGNITE-11432
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Let's consider the following scenario:
> 1) A user starts an empty node, the node generates a consistent ID as UUID
> and creates a persistence folder {{node00-UUID}}
> 2) If a user cleans up the persistence directory, the node will generate
> another consistent ID.
> Now, the user has no option to specify the old consistent ID in
> configuration: if we set the conistent ID to the UUD, the persistece folder
> will be named {{UUID}}. If the user specifies {{node00-UUID}}, the folder
> will be named properly, but the actual consistent ID will be {{node00-UUID}}.
> We need to add an option to specify the proper consistent ID.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840526#comment-16840526
]
Pavel Kuznetsov commented on IGNITE-11837:
--
[~nick_di] Sure. If you have any questions - join us on the user list:
https://ignite.apache.org/community/resources.html#mail-lists
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10619) Add support files transmission between nodes over connection via CommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10619:
-
Description:
Partition preloader must support cache partition file relocation from one
cluster node to another (the zero copy algorithm [1] assume to be used by
default). To achieve this, the file transfer machinery must be implemented at
Apache Ignite over Communication SPI.
_CommunicationSpi_
Ignite's Comminication SPI must support to:
* establishing channel connections to the remote node to an arbitrary topic
(GridTopic) with predefined processing policy;
* listening incoming channel creation events and registering connection
handlers on the particular node;
* an arbitrary set of channel parameters on connection handshake;
_FileTransmitProcessor_
The file transmission manager must support to:
* using different approaches of incoming data handling – buffered and direct
(zero-copy approach of FileChannel#transferTo);
* transferring data by chunks of predefined size with saving intermediate
results;
* re-establishing connection if an error occurs and continue file
upload\download;
* limiting connection bandwidth (upload and download) at runtime;
was:
To benefit from zero copy we must delegate the file transferring to
FileChannel#transferTo(long, long, java.nio.channels.WritableByteChannel)
because the fast path of transferTo method is only executed if the destination
buffer inherits from an internal JDK class.
The {{CommunicationSpi}} needs to support pipe connections between two nodes;
* The WritableByteChannel needs to be accessed on the supplier side;
* The ReadableByteChannel needs to be read on the demander side;
* The CommunicationListener must be extended to respond on new incoming pipe
connections;
> Add support files transmission between nodes over connection via
> CommunicationSpi
> -
>
> Key: IGNITE-10619
> URL: https://issues.apache.org/jira/browse/IGNITE-10619
> Project: Ignite
> Issue Type: Sub-task
> Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-28
>
> Partition preloader must support cache partition file relocation from one
> cluster node to another (the zero copy algorithm [1] assume to be used by
> default). To achieve this, the file transfer machinery must be implemented at
> Apache Ignite over Communication SPI.
> _CommunicationSpi_
> Ignite's Comminication SPI must support to:
> * establishing channel connections to the remote node to an arbitrary topic
> (GridTopic) with predefined processing policy;
> * listening incoming channel creation events and registering connection
> handlers on the particular node;
> * an arbitrary set of channel parameters on connection handshake;
> _FileTransmitProcessor_
> The file transmission manager must support to:
> * using different approaches of incoming data handling – buffered and direct
> (zero-copy approach of FileChannel#transferTo);
> * transferring data by chunks of predefined size with saving intermediate
> results;
> * re-establishing connection if an error occurs and continue file
> upload\download;
> * limiting connection bandwidth (upload and download) at runtime;
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11051) Implement partition upload process as new part of GridCachePreloader
[ https://issues.apache.org/jira/browse/IGNITE-11051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11051: - Labels: (was: iep-28) > Implement partition upload process as new part of GridCachePreloader > > > Key: IGNITE-11051 > URL: https://issues.apache.org/jira/browse/IGNITE-11051 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: None > > > *Preloader* > A new implementation of cache entries preloader assume to be done. The new > implementation must send and receive cache partition files over the > CommunicationSpi channels by chunks of data with validation received items. > The new layer over the cache partition file must support direct using of > FileChannel#transferTo method over the CommunicationSpi pipe connection; > # The process manager must support transferring the cache partition file by > chunks of predefined size (multiply to the page size) one by one; > # The connection bandwidth of the cache partition file transfer must have the > ability to be limited at runtime; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840481#comment-16840481
]
Nikola Arnaudov commented on IGNITE-11837:
--
Thanks a lot! [~pkouznet]
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11410) Security Engine fixes and test coverage. Phase #2.
[ https://issues.apache.org/jira/browse/IGNITE-11410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-11410: -- Security: (was: Private) > Security Engine fixes and test coverage. Phase #2. > -- > > Key: IGNITE-11410 > URL: https://issues.apache.org/jira/browse/IGNITE-11410 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > TBD -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11837) Thin client fails to connect to the cluster if one node is down
[
https://issues.apache.org/jira/browse/IGNITE-11837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840426#comment-16840426
]
Pavel Kuznetsov commented on IGNITE-11837:
--
[~nick_di]
>Does the client reconnect to another node if the node which is connected
>initially goes down?
I've asked author: Yes it does. If initial node went down, client reconnects to
other node on the next request (any Client's api call).
> Thin client fails to connect to the cluster if one node is down
> ---
>
> Key: IGNITE-11837
> URL: https://issues.apache.org/jira/browse/IGNITE-11837
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Nikola Arnaudov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: javadoc
>
> According to java doc:
> in org.apache.ignite.Ignition
> {code:java}
> /**
> * Initializes new instance of \{@link IgniteClient}.
> *
> * Server connection will be lazily initialized when first required.
> *
> * @param cfg Thin client configuration.
> * @return Successfully opened thin client connection.
> */
> public static IgniteClient startClient(ClientConfiguration cfg)
> {code}
> but that seems wrong as I get exception:
> {code}
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Ignite cluster is
> unavailable
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:114)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.lambda$new$0(TcpIgniteClient.java:79)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.(ReliableChannel.java:84)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:86)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:205)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.createSocket(TcpClientChannel.java:216)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:108)at
> org.apache.ignite.Ignition.startClient(Ignition.java:586)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10760) Confusing message about system worker blocking
[
https://issues.apache.org/jira/browse/IGNITE-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rodion reassigned IGNITE-10760:
---
Assignee: Rodion
> Confusing message about system worker blocking
> ---
>
> Key: IGNITE-10760
> URL: https://issues.apache.org/jira/browse/IGNITE-10760
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Andrey Gura
>Assignee: Rodion
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> System workers blocking monitoring message can confuse because print out
> worker's name while references to this name as {{threadName}}:
> {noformat}
> [ERROR] 2018-12-18 14:58:06.811
> [tcp-disco-msg-worker-#2%hermesCacheInstance%] G - Blocked system-critical
> thread has been detected. This can lead to cluster-wide undefined behaviour
> [threadName=partition-exchanger, blockedFor=5s]
> {noformat}
> It should be fixed in the following manner:
> - print out {{GridWorker.runner().getName()}} for {{threadName}}
> - add {{workerName}} field to the message that should contain
> {{GridWorker.name()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11821) Deprecate rebalance properties at CacheConfiguration and move them to IgniteConfiguration level
[
https://issues.apache.org/jira/browse/IGNITE-11821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840213#comment-16840213
]
Ignite TC Bot commented on IGNITE-11821:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3838961&buildTypeId=IgniteTests24Java8_RunAll]
> Deprecate rebalance properties at CacheConfiguration and move them to
> IgniteConfiguration level
> ---
>
> Key: IGNITE-11821
> URL: https://issues.apache.org/jira/browse/IGNITE-11821
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-16, rebalance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The set of cluster rebalancing properties below must be maintained and
> provided by {{IgniteConfiguration}}, so an administrator will be able to tune
> the cluster rebalance behaviour depending on used hardware (e.g. the
> different hardware can have different maximum transmission unit (MTU) and
> it's strongly recommended to use specific rebalanceBatchSize for each cluster
> environment).
> Currently, there is no way to change these properties for already created
> persistent caches.
> {code:java|title=CacheConfiguration.java}
> /** Rebalance timeout. */
> private long rebalanceTimeout = DFLT_REBALANCE_TIMEOUT;
> /** Rebalance batch size. */
> private int rebalanceBatchSize = DFLT_REBALANCE_BATCH_SIZE;
> /** Rebalance batches prefetch count. */
> private long rebalanceBatchesPrefetchCnt =
> DFLT_REBALANCE_BATCHES_PREFETCH_COUNT;
> /** Time in milliseconds to wait between rebalance messages to avoid
> overloading CPU. */
> private long rebalanceThrottle = DFLT_REBALANCE_THROTTLE;
> {code}
> _*Documentation must be updated.*_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11821) Deprecate rebalance properties at CacheConfiguration and move them to IgniteConfiguration level
[
https://issues.apache.org/jira/browse/IGNITE-11821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840215#comment-16840215
]
Maxim Muzafarov commented on IGNITE-11821:
--
[~avinogradov],
Changes are ready, can you take a look?
> Deprecate rebalance properties at CacheConfiguration and move them to
> IgniteConfiguration level
> ---
>
> Key: IGNITE-11821
> URL: https://issues.apache.org/jira/browse/IGNITE-11821
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-16, rebalance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The set of cluster rebalancing properties below must be maintained and
> provided by {{IgniteConfiguration}}, so an administrator will be able to tune
> the cluster rebalance behaviour depending on used hardware (e.g. the
> different hardware can have different maximum transmission unit (MTU) and
> it's strongly recommended to use specific rebalanceBatchSize for each cluster
> environment).
> Currently, there is no way to change these properties for already created
> persistent caches.
> {code:java|title=CacheConfiguration.java}
> /** Rebalance timeout. */
> private long rebalanceTimeout = DFLT_REBALANCE_TIMEOUT;
> /** Rebalance batch size. */
> private int rebalanceBatchSize = DFLT_REBALANCE_BATCH_SIZE;
> /** Rebalance batches prefetch count. */
> private long rebalanceBatchesPrefetchCnt =
> DFLT_REBALANCE_BATCHES_PREFETCH_COUNT;
> /** Time in milliseconds to wait between rebalance messages to avoid
> overloading CPU. */
> private long rebalanceThrottle = DFLT_REBALANCE_THROTTLE;
> {code}
> _*Documentation must be updated.*_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
